check-impactlisted

# Blast radius Before a change lands, find what it breaks outside its diff and prove the fact its safety rests on by running the real code. The enemy is the caller list plus "looks safe": a writeup that reads well, was never executed, and is trusted because CI is green. The overcorrection is a long list of maybes nobody weighed, or a proof harness for an edit whose effect stays inside one function. ## When to use - A diff about to merge or ship whose effect can reach code, data or processes it does not touch: a renamed field, a new side effect, a changed return or timing. - A request asking what a change could break, or a diff the user does not trust. - A brief, plan or request asserting that existing code already handles something or that nothing depends on something, before a design builds on it. - Not for a failure already observed: `find-cause` owns it. - Not for how or why code works with no decision riding on it: `explain-code` owns it. - Not for checking a finished plan branch against its plan: the review-branch agents `run-plan` dispatches own it. - Not for choosing what to restructure (`audit-architecture`) or pinning a named refactor's behavior (`refactor`). ## The loop 1. **State what now behaves differently.** Include what the diff does not spell out: what the functions it newly calls do, the shape it now writes, the order or timing it moves. 2. **Name the one fact it is safe because of.** One sentence, such as "prune only drops entries every reader already t