adversarial-review

name	adversarial-review
description	The pre-merge review playbook — reproduce, don't adopt. Use for any branch review; defines the minimum attack set, the verdict format, and the honesty requirements for what was and wasn't reproduced.

Adversarial review playbook

Your job is to try to make the change fail, not to confirm it works. The author's report is a list of claims; reproduce every claim you rely on.

Minimum attack set

1. Merge reality. Fetch, then merge-tree against the LIVE tip (it moves during long reviews — re-check before verdict). Check file overlap with recent history for semantic conflicts, not just textual ones.
2. Fresh-binary gates. Delete the test executables, rebuild, confirm exit code AND new mtimes, then run the suites yourself. Beware false greens: a test runner whose filter matches nothing can exit 0 — verify the suite ran by its test counts.
3. Red-green. Reproduce the red state for new tests (revert the change, keep the tests, observe the failure). A test that was never red is a claim, not a proof. Check for tautologies — a control assertion that stays green in the red build.
4. Hostile inputs. Anything parsing external or untrusted bytes gets crafted-input attacks — overflowed length fields, truncation at every structural boundary, declared-size bombs, wrong-type fields — run under a watchdog. A hang is a finding, not a timeout.
5. Threading and lifetime. For concurrency changes: who owns destruction; what happens on the cancel, shutdown, and error paths; can a slot or lock leak or double-release; does any worker ever wait on work scheduled to its own pool; does anything publish state outside the lock its reader holds.
6. Stale-context sweep. Grep for comments and docs the diff falsifies. A correct fix sitting next to a contradicting comment is a future bug — require the comment fixed in the same change.
7. Excuse verification. When the author skipped something ("no test target exists", "not reproducible"), verify the excuse against the build system or the repro before accepting it.
8. Deletions review. Every removed line justified; no dead code left behind; no defense removed without an equivalent replacement.
9. Evidence audit. Claims must be tiered verified/inferred/assumed; measurements must exist as artifacts — spot-check that cited artifacts exist and say what the report says they say.

Verdict

MERGE-READY or NOT-READY, with numbered findings tagged [BLOCKER] / [SHOULD-FIX] / [NIT], each with file:line and a minimal fix. State explicitly: what you reproduced vs reviewed statically, and what you deliberately skipped and why. If your verdict depends on something you did not reproduce, say so in the verdict line itself.