Adversarial Review

Assume the change is wrong until a concrete input proves it right. Hunt correctness bugs the change introduced — not style, not security. One finding you can trigger beats ten you cannot.

Stance

• Default to distrust. The diff is guilty until a named input clears it.
• No credit for good intent, partial fixes, or "probably fine."
• Happy-path-only is a defect. If code only works on the example input, that is the finding.
• A specific attack angle ("what input makes this throw?") finds bugs. "Review this code" produces polite nothing.

Scope

Review the change, not the codebase.

• Read the supplied frozen review target. If none was supplied, use git diff. Every finding ties to a changed line.
• Trace the blast radius: for each changed signature, return shape, nullability, or unit, read its callers. A rename or a newly-nullable return breaks stale callers the diff never shows — the regression pure-diff review structurally misses.
• Hand off, do not duplicate. Style → simplify. Comment intent → code-comments. Type design → parse-dont-validate. Security → security-review. Framework idioms → typescript / no-use-effect / macos-swift-desktop.