Evidence Before Claims

Read collaboration when dispatching the verifier — its status is at most ten lines and its report is never pasted into your context — and artifacts before writing verdict.md or state.md.

Route

• no argument, mid-work: the gate below, then continue
• <feature-slug>: full adversarial verification, ending in a verdict
• --strict: two verifier lenses in parallel; the verdict is the worse of the two

The gate

Before any claim that something works, fixed, passes, or is done:

1. Identify the command that would prove it. .planning/power/context/project.md records this repository's real test, lint and build commands; use those rather than the ones that are conventional for the ecosystem.
2. Run it, fresh and complete. Not a cached result, not a subset.
3. Read the whole output: the exit code, the failure count, the warnings.
4. Verify the output actually says what you are about to claim.
5. Only then, claim it.

Skipping a step is not verifying faster; it is asserting.

Claim	Requires	Not sufficient
"Tests pass"	the full suite run now, output read	the last run, before your change
"It builds"	the real build command	the linter passed
"The bug is fixed"	the regression test failing before and passing after	the symptom is gone
"Nothing else broke"	the full suite	the touched file's tests
"The agent did it"	the VCS diff	the agent said DONE

No satisfaction before evidence. Not "Great!", not "Perfect!", not "That should do it". Those phrases commit you to a conclusion you have not yet checked, and having committed, you will read the output looking for agreement.

Adversarial verification

When verifying a whole feature, dispatch the verifier subagent. Its instruction is not "check whether this is complete" — it is "try to refute that this is complete".

Give it the spec, the plan, the ledger, and the branch range. It falsifies each stated truth — objective, acceptance criteria, definition of done, prohibitions — with real commands, and reports what survived.

--strict runs two lenses in parallel:

• Functional: does it do what the spec says, under the spec's exact values?
• Compliance: does it respect the prohibitions, conventions and non-functional constraints?

The final verdict is the worse of the two. A feature that works but violates a stated prohibition is not approved.

Verdicts

Verdict	Meaning	Next
APPROVED	Every stated truth survived refutation.	pwdev-power:power-finish
CAVEATS	Approved, with findings recorded that nothing blocks on.	pwdev-power:power-finish, caveats surfaced
REJECTED	At least one stated truth was falsified.	fix plan, then re-verify

Write the verdict to .planning/power/features/<slug>/verdict.md with the evidence — the commands run and their output — and record the gate in state.md.

Correction cap

A REJECTED verdict produces fix-<NN>.md, executed through pwdev-power:power-execute. At most two correction cycles. A third rejection stops and goes to the human; it never becomes an approval by attrition.