Maestro Verify

<!-- maestro-skill-version: dev -->

maestro-verify

Use for verification and close. Read WORKFLOW.md for testing, recovery, authorization, and completion rules. Delivery actions such as commit, install, push, or release remain separate gates.

Precondition: an open bundle with a drafted VERIFY.md. Without a bundle, verify inline and close a tracked item with maestro work done; an untracked quickfix needs no record. This skill's table pass is for Full work. The evidence-layer vocabulary below still applies to any claim at any tier.

Evidence layers

Proof follows five links. Claim only as far as the last proven link.

• source - source-level tests, lint, type checks, or direct inspection.
• artifact - the built or packaged output is present and has been read back.
• installed - the installed stamp, version, or files match the intended artifact.
• live - the running process, pid, or active runtime matches the installed layer.
• journey - the real user path reaches the observable outcome end to end.

"Tests pass" is a source claim. A claim that touches install or runtime must include a readback at that layer. A suite that is green only on this machine is not a source claim about the repo: before any commit, release, or handback gate, re-run the touched suite with the developer environment removed (HOME=$(mktemp -d), env -u HERDR_ENV). A test that reads the installed copy, the room, or a home config passes for you and fails in CI. Every proof and VERIFY result lists untested links explicitly as NOT TESTED, never by omission:

proof: "suite 135 pass @ a52bd4a7 (source); runtime stamp readback a52bd4a7 (installed); live: NOT TESTED"
Assumptions not verified: None
Residual risks: None

Verify

• Cross-check the evidence plan against acceptance and relevant risks. Map existing tests, necessary new checks, readbacks, or baselines to VERIFY.md. A missing behavior check is a gap; the absence of a newly written test is not.
• Run every VERIFY.md scenario against its work item's acceptance/claims and fill the Result column; run each anti-goal check (grep, diff, readback). Stamp the pass with its date and commit. Results hold this run only: a re-run replaces prior results wholesale, and a failed pass leaves its one-line failed: note on the work item, never accumulated rounds in VERIFY.md. Apply Recovery and verification when a scenario cannot run as written: document and execute an equivalent check without changing acceptance, or report the gap if equivalence is unknown.
• Run the repo's checks for the touched surface (tests, lint, types, build), then freeze and review the task-owned diff: every changed line traces to the SPEC's scope or a linked work item; nothing unrelated is staged.
• For a concrete assertion-strength concern, inspect whether the existing check distinguishes the approved outcome from the suspected wrong behavior. A focused mutation can establish that; restore it before continuing. Do not expand verification into an unrelated edge-case or coverage campaign.
• Re-read the user's exact delivery authority and target before any gate.
• Select one legal next gate at a time: final verification, independent QA or witness, scoped commit, local install, external delivery, or stop. Do not bundle gates whose authority differs.
• Read back the actual result: test output, commit hash, installed version. A started or interrupted command is not delivery evidence.

For substantial diffs, verify in a fresh context: dispatch a subagent that reads only the bundle and the diff - the implementer verifying their own work invites confirmation bias. The subagent never fixes anything: mutants it flips are reverted before reporting, and on FAIL it records the verdict and stops; routing back to implementation belongs to the parent turn that holds the user's ask. A subagent that fails to start or report is a dispatch failure, not evidence: run the checklist in this session instead of polling for it.

On FAIL, leave maestro work note <id> "failed: <one line>" and return the evidence to the implementation owner. Use the shared recovery rule to choose the next action from the cause, not a failure count. Read prior failed notes so a new session does not repeat the same uninformative attempt.

Read-only review method: references/audit.md. When the failure location is unclear, follow references/triage.md.