did-we-break-it

Find what this change breaks somewhere else. A list of callers is not the job: grep gives that in a second. The job is what grep will not show. A write-up that sounds right proves nothing, so a risk counts only when a run shows it.

Change: $ARGUMENTS. If that is empty, the current branch from its merge base with the default branch, through uncommitted work.

Steps

1. Read the whole change. The diff, every name it adds, changes or deletes, and what it now does differently, including what the diff does not spell out.
2. Find the one fact it is safe because of. Most risky-looking changes are safe because of one fact, such as "nothing reads this column any more". Write that fact as one sentence.
3. Look where grep stops:
   • Names built at run time: strings, config keys, reflection, templates, routes.
   • Other readers of the same data: jobs, reports, exports, other services, the frontend.
   • Saved data: rows, caches and queued messages written in the old shape.
   • Timing: order of start-up, transactions, retries, concurrent calls.
   • The library's own source at its pinned version, not your memory of it.
4. Try to break it. For each real risk, write a script or test that runs the real code and fails loud if you are right. Run it and keep the output.
5. Prove the one fact. Take it as far down this list as is cheap, and say where it stopped:
   1. You said so: worth nothing.
   2. You pointed at the line.
   3. You walked the failure step by step and it does not reach.
   4. You ran it.
   5. You reproduced it in the running app.

For a wide change, ask a second agent the same question and give it only the diff, not your conclusions. Keep what its runs prove.

Report

Do not apply fixes.

Say "nothing broken found" when that is the result. Do not invent findings to fill the table.