Walk the blast radius before you touch shared code

Impact analysisModel-agnosticupdated 2026-08-28sha 010e9558a358

The fix was right and it broke something three directories away that nobody thought about. That is not carelessness, it is the ordinary result of editing shared code from inside the file you happen to have open. The reach of a change is a thing you can enumerate before you make it, and the enumeration is cheap compared to the incident.

You are about to change code that other things depend on. Before you edit it, enumerate what it reaches. Read only - no changes in this pass.

WHAT I AM ABOUT TO CHANGE: {{target}}
REPO: {{repo_path}}
HOW TO RUN THINGS: {{verify_cmd}}

STEP 1 - Say exactly what you are changing.
Name the function, type, endpoint, table, config key, or file, and the specific behaviour that will be different afterwards. "Refactoring the handler" is not a target; "the return shape of parseOrder when the input is empty" is. If you cannot state the behaviour change in one sentence, you do not yet know what you are doing and should stop here.

STEP 2 - Enumerate the callers, from evidence.
Find everything that reaches this, and give file:line for each. Search rather than reason - a caller you deduced is not a caller you found. Cover all of these and say for each how you searched:
- Direct callers in this repo.
- Tests and fixtures that exercise it, including snapshots and golden files.
- Scheduled jobs, CLI entry points, build steps, and CI workflow steps.
- HTTP routes, event handlers, queue consumers, and webhooks that land here.
- Config, feature flags, and environment values that change its behaviour.
- Anything that reaches it dynamically: reflection, string-built names, dependency injection, a registry, a handler name stored in a database. These will not appear in a symbol search. Say what you did to look for them, and if you could not look, say that - it is the most important sentence in this step.
- Consumers OUTSIDE this repo: other services, published packages, documented API responses, saved queries. You usually cannot enumerate these. Name the ones you know of and state plainly that the list is incomplete.

STEP 3 - Classify each one.
For every caller: does the change break it, alter its behaviour without breaking it, or leave it untouched? One line each, with the reason. "Probably fine" is not a classification - either you can say why, or it goes in the third list below.

Produce three lists:
- BREAKS: must be changed in the same commit.
- BEHAVIOUR CHANGES: still compiles, does something different. This list is where the incidents come from.
- CANNOT DETERMINE: you found it but cannot tell without running it. Say what you would run.

STEP 4 - State the blast radius in one paragraph.
If this change is wrong, what is the worst thing a user notices, and how would anyone find out? Name the signal - a failing test, an alert, a support ticket, or nothing at all. "Nothing at all" is the answer that should stop the change and send you to write a test first.

STEP 5 - Say what the fan-in means.
Give the count. If it is large enough that the enumeration above is unreliable, say so and recommend the alternative: add alongside and migrate, rather than change in place. Do not grind through a hundred call sites because the contract asked you to enumerate them.

RULES.
- Every caller is labelled FOUND (searched, path shown, command stated) or INFERRED (reasoned about). Never present the second as the first.
- Do not fix anything in this pass. The output is the map. A change made while mapping is a change nobody scoped.
- An empty BREAKS list is a claim. If you found nothing that breaks, say what you searched and name the one caller you were least sure about.

END WITH: total callers found, the count in each of the three lists, the worst realistic outcome, and whether you would make this change in place or alongside.

Fill in: target repo_path verify_cmd

Shared as is, for reference. Read it and decide what it will do before you run it; using it is your responsibility, under the terms.