Exercise 2: Why "Mitigate First" Isn't a Blanket Rule — Possible Solution
====================================================================

THE DATA-WRITE RESTART EXAMPLE
------------------------------
Per this chapter's warn-box, "restarting a service mid-way through a
critical data write can cause real data corruption - a genuinely
worse outcome than simply losing some diagnostic evidence." Killing a
process while it's actively writing data can leave that data in a
half-written, inconsistent state - a new and worse problem, not simply
a continuation of the original incident.

WHY THIS SHOWS MITIGATION CAN ACTIVELY MAKE THINGS WORSE
------------------------------
The chapter's general advice favors mitigating quickly to reduce user
pain. This example shows a specific case where the mitigating action
itself introduces a new, distinct harm (data corruption) that is worse
than the cost of a brief delay - meaning "restore service as fast as
possible, always" isn't a safe rule to follow mechanically in every
situation.

WHAT THIS CHAPTER RECOMMENDS INSTEAD
------------------------------
Per this chapter, "a few seconds spent asking 'could this specific
mitigating action itself cause additional harm?' is worth it even
under real time pressure." Rather than abandoning the general
preference for fast mitigation, the chapter recommends a brief,
deliberate sanity check on the specific action being considered - a
small pause for judgment, not a full investigation, before executing a
mitigation that could plausibly cause its own harm.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the specific risk in the data-write example, why it proves
"mitigate first" can't be applied unconditionally, and states the
chapter's own recommended safeguard (a brief harm-check) rather than
either extreme of "always mitigate immediately" or "always investigate
fully first."