code-review: findings are adversarially verified, but the fix plan never is — a fix-plan design pass measurably breaks fix→regress cascades

The gap. The workflow-backed /code-review pipeline verifies findings rigorously (finders → adversarial verifiers → synthesize), but the loop then goes straight from findings list → edits. Fixes get written under a "resolve this finding" frame — they're first drafts, and nothing reviews them until the NEXT full round harvests their defects. The findings-list output format itself invites per-finding patching even when several findings are one design defect wearing masks.

Evidence it matters. Across four consecutive multi-round review campaigns on a ~38K LOC/week project (multi-agent reviews at high/xhigh effort), convergence took 12, 9, 8, and 5+ rounds, with the same signature every time: round N's correctness findings dominated by defects introduced by round N−1's fixes (in one campaign, a round-7 fix directly caused the round-8 regression). Concrete cascade shapes: a guard added to one worker path but not its sibling; behavior relocated with a side effect dropped on one exit path; a new seam whose cancel-window matrix was never enumerated.

The intervention. We restored a stage our older custom review pipeline had and the workflow loop dropped: a fix-plan sanity pass between triage and implementation. Input = the verified findings plus a written, numbered fix plan. Two agents judge the plan against real source — a design lens (chokepoint locality, fragility-to-next-edit, shared chokepoints where one edit lands several findings, completeness, sibling side effects, idiom) and a coverage lens (symmetry sweep across sibling sites, moved-behavior audit, concurrency seam matrix, and "tests must assert the matrix, not replay the findings"). Cost ≈ ⅕ of a full review round.

Results. On the current change set, unprimed full-surface correctness counts ran 15 → 6 → 6 → 4 → 4 — and the first round reviewing sanity-gated fixes contained zero findings manufactured by the prior round's fixes, previously the dominant category. Every sanity run pre-caught would-be next-round findings: a retry loop re-binding a stale session capture (would have re-shipped the exact bug being fixed), an unlatch-without-restore that recreated the reported symptom on an adjacent path, a machine-readable API-spec surface with no freshness gate, and a duplicated timeout constant in a sibling pane.

Ask. Consider adding a fix-plan design pass to the bundled code-review loop — as a workflow stage after findings (review the proposed remediation, not just the claims) or as apply-flow guidance (cluster findings by seam, write the plan, judge it before editing). Happy to share our workflow script and the round-by-round data.

(Drafted with Claude Code in the sessions where this loop was developed and measured.)