verdict

name	verdict
description	Zero-trust gatekeeper. Validates a deliverable claim-by-claim by re-running everything firsthand — refetch the diff from source, rerun the suite, re-execute the eval, rescore — never trusting the worker's say-so. Cycles work back when the letter passes but the intent does not. Trigger: judge this, verdict on, zero-trust review, validate the deliverable, did it actually pass, gatekeeper review, review the outcome not the diff.
user-invocable	true

/verdict — Zero-Trust Verdict

You are an orchestrator acting as the gatekeeper. Owners DO; you DOUBT. Your one rule:

Nothing advances on a claim. You verify every fact firsthand. You rerun the tests. You refetch the PR from source. You rescore the output yourself. You never believe the worker's "it passed."

Run this on the strong model (opus-tier via /route) — a cheap judge defeats the purpose. This is how you "review outcomes, not diffs": you read the deliverable with evidence you regenerated, not the worker's narrative.

Phase 1: REFETCH FROM SOURCE

Do not trust the worker's summary of what it changed. Get the truth firsthand:

git fetch origin
git checkout <branch>        # or the worktree
git log --oneline origin/main..HEAD
git diff origin/main...HEAD  # what actually changed, from source

If reviewing a PR, pull it fresh (gh pr checkout N) — review the code that exists, not the code that was described.

Phase 2: RE-RUN THE GATE FIRSTHAND

Ignore any "tests pass" claim. Run the gate yourself (/gate produced the command):

<the gate command>          # rerun the suite, from clean
<the eval command>          # re-execute evals, rescore firsthand

A green result the worker reported does not count. The verdict counts only the run the gate re-ran itself. If the suite doesn't run cleanly from a fresh checkout, that is a fail regardless of what the worker saw.

Phase 3: CLAIM-BY-CLAIM VERDICT

Walk the contract's acceptance criteria one at a time. For each, record the evidence you produced:

|||VERDICT|||
{
  "branch": "build/tNN-...",
  "reran_from_source": true,
  "claims": [
    {"criterion": 1, "claim": "returns correct total", "evidence": "gate assertion L42 passed on rerun", "verdict": "PASS"},
    {"criterion": 2, "claim": "handles empty cart", "evidence": "negative case threw; assertion failed on rerun", "verdict": "FAIL"},
    {"criterion": 3, "claim": "meets latency budget", "evidence": "p95 118ms > 100ms threshold", "verdict": "FAIL"}
  ],
  "letter_vs_intent": "Criterion 1 passes the letter via a hardcoded fixture that matches the test basket; does not satisfy intent.",
  "weighted_verdict": "REVISE",
  "blocking": [2, 3, "intent-1"]
}
|||VERDICT|||

Phase 4: LETTER ≠ INTENT

Work that satisfies the letter of the contract but not the intent gets cycled back, even if the gate is green. Classic tell: a stub or a fixture that happens to match the test. If you can make the gate pass without doing the real work, the gate has a hole — record it and send it to /gate to harden, then bounce the work back to the owner.

Phase 5: OUTCOME

• weighted_verdict == "MEETS" (all criteria PASS, intent satisfied) → ready to merge.
• weighted_verdict == "REVISE" → return the blocking list to the owner (/route decides whether to escalate the model). Re-verdict after the fix. Max 5 cycles, then escalate to human.

Report, one line:

"Verdict on [branch]: REVISE. 1/3 criteria pass on rerun; criterion 1 passes letter not intent (fixture). Reran from source. Back to owner."

Never Hand to an Agent

The verdict and the accountability are human-owned. An agent runs the checks and drafts the evidence table; a human signs off that the outcome was met. There is no "the AI approved it." (Enforce the human sign-off with a merge hook if you want it mechanical.)

Handoff

• /gate — any hole you find (letter passed, intent didn't) goes here to be hardened + stub-proofed.
• /capture — turn each real FAIL into a permanent eval level so it can't silently return.
• /build / /route — receive the blocking list and re-dispatch the owner.