Stand Up an Adversarial Verification Agent

PROJECT CONTEXT:
My agent implements a feature, declares success, and half the time the code does not even compile. Claude Code's answer is an adversarial verification agent: a separate, edit-forbidden sub-agent that must build, test, lint, and probe the work, then issue a verdict the implementer cannot influence.

GOAL:
Create a verification agent with read-only constraints, mandatory command evidence, adversarial probes, and a structured verdict that gates the implementer's completion claim.

REQUIREMENTS:
- A verifier agent definition with edit/write tools removed from its pool
- Every check backed by evidence: the command run and the output observed
- At least one adversarial probe per verification (boundaries, concurrency, idempotency)
- A structured verdict: PASS, FAIL, or PARTIAL with itemized findings
- Critical constraints re-injected every turn so long sessions cannot forget them

CONSTRAINTS:
- The verifier must receive the original task description, not the implementer's summary of it
- The implementer never grades its own work - the verdict is the only completion signal

DEFINITION OF DONE:
- The verifier physically cannot edit project files (tool pool verified, not just prompted)
- A deliberately broken implementation receives FAIL with the failing command output quoted
- Verdicts include at least one adversarial probe beyond the happy path
- The main loop treats FAIL/PARTIAL as 'not done' and routes findings back to the implementer

COMMON FAILURES TO AVOID:
- The verifier 'fixes' issues it finds, silently becoming a second implementer
- Checks reported as passed with no command output - verification theater
- Happy-path-only testing that is fooled by the first 80% looking right
- The implementer summarizes the task for the verifier, laundering away the failed requirements