adversarial-looplisted

# Adversarial loop Two agents with asymmetric roles and separate contexts, tests before fixes — a second vendor is one way to get that separation, not a requirement (see the tool-posture section). The building agent never grades its own work, and the adversary never merges its own opinion — the merge condition is a green gate plus an exact verdict token. This exists because diff review after the code is written cannot catch the worst class: a suite that passes without asserting anything. A reviewer reading a diff sees a plausible test. Only a test that was **watched failing on the defect** is evidence. So the adversary's first deliverable is failing tests, not comments. ## Roles - **Adversary** (a different vendor's model): audits the subject, writes acceptance tests that FAIL on current code, and reviews each fix round. It never edits the fix branch and never runs the gate. - **Builder** (this session): confirms each finding against the real code before starting, implements, runs the complete gate, and owns the evidence. It never edits the test branch. - Two branches: `<topic>/test-acceptance` (adversary's commits) and `<topic>/fix` (builder's commits, which merges the test branch in). ### Route by what each side is actually good at `[measured 2026-08-31]` over one 24-round audit of a repo's own gates. The adversary's eight opening findings were all real, all in gates the builder had written, and all in code that an 85-suite gate passed green. Every one was t