Blast radius before fixing

This is a speed discipline, not a caution discipline.

Skip it and defects surface serially — one per fix, one deploy each. I once burned four deploy cycles on what was one class of problem, because each fix revealed the next.

Five questions, before touching code

1. Is the diagnosis direct measurement, or inference?

An inferred mechanism is a hypothesis until something measures it directly. I shipped a repair on top of an inferred cause twice; both inferences were wrong.

If the answer is "inference," the correct next step is usually instrumentation, not a fix.

2. Who else uses this predicate or constant?

Grep for the constant's value, the function name, and the concept — all three. Constants get copied; concepts get reimplemented under different names.

Where you find the same concept in several places, the fix is usually to collapse them into one definition, not to patch each. But check first whether they're the same concept or just the same number: two thresholds that happen to both be 0.55 may be unrelated, and merging them creates a coupling that will break later in a way nobody can trace.

Widening a shared predicate is especially dangerous in reverse: if eight guards read one regex, narrowing it blinds all eight, and none of them will fail loudly.

3. Where is the thing I'm adding actually read?

Adding a field, counter, or flag that nothing consumes is an unfinished change that looks finished. It will pass review. It will sit there for weeks.

Before you write it: name the read path. If there isn't one, the read path is part of this change.

The same applies to running code: a stage that executes every cycle and writes to a key with zero consumers is pure cost. Grep for consumers of anything you're extending.

4. What does the act of deploying cost?

On a system with scheduled work, a deploy can kill an in-flight cycle. That makes even a pure-observation change cost real throughput.

Know your deploy cost before you decide "this is small enough to ship alone." Batch independent changes that don't interact.

5. How do I undo it, and what will I see?

Write both down before shipping:

• Rollback — the specific command or revert. One line if possible.
• Expected signals — what changes if it worked.
• Signals that must NOT change — this is the half everyone skips. Without it, you can't distinguish "worked" from "worked and broke something adjacent."
• What silent failure looks like — if it doesn't take effect, what do you see? If the answer is "the same as success," you have no verification.

The trap: "pure measurement" changes

A commit labeled pure measurement changed behavior — a newly added elif branch sealed off a recovery path that had previously been reached by fallthrough.

Verify purity, don't assert it. Add a test that asserts the observable behavior is byte-identical with the new code path present. Labels are not evidence.

Related

• verify-before-judging — before this, confirm the problem is real
• root-cause-discipline — before this, confirm you're fixing the generator
• ratchet-not-ceiling — after this, make the class impossible to reintroduce