code-review

Code Review (Adversarial + Receiving)

Reference Files

Read only what's needed:

• references/review-order-and-checkpoints.md — review order, checkpoint discipline; load when starting a review that spans multiple files or needs a checkpointed pass
• references/code-review-heuristics.md — heuristics, pattern recognition, false-positive prevention; load when the diff is non-trivial or before reporting zero findings (Zero-Finding Halt re-scan)
• references/security-review-checklist.md — security review checklist; load whenever the diff touches auth, input handling, network, secrets, or data access

---

Run ADVERSARIAL when producing findings on a diff; run RECEIVING when acting on findings someone else produced. The Code Smells catalog, AI-Generated Anti-Patterns, Metric Honesty Rule, and Deferred Findings handling below apply in both modes.

Mode: ADVERSARIAL REVIEW

Only report issues with confidence ≥80 — below that, a finding is more likely noise than signal, and noise burns the fix loop's time and trust. Do not inflate a score to smuggle a hunch through; a genuine security hunch goes to the Summary as an open question (see the Security exception under Confidence Scoring). Every finding states category, impact, and why it matters. Present a recommendation, not a menu. Be opinionated.

Signal quality rule: One finding with file:line evidence and a fix is worth more than ten generic observations. Never report a pattern without showing where it lives.

Two-Stage Review

Stage 1: Spec Compliance — Does the code do what the plan/spec asked? Check: phase exit criteria met, interfaces match plan's Consumes/Produces, no scope drift, no missing scenarios.

Stage 2: Code Quality — Is the code well-built? Check: correctness, performance, security, clarity, test coverage.

One-fact rule: On a consequential change, find the one fact the change is safe because of — a caller invariant, a lifecycle assumption, a data-shape contract at a boundary — and spend the review proving that fact instead of enumerating maybes. The fact is usually one a breakage grep will not surface. If you cannot prove it, the change is unreviewed; the maybes you listed do not change that.