blast-radius.md

<!-- AUTO-GENERATED from blast-radius.md.tmpl — do not edit directly --> <!-- Regenerate: bun run gen:skill-docs --> <!-- Blast-radius discipline derived from pstack's blast-radius skill (Lauren Tan, MIT), rewritten for gstack. See NOTICE.md. -->

Blast radius

What a change breaks is rarely inside the diff. Listing the callers is not the job; a symbol search does that in a second. The job is the breakage the search cannot show, and a writeup that sounds right proves nothing either way, so the deliverable is a fact that was run, not a paragraph.

1. Read the whole change. The diff, every symbol it adds, changes or removes, and what now happens differently, including what the diff does not spell out: a default that moved, an order that changed, a call that is now skipped.
2. Name the one fact it is safe because of. Most risky-looking changes are safe for a single reason ("this path only ever sees entries that have already expired"). Write that sentence down. If it holds, most of the maybes clear at once, so spend the time here, not on a long list of them.
3. Look where grep stops. Read the source of the library you call, at the pinned version plus any local patch. Work out when things run: microtask against macrotask, unmount and teardown, an effect that fires twice. Follow what a symbol search misses: the JSON an API returns, a database column, a wire format, another language reading the same bytes, a feature flag, code three hops downstream.
4. Climb the evidence ladder for each safety fact, as far as is cheap, and say where you stopped:
5. You said so. Worth nothing on its own.
6. You pointed at it: a real file:line, or the library's own source.
7. You walked the failure step by step and it does not reach.
8. You ran it: a script or test that calls the real code and fails loud if you are wrong. Usually one small file that imports the library the app ships and calls the exact function in question.
9. You reproduced it in the running app.
10. Keep confirmed risks and cleared risks apart. A confirmed risk names how it breaks, the file:line, how likely and how costly it is, and the check that would catch it. Cleared risks go in their own list with what you checked. A search that finds nothing is still an answer; never invent a caller or an API.

Report, in this order: what the change does, including the part that is not obvious; the one safety fact, its rung, and the proof or the word "unproven"; confirmed risks; cleared risks; and the cheapest test or reproduction that would catch the real bug, including any script you wrote. Cite real code and strip anything private before the report leaves the machine. Under /ship this is the material for the PR body's ## Blast radius line.