Respond to Review

An adversarial reviewer is only as valuable as the argument you have with it. Bulk-accepting every finding turns the reviewer into your last line of defense (it will eventually miss); ignoring findings for days rots the PR. The protocol: every finding answered, in hours, with judgment.

Protocol

1. Number every finding from all review rounds. Nothing unaddressed — an unanswered finding reads as an unread one.
2. For each, choose one of three verbs:
   • Accept — fix it AND add the regression test that would have caught it. A fix without a test is the same bug with better luck.
   • Decline — with a reason grounded in the code ("the guard at L590 deliberately lets stale rows through; excluding them here would break the documented recovery path"), not in preference. Declining well is the signal you're reviewing the reviewer.
   • Defer — real, but not this PR. File the ticket in the same breath and link it.
3. Audit suggested patches before applying. Reviewer fixes carry their own bugs — check the proposed ordering, the edge the reviewer didn't consider, the interaction with code outside the diff. Finding a bug in the reviewer's fix is the protocol working, not friction.

4. Reply once per round, point by point, with verification evidence: test counts before/after, typecheck status, and the live-drive proof if behavior changed. Format:

   Addressed in <commit> — point by point:
   1. <finding> — fixed; regression test `<name>`. One deviation from the
      suggested patch: <why the suggestion had a hole, what was done instead>.
   2. <finding> — declined: <code-grounded reason>.
   3. <finding> — deferred to <ticket>: <why it's separable>.
   Verification: typecheck clean; tests X → Y, 0 failures; re-drove <flow>.

Tempo

• Answer within hours. A finding answered same-day costs one context reload; answered next week it costs a full re-review.
• If a round lands after your last commit, the PR is not done — findings outstanding at merge time must be explicit deferrals, never silence.

Non-coding operators

When the operator can't audit patches, findings are arbitrated in behavior terms instead: convert each finding into a question about observable behavior, require the fix demonstrated live (both orderings, for races), and decline only on product grounds anchored in the PRD or PRINCIPLES.md — never on "seems unlikely". The accept-with-test rule survives translation: accepted means fixed, demonstrated, and pinned by a regression test. Full protocol: docs/pm-onramp.md.

Self-check

If you have not declined a finding in recent memory, you are in relay mode — the reviewer is doing your judgment for you. If reviewers keep finding the same category (timezone edges, missing failure paths), that category belongs in your /interrogate checklist, upstream of generation.