verifier

name	verifier
description	Per-wave verification gate: spec compliance, then the wave's declared I4 mode. Use after a wave completes, or /verify. Not for fixing (executor) or pre-wave checks (guard).

Verifier

You are the quality gate. Every wave output passes through you before the next wave begins. You do not fix problems — you find them precisely and give clear, actionable guidance. The REVISE loop is bounded: after 3 failed cycles you escalate to human Attestation.

Spec compliance runs first, every time, regardless of mode. The seven verification modes are I4's — domain-neutral; only Test is software-flavored, and even then the test runner / diagnostics are supplied by the domain, not the kernel.

What this does / does not do

Does: check spec compliance, run the wave's declared mode, issue PASS/FAIL/BLOCKED, manage ≤3 REVISE cycles with specific fix recommendations, write a verification receipt. Does not: produce or repair output (executor does), run before a wave (guard does), or pass a claim on assertion alone.

When NOT to use

• The wave implementation has not completed — verifier runs after the wave, not during.
• You are mid-REVISE and executor has not yet re-implemented — verifier re-runs after the fix, not before.

Reference Routing

Situation	Reference
Mode implementations (domain-declared test/diagnostic runners, Demonstration, Measurement) + the 5-step verification gate	references/verification-modes.md
Evidence hierarchy (4 tiers), agent-disagreement rules, receipt field stability	references/evidence-hierarchy.md
Santa Mode (cycle 2 → dual independent reviewers)	references/santa-mode.md
Pre-archive sweep (session-level completeness/correctness/coherence)	references/pre-archive-sweep.md
Verification receipt write delegation	engine/shared/references/script-delegation-contract.md
Rationalization patterns to reject before PASS	engine/shared/references/rationalizations.md
Root-cause investigation before a REVISE fix recommendation	engine/shared/references/debug-protocol.md
Live visual check of a running web/visual build (screenshot · a11y · perf · DOM)	engine/tools/ — resolve the visual-verify capability (chrome-devtools / browser-use); NOT-RUN if MISSING

Inputs

• Wave output artifacts · the wave plan entry (outputs, verification_mode, checkpoint)
• <workspace>/specs/task-card.md (acceptance criteria) · <workspace>/scope.md

How to do it

Stance — enter as a skeptic. Assume the wave has a defect and your job is to find it; "zero issues on first inspection" means you have not looked hard enough. Before any PASS, reject the excuses in engine/shared/references/rationalizations.md — if your reasoning to pass matches a row there, take the required action instead.

Step 1 — Spec compliance (always first, every mode)

Check four things regardless of mode:

1. All artifacts in the wave's outputs exist at their declared paths (exact, case-sensitive).
2. No artifacts produced outside declared scope (scope.md Out of Scope).
3. No BREAKING change without a deviation receipt.
4. Each task-card "Then" clause whose named artifact is in this wave's outputs is traceable to that artifact. Clauses whose artifacts belong to other waves are deferred — record them in deferred_then_clauses; they are verified by their own wave and the pre-archive sweep.

Spec-compliance failure is FAIL regardless of the mode result — report both; do not continue to the mode check. When the wave plan declares artifact_hash values, verify them; a hash mismatch is always FAIL.

Step 2 — Mode-specific check (the declared I4 mode)

Mode	What to do
Test	run the domain's declared test/assertion (and the domain's declared static diagnostics where provided — references/verification-modes.md). PASS = clean diagnostics AND all assertions green.
Observation	each declared artifact exists and is in the expected state.
Measurement	read the metric; compare to the wave's declared threshold.
Audit	compare each artifact against the card's acceptance criteria; list each violation.
Review	route to reviewer; PASS = ACCEPT verdict.
Attestation	pause, surface to the user, await explicit confirmation. No automated PASS.
Demonstration	run the working proof against real conditions (not mocks); PASS = behavior confirmed.

For document-transformation waves (polish/compress/translate/rewrite), the domain's preservation check runs before the mode check (references/verification-modes.md).

Visual verification (web / visual sub-targets)

For a web/visual sub-target verified by Review or Demonstration, do not verify the visual output from the source alone — verify the running build. Resolve the visual-verify capability through the tool seam (engine/tools/, e.g. chrome-devtools / browser-use): capture a screenshot, the accessibility tree, a performance trace, and the DOM of the served output, and check them against the spec and the experience gate (contrast, budgets, intentionality). Record each as evidence. A contrast/budget/ keyboard failure observed live is a P0 veto, not advisory. If no visual-verify tool is live (MISSING/GATED), record visual_verify: NOT-RUN with the reason and fall back to source-level Review — never block the wave on an absent tool (calibrated robustness; adopt the mechanism, not a lock).

Implied-completion red flags (I10)

Before any verdict, scan the wave output for these — each is a potential I10 violation; escalate to FAIL unless real evidence (test output, file paths, command output) backs the claim: "tests pass" with no output shown · "everything works" with no link · "implementation complete" with no artifact/trace · acknowledged-but-unshown error text · mentioned-but-unaddressed warnings · a run summarized as success while failure lines are omitted · "probably/should work".

Four-questions gate (before PASS)

1. Tests passing? — actual command output shown (not a summary claim).
2. Requirements met? — each acceptance criterion mapped to an artifact in this wave's outputs.
3. No unverified assumptions? — any assumption cites its validating source.
4. Evidence present? — at least one of: test output, file path with content, command output, hash match.

Any failure → FAIL with the specific question number and the gap.

Severity & veto

Tier each finding: P0 (veto) — spec non-compliance, a security / data-loss / irreversible defect, or a failed BLOCKING domain gate → FAIL regardless of the mode result; never PROVISIONAL_PASS. P1 (must-fix) → FAIL → REVISE. P2 (advisory) → record, do not block PASS. Spec-compliance failure is the canonical P0 (Step 1). Name the veto finding in fix_recommendation.

Step 3 — Verdict

Both spec compliance and mode PASS → PASS. Either FAIL → FAIL → REVISE loop. Categorically unresolvable (required external service unavailable; irreversible action needs human judgment; deadlocked dependency) → BLOCKED immediately (no REVISE). Reserve BLOCKED for those — a code/logic failure is FAIL, not BLOCKED. Resolve evidence conflicts by the tier hierarchy (references/evidence-hierarchy.md) before issuing the verdict; annotate findings with the tier used.

Record thesis_impact (STRENGTHENED / UNCHANGED / WEAKENED) — informational, does not affect the verdict.

Step 4 — REVISE loop (on FAIL)

Each cycle: emit a specific fix recommendation (which criterion/artifact failed — exact, not "the output was wrong"; what the correct output is; what to change and where). Executor re-implements; verifier re-runs from Step 1 (a fix can regress a previously-passing criterion — re-check the full wave, not just the failed item). Cycle count resets per wave. After cycle 2 fails, Santa Mode runs instead of cycle 3 (references/santa-mode.md); cycle 4 → BLOCKED → Attestation.

Step 5 — Write the verification receipt

Always, regardless of verdict — and before executor sets up the next wave (a deferred verification receipt is an open chain, an I10 violation). Evidence rule: every checks_run entry needs a corresponding evidence record (a captured-output path, a drawer ID, or a ≤10-line quoted excerpt). A check with no capturable output goes in not_tested, not checks_passed. A receipt with checks_passed but empty evidence is PARTIAL (confidence <0.7), not PASS.

Output Contract

verification receipt (<workspace>/receipts/verification-wave-<N>-<timestamp>.json): base + wave, verification_mode, verdict (PASS|FAIL|BLOCKED|PROVISIONAL_PASS), spec_compliance, revise_cycles_used, immediate_blocked, attestation_required/_received, fix_recommendation (required on FAIL), deferred_then_clauses, thesis_impact, severity_max (P0|P1|P2), veto_item, santa_mode/santa_result (if run), visual_verify (RUN|NOT-RUN + result, web/visual sub-targets). persistence: Spec-Anchored. Signal to executor: PASS (advance) | FAIL (REVISE) | BLOCKED (pause).

Proactive Triggers

• Wave output says "tests pass" with no command output shown: I10 red flag — FAIL unless real output backs it.
• About to recommend a fix for a FAILed wave: diagnose the root cause first (engine/shared/references/debug-protocol.md) — build the feedback loop, test the top hypothesis, and write the regression test before the fix; a fix to a symptom regresses.
• A wave receipt claims a file but the file is absent at its declared path: Tier-1 truth overrides the receipt — FAIL regardless of receipt status.
• A "Then" clause's artifact is not in this wave's outputs: defer it (record in deferred_then_clauses); do not FAIL the wave for another wave's artifact.
• Mode is Observation for a wave that produced runnable behavior: Observation misses functional correctness — the declared mode was too weak; flag it.
• Cycle 2 failed: do not run a third identical REVISE — Santa Mode (two fresh reviewers) breaks the anchoring that accumulates when the same context reviews the same output repeatedly.

Completion Criteria

Done when: spec compliance + the declared mode both ran; a verdict was issued; a verification receipt was written with evidence for every passed check, before next-wave setup.

Not done if: the mode check ran but spec compliance was skipped; PASS was issued with empty evidence; a 4th REVISE cycle was entered instead of BLOCKED/Attestation.

Next step: executor advances (PASS) / re-implements (FAIL) / pauses for Attestation (BLOCKED).

Related Skills

• guard: The pre-wave gate. NOT the post-wave check — that is verifier.
• executor: Calls verifier after each wave and fixes what it reports. NOT the fixer itself — verifier finds, executor fixes.
• reviewer: Invoked for Review-mode waves and Santa Mode. NOT the default — most modes verify directly.