blast-radius

Read the diff and what it now does differently, find the one fact the change is safe because of, then check where grep stops: library source, pinned versions, async timing, and downstream consumers. Prove the safety fact by running a script or test against the real code.

Focus on the single fact the change's safety depends on rather than listing every possible risk. Write a small script that imports the same library the app ships and calls the exact function you are worried about, then paste the result as proof.

Symbol search misses breakage through JSON API responses, DB columns, wire formats, other languages reading the same bytes, feature flags, and code several hops downstream. It also cannot reveal timing issues like microtasks, unmount behavior, or framework differences.

Proof is ranked from weakest to strongest: your assertion, a cited file:line, a walked-through failure case, a script or test that runs the real code and fails loudly, and reproduction in the running app. Anything below a running test should be marked unproven.

For big or wide changes, run the analysis as an arena by asking several models the same question and merging their answers. Different models catch different real bugs, which widens coverage beyond a single review pass.