spec-verify

# /spec-verify - Verification Phase **Phase 3 of the /spec workflow (features).** Runs comprehensive verification: automated checks, code review, program execution, and E2E tests. For bugfix plans, use `spec-bugfix-verify` instead. **Input:** Plan file with `Status: COMPLETE` **Output:** Plan status → VERIFIED (success) or loop back to implementation (failure) --- ## ⛔ KEY CONSTRAINTS 1. **Run code review when enabled** — Step 3.1 launches `changes-review` via `Task(subagent_type="pilot:changes-review")` when `PILOT_CHANGES_REVIEW_ENABLED` is not `"false"` (read in Step 0). To disable, use Console Settings → Reviewers → Changes Review toggle. 2. **Only changes-review — NEVER spec-review** — Do NOT launch `spec-review` during verification. Do NOT read or reference `findings-spec-review-*.json` files — they are stale artifacts from the planning phase that were already addressed during implementation. If you encounter a spec-review findings file, **ignore it completely**. 3. **NO stopping** — Everything automatic. Never ask "Should I fix these?" 4. **Fix ALL findings** — must_fix AND should_fix. No permission needed. 5. **Code changes finish BEFORE runtime testing** — Phase A then Phase B. 6. **Plan file is source of truth** — re-read it after auto-compaction, don't rely on conversation memory. 7. **Re-verification after fixes is MANDATORY** — fixes can introduce new bugs. 8. **Quality over speed** — never rush due to context pressure. --- ## Step 0: Read Toggle Configura...