correctness-reviewlisted

# Adversarial Correctness Review Run **one** adversarial correctness review over a diff and route every surviving finding to a fix or a durable record. The pipeline is FIND → SCORE → THRESHOLD → classify → fix-loop, backed by `./correctness-reviewer-prompt.md` (high-recall finder) and `./correctness-scorer-prompt.md` (cheap-model scorer). **Two entry points, one pipeline:** - **Standalone** — `/correctness-review` on any diff, ad-hoc, outside the workflow gates. Use it on a branch before a PR, on uncommitted work, or on any range you name. - **In-flow** — `subagent-driven-development` calls this as its always-on final pass after all tasks pass their spec + quality reviews, before `finishing-a-development-branch`. **Why this stage exists.** Per-task spec and quality reviewers are anchored to the plan as the oracle — spec review asks *"does it match the spec?"*, quality review asks *"is it clean?"*. Neither asks *"even if the spec is right, does this code fail at runtime?"*. A bug that faithfully implements a flawed spec passes both. This is the gap that lets real bugs survive to production and get caught by external reviewers post-push. ## When to Use - Before opening a PR or merging a branch — a final bug hunt over the whole change. - After any implementation, when you want correctness coverage decoupled from the full workflow. - Automatically, as the final gate inside `subagent-driven-development` (no manual call needed). Not for style, naming, or maintainability