/verify

/verify is a formal phase gate. It checks three artifacts against each other — the intent (the original goal), the plan (the stated approach), and the execution (what was actually done) — and reports whether they still align before you proceed.

It hard-gates on two of them: the intent and the execution. If either is absent it stops and names what is missing, rather than guessing. The plan is optional — when absent, verify reports status: plan-not-found rather than failing. For a softer pause with no artifact requirement, use /reflect; for a quick re-read of a single claim, use /double-check.

Structured execution spec: protocol.yon. It carries the canonical preconditions, step sequence, and routing as named, validatable records; this file is the human-facing explanation. The two must stay in sync — if you edit one, update the other and refresh the @STAMP date.

Preconditions

Two artifacts hard-gate the run: the intent and the execution. If either is missing, verify aborts and says so — there is nothing to align without both. The plan may be absent: when it is, verify skips the plan and execution checks and reports status: plan-not-found rather than failing.

The five phases

1. Intent check. Using the intent as ground truth, name any drift between the original goal and the current direction — with evidence.
2. Plan check. Does the plan match the intent? Look for scope creep, missing steps, unstated assumptions, over-engineering. Cite specific sections.
3. Execution check. Does the execution match the plan? Look for skipped steps, deviations, unplanned changes, incomplete work. Cite specific evidence.
4. Source re-check (active, per-claim — the load-bearing gate). For every load-bearing factual claim in the execution or output, re-open the source that would confirm or refute it and check it directly; revise the claim if wrong. A claim not re-checked against its source is reported unverified, never as passing. The agent's own report that it "already checked" is NOT evidence — only a fresh read of the source counts. When assessing a claim, pose it as a question ("Is X true, per the source?"), not a statement to confirm. When the claim is about a committed, built, or published artifact, re-check against the consumed form — the committed blob (git show <ref>:<path>), the built dist/tarball, or the published version — not the mutable working tree; a dirty tree or a stale dist can pass a claim while the committed HEAD / shipped artifact is broken (grepping the working tree is not verifying the commit). Exception: when uncommitted WIP is itself the artifact under verification, the working copy is the correct source. (Grounded in the critical-thinking arc: passive/optional verification lets false claims through; a mandated active re-check catches them. The consumed-artifact clause was added 2026-07-07 after /verify returned clean on a working-tree grep while the committed HEAD shipped two CLI verbs dead — same family as tsc-green≠verified and served-route-shadows-source.)
5. Report. Produce a structured verdict: clean (true/false), gaps, drifts, issues, and a status of clean | gaps-found | plan-not-found | incomplete | unverified. A clean: true verdict must cite evidence, must follow substantive analysis of all prior phases, and requires every load-bearing claim to have passed the phase-4 source re-check.