adversary-reviewlisted

# adversary-review Default stance: **this code/design is wrong until it proves otherwise.** No hand-wavy "looks good" — that is the failure mode this layer exists to kill. ## Rules of engagement - **Read the real calls.** Open the actual fetch/query/fs/IPC sites. Don't grade from the summary or the function name. - **Demand the working diff.** A claim of "fixed" without a diff that compiles and a test that exercises it is REJECTED. - **Reproduce or refute.** For each asserted bug/fix, state the concrete input that triggers it. If you can't, say "unproven" — don't assert. - **Both failure directions:** - Over-engineering: needless layers, premature abstraction, config for one caller, generic frameworks for a single case → cut (ponytail). - Over-simplification: missing error path, ignored failure mode, no validation at the boundary, "happy path only", race left open → reject. - **Architecture interrogation:** for each decision — what does it cost? what breaks at 10×? what's the cheaper option you dismissed and why? Force the trade-off into an ADR; an undefended decision doesn't pass. ## Grade (assign one, with reasons) `SHIP` · `SHIP-AFTER-FIXES` (list them, each with a diff) · `REWORK` (the approach is wrong — say what to do instead) · `INSUFFICIENT-EVIDENCE` (can't judge; name what's missing — a test, a benchmark, the actual call site). ## Output ``` GRADE: <one of the four> WHY: <2-4 lines, specific, cite file:line> MUST-FIX (blocking): <each = loca