respond-to-review

# Respond to review feedback Goal end-state: every finding on the PR has exactly one of four answers — a minimal fix with a test, a corrected claim in the PR description, a follow-up issue, or a written decline. The PR's diff grows as little as possible. Classification precedes code. Never start implementing a finding before classifying it. ## Phase 1 — Gather and dedupe 1. Pull every review body and inline comment on the PR. Drop reviews marked "This review has been superseded." 2. Merge duplicate findings — same file, same defect — into one item for classification. 3. Discard the bots' severity labels and verdicts. Phase 2 re-derives priority. ## Phase 2 — Classify every finding Run each finding through these tests in order. The first test that matches decides the bucket. ### Test 1 — the bot hedged If the bot itself presents the finding as optional or non-blocking — "no action required", "consider", "worth noting": **decline**. ### Test 2 — the PR already disclosed it If the finding restates a "Not in this PR" item, a stated tradeoff, or a documented transitional state: **decline**, pointing at the section that covers it. ### Test 3 — no caller can reach it Ask what concrete caller, with what concrete input, hits the defect on `main` plus this diff. If the answer needs a future adapter, a third-party implementation, an input no caller produces, or a scale nothing is wired to reach: **decline**, stating what would have to exist first. If the concern matters late...