verify: evidence, not confidence
A change is verified when its observable behavior matches its acceptance criteria, and you have
seen that behavior yourself. "Should work", "compiles", "tests pass" are not that.
1. The floor: every gate green
Run the full chain and paste real results, not summaries of results:
node checks/check.mjs, then the stack gates (typecheck, lint, tests, build; commands are in
docs/standards/<stack>.md). Red gate → stop, fix, rerun. Never weaken a gate to pass it.
2. The point: exercise the change
- Take the spec's acceptance criteria (tier S: the request itself) and walk them end to end
in the closest thing to reality available: run the app, call the endpoint, click the flow,
render the document. Per criterion: what you predicted you would see → what you did → what you
observed. Write the prediction down before running. A pass you did not predict proves only that
something happened; a prediction that turns out wrong is the finding, and the real behavior gets
explained and traced to a rule before the criterion counts as met.
- Probe the edges the criteria imply: empty input, wrong input, unauthorized user, the second
run (idempotency), the slow path. The first bug is usually one step off the happy path.
- Run the long things at arm's length. A test run, a build or a log enters the context as its
counts and its failures (tail, grep, or a subagent that reads it and returns two lines), so the
transcript carries the conclusion and not the log; the full output stays on disk for the report.
- Exercise against the real dependency, or the test double the spec names. A path that passed
because a fallback returned canned data (a sample response, a stub, a default) is a failure, and
the fallback is a finding: it carries a
defer: marker with its trigger, or it goes.
- User-facing output → also run
design-guard on what rendered. A built interface gets re-checked
against its direction contract and the finish verdict; a document, e-mail, export or error
string gets judged there in full, because the design method does not carry those.
- Bug fix → reproduce the bug first on the old behavior (or its regression test), then show it
gone. A fix you never saw fail is a guess. Cause unknown, or a fix attempt already failed?
Run the
debug skill's loop before trying again.
3. What you cannot verify
Some things this environment can't exercise (production data, real payment, app-store review).
Name them explicitly: "verified: A, B; not verifiable here: C, needs , tracked in
STATE.md". Unverifiable-and-silent is how "works on my machine" ships.
4. Converge and record
- Substantial change (per
code-review's own bar)? Hand the diff to code-review now, before
any status flips: findings must land while they can still change the work. Blocker fixes come
back through §1-2. Trivial tier: record "code-review: skipped (trivial)" in STATE.md instead.
- Reconcile docs the verified change made stale; retired wording → denylist
(
checks/config.json). Spec: Verified by: names this run's artifact (the suite and its count, the walk, the log entry), status → done, folder → archive (see spec).
- STATE.md: gates line updated with the evidence summary ("checks green, tests 61/61, criteria
4/4 exercised"), Now ▶ next step.
Report format, per criterion one line: ✓/✗ <criterion>: <what was observed>, then the
gates line, then anything unverifiable. No prose padding. ⚓
1---2name: verify3description: Prove a change actually works before it counts as done. Use after building any non-trivial change, before deliver, and whenever claiming something works. Exercises real behavior end-to-end. Green tools alone are not verification.4---56# verify: evidence, not confidence78A change is verified when its observable behavior matches its acceptance criteria, and you have9seen that behavior yourself. "Should work", "compiles", "tests pass" are not that.1011## 1. The floor: every gate green1213Run the full chain and paste real results, not summaries of results:14`node checks/check.mjs`, then the stack gates (typecheck, lint, tests, build; commands are in15`docs/standards/<stack>.md`). Red gate → stop, fix, rerun. Never weaken a gate to pass it.1617## 2. The point: exercise the change1819- Take the spec's acceptance criteria (tier S: the request itself) and walk them **end to end**20 in the closest thing to reality available: run the app, call the endpoint, click the flow,21 render the document. Per criterion: what you predicted you would see → what you did → what you22 observed. Write the prediction down before running. A pass you did not predict proves only that23 something happened; a prediction that turns out wrong is the finding, and the real behavior gets24 explained and traced to a rule before the criterion counts as met.25- Probe the edges the criteria imply: empty input, wrong input, unauthorized user, the second26 run (idempotency), the slow path. The first bug is usually one step off the happy path.27- Run the long things at arm's length. A test run, a build or a log enters the context as its28 counts and its failures (tail, grep, or a subagent that reads it and returns two lines), so the29 transcript carries the conclusion and not the log; the full output stays on disk for the report.30- Exercise against the real dependency, or the test double the spec names. A path that passed31 because a fallback returned canned data (a sample response, a stub, a default) is a failure, and32 the fallback is a finding: it carries a `defer:` marker with its trigger, or it goes.33- User-facing output → also run `design-guard` on what rendered. A built interface gets re-checked34 against its direction contract and the finish verdict; a document, e-mail, export or error35 string gets judged there in full, because the design method does not carry those.36- Bug fix → reproduce the bug first on the old behavior (or its regression test), then show it37 gone. A fix you never saw fail is a guess. Cause unknown, or a fix attempt already failed?38 Run the `debug` skill's loop before trying again.3940## 3. What you cannot verify4142Some things this environment can't exercise (production data, real payment, app-store review).43Name them explicitly: "verified: A, B; not verifiable here: C, needs <what>, tracked in44STATE.md". Unverifiable-and-silent is how "works on my machine" ships.4546## 4. Converge and record4748- Substantial change (per `code-review`'s own bar)? Hand the diff to `code-review` now, before49 any status flips: findings must land while they can still change the work. Blocker fixes come50 back through §1-2. Trivial tier: record "code-review: skipped (trivial)" in STATE.md instead.51- Reconcile docs the verified change made stale; retired wording → denylist52 (`checks/config.json`). Spec: `Verified by:` names this run's artifact (the suite and its count, the walk, the log entry), status → `done`, folder → archive (see `spec`).53- STATE.md: gates line updated with the evidence summary ("checks green, tests 61/61, criteria54 4/4 exercised"), Now ▶ next step.5556Report format, per criterion one line: `✓/✗ <criterion>: <what was observed>`, then the57gates line, then anything unverifiable. No prose padding. ⚓
Tradebaas