adversarial-reviewlisted

# Adversarial review — thesis → antithesis → synthesis The Socratic core of the method: **nothing ships on the first draft.** Two moments, always. ## 1. Design closed → REFUTE before asking for approval When you have finished writing a Design/plan and are about to ask the user for the OK: 1. Run the **`adversarial-critic`** agent on the design you just wrote (pass it the path of the design log, or the design text + the requirements/constraints). 2. The refuter tries to **tear it apart**: fragile assumptions, scenarios where it fails, what is taken for granted, what is missing. It doesn't rewrite — it attacks. 3. **Incorporate** the critique into the design (update Q&A / Trade-offs / Open questions; fix or defend each point). Thesis (design) → antithesis (refutation) → **synthesis** (a design that holds). 4. **Only now** ask the user for approval — presenting also what the refuter raised and how you resolved it. > Applies to significant **design** decisions (that is where the decisions live). A trivial fix (<3 files, obvious) doesn't need the round. ## 2. Implementation finished → VERIFY + TEST before declaring it done When you have finished implementing and are about to say "done" (or before moving it to DONE — ties into R.16): 1. Run the **`verifier`** agent: it checks that what was implemented **really meets the requirements/design**, point by point — not "it compiles = it works". 2. Run the **`tester`** agent: it designs and runs **test scenarios** (including the e