blast-radius

Blast radius

Contract

Inputs

A diff, branch, or set of changed files to analyze. The change must be readable from the working tree or a supplied patch. Optional: the running application for in-app reproduction.

Procedure

1. Read the change completely: the diff, the symbols it adds, changes, and deletes, and what it now does differently, including behavior the diff does not spell out. Done when: the full change is understood beyond the diff surface.
2. Find the single fact the change's safety depends on. Most changes that look dangerous are safe because of one fact, for example, "this call only drops already-dead cache entries and does nothing else." If that fact holds, most scary cases collapse at once. Spend time here, not on a long list of maybes. Done when: the single load-bearing safety fact is identified or confirmed absent.
3. Look where a symbol search stops. Read the source of any library the change calls; check its pinned version and any local patch. Work out when things run: async task ordering, teardown and unmount, framework-specific lifecycle. Follow what a grep misses: a JSON shape an API returns, a database column, a wire format, another language reading the same bytes, a feature flag, code three hops downstream. Done when: every reachable consumer and runtime path is traced or marked unreachable with evidence.
4. For each risk, give it a real chance of happening and a real cost if it does. Cite a concrete file:line for every claim. A search that finds nothing is still an answer. Never invent a caller or an API. Done when: every risk has a file:line, likelihood, and cost.
5. Rate each safety fact on the certainty ladder and say where it stopped:
   1. Stated without evidence: worthless on its own.
   2. Pointed at the line: a real file:line or the library's own source.
   3. Walked the failure path step by step and it does not reach the bad case.
   4. Ran it: a script or test calling the real code that fails loud if the claim is wrong.
   5. Reproduced in the running application. Any safety fact that cannot reach step 4 must be stated as unproven, not written up as settled. Step 4 is usually one small script importing the same library the application ships and calling the exact function in question. Done when: every safety fact has its certainty-ladder step stated, with unproven facts marked.
6. Write and run one proof script or test that exercises the single load-bearing fact. Run it. Paste the output. If the proof cannot be produced cheaply, mark the fact unproven; do not round up. Done when: the proof script ran and its output is captured, or the fact is marked unproven.
7. Delete the proof script after capturing its output, if one was written. Done when: the script, if one was written, is deleted and no artifact remains.