Verify

Core principle: Evidence before claims, always.

If you haven't run the verification command in this message, you cannot claim it passes.

The Gate

Before claiming any status:

1. IDENTIFY — what command proves this claim?
2. RUN — execute it (fresh, complete)
3. READ — full output, check exit code
4. CONFIRM — does output support the claim?
5. THEN — make the claim with evidence

Common Failures

Claim	Requires	Not Sufficient
Tests pass	Test output: 0 failures	Previous run, "should pass"
Build succeeds	Build output: exit 0	"Linter passed"
Bug fixed	Reproduce original symptom: fixed	"Code changed"
Agent completed	git diff shows changes	Agent says "success"
Requirements met	Line-by-line checklist	"Tests pass"

Red Flags — STOP

If you catch yourself thinking any of these, run the verification:

• "Should work now"
• "I'm confident"
• "Linter passed" (linter ≠ compiler)
• "Agent said success"
• "Just this once"

Run the command. Read the output. THEN claim the result.

Runner Delegation

Dispatch test execution to test-runner workers (see test-runner-prompt.md), one per test group, instead of running suites in the main loop — suite output floods context and blocks everything else. The gate is preserved: each runner returns a digest with commands, exit codes, failing test names, and a log path, and you claim results only from that evidence. A runner's "passed" without commands + exit codes is a worker success claim — reject it. Quick read-only checks (git diff, single-file inspection) stay in the main loop.

Local-CI runner — required stage element: alongside the per-group runners, dispatch the local-CI runner (submit-ticket-pr/local-ci-runner-prompt.md): repo-local gates (lint, typecheck, validation scripts named in the repo instructions) plus broader cross-area regression checks, with its discover-and-run mandate intact — where the Testing Contract's Broader-regression line is to-be-discovered or narrow, the runner's discovery obligation governs. Pass it a groups-covered-elsewhere scope note naming the test groups the per-group runners already cover, so the same suites are not run twice in one stage.

Digest head-SHA rule: every runner digest — per-group and local-CI alike — records the head SHA its commands ran against, so downstream gates can tie each green result to the exact tree state that produced it. A digest without its head SHA is incomplete evidence — reject it the same way as a missing exit code.

Epic Orchestration Verification Rules

• Read the Testing Contract before choosing commands.
• Do not skip required unit, integration, or e2e groups because a harness is absent.
• Set up missing required harnesses when feasible.
• Classify failures as test bug, implementation bug, environment/harness issue, or spec/plan mismatch.
• Fix the right thing; do not default to editing tests.
• Return to the spec lane when verification exposes a spec/plan mismatch.
• For an epic full regression run before the epic PR, cover the union of all merged children's required test groups on the integrated epic head (after the latest main/master sync), not just one ticket's contract. Record the commands, exit codes, and the head SHA the suite ran against.