verifylisted

# 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. - UI change → also run `design-guard` on what appeared on screen. - 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,