/sw-verify

name: sw-verify
description: >-
  Orchestrates quality gates for the current work unit. Runs enabled gates
  in dependency order, produces an aggregate evidence report with gate handoff.
argument-hint: '[--gate=<name>] [--accept-mutant {id} --reason "{prose}"]'
allowed-tools:
  - Read
  - Write
  - Bash
  - Glob
  - Grep
  - Task

Specwright Verify

Goal

Run quality gates against the work unit. Continue through all gates regardless of failures and present the report at handoff per `protocols/decision.md`.

Inputs

• `{worktreeStateRoot}/session.json` -- selected work
• `{repoStateRoot}/work/{selectedWork.id}/workflow.json` -- work state and gate results
• `{projectArtifactsRoot}/config.json` -- gate configuration
• `{workDir}/spec.md` -- for spec compliance gate
• `{workDir}/implementation-rationale.md` -- curated build rationale when present
• `{workArtifactsRoot}/{selectedWork.id}/integration-criteria.md` -- behavioral IC list when present
• Gate skill files in `skills/gate-*/SKILL.md`

Outputs

• `{repoStateRoot}/work/{selectedWork.id}/units/{selectedWork.unitId}/stage-report.md` -- verify handoff digest
• Evidence files in `{workDir}/evidence/`, one per gate
• `{workDir}/review-packet.md` -- reviewer synthesis from approvals, rationale, proof, and gate outcomes
• Selected work's `workflow.json` updated with gate results; status `verifying`
• Aggregate report presented at gate handoff

Constraints

**Stage boundary (LOW freedom):** Follow `protocols/stage-boundary.md`. Run quality gates and show findings. NEVER fix code, create PRs, or ship. After gate handoff, STOP.

**Ownership check (LOW freedom):** Resolve the selected work from the current worktree session. If another live top-level worktree owns that work, STOP with explicit `/sw-adopt` guidance and do not rely on generic adopt/takeover behavior.

**Assumption re-validation (LOW freedom) — before gate execution:** Scan the design assumptions artifact from the design-level directory. Check ACCEPTED/VERIFIED assumptions against current code. Invalid → WARN in the aggregate report. Runs silently.

**Approval lineage check (LOW freedom) — before gate execution:** Use `protocols/approvals.md` and the shared helper to validate the recorded `design` and current `unit-spec` approval hashes. Missing, `STALE`, or `SUPERSEDED` lineage becomes a distinct approval finding; headless verify may report it but never create `APPROVED` entries.

**Accepted-mutant lineage and mutation disclosure (LOW freedom):** When `/sw-verify --accept-mutant {id} --reason "{prose}"` is present, use `protocols/approvals.md` plus the shared helper to record or refresh the accepted-mutant approval entry before gate execution. Persist the config linkage at `config.gates.tests.mutation.acceptedMutants[]`, require a reason, and set expiry to 90 days from approval unless a later explicit expiry is being refreshed. Ordinary verify runs validate and report accepted-mutant lineage; they never fabricate approval state or silently waive survivors. Mutation analysis stays inside `gate-tests`, not a seventh gate. When `gate-tests` emits mutation evidence, surface the tier (`T1`, `T2`, or `T3`), any accepted-mutant approval lineage, and only the restricted survivor record: operator, location, before/after, defect category, and action. No test bodies and no assertion literals. Missing-tool or fallback paths may degrade through `T2`/`T3`, but never to a silent skip.

**Freshness checkpoint (LOW freedom) — before any gate runs:** Use `protocols/git-freshness.md` to assess the selected work's verify checkpoint from the recorded target and policy. For branch-head validation, branch-head `require` blocks stale, diverged, and blocked freshness results. Queue-managed mode remains a distinct validation path and does not prescribe a local rebase before verification. When branch-head validation is blocked and `rebase` or `merge` reconcile is configured, run `protocols/git-reconcile.md` in the owning worktree and continue gate execution in that same verify run after a successful reconcile. `manual` remains an explicit fallback: stop with manual reconcile guidance, reconcile the current branch against the recorded target in the owning worktree, or run `/sw-adopt` first if a linked-worktree ownership conflict exists, then rerun `/sw-verify`. Do not redirect to `/sw-build` solely to clear freshness, and do not silently rewrite `targetRef` or freshness metadata. In headless mode, follow `protocols/headless.md`: skip freshness blocking, continue gate execution, and report the freshness result with the gate findings.

**Gate execution order (LOW freedom):** Determine enabled gates from config. Support both formats:

• **Object format**: `config.gates.{gateName}` exists and `.enabled === true`
• **Array format**: gate name present in `config.gates.enabled` array

All six gates are eligible when enabled in config: build, tests, security, wiring, semantic, spec. Execute enabled gates in dependency order: gate-build → gate-tests → gate-security, gate-wiring → gate-semantic → gate-spec. If `--gate=<name>` argument, run only that gate. Load calibration notes per `protocols/evidence.md#verdict-rendering`.

Freshness is a prerequisite checkpoint, and gate-build plus gate-tests remain the ordered prerequisites before any parallel or read-only lane begins. When parallel verify execution is enabled under the same `protocols/parallel-build.md` prerequisites (`config.experimental.agentTeams.enabled=true`, `SPECWRIGHT_AGENT_TEAMS=1`, and a selected work unit with 4 or more tasks), only gate-security, gate-wiring, gate-semantic, and gate-spec may run as read-only evidence producers after the freshness, build, and tests steps complete.

Parallel lanes never become independent workflow owners. The parent or top-level verify execution remains the only authority that aggregates lane results into shared work state, including the selected work's `workflow.json` `gates` section.

Missing eviden