coyote/assets/agents/adversary/README.md

Adversary

An adversarial plan-conformance reviewer. Where code-reviewer asks "is this code good?", adversary asks a different, harder question:

"Is this the code the plan asked for — all of it, and only it?"

It hunts the gap between what a task/plan specified and what the implementer actually built: silently skipped acceptance criteria, scope creep, interface substitution, approach drift, and the requirements that never showed up in the diff at all ("the dog that didn't bark"). It assumes the implementer drifted until the diff proves otherwise — the independence is the value.

Why it's separate from code-reviewer

	code-reviewer	adversary
Question	Is the code correct/clean/safe?	Does the code match the plan?
Input	The diff	The diff + the plan's acceptance criteria
Blind spot it covers	slop, bugs, coupling, footguns	skipped criteria, scope drift, contract breakage
Output	severity-tagged findings (🔴🟡🟢)	a blocking verdict: CONFORMS / DIVERGES

They are complementary passes, not substitutes. sisyphus runs both on non-trivial work: one guards quality, the other guards fidelity to the plan.

Verdict (blocking)

The agent ends every review with one sentinel:

ADVERSARIAL_REVIEW: CONFORMS
Criteria: N/N met (all with tests).

ADVERSARIAL_REVIEW: DIVERGES
Criteria: X/N met, Y partial, Z unmet/diverged.
Complaints:
1. Acceptance criterion "<quoted>" — <Unmet|Partial|Diverged> — <what the diff does/omits, file:line> — <fix>
2. ...

A DIVERGES verdict blocks completion. The caller (sisyphus/architect) must reconcile it — resume the SAME coder/sisyphus session with the complaints pasted verbatim — or escalate. It mirrors the oracle + plan-review gate used before implementation, but applied after implementation.

Every complaint ties to a quoted acceptance criterion (or a named scope/interface/out-of-scope violation) and cites file:line. Vague complaints are not emitted.

How it reviews

Driven by the adversarial-review skill:

1. Map every acceptance criterion to specific evidence in the diff → ✅ Met / ⚠️ Partial / ❌ Unmet / 🔀 Diverged. No test proving the behavior ⇒ at best ⚠️ Partial.
2. Ground-truth with read-only tools (fs_grep/fs_read/ast_grep): confirm required symbols exist as specified, changes land where they must, new behavior is actually reached, tests target behavior not implementation.
3. Hunt adversarially for the absent: skipped criteria, scope creep, interface/approach substitution, out-of-scope touches, downstream contract breakage.

It is read-only — it produces a verdict, never a fix.

Usage

Typically spawned by sisyphus (or architect) alongside code-reviewer. The spawn prompt IS its entire context, so it must include the diff (or a base ref to fetch) and the acceptance criteria:

agent__spawn --agent adversary --prompt "
## TASK
Adversarially review the recent changes for TASK-NNN against its plan. Return CONFORMS/DIVERGES.

## DIFF
Run get_diff (or --base main), or: <paste diff>

## PLAN — acceptance criteria to check against
<paste the task index.md body + the relevant PLAN-*.md section, verbatim>
"

Direct invocation for ad-hoc use:

coyote -a adversary --agent-variable project_dir /path/to/repo \
  "Review staged changes against these criteria: <paste criteria>"

Tools

• get_diff [--base <ref>] — staged → unstaged → HEAD~1 fallback (or an explicit base/PR branch).
• get_changed_files [--base <ref>] — quick changed-file map.
• Plus read-only fs_* and ast_grep for ground-truth checks.

Related

• adversarial-review — the conformance methodology it runs on.
• code-reviewer — the quality reviewer it runs alongside.
• plan-review — the pre-implementation plan gate; adversary is its post-implementation counterpart.