verify

Evidence comes before a claim. Do not make a claim without a fresh command run behind it.

Fast path: when the plan is one sentence and there is no spec file, the gate is that sentence's criterion. Run only the tests that exercise the change, and still run the changed path end to end. When the gate fails a second time on a fast-path task, the task was not obvious. Stop, and run drill on it.

1. Name the claim that you are about to make: "done", "fixed", "passes", or "works".
2. Sort the claim. Verify here what a command can settle. Send a claim about quality to the rubric skill now, whatever the commands show. A claim about quality is about a design, a UI, a public interface, a name, or prose. To fail it as unprovable is a routing failure. Passing commands never pass it.
3. Run the commands that would prove the claim false: the tests, the build, the linter, and the behavior that changed. The full gate is every test, the build, and the linter. It runs once for each commit, on the tree that you are about to commit. On the fast path, the gate is the criterion of the sentence. Inside a slice, the test loop runs only the tests that exercise the slice. Inside a phase that the spec declares, a commit uses the checks of the area that it touches. The last commit of the phase runs the full gate.
4. When a spec exists at docs/specs/<slug>.md, gate each criterion separately. At the commit of a slice, gate the criteria that the slice touches. A criterion where a declared phase ends waits for the last commit of the phase. When you claim that the whole work is done, gate every criterion. Take each result from the last evidence record when its hash still matches the tree. Run the verification command of each criterion, and quote the output that proves it. For a criterion whose line names rubric, use the verdict of that judge. When you claim that the whole work is done, the criteria are items in the current task list. When no list exists and there are three criteria or more, create one. Mark an item done only on the output or the verdict that proves it. A criterion without proof stays open. Then check the diff against the non-goals of the spec. A change inside excluded scope fails the claim, even when the tests pass. A spec that still has an ## Open decisions section is a draft. No claim stands against a draft. Send it back to drill.
5. Exercise the changed path end to end, not only its unit tests. When the change has a runtime interface, drive it, and keep what it showed. A runtime interface is a UI, a CLI, a TUI, or a service. Keep the command output, the logs, a screenshot, or a transcript. When the base branch has a recipe, drive the touched features with it, as app-check.md says. The recipe is a project skill named verify-<app>. Write or update that recipe only when the user asks, through the same reference. For a runtime interface with no recipe, offer in one line to write one. Read prove it works when you read the result of the changed path through a proxy. A proxy is a timestamp, a status file, a cached value, a screenshot, or a report from another agent. Read it also when a check fails, or when the work is a port or a migration.
6. Read the output. Passing means that the output says passing, not that the command exited.
7. State what you ran and what it showed. If it broke, say that it broke, and show the output. When the spec names a demo artifact, run that artifact again to show the demo. Do not describe an earlier run. A demo shows that the change works, but it proves no criterion. So a script written on the branch can be the demo.

Rules: