cclaw-cli 0.15.0 → 0.15.1

package/dist/content/stage-schema.js

@@ -1,4 +1,11 @@
 import { COMMAND_FILE_ORDER } from "../constants.js";
+import { BRAINSTORM, SCOPE, DESIGN, SPEC, PLAN, TDD, REVIEW, SHIP } from "./stages/index.js";
+// ---------------------------------------------------------------------------
+// NOTE: The former QUESTION_FORMAT_SPEC / ERROR_BUDGET_SPEC exports were
+// hoisted into `src/content/meta-skill.ts` (Shared Decision + Tool-Use
+// Protocol). They are no longer re-exported from here to avoid duplication
+// and drift. Stage skills cite the meta-skill by path instead.
+// ---------------------------------------------------------------------------
 /**
  * Gate tiers:
  * - required: blocking for stage completion.
@@ -117,1347 +124,6 @@ function tieredArtifactValidation(stage, rows) {
         };
     });
 }
-const BRAINSTORM = {
-    stage: "brainstorm",
-    skillFolder: "brainstorming",
-    skillName: "brainstorming",
-    skillDescription: "Design-first stage. Explore context, understand intent through collaborative dialogue, propose distinct approaches, and lock an approved direction before scope/design work.",
-    hardGate: "Do NOT invoke implementation skills, write code, scaffold projects, or mutate product behavior until a concrete direction is approved by the user.",
-    ironLaw: "NO ARTIFACT IS COMPLETE WITHOUT AN EXPLICITLY APPROVED DIRECTION — SILENCE IS NOT APPROVAL.",
-    purpose: "Turn an initial idea into an approved design direction through natural collaborative dialogue — understanding the problem before proposing solutions.",
-    whenToUse: [
-        "Starting a new feature or behavior change",
-        "Requirements are ambiguous or trade-offs are unclear",
-        "Before any implementation-stage command or architecture commitment"
-    ],
-    whenNotToUse: [
-        "A valid approved direction already exists and only execution remains",
-        "The request is a pure release/finalization action with no new product decisions",
-        "The task is retrospective only (post-ship audit with no new solution choices)"
-    ],
-    checklist: [
-        "**Explore project context** — check files, docs, recent commits to understand what already exists.",
-        "**Assess scope** — if the request covers multiple independent subsystems, flag it and help decompose before deep-diving. Each sub-project gets its own brainstorm cycle.",
-        "**Ask clarifying questions** — one at a time, understand purpose, constraints, and success criteria. Prefer multiple choice when possible. Each question should change what we build, not just gather trivia.",
-        "**Propose 2-3 architecturally distinct approaches** — with real trade-offs and your recommendation. Lead with the recommended option and explain why.",
-        "**Present design by sections** — scale each section to its complexity. Ask after each section whether it looks right so far. Cover: architecture, key components, data flow.",
-        "**Write artifact** to `.cclaw/artifacts/01-brainstorm.md`.",
-        "**Self-review** — scan for placeholders/TODOs, check internal consistency, verify scope is focused, resolve any ambiguity.",
-        "**User reviews artifact** — ask the user to review the written artifact and explicitly approve or request changes.",
-        "**Handoff** — only then complete stage and point to `/cc-next`."
-    ],
-    interactionProtocol: [
-        "Explore what exists before asking what to build — check project files first.",
-        "If the idea is vague or could mean many different things, your FIRST question narrows to a specific kind of project. Do not ask detail questions until the project type is clear.",
-        "Ask exactly one question per turn. Prefer multiple choice. No bundled questions.",
-        "After 2-3 questions, summarize your emerging understanding before continuing so the user can correct course early.",
-        "Each question should change a concrete design decision. Litmus test: if the two most likely answers do not lead to different architectures, make the choice yourself and state it.",
-        "Present design in sections scaled to their complexity — a few sentences for simple aspects, detailed for nuanced ones. Get approval after each section.",
-        "When proposing approaches, lead with your recommendation and explain why.",
-        "State explicitly what is being approved when requesting approval.",
-        "Run a brief self-review (placeholders, contradictions, scope, ambiguity) before presenting the artifact.",
-        "**STOP.** Wait for explicit user approval after writing the artifact. Do NOT auto-advance."
-    ],
-    process: [
-        "Explore project context: check files, docs, recent activity.",
-        "Assess scope: flag if request is too broad, help decompose first.",
-        "Ask clarifying questions one at a time — focus on purpose, constraints, success criteria.",
-        "Propose 2-3 architecturally distinct approaches with trade-offs and a recommendation.",
-        "Present design sections incrementally, get approval after each.",
-        "Write approved direction to `.cclaw/artifacts/01-brainstorm.md`.",
-        "Self-review: placeholder scan, internal consistency, scope check, ambiguity check.",
-        "Request explicit user approval of the artifact.",
-        "Handoff to scope only after approval is explicit."
-    ],
-    requiredGates: [
-        { id: "brainstorm_context_explored", description: "Project context (files, docs, existing patterns) was checked before asking questions." },
-        { id: "brainstorm_idea_understood", description: "Agent and user share the same understanding of the problem, constraints, and success criteria." },
-        { id: "brainstorm_approaches_compared", description: "2-3 architecturally distinct approaches were compared with real trade-offs and a recommendation." },
-        { id: "brainstorm_direction_approved", description: "User approved a concrete direction and what exactly was approved is stated." },
-        { id: "brainstorm_artifact_reviewed", description: "User reviewed the written brainstorm artifact and confirmed readiness." }
-    ],
-    requiredEvidence: [
-        "Artifact written to `.cclaw/artifacts/01-brainstorm.md`.",
-        "Project context was explored (files, docs, or recent activity referenced).",
-        "Clarifying questions and their answers are captured.",
-        "2-3 approaches with trade-offs and recommendation are recorded.",
-        "Approved direction and approval marker are present.",
-        "Assumptions and open questions are captured (or explicitly marked as none)."
-    ],
-    inputs: ["problem statement", "constraints", "success criteria"],
-    requiredContext: [
-        "existing project context and patterns",
-        "current behavior of affected area",
-        "business and delivery constraints"
-    ],
-    researchPlaybooks: [
-        "research/repo-scan.md",
-        "research/learnings-lookup.md"
-    ],
-    outputs: [
-        "approved design direction",
-        "alternatives with trade-offs",
-        "brainstorm artifact"
-    ],
-    blockers: [
-        "no explicit approval",
-        "critical ambiguity unresolved",
-        "project context not explored"
-    ],
-    exitCriteria: [
-        "approved design direction documented",
-        "required gates marked satisfied",
-        "no implementation action taken",
-        "artifact reviewed by user"
-    ],
-    antiPatterns: [
-        "Asking questions without exploring existing project context first",
-        "Asking bundled or purely informational questions that don't change decisions",
-        "Proposing cosmetic option variants instead of architecturally distinct approaches",
-        "Jumping directly into implementation",
-        "Requesting approval without stating what decision is being approved"
-    ],
-    redFlags: [
-        "No project context exploration before questions",
-        "Questions that only gather preferences without design impact",
-        "Options that are variants of one approach, not distinct alternatives",
-        "Approval requested without explicit decision context"
-    ],
-    policyNeedles: [
-        "Explore project context",
-        "One question at a time",
-        "2-3 architecturally distinct approaches",
-        "State what is being approved",
-        "Self-review before handoff",
-        "Do NOT implement, scaffold, or modify behavior"
-    ],
-    artifactFile: "01-brainstorm.md",
-    next: "scope",
-    reviewSections: [],
-    completionStatus: ["DONE", "DONE_WITH_CONCERNS", "BLOCKED"],
-    crossStageTrace: {
-        readsFrom: [],
-        writesTo: [".cclaw/artifacts/01-brainstorm.md"],
-        traceabilityRule: "Scope and design decisions must trace back to explored context and approved brainstorm direction."
-    },
-    artifactValidation: [
-        { section: "Context", required: true, validationRule: "Must reference project state and relevant existing code or patterns." },
-        { section: "Problem", required: true, validationRule: "Must define what we're solving, success criteria, and constraints." },
-        { section: "Clarifying Questions", required: true, validationRule: "Must capture question, answer, and decision impact for each clarifying question." },
-        { section: "Approaches", required: true, validationRule: "Must compare 2-3 architecturally distinct options with real trade-offs and recommendation." },
-        { section: "Selected Direction", required: true, validationRule: "Must include the selected approach, rationale, and explicit approval marker." },
-        { section: "Design", required: true, validationRule: "Must cover architecture, key components, and data flow scaled to complexity." },
-        { section: "Assumptions and Open Questions", required: true, validationRule: "Must capture unresolved assumptions/open questions, or explicitly state none." }
-    ]
-};
-// ---------------------------------------------------------------------------
-// SCOPE — reference: gstack CEO review
-// ---------------------------------------------------------------------------
-const SCOPE = {
-    stage: "scope",
-    skillFolder: "scope-shaping",
-    skillName: "scope-shaping",
-    skillDescription: "Strategic scope stage. Challenge premise and lock explicit in-scope/out-of-scope boundaries using CEO-level thinking.",
-    hardGate: "Do NOT begin architecture, design, or code. This stage produces scope decisions only. Do not silently add or remove scope — every change is an explicit user opt-in.",
-    ironLaw: "EVERY SCOPE CHANGE IS AN EXPLICIT USER OPT-IN — NEVER A SILENT ENLARGEMENT OR TRIM.",
-    purpose: "Decide the right scope before technical lock-in using explicit mode selection and rigorous premise challenge.",
-    whenToUse: [
-        "After brainstorm approval",
-        "Before architecture/design lock-in",
-        "When ambition vs feasibility trade-off is unclear"
-    ],
-    whenNotToUse: [
-        "Brainstorm has not been approved yet",
-        "Scope boundaries are already locked and user requested no scope changes",
-        "The work is a pure implementation or debugging pass within existing scope"
-    ],
-    checklist: [
-        "**Assess complexity** — Read the brainstorm artifact. If project is simple (single component, clear architecture, personal/prototype), run light-touch scope: mode selection, 3-5 key in/out boundaries, deferred items. Skip Dream State Mapping and Temporal Interrogation. If project is complex (multi-component, team delivery, production), run the full checklist.",
-        "**Prime Directives** — Zero silent failures. For each in-scope capability, name concrete failure modes, the exact error surface, and trace all four data-flow paths (happy, nil, empty, upstream error). Include interaction edge cases (double-click, navigate-away, stale state), observability commitments, and explicit deferred-item logging.",
-        "**Premise Challenge** — Is this the right problem? What if we do nothing? What are we optimizing for?",
-        "**Existing Code Leverage** — Search for existing solutions before deciding to build new.",
-        "**Dream State Mapping** — (complex projects only) describe the ideal state 12 months out using `CURRENT STATE -> THIS PLAN -> 12-MONTH IDEAL`, then verify this scope moves toward that target.",
-        "**Implementation Alternatives** — Produce 2-3 distinct approaches. For each: Name, Summary, Effort (S/M/L/XL), Risk (Low/Med/High), 2-3 Pros, 2-3 Cons, and explicit Reuses. One option must be minimal viable, one must be ideal architecture.",
-        "**Temporal Interrogation** — (complex projects only) simulate implementation timeline: HOUR 1 foundations, HOUR 2-3 core logic, HOUR 4-5 integration surprises, HOUR 6+ polish/tests. Decide what must be locked now vs safely deferred.",
-        "**Mode Selection** — Present expand/selective/hold/reduce with recommendation and default heuristic: greenfield -> expand, feature enhancement -> selective, bugfix/hotfix/refactor -> hold, broad blast radius (>15 files or multi-team impact) -> reduce.",
-        "**Mode-Specific Analysis** — After mode is selected, run the matching analysis: EXPAND (10x and delight opportunities), SELECTIVE (hold-scope rigor then cherry-picked expansions), HOLD (minimum-change-set hardening), REDUCE (ruthless cuts and follow-up split).",
-        "**Error and Rescue Registry** — For each capability: what breaks, how detected, what fallback."
-    ],
-    interactionProtocol: [
-        "For scope mode selection: use the Decision Protocol — present expand/selective/hold/reduce as labeled options with trade-offs and mark one as (recommended). Do NOT use a numeric Completeness rubric; recommend the option that best covers the prime-directive failure modes, four data-flow paths, observability, and deferred handling for the in-scope set with the smallest blast radius. Base your recommendation on default heuristics: greenfield -> expand, enhancement -> selective, bugfix/hotfix/refactor -> hold, broad blast radius -> reduce. If AskQuestion/AskUserQuestion is available, send exactly ONE question per call, validate fields against runtime schema, and on schema error immediately fall back to plain-text question instead of retrying guessed payloads.",
-        "Walk through the scope checklist interactively. Each checklist item that surfaces a decision should be presented to the user as a question, not as a monologue. Do not dump all items at once.",
-        "Challenge premise and verify the problem framing before anything else.",
-        "Take a position on every scope decision. Avoid hedging phrases like 'this could work' or 'there are many ways'; state your recommendation and one concrete condition that would change it.",
-        "Use pushback patterns when framing is weak: vague scope -> force a specific user/problem, platform vision -> force a narrowest viable wedge, social proof -> demand behavioral evidence.",
-        "Present one structural scope issue at a time for decision. Do NOT batch. Use structured options for each scope boundary question.",
-        "Record explicit in-scope and out-of-scope contract.",
-        "Once the user accepts or rejects a recommendation, commit fully. Do not re-argue.",
-        "Produce a clean scope summary after all issues are resolved.",
-        "**STOP.** Wait for explicit user approval of scope contract before advancing to design."
-    ],
-    process: [
-        "Run premise challenge and existing-solution leverage check.",
-        "Produce 2-3 scope alternatives in a structured format (Name, Summary, Effort, Risk, Pros, Cons, Reuses) with minimum viable and ideal architecture options included.",
-        "Choose scope mode with user approval.",
-        "Run mode-specific analysis that matches the selected scope mode.",
-        "Walk through scope review sections one at a time.",
-        "Write explicit scope contract, discretion areas, and deferred items.",
-        "Produce scope summary plus completion dashboard (checklist findings, number of resolved decisions, unresolved items or `None`)."
-    ],
-    requiredGates: [
-        { id: "scope_premise_challenged", description: "Problem framing and assumptions were challenged." },
-        { id: "scope_alternatives_produced", description: "At least 2 implementation alternatives were evaluated with explicit effort/risk and reuse fields." },
-        { id: "scope_mode_selected", description: "One scope mode was explicitly selected." },
-        { id: "scope_contract_written", description: "In-scope/out-of-scope contract is documented." },
-        { id: "scope_discretion_documented", description: "Discretion areas are documented (or explicitly marked as none)." },
-        { id: "scope_user_approved", description: "User approved the final scope direction." }
-    ],
-    requiredEvidence: [
-        "Artifact written to `.cclaw/artifacts/02-scope.md`.",
-        "In-scope and out-of-scope lists are explicit.",
-        "Discretion areas are explicit (or marked as `None`).",
-        "Selected mode and rationale are documented.",
-        "Premise challenge findings documented.",
-        "Deferred items list with one-line rationale for each.",
-        "Completion dashboard lists checklist findings, decision count, and unresolved items (or `None`)."
-    ],
-    inputs: ["brainstorm artifact", "timeline constraints", "product priorities"],
-    requiredContext: [
-        "approved brainstorm direction",
-        "existing capabilities and reusable components",
-        "delivery deadlines and risk tolerance"
-    ],
-    researchPlaybooks: [
-        "research/git-history.md"
-    ],
-    outputs: ["scope mode decision", "scope contract", "discretion areas list", "deferred scope list", "scope summary", "scope completion dashboard"],
-    blockers: [
-        "scope mode not selected",
-        "in/out boundaries ambiguous",
-        "discretion areas undefined",
-        "critical premise disagreement unresolved"
-    ],
-    exitCriteria: [
-        "scope contract approved by user",
-        "discretion areas recorded explicitly",
-        "required gates marked satisfied",
-        "deferred list recorded explicitly",
-        "completion dashboard produced",
-        "scope summary produced"
-    ],
-    antiPatterns: [
-        "Scope silently expanded during discussion",
-        "No explicit out-of-scope section",
-        "Premise accepted without challenge",
-        "Sycophantic agreement without evidence-based pushback",
-        "Hedged recommendations that avoid taking a position",
-        "Batching multiple scope issues into one question",
-        "Re-arguing for smaller scope after user rejects reduction"
-    ],
-    redFlags: [
-        "No selected mode in artifact",
-        "Mode selected without heuristic justification",
-        "No discretion section (or explicit `None`) in artifact",
-        "No deferred/not-in-scope section",
-        "No user approval marker",
-        "Premise challenge missing or superficial",
-        "No implementation alternatives evaluated"
-    ],
-    policyNeedles: ["Scope mode", "In Scope", "Out of Scope", "Discretion Areas", "NOT in scope", "Premise Challenge"],
-    artifactFile: "02-scope.md",
-    next: "design",
-    reviewSections: [
-        {
-            title: "Scope Boundary Audit",
-            evaluationPoints: [
-                "Are all in-scope items justified by the problem statement?",
-                "Are any in-scope items actually solving a proxy problem instead of the real one?",
-                "Could any in-scope item be deferred without blocking the core objective?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Deferred Items Review",
-            evaluationPoints: [
-                "Does each deferred item have a one-line rationale?",
-                "Are any deferred items actually blockers for the core scope?",
-                "Will deferring these items create technical debt that is expensive to unwind?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Risk and Reversibility Check",
-            evaluationPoints: [
-                "For each major scope decision: is it reversible?",
-                "What is the blast radius if this decision is wrong?",
-                "Are there hidden dependencies between in-scope and out-of-scope items?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Existing-Code Reuse Check",
-            evaluationPoints: [
-                "Has every sub-problem been mapped to existing code?",
-                "Is the plan rebuilding anything that already exists?",
-                "Are there integration opportunities that reduce new code?",
-                "Have you searched for built-in or library solutions before scoping custom work?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Error & Rescue Scope Check",
-            evaluationPoints: [
-                "For every new capability: what breaks if it fails?",
-                "Is failure detection in scope or deferred? If deferred, is that acceptable?",
-                "Are there rescue/fallback paths for critical user journeys?",
-                "Is observability (logging, metrics, alerts) explicitly in or out of scope?"
-            ],
-            stopGate: true
-        }
-    ],
-    completionStatus: ["DONE", "DONE_WITH_CONCERNS", "BLOCKED"],
-    crossStageTrace: {
-        readsFrom: [".cclaw/artifacts/01-brainstorm.md"],
-        writesTo: [".cclaw/artifacts/02-scope.md"],
-        traceabilityRule: "Every scope boundary must be traceable to a brainstorm decision. Every downstream design choice must stay within the scope contract."
-    },
-    artifactValidation: [
-        { section: "Prime Directives", required: true, validationRule: "For each scoped capability: named failure modes, explicit error surface, four data-flow paths, interaction edge cases, observability expectations, and deferred-item handling." },
-        { section: "Premise Challenge", required: true, validationRule: "Must contain explicit answers to: right problem? direct path? what if nothing?" },
-        { section: "Requirements", required: true, validationRule: "Table of stable requirement IDs (R1, R2, R3…) one per row with observable outcome, priority, and source. IDs are assigned once and never renumbered across scope/design/spec/plan/review; dropped requirements stay with Priority `DROPPED`." },
-        { section: "Implementation Alternatives", required: true, validationRule: "2-3 options with Name, Summary, Effort, Risk, Pros, Cons, and Reuses. Must include minimal viable and ideal architecture options." },
-        { section: "Scope Mode", required: true, validationRule: "Must state selected mode and rationale with default heuristic justification." },
-        { section: "Mode-Specific Analysis", required: true, validationRule: "Must document the analysis matching the selected scope mode: EXPAND (10x and delight opportunities), SELECTIVE (hold-scope baseline then cherry-picked expansions), HOLD (minimum-change-set hardening), REDUCE (ruthless cuts and follow-up split)." },
-        { section: "In Scope / Out of Scope", required: true, validationRule: "Two separate explicit lists. Out-of-scope must not be empty." },
-        { section: "Discretion Areas", required: true, validationRule: "Explicit list of implementer decision zones, or 'None' if scope is fully locked." },
-        { section: "Deferred Items", required: true, validationRule: "Each item has one-line rationale. If empty, state 'None' explicitly." },
-        { section: "Error & Rescue Registry", required: true, validationRule: "Each scoped capability has: failure mode, detection method, fallback decision." },
-        { section: "Completion Dashboard", required: true, validationRule: "Lists checklist findings, count of resolved decisions, and unresolved decisions (or 'None')." },
-        { section: "Scope Summary", required: true, validationRule: "Clean summary: mode, strongest challenges, recommended path, accepted scope, deferred, excluded." },
-        { section: "Dream State Mapping", required: false, validationRule: "If present (complex projects): CURRENT STATE, THIS PLAN, 12-MONTH IDEAL, and alignment verdict." },
-        { section: "Temporal Interrogation", required: false, validationRule: "If present (complex projects): timeline simulation table with decision pressures and lock-now vs defer verdicts." }
-    ]
-};
-// ---------------------------------------------------------------------------
-// DESIGN — reference: gstack Eng review
-// ---------------------------------------------------------------------------
-const DESIGN = {
-    stage: "design",
-    skillFolder: "engineering-design-lock",
-    skillName: "engineering-design-lock",
-    skillDescription: "Engineering lock-in stage. Build a concrete technical spine before spec and planning, with section-by-section interactive review.",
-    hardGate: "Do NOT write implementation code. This stage produces design decisions and architecture documents only. No code changes, no scaffolding, no test files.",
-    ironLaw: "NO DESIGN DECISION WITHOUT A LABELED DIAGRAM, A REJECTED ALTERNATIVE, AND A NAMED FAILURE MODE.",
-    purpose: "Lock architecture, data flow, failure modes, and test/performance expectations through rigorous interactive review.",
-    whenToUse: [
-        "After scope contract approval",
-        "Before writing final spec and execution plan",
-        "When architecture risks need explicit treatment"
-    ],
-    whenNotToUse: [
-        "Scope mode and boundaries are still unresolved",
-        "The change is docs-only or metadata-only with no architecture impact",
-        "Implementation has already started and requires review instead of design lock"
-    ],
-    checklist: [
-        "Trivial-Change Escape Hatch — If scope artifact shows ≤3 files, zero new interfaces, and no cross-module data flow, skip full review sections. Produce a mini-design: one paragraph of rationale, list of changed files, one risk to watch. Proceed to spec.",
-        "Design Doc Check — read existing design docs, scope artifact, brainstorm artifact. If a design doc exists that covers this area, check for 'Supersedes:' and use the latest. Use upstream artifacts as source of truth.",
-        "Codebase Investigation — Before any design decision, read the actual code in the blast radius. List every file that will be touched, its current responsibilities, and existing patterns (error handling, naming, test style). Design must conform to discovered patterns, not impose new ones without justification.",
-        "Step 0: Scope Challenge — what existing code solves sub-problems? Minimum change set? Complexity check: 8+ files or 2+ new services = complexity smell → flag for possible scope reduction.",
-        "Search Before Building — For each technical choice (library, pattern, architecture), search for existing solutions. Label findings: Layer 1 (exact match), Layer 2 (partial match, needs adaptation), Layer 3 (inspiration only), EUREKA (unexpected perfect solution). Default to existing before custom.",
-        "Architecture Review — system design, component boundaries, data flow, scaling, security architecture. For each new codepath: one realistic production failure scenario. **Mandatory:** produce at least one architecture diagram (ASCII, Mermaid, or tool-generated) showing component boundaries and data flow direction. Apply the **Visual Communication rules** (see below) — an unlabeled or generic diagram is worse than no diagram, because it pretends to encode decisions it does not.",
-        "Code Quality Review — code organization, DRY violations, error handling patterns, over/under-engineering assessment.",
-        "Test Review — diagram every new flow, data path, error path. For each: what test type covers it? Does one exist? What is the gap? Produce test plan artifact.",
-        "Performance Review — N+1 queries, memory concerns, caching opportunities, slow code paths. What breaks at 10x load? At 100x?",
-        "Parallelization Strategy — If multiple independent modules, produce dependency table: which can be built in parallel? Where are conflict risks? Flag shared-state modules.",
-        "Unresolved Decisions — List any design decisions that could not be resolved in this session. For each: what information is missing? Who can provide it? What is the default if no answer comes?",
-        "Distribution Check — If the plan creates new artifact types (packages, CLI tools, configs), document the build/publish story. How does it reach the user?",
-        "Deferred Items Cross-Reference — Collect every item explicitly deferred during design review. Each must appear in the Unresolved Decisions table or in the upstream scope artifact's deferred list. No deferred item may exist only in conversation — it must be written down."
-    ],
-    interactionProtocol: [
-        "Review architecture decisions section-by-section.",
-        "For EACH issue found in a review section, present it ONE AT A TIME. Do NOT batch multiple issues.",
-        "For each issue: use the Decision Protocol — describe concretely with file/line references, present labeled options (A/B/C) with trade-offs, effort estimate (S/M/L/XL), risk level (Low/Med/High), and mark one as (recommended). Do NOT use a numeric Completeness rubric; recommend the option that best covers architecture, data-flow, failure-modes, test, and perf review concerns for the issue with the lowest risk. If AskQuestion/AskUserQuestion is available, send exactly ONE question per call, validate fields against runtime schema, and on schema error immediately fall back to plain-text question instead of retrying guessed payloads.",
-        "Only proceed to the next review section after ALL issues in the current section are resolved.",
-        "If a section has no issues, say 'No issues found' and move on.",
-        "Do not skip failure-mode mapping.",
-        "For design baseline approval: present the full baseline. **STOP.** Do NOT proceed until user explicitly approves the design.",
-        "Take a firm position on every recommendation. Do NOT hedge with 'it depends' or 'you could do either'. State your opinion, then justify it.",
-        "Use pushback patterns for weak framing: if the user says 'it's just a small change', respond with 'small changes to shared interfaces have outsized blast radius — let's map it'. If 'we'll refactor later', respond with 'later never comes — show me the refactor ticket or do it now'.",
-        "When the user's proposed architecture is suboptimal, say so directly. Offer the alternative with concrete trade-offs, do not bury criticism in praise.",
-        "When encountering ambiguity, classify it before acting: (A) ask user for missing info, (B) enumerate interpretations and pick one with justification, (C) propose hypothesis with validation path. Do NOT silently resolve ambiguity."
-    ],
-    process: [
-        "Read upstream artifacts (brainstorm, scope).",
-        "Investigate codebase: read files in blast radius, catalogue current patterns and responsibilities.",
-        "Run Step 0 scope challenge: existing code leverage, minimum change set, complexity check.",
-        "Walk through each review section interactively.",
-        "Define architecture boundaries and ownership.",
-        "Describe data flow and state transitions with edge paths.",
-        "Map failure modes and recovery strategy.",
-        "Define test coverage strategy and performance budget.",
-        "Produce required outputs: NOT-in-scope section, What-already-exists section, diagrams, failure mode table.",
-        "Produce completion dashboard: list every review section with status (clear / issues-found-resolved / issues-open), count of decisions made, and list of unresolved items.",
-        "Write design lock artifact for downstream spec/plan."
-    ],
-    requiredGates: [
-        { id: "design_codebase_investigated", description: "Blast-radius files read and current patterns catalogued." },
-        { id: "design_scope_challenge_done", description: "Step 0 scope challenge completed with existing-code mapping." },
-        { id: "design_architecture_locked", description: "Architecture boundaries are explicit and approved." },
-        { id: "design_data_flow_mapped", description: "Data/state flow includes edge-case paths." },
-        { id: "design_failure_modes_mapped", description: "Failure modes and mitigations are documented." },
-        { id: "design_test_and_perf_defined", description: "Test strategy and performance budget are defined." }
-    ],
-    requiredEvidence: [
-        "Artifact written to `.cclaw/artifacts/03-design.md`.",
-        "Failure-mode table exists with mitigations.",
-        "Test strategy includes unit/integration/e2e expectations.",
-        "NOT-in-scope section produced.",
-        "What-already-exists section produced.",
-        "Completion dashboard lists every review section status, decision count, and unresolved items (or 'None')."
-    ],
-    inputs: ["scope contract", "system constraints", "non-functional requirements"],
-    requiredContext: [
-        "existing architecture and boundaries",
-        "operational constraints",
-        "security and reliability expectations"
-    ],
-    researchPlaybooks: [
-        "research/framework-docs-lookup.md",
-        "research/best-practices-lookup.md"
-    ],
-    outputs: [
-        "architecture lock",
-        "risk and failure map",
-        "test and performance baseline",
-        "NOT-in-scope section",
-        "What-already-exists section",
-        "design completion dashboard"
-    ],
-    blockers: [
-        "architecture ambiguity remains",
-        "failure modes not mapped",
-        "test/performance targets missing"
-    ],
-    exitCriteria: [
-        "design baseline approved",
-        "all review sections completed",
-        "required gates marked satisfied",
-        "completion dashboard present with all review-section statuses",
-        "artifact complete for spec handoff"
-    ],
-    antiPatterns: [
-        "Architecture deferred to implementation phase",
-        "Missing data-flow edge cases",
-        "No performance budget for critical path",
-        "Batching multiple design issues into one question",
-        "Skipping review sections because plan seems simple",
-        "Agreeing with user's architecture choice without evaluating alternatives",
-        "Hedging every recommendation with 'it depends' instead of taking a position"
-    ],
-    redFlags: [
-        "No explicit architecture boundary section",
-        "No failure recovery strategy",
-        "No defined test/perf baseline",
-        "Review sections skipped or condensed",
-        "No NOT-in-scope output section",
-        "No What-already-exists output section",
-        "Design decisions made without reading the actual code first"
-    ],
-    policyNeedles: [
-        "Architecture",
-        "Data Flow",
-        "Failure Modes and Mitigation",
-        "Performance Budget",
-        "One issue at a time"
-    ],
-    artifactFile: "03-design.md",
-    next: "spec",
-    reviewSections: [
-        {
-            title: "Architecture Review",
-            evaluationPoints: [
-                "System design and component boundaries",
-                "Dependency graph and coupling concerns",
-                "Data flow patterns and potential bottlenecks",
-                "Scaling characteristics and single points of failure",
-                "Security architecture (auth, data access, API boundaries)",
-                "For each new codepath: one realistic production failure scenario"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Code Quality Review",
-            evaluationPoints: [
-                "Code organization and module structure",
-                "DRY violations — flag aggressively",
-                "Error handling patterns and missing edge cases",
-                "Over-engineered or under-engineered areas",
-                "Existing diagrams in touched files — still accurate?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Test Review",
-            evaluationPoints: [
-                "Diagram every new UX flow, data flow, codepath, background job, integration, error path",
-                "For each: what type of test covers it? Does one exist? What is the gap?",
-                "Coverage expectations: unit, integration, e2e split"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Performance Review",
-            evaluationPoints: [
-                "N+1 queries and database access patterns",
-                "Memory-usage concerns",
-                "Caching opportunities",
-                "Slow or high-complexity code paths",
-                "What breaks at 10x load? At 100x?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Distribution & Delivery Review",
-            evaluationPoints: [
-                "If new artifact types are created (packages, CLI, configs): is the build/publish story documented?",
-                "Are there new dependencies that need version pinning?",
-                "Does the change affect existing consumers (APIs, shared modules)?",
-                "Is backwards compatibility maintained or is a migration needed?"
-            ],
-            stopGate: false
-        }
-    ],
-    completionStatus: ["DONE", "DONE_WITH_CONCERNS", "BLOCKED"],
-    crossStageTrace: {
-        readsFrom: [".cclaw/artifacts/01-brainstorm.md", ".cclaw/artifacts/02-scope.md"],
-        writesTo: [".cclaw/artifacts/03-design.md"],
-        traceabilityRule: "Every architecture decision must trace to a scope boundary. Every downstream spec requirement must trace to a design decision."
-    },
-    artifactValidation: [
-        { section: "Codebase Investigation", required: true, validationRule: "Must list blast-radius files with current responsibilities and discovered patterns." },
-        { section: "Search Before Building", required: true, validationRule: "For each technical choice: Layer 1 (exact match), Layer 2 (partial match), Layer 3 (inspiration), EUREKA labels with reuse-first default." },
-        { section: "Architecture Boundaries", required: true, validationRule: "Must list component boundaries with ownership." },
-        { section: "Architecture Diagram", required: true, validationRule: "At least one diagram (ASCII, Mermaid, or image) showing component boundaries and data flow direction. Diagram must: (1) label every node with a concrete component name (no generic 'Service A/B'), (2) label every arrow with the action or message (no unlabeled arrows), (3) mark direction of data flow explicitly, (4) distinguish synchronous from asynchronous edges (e.g. solid vs dashed, or `sync:` / `async:` prefix), (5) show at least one failure edge or degraded-mode branch when the system has one." },
-        { section: "Data Flow", required: true, validationRule: "Must include happy path, nil input, empty input, upstream error paths." },
-        { section: "Failure Mode Table", required: true, validationRule: "Each failure mode has: trigger, detection, mitigation, user impact." },
-        { section: "Test Strategy", required: true, validationRule: "Must define unit/integration/e2e expectations with coverage targets." },
-        { section: "Performance Budget", required: true, validationRule: "For each critical path: metric name, target threshold, and measurement method." },
-        { section: "What Already Exists", required: true, validationRule: "For each sub-problem: existing code/library found (Layer 1-3/EUREKA label), reuse decision, and adaptation needed." },
-        { section: "NOT in scope", required: true, validationRule: "Work considered and explicitly deferred with one-line rationale." },
-        { section: "Parallelization Strategy", required: false, validationRule: "If multi-module: dependency table, parallel lanes, conflict flags." },
-        { section: "Unresolved Decisions", required: false, validationRule: "If any: what info is missing, who provides it, default if unanswered." },
-        { section: "Interface Contracts", required: false, validationRule: "If present: for each module boundary list produces (outputs) and consumes (inputs) with data types." },
-        { section: "Patterns to Mirror", required: false, validationRule: "If present: list discovered codebase patterns to follow, with file references and rationale for each." },
-        { section: "Completion Dashboard", required: true, validationRule: "Lists every review section with status (clear / issues-found-resolved / issues-open), decision count, and unresolved items (or 'None')." }
-    ],
-    trivialOverrideSections: ["Architecture Boundaries", "NOT in scope", "Completion Dashboard"]
-};
-// ---------------------------------------------------------------------------
-// SPEC
-// ---------------------------------------------------------------------------
-const SPEC = {
-    stage: "spec",
-    skillFolder: "specification-authoring",
-    skillName: "specification-authoring",
-    skillDescription: "Specification stage. Produce measurable, testable requirements without ambiguity.",
-    hardGate: "Do NOT plan tasks or write implementation code. This stage produces a specification document only. Every requirement must be expressed in observable, testable terms.",
-    ironLaw: "EVERY ACCEPTANCE CRITERION MUST BE OBSERVABLE AND TESTABLE — OR IT DOES NOT EXIST.",
-    purpose: "Create a testable specification aligned with approved design and constraints.",
-    whenToUse: [
-        "After design lock",
-        "Before planning and implementation",
-        "When acceptance criteria must be measurable"
-    ],
-    whenNotToUse: [
-        "Design decisions are still unresolved or disputed",
-        "The task is implementation-only cleanup with unchanged behavior",
-        "You still need to challenge scope rather than author requirements"
-    ],
-    checklist: [
-        "Read upstream — load design artifact and scope contract. Cross-reference architecture decisions.",
-        "Define measurable acceptance criteria — each criterion must be observable and falsifiable. No vague adjectives.",
-        "Capture edge cases — for each criterion, define at least one boundary condition and one error condition.",
-        "Document constraints and assumptions — regulatory, system, integration, and performance boundaries. Surface implicit assumptions explicitly.",
-        "Confirm testability — for each acceptance criterion, describe the test that would prove it. If untestable, rewrite the criterion.",
-        "Write spec artifact and request user approval — wait for explicit confirmation before proceeding."
-    ],
-    interactionProtocol: [
-        "Express each requirement in observable terms.",
-        "Resolve ambiguity before moving to plan. Challenge vague language.",
-        "Capture assumptions explicitly, not implicitly.",
-        "Require user confirmation on the written spec. **STOP.** Do NOT proceed to plan until user approves.",
-        "For each criterion, ask: how would you test this? If the answer is unclear, rewrite.",
-        "When encountering ambiguity, classify it before acting: (A) ask user for missing info, (B) enumerate interpretations and pick one with justification, (C) propose hypothesis with validation path. Do NOT silently resolve ambiguity."
-    ],
-    process: [
-        "Define measurable acceptance criteria.",
-        "Capture constraints, assumptions, and edge cases.",
-        "Build testability map: criterion -> test description.",
-        "Confirm testability for each criterion.",
-        "Write spec artifact and request approval."
-    ],
-    requiredGates: [
-        { id: "spec_acceptance_measurable", description: "Acceptance criteria are measurable and observable." },
-        { id: "spec_edge_cases_documented", description: "Boundary and error conditions are defined for each criterion." },
-        { id: "spec_constraints_documented", description: "Constraints and assumptions are explicit." },
-        { id: "spec_testability_confirmed", description: "Each criterion has a described test method." },
-        { id: "spec_user_approved", description: "User approved the final written spec." }
-    ],
-    requiredEvidence: [
-        "Artifact written to `.cclaw/artifacts/04-spec.md`.",
-        "Each acceptance criterion maps to a testable outcome.",
-        "Edge cases documented per criterion.",
-        "Approval marker captured in artifact."
-    ],
-    inputs: ["design artifact", "business constraints", "quality requirements"],
-    requiredContext: [
-        "design lock baseline",
-        "regulatory or system boundaries",
-        "integration constraints"
-    ],
-    outputs: [
-        "measurable specification",
-        "acceptance-to-testability map",
-        "approved spec artifact"
-    ],
-    blockers: [
-        "non-measurable criteria",
-        "constraints missing",
-        "open ambiguities remain"
-    ],
-    exitCriteria: [
-        "spec approved by user",
-        "required gates marked satisfied",
-        "plan-ready acceptance mapping exists",
-        "testability confirmed for all criteria"
-    ],
-    antiPatterns: [
-        "High-level goals without measurable outcomes",
-        "Implicit assumptions",
-        "Proceeding to plan before approval",
-        "Using vague adjectives (fast, intuitive, robust) without thresholds"
-    ],
-    redFlags: [
-        "Criteria use vague language (fast, intuitive, robust) without thresholds",
-        "No explicit assumptions section",
-        "No approval record",
-        "No testability mapping",
-        "Edge cases missing or deferred"
-    ],
-    policyNeedles: ["Acceptance Criteria", "Constraints", "Testability", "approved spec", "Edge Cases"],
-    artifactFile: "04-spec.md",
-    next: "plan",
-    reviewSections: [
-        {
-            title: "Acceptance Criteria Audit",
-            evaluationPoints: [
-                "Is every criterion observable (can you point to evidence of pass/fail)?",
-                "Is every criterion measurable (numeric threshold or boolean outcome)?",
-                "Is every criterion falsifiable (can you describe what failure looks like)?",
-                "Does every criterion trace to a design decision (Design Decision Ref)?",
-                "Are there any vague adjectives (fast, intuitive, robust) without thresholds?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Testability Audit",
-            evaluationPoints: [
-                "Does every criterion have a concrete test description in the Testability Map?",
-                "Does every test specify a verification approach (unit, integration, e2e, manual)?",
-                "Does every test include a runnable command or manual steps?",
-                "Are edge cases (boundary + error) defined for every criterion?",
-                "Can you run every verification command right now and get a meaningful result?"
-            ],
-            stopGate: true
-        }
-    ],
-    completionStatus: ["DONE", "DONE_WITH_CONCERNS", "BLOCKED"],
-    crossStageTrace: {
-        readsFrom: [".cclaw/artifacts/03-design.md", ".cclaw/artifacts/02-scope.md"],
-        writesTo: [".cclaw/artifacts/04-spec.md"],
-        traceabilityRule: "Every acceptance criterion must trace to a design decision. Every downstream plan task must trace to a spec criterion."
-    },
-    artifactValidation: [
-        { section: "Acceptance Criteria", required: true, validationRule: "Each criterion is observable, measurable, and falsifiable. Table must include a Requirement Ref column linking to R# IDs in 02-scope.md and a Design Decision Ref column tracing back to design artifact. AC IDs (AC-1, AC-2…) are stable across revisions — dropped ACs stay with Priority `DROPPED`." },
-        { section: "Edge Cases", required: true, validationRule: "At least one boundary and one error condition per criterion." },
-        { section: "Constraints and Assumptions", required: true, validationRule: "All implicit assumptions surfaced. Constraints have sources." },
-        { section: "Testability Map", required: true, validationRule: "Each criterion maps to a concrete test description with verification approach (unit, integration, e2e, manual) and command or manual steps." },
-        { section: "Vague to Fixed", required: false, validationRule: "If present: table with original vague wording and rewritten observable/testable version for each ambiguous requirement." },
-        { section: "Non-Functional Requirements", required: false, validationRule: "If present: performance thresholds, security constraints, scalability limits, reliability targets with measurable values." },
-        { section: "Interface Contracts", required: false, validationRule: "If present: for each module boundary list produces (outputs) and consumes (inputs) with data types." },
-        { section: "Approval", required: true, validationRule: "Explicit user approval marker present." }
-    ]
-};
-// ---------------------------------------------------------------------------
-// PLAN
-// ---------------------------------------------------------------------------
-const PLAN = {
-    stage: "plan",
-    skillFolder: "planning-and-task-breakdown",
-    skillName: "planning-and-task-breakdown",
-    skillDescription: "Execution planning stage with strict confirmation gate before implementation.",
-    hardGate: "Do NOT write code or tests. Planning only. This stage produces a task graph and execution order. WAIT_FOR_CONFIRM before any handoff to implementation.",
-    ironLaw: "EVERY TASK IS 2–5 MINUTES, FULLY SPELLED OUT, AND CARRIES A STABLE ID — NO PLACEHOLDERS, NO ‘ETC.’.",
-    purpose: "Create small executable tasks with dependencies and pause for explicit user confirmation.",
-    whenToUse: [
-        "After spec approval",
-        "Before writing tests or implementation",
-        "When delivery path and dependency order are needed"
-    ],
-    whenNotToUse: [
-        "Specification is unapproved or lacks measurable acceptance criteria",
-        "Execution is already in TDD stage with active slice evidence",
-        "The request is only release packaging with no task decomposition needed"
-    ],
-    checklist: [
-        "Read upstream — load spec, design, and scope artifacts. Cross-reference acceptance criteria.",
-        "Build dependency graph — identify task ordering, parallel opportunities, and blocking dependencies.",
-        "Group tasks into dependency waves — wave N+1 cannot start until wave N has verification evidence.",
-        "Slice into vertical tasks — each task targets 2-5 minutes, produces one testable outcome, and touches one coherent area.",
-        "Attach verification — every task has an acceptance criterion mapping and a concrete verification command.",
-        "Define checkpoints — mark points where progress should be validated before continuing.",
-        "WAIT_FOR_CONFIRM — write plan artifact and explicitly pause. **STOP.** Do NOT proceed until user confirms. Then update `flow-state.json` and tell user to run `/cc-next`."
-    ],
-    interactionProtocol: [
-        "Plan in read-only mode relative to implementation.",
-        "Split work into small vertical slices (target 2-5 minute tasks).",
-        "Publish explicit dependency waves with entry and exit checks for each wave.",
-        "Attach verification step to every task.",
-        "Enforce WAIT_FOR_CONFIRM: present the plan summary with options (A) Approve / (B) Revise / (C) Reject.",
-        "**STOP.** Do NOT proceed until user explicitly approves. Then update `flow-state.json` and tell user to run `/cc-next`."
-    ],
-    process: [
-        "Build dependency graph and ordered slices.",
-        "Group slices into execution waves and define gate criteria per wave.",
-        "Define each task with acceptance mapping and verification commands.",
-        "Record checkpoints and blockers.",
-        "Write plan artifact and pause at WAIT_FOR_CONFIRM."
-    ],
-    requiredGates: [
-        { id: "plan_tasks_sliced_2_5_min", description: "Tasks are small, executable slices." },
-        { id: "plan_dependency_graph_written", description: "Dependency graph and order are explicit." },
-        { id: "plan_dependency_waves_defined", description: "Tasks are grouped into executable waves with gate checks." },
-        { id: "plan_verification_steps_defined", description: "Each task has verification guidance." },
-        { id: "plan_acceptance_mapped", description: "Each task maps to a spec acceptance criterion." },
-        { id: "plan_wait_for_confirm", description: "Execution blocked until explicit user confirmation." }
-    ],
-    requiredEvidence: [
-        "Artifact written to `.cclaw/artifacts/05-plan.md`.",
-        "Task list includes acceptance mapping.",
-        "Dependency graph documented.",
-        "Dependency waves documented with wave-by-wave verification gates.",
-        "WAIT_FOR_CONFIRM status recorded."
-    ],
-    inputs: ["approved spec", "codebase context", "delivery constraints"],
-    requiredContext: [
-        "spec acceptance criteria",
-        "current architecture",
-        "known technical debt and dependencies"
-    ],
-    outputs: ["task graph", "dependency wave plan", "ordered plan", "explicit confirmation checkpoint"],
-    blockers: [
-        "tasks too broad",
-        "dependency uncertainty unresolved",
-        "wave boundaries are unclear",
-        "no explicit confirmation"
-    ],
-    exitCriteria: [
-        "plan quality gates complete",
-        "WAIT_FOR_CONFIRM present and unresolved until user approves",
-        "artifact ready for TDD execution",
-        "acceptance mapping complete"
-    ],
-    antiPatterns: [
-        "Horizontal decomposition without end-to-end slices",
-        "Tasks without verification steps",
-        "Starting execution before approval",
-        "Tasks that touch multiple unrelated areas"
-    ],
-    redFlags: [
-        "No dependency graph",
-        "No WAIT_FOR_CONFIRM marker",
-        "No explicit dependency waves",
-        "Tasks exceed one coherent outcome",
-        "No acceptance mapping"
-    ],
-    policyNeedles: ["WAIT_FOR_CONFIRM", "Task Graph", "Dependency Waves", "Acceptance Mapping", "verification steps"],
-    artifactFile: "05-plan.md",
-    next: "tdd",
-    reviewSections: [
-        {
-            title: "Task Decomposition Audit",
-            evaluationPoints: [
-                "Does every task target a single coherent area (vertical slice)?",
-                "Can each task be completed in 2-5 minutes?",
-                "Does every task have an acceptance criterion link and verification command?",
-                "Are there tasks that touch multiple unrelated areas?",
-                "Would a new engineer understand and start each task within two minutes?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Wave Completeness Audit",
-            evaluationPoints: [
-                "Does every task belong to exactly one wave?",
-                "Does each wave have a verification gate?",
-                "Are wave dependencies explicit and acyclic?",
-                "Is the acceptance mapping complete — every spec criterion covered?",
-                "Are there hidden dependencies between tasks in different waves?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Five-Minute Budget + No-Placeholders Audit",
-            evaluationPoints: [
-                "Does every task carry an explicit minutes estimate (e.g. `[~3m]`) and does every estimate fit the 2-to-5-minute budget? Estimates >5 minutes must be split.",
-                "Are all file paths, test commands, and verification commands copy-pasteable as written — no `TODO`, `TBD`, `FIXME`, `<fill-in>`, `<your-*-here>`, `xxx`, or ellipsis standing in for omitted args?",
-                "Does every acceptance-criterion reference resolve to a real R# / AC-### in the spec (not a blank link)?",
-                "If an estimate is genuinely uncertain (first-time integration, unfamiliar library), is the uncertainty named explicitly and scheduled as a spike task in wave 0, rather than hidden behind a large estimate?"
-            ],
-            stopGate: true
-        }
-    ],
-    completionStatus: ["DONE", "DONE_WITH_CONCERNS", "BLOCKED"],
-    crossStageTrace: {
-        readsFrom: [".cclaw/artifacts/04-spec.md", ".cclaw/artifacts/03-design.md", ".cclaw/artifacts/02-scope.md"],
-        writesTo: [".cclaw/artifacts/05-plan.md"],
-        traceabilityRule: "Every task must trace to a spec acceptance criterion. Every downstream RED test must trace to a plan task."
-    },
-    artifactValidation: [
-        { section: "Dependency Graph", required: true, validationRule: "Ordering and parallel opportunities explicit. No circular dependencies." },
-        { section: "Dependency Waves", required: true, validationRule: "Every task belongs to a wave. Each wave has an exit gate and dependency statement." },
-        { section: "Task List", required: true, validationRule: "Each task row includes ID, description, acceptance criterion, verification command, and effort estimate (S/M/L). Every task must also carry a minutes estimate within the 2-5 minute budget." },
-        { section: "Acceptance Mapping", required: true, validationRule: "Every spec criterion is covered by at least one task." },
-        { section: "Risk Assessment", required: false, validationRule: "If present: per-task or per-wave risk identification with likelihood, impact, and mitigation strategy." },
-        { section: "Boundary Map", required: false, validationRule: "If present: per-wave or per-task interface contracts listing what each task produces (exports) and consumes (imports) from other tasks." },
-        { section: "WAIT_FOR_CONFIRM", required: true, validationRule: "Explicit marker present. Status: pending until user approves." },
-        { section: "No-Placeholder Scan", required: false, validationRule: "If present: confirmation that a text scan for `TODO`, `TBD`, `FIXME`, `<fill-in>`, `<your-*-here>`, `xxx`, or bare ellipses has zero hits in the task list. A placeholder is a deferred decision masquerading as a plan." }
-    ]
-};
-// ---------------------------------------------------------------------------
-// TDD — RED → GREEN → REFACTOR cycle (merged test + build)
-// ---------------------------------------------------------------------------
-const TDD = {
-    stage: "tdd",
-    skillFolder: "test-driven-development",
-    skillName: "test-driven-development",
-    skillDescription: "Full TDD cycle: RED (failing tests), GREEN (minimal implementation), REFACTOR (cleanup). One plan slice at a time with strict traceability.",
-    hardGate: "Do NOT merge, ship, or skip review. Follow RED → GREEN → REFACTOR strictly for each plan slice. Do NOT write implementation code before RED tests exist. Do NOT skip the REFACTOR step.",
-    ironLaw: "NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST — THE RED FAILURE IS THE SPEC.",
-    purpose: "Implement features through the TDD cycle: write failing tests, make them pass with minimal code, then refactor.",
-    whenToUse: [
-        "After plan confirmation",
-        "For every behavior change in scope",
-        "Before review stage"
-    ],
-    whenNotToUse: [
-        "Plan approval is still pending WAIT_FOR_CONFIRM",
-        "The change is docs-only and does not alter behavior",
-        "The stage intent is review/ship sign-off rather than implementation"
-    ],
-    checklist: [
-        "Select plan slice — pick one task from the plan. Do not batch multiple tasks.",
-        "Map to acceptance criterion — identify the specific spec criterion this test proves.",
-        "RED: Write behavior-focused test — test the expected behavior, not implementation details. Tests MUST fail.",
-        "RED: Capture failure output — copy the exact failure output as RED evidence. Record in artifact.",
-        "GREEN: Minimal implementation — write the smallest code change that makes the RED tests pass. No extra features.",
-        "GREEN: Run full suite — execute ALL tests, not just the ones you wrote. The full suite must be GREEN.",
-        "GREEN: Verify no regressions — if any existing test breaks, fix the regression before proceeding.",
-        "REFACTOR: Improve code quality — without changing behavior. Document what you changed and why.",
-        "Record evidence — capture RED failure, GREEN output, and REFACTOR notes in the TDD artifact.",
-        "Annotate traceability — link to plan task ID and spec criterion.",
-        "Repeat for each slice — return to step 1 for the next plan slice."
-    ],
-    interactionProtocol: [
-        "Pick one planned slice at a time.",
-        "Write behavior-focused tests before changing implementation (RED).",
-        "Capture and store failing output as RED evidence.",
-        "Apply minimal change to satisfy RED tests (GREEN).",
-        "Run full suite, not partial checks, for GREEN validation.",
-        "Refactor without changing behavior and document rationale (REFACTOR).",
-        "Stop if regressions appear and fix before proceeding.",
-        "If a test passes unexpectedly, investigate: does the behavior already exist, or is the test wrong?"
-    ],
-    process: [
-        "Select slice and map to acceptance criterion.",
-        "Write test(s) that fail for expected reason (RED).",
-        "Run tests and capture failure output.",
-        "Implement smallest change needed for GREEN.",
-        "Run full tests and build checks.",
-        "Perform refactor pass preserving behavior.",
-        "Record RED, GREEN, and REFACTOR evidence in artifact.",
-        "Annotate traceability to plan task and spec criterion."
-    ],
-    requiredGates: [
-        { id: "tdd_red_test_written", description: "Failing tests exist before implementation changes." },
-        { id: "tdd_red_failure_captured", description: "Failure output is captured as evidence." },
-        { id: "tdd_trace_to_acceptance", description: "RED tests trace to explicit acceptance criteria." },
-        { id: "tdd_red_failure_reason_verified", description: "Failure is for the expected reason, not an unrelated error." },
-        { id: "tdd_green_full_suite", description: "Full relevant suite passes in GREEN state." },
-        { id: "tdd_refactor_completed", description: "Refactor pass completed with behavior preservation verified." },
-        { id: "tdd_refactor_notes_written", description: "Refactor decisions and outcomes are documented." },
-        { id: "tdd_traceable_to_plan", description: "Change traceability to plan slice is explicit." }
-    ],
-    requiredEvidence: [
-        "Artifact updated at `.cclaw/artifacts/06-tdd.md` with RED, GREEN, and REFACTOR sections.",
-        "Failing command output captured (RED).",
-        "Full test/build output recorded (GREEN).",
-        "Acceptance mapping documented.",
-        "Failure reason analysis recorded.",
-        "Refactor rationale captured.",
-        "Traceability to task identifier is documented."
-    ],
-    inputs: ["approved plan slice", "spec acceptance criterion", "test harness configuration", "coding standards and constraints"],
-    requiredContext: ["plan artifact", "spec artifact", "existing test patterns"],
-    outputs: ["failing test set", "passing implementation", "refactor evidence", "review-ready change set"],
-    blockers: [
-        "tests pass before behavior change (RED failure missing)",
-        "full suite not green",
-        "behavior changed during refactor",
-        "no evidence recorded"
-    ],
-    exitCriteria: [
-        "RED evidence exists and is traceable",
-        "GREEN evidence captured with full suite pass",
-        "REFACTOR evidence captured",
-        "required gates marked satisfied",
-        "traceability annotated"
-    ],
-    antiPatterns: [
-        "Writing code before failing test",
-        "Asserting implementation details instead of behavior",
-        "Big-bang implementation across multiple slices",
-        "Partial test runs presented as GREEN",
-        "Skipping evidence capture",
-        "Undocumented refactor changes",
-        "Adding features beyond what RED tests require"
-    ],
-    redFlags: [
-        "No failing test output (RED missing)",
-        "Implementation edits appear before RED evidence",
-        "No full-suite GREEN evidence",
-        "No refactor notes",
-        "Multiple tasks implemented in one pass without justification",
-        "Files changed outside current slice scope"
-    ],
-    policyNeedles: ["RED", "GREEN", "REFACTOR", "failing test", "full test suite", "acceptance criteria", "traceable to plan slice"],
-    artifactFile: "06-tdd.md",
-    next: "review",
-    reviewSections: [
-        {
-            title: "RED Evidence Audit",
-            evaluationPoints: [
-                "Does every slice have a captured failing test output?",
-                "Does each failure reason match the expected missing behavior (not a typo or config error)?",
-                "Were tests written BEFORE any production code for that slice?",
-                "Does each RED test assert observable behavior, not implementation details?",
-                "Is there a test for each acceptance criterion mapped in the plan?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "GREEN/REFACTOR Audit",
-            evaluationPoints: [
-                "Does GREEN evidence show a FULL suite pass (not partial)?",
-                "Is the GREEN implementation minimal — no features beyond what RED tests require?",
-                "Does the REFACTOR step preserve all existing behavior (no new failures)?",
-                "Are REFACTOR notes documented with rationale?",
-                "Is traceability complete: every change links to plan task ID and spec criterion?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Test Pyramid + Size Audit",
-            evaluationPoints: [
-                "Is the tests-added count skewed toward Small (unit) tests, with Medium and Large used only when a real boundary justifies the cost?",
-                "Does every newly added test declare a size class (Small / Medium / Large) — either inline in the test file or in the TDD artifact table?",
-                "Are Large tests reserved for genuine end-to-end user journeys (not substitutes for unit coverage)?",
-                "Has the slice avoided using Medium/Large tests to paper over testability problems that should be fixed at the design layer?"
-            ],
-            stopGate: false
-        },
-        {
-            title: "Prove-It Reproduction (bug-fix slices)",
-            evaluationPoints: [
-                "Does the artifact identify this slice as a bug fix, and if so, include a reproduction test checked in alongside the fix?",
-                "Is there captured RED evidence from running the reproduction WITHOUT the fix applied?",
-                "Is there captured GREEN evidence from the same reproduction AFTER the fix was applied?",
-                "Is there a note confirming the reproduction test fails again if the fix is reverted (or equivalent evidence that the test is actually pinned to this fix)?"
-            ],
-            stopGate: false
-        },
-        {
-            title: "State-over-Interaction + Beyoncé Coverage",
-            evaluationPoints: [
-                "Do assertions target observable state (return values, persisted data, HTTP responses, logs) rather than which internal helpers were called?",
-                "Are mocks/spies used only at true trust boundaries (network, filesystem, time, external services), not for module-internal collaborators?",
-                "For every public surface touched in this slice (exported API, CLI flag, config key, env var, exit code, schema field) — does at least one test observe it?",
-                "If a bug or review finding revealed an uncovered surface, was a test added alongside the fix, not just the code change?",
-                "Are interaction-style assertions (e.g. `toHaveBeenCalledWith` without a state assertion) justified by an explicit boundary comment, or flagged for follow-up?"
-            ],
-            stopGate: false
-        }
-    ],
-    completionStatus: ["DONE", "DONE_WITH_CONCERNS", "BLOCKED"],
-    crossStageTrace: {
-        readsFrom: [".cclaw/artifacts/05-plan.md", ".cclaw/artifacts/04-spec.md", ".cclaw/artifacts/03-design.md"],
-        writesTo: [".cclaw/artifacts/06-tdd.md"],
-        traceabilityRule: "Every RED test traces to a plan task. Every GREEN change traces to a RED test. Every plan task traces to a spec criterion. Design decisions inform test strategy. Evidence chain must be unbroken."
-    },
-    artifactValidation: [
-        { section: "RED Evidence", required: true, validationRule: "Failing test output captured per slice." },
-        { section: "Acceptance Mapping", required: true, validationRule: "Each RED test links to a plan task and spec criterion." },
-        { section: "Failure Analysis", required: true, validationRule: "Failure reason matches expected missing behavior." },
-        { section: "GREEN Evidence", required: true, validationRule: "Full suite pass output captured." },
-        { section: "REFACTOR Notes", required: true, validationRule: "What changed, why, behavior preservation confirmed." },
-        { section: "Traceability", required: true, validationRule: "Plan task ID and spec criterion linked." },
-        { section: "Verification Ladder", required: false, validationRule: "If present: per-slice verification tier (static, command, behavioral, human) with evidence for highest tier reached." },
-        { section: "Coverage Targets", required: false, validationRule: "If present: per-module or per-code-type coverage thresholds with current values and measurement commands." },
-        { section: "Test Pyramid Shape", required: false, validationRule: "If present: per-slice count of Small/Medium/Large tests added, to let reviewers verify the suite is not drifting top-heavy." },
-        { section: "Prove-It Reproduction", required: false, validationRule: "Required for bug-fix slices: original failing reproduction test (RED without fix), passing output with fix (GREEN), and a note confirming the test fails again if the fix is reverted." }
-    ],
-    waveExecutionAllowed: true
-};
-// ---------------------------------------------------------------------------
-// REVIEW — reference: superpowers code-review + gstack /review
-// ---------------------------------------------------------------------------
-const REVIEW = {
-    stage: "review",
-    skillFolder: "two-layer-review",
-    skillName: "two-layer-review",
-    skillDescription: "Two-layer review stage: spec compliance first, then code quality and production readiness. Section-by-section with severity discipline.",
-    hardGate: "Do NOT ship, merge, or release until both review layers complete with an explicit verdict. No exceptions for urgency. Critical blockers MUST be resolved before handoff.",
-    ironLaw: "NO SHIP VERDICT UNTIL BOTH REVIEW LAYERS COMPLETE AND EVERY CRITICAL IS RESOLVED OR EXPLICITLY ACCEPTED.",
-    purpose: "Validate that implementation matches spec and meets quality/security/performance bar through structured two-layer review.",
-    whenToUse: [
-        "After TDD stage completes",
-        "Before any ship action",
-        "When release risk must be assessed explicitly"
-    ],
-    whenNotToUse: [
-        "There is no implementation diff to review",
-        "TDD stage evidence is missing or stale",
-        "The goal is direct release execution without layered quality checks"
-    ],
-    checklist: [
-        "Diff Scope — Run `git diff` against base branch. If no diff, exit early with APPROVED (no changes to review). Scope the review to changed files unless blast-radius analysis requires wider inspection.",
-        "Change-Size Check — ~100 lines = normal. ~300 lines = consider splitting. ~1000+ lines = strongly recommend stacked PRs. Flag large diffs to the user.",
-        "Adversarial Trigger Check — compute changed-line count (`git diff --shortstat <base>..HEAD`), files-touched count, and whether trust boundaries changed (auth/secrets/external inputs/permissions). If `lines > 100` OR `files > 10` OR `trust boundary changed`, **dispatch a SECOND reviewer agent with the `adversarial-review` skill loaded** and reconcile its findings into the review army (treat the conditional dispatch as mandatory whenever the trigger holds; record the trigger that fired in the dashboard).",
-        "Load upstream evidence — read TDD artifact (RED + GREEN + REFACTOR), spec, and plan. Verify evidence chain is unbroken.",
-        "Layer 1: Spec Compliance — check every acceptance criterion against implementation. Verdict: pass/fail per criterion.",
-        "Layer 2a: Correctness — logic errors, race conditions, boundary violations, null handling.",
-        "Layer 2b: Security — input validation, auth boundaries, secrets exposure, injection vectors. **Mandatory:** also load and execute the `.cclaw/skills/security-audit/SKILL.md` utility skill (proactive pattern sweep across diff + touched modules, not just the diff itself) and merge findings into the review army. The Layer 2 security pass is not complete until the audit sweep records a finding count (0 acceptable) with file:line evidence for every Critical.",
-        "Layer 2c: Performance — N+1 queries, memory leaks, missing caching, hot paths.",
-        "Layer 2d: Architecture Fit — does the implementation match the locked design? Coupling, cohesion, interface contracts.",
-        "Layer 2e: External Safety — SQL safety, concurrency, secrets in logs, enum completeness (grep outside diff), LLM trust boundaries.",
-        "Review Army reconciliation — normalize findings into structured records, dedup by fingerprint, and mark multi-specialist confirmations.",
-        "Meta-Review — Were tests actually run? Do test names match what they test? Are there real assertions?",
-        "Classify findings — Critical (blocks ship), Important (should fix), Suggestion (optional improvement).",
-        "Produce verdict — APPROVED, APPROVED_WITH_CONCERNS, or BLOCKED."
-    ],
-    interactionProtocol: [
-        "Run Layer 1 (spec compliance) completely before starting Layer 2.",
-        "In each review section, present findings ONE AT A TIME. Do NOT batch.",
-        "Classify every finding as Critical, Important, or Suggestion.",
-        "For each Critical finding: use the Decision Protocol — present resolution options (A/B/C) with trade-offs, and mark one as (recommended). Do NOT use a numeric Completeness rubric; recommend the option that fully closes the finding with no carry-over risk and the smallest blast radius. If AskQuestion/AskUserQuestion is available, send exactly ONE question per call, validate fields against runtime schema, and on schema error immediately fall back to plain-text question instead of retrying guessed payloads.",
-        "Resolve all critical blockers before ship.",
-        "For final verdict: use AskQuestion/AskUserQuestion only if runtime schema is confirmed; otherwise collect verdict with a plain-text single-choice prompt (APPROVED / APPROVED_WITH_CONCERNS / BLOCKED).",
-        "**STOP.** Do NOT proceed to ship until the user provides an explicit verdict."
-    ],
-    process: [
-        "Layer 1: check acceptance criteria and requirement coverage.",
-        "Layer 2a: check correctness — logic, races, boundaries, null handling.",
-        "Layer 2b: check security — validation, auth, secrets, injection.",
-        "Layer 2c: check performance — queries, memory, caching, hot paths.",
-        "Layer 2d: check architecture fit — design compliance, coupling, interfaces.",
-        "Reconcile multi-agent findings into `.cclaw/artifacts/07-review-army.json` (dedup + confidence + conflict notes).",
-        "Classify and prioritize all findings.",
-        "Write review report artifact with explicit verdict."
-    ],
-    requiredGates: [
-        { id: "review_layer1_spec_compliance", description: "Spec compliance check completed with per-criterion verdict." },
-        { id: "review_layer2_correctness", description: "Correctness review completed." },
-        { id: "review_layer2_security", description: "Security review completed." },
-        { id: "review_layer2_performance", description: "Performance review completed." },
-        { id: "review_layer2_architecture", description: "Architecture fit review completed." },
-        { id: "review_severity_classified", description: "All findings are severity-tagged." },
-        { id: "review_criticals_resolved", description: "No unresolved critical blockers remain." },
-        { id: "review_army_json_valid", description: "07-review-army.json passes schema validation (validateReviewArmy)." },
-        { id: "review_completeness_scored", description: "Completeness score is computed and recorded (AC coverage, task coverage, slice coverage, adversarial pass)." },
-        { id: "review_security_audit_swept", description: "The security-audit utility skill was run against the diff scope and the modules it touches. Finding count (0 if clean) recorded in the review army with file:line evidence for every Critical." }
-    ],
-    requiredEvidence: [
-        "Artifact written to `.cclaw/artifacts/07-review.md`.",
-        "Artifact written to `.cclaw/artifacts/07-review-army.json`.",
-        "Layer 1 verdict captured with per-criterion pass/fail.",
-        "Layer 2 sections completed with findings.",
-        "Severity log includes critical/important/suggestion buckets.",
-        "Explicit final verdict: APPROVED, APPROVED_WITH_CONCERNS, or BLOCKED."
-    ],
-    inputs: ["implementation diff", "spec and plan artifacts", "test/build evidence"],
-    requiredContext: ["spec criteria", "tdd artifact", "rulebook constraints"],
-    outputs: ["review verdict", "severity-indexed findings", "reconciled review-army findings", "ship readiness decision"],
-    blockers: [
-        "layer 1 failed",
-        "critical findings unresolved",
-        "missing regression evidence"
-    ],
-    exitCriteria: [
-        "both layers completed",
-        "all review sections evaluated",
-        "critical blockers resolved",
-        "ship readiness explicitly stated"
-    ],
-    antiPatterns: [
-        "Single generic review without layered structure",
-        "No severity classification",
-        "Shipping with open criticals",
-        "Batching multiple findings into one report without individual resolution",
-        "Skipping Layer 2 sections because Layer 1 passed"
-    ],
-    redFlags: [
-        "No separate Layer 1/Layer 2 outcomes",
-        "No structured review-army reconciliation artifact",
-        "No critical bucket",
-        "No explicit ready/not-ready verdict",
-        "Review sections skipped or abbreviated",
-        "Findings not classified by severity"
-    ],
-    policyNeedles: ["Layer 1", "Layer 2", "Critical", "Review Army", "Ready to Ship", "One issue at a time"],
-    artifactFile: "07-review.md",
-    next: "ship",
-    reviewSections: [
-        {
-            title: "Layer 1: Spec Compliance",
-            evaluationPoints: [
-                "For each acceptance criterion: does the implementation satisfy it?",
-                "Are there spec requirements with no corresponding implementation?",
-                "Are there implementations with no corresponding spec requirement (scope creep)?",
-                "Is every edge case from the spec handled?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Layer 2a: Correctness",
-            evaluationPoints: [
-                "Logic errors and boundary violations",
-                "Race conditions and concurrency issues",
-                "Null/undefined handling",
-                "Error propagation and recovery paths"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Layer 2b: Security",
-            evaluationPoints: [
-                "Input validation completeness",
-                "Authorization boundary enforcement",
-                "Secrets exposure risk",
-                "Injection vector assessment"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Layer 2c: Performance",
-            evaluationPoints: [
-                "N+1 query patterns",
-                "Memory leak potential",
-                "Missing caching opportunities",
-                "Hot path complexity analysis"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Layer 2d: Architecture Fit",
-            evaluationPoints: [
-                "Does implementation match the locked design?",
-                "Coupling and cohesion assessment",
-                "Interface contract compliance",
-                "Unintended architectural drift"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Layer 2e: External Safety Checklist",
-            evaluationPoints: [
-                "SQL/database: parameterized queries, no raw string interpolation, migration safety",
-                "Concurrency: race conditions in shared state, lock ordering, timeout handling",
-                "Secrets: no hardcoded tokens, no secrets in logs, env vars for sensitive config",
-                "Enum/constant completeness: grep for sibling values OUTSIDE the diff — are all cases handled?",
-                "Trust boundaries: if LLM/AI output is used, is it validated before acting on it?"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Meta-Review: Verify the Verification",
-            evaluationPoints: [
-                "Were tests actually run (not just assumed to pass)?",
-                "Do the test names match what they actually test?",
-                "Is there test coverage for the specific changes in this diff?",
-                "Are there assertions, or do tests just run without checking results?"
-            ],
-            stopGate: false
-        }
-    ],
-    completionStatus: ["APPROVED", "APPROVED_WITH_CONCERNS", "BLOCKED"],
-    crossStageTrace: {
-        readsFrom: [".cclaw/artifacts/06-tdd.md", ".cclaw/artifacts/04-spec.md", ".cclaw/artifacts/05-plan.md"],
-        writesTo: [".cclaw/artifacts/07-review.md", ".cclaw/artifacts/07-review-army.json"],
-        traceabilityRule: "Review verdict must reference specific spec criteria and TDD evidence. Downstream ship stage must reference review verdict."
-    },
-    artifactValidation: [
-        { section: "Layer 1 Verdict", required: true, validationRule: "Per-criterion pass/fail with references." },
-        { section: "Layer 2 Findings", required: true, validationRule: "Each finding has severity, description, and resolution status." },
-        { section: "Review Army Contract", required: true, validationRule: "Structured findings include id/severity/confidence/fingerprint/reportedBy/status with dedup reconciliation summary." },
-        { section: "Review Readiness Dashboard", required: true, validationRule: "Includes a per-pass table (Layer 1 / Layer 2 / Adversarial / Schema) with a 'Completed at' column, a Delegation log snapshot block (path .cclaw/state/delegation-log.json with required/completed/waived/pending), a Staleness signal block (commit at last review pass and current commit), and a Headline with open critical blockers + ship recommendation. At minimum, the section text must contain the substrings 'Completed at', 'delegation-log.json', 'commit at last review pass', and 'Ship recommendation'." },
-        { section: "Completeness Score", required: true, validationRule: "Records AC coverage, task coverage, test-slice coverage, and adversarial-review pass status as numeric or boolean values. At minimum, a line like 'AC coverage: N/M' or 'AC coverage: 100%'." },
-        { section: "Severity Summary", required: true, validationRule: "Per-severity count lines for critical, important, and suggestion buckets." },
-        { section: "Final Verdict", required: true, validationRule: "Exactly one of: APPROVED, APPROVED_WITH_CONCERNS, BLOCKED." }
-    ]
-};
-// ---------------------------------------------------------------------------
-// SHIP — reference: superpowers finishing-a-development-branch + gstack /ship
-// ---------------------------------------------------------------------------
-const SHIP = {
-    stage: "ship",
-    skillFolder: "shipping-and-handoff",
-    skillName: "shipping-and-handoff",
-    skillDescription: "Release handoff stage with preflight checks, rollback readiness, and explicit finalization mode.",
-    hardGate: "Do NOT merge, push, or finalize without a passed preflight check, written rollback plan, and exactly one explicit finalization mode selected. No exceptions for urgency.",
-    ironLaw: "NO MERGE WITHOUT GREEN CI, A WRITTEN ROLLBACK, AND EXACTLY ONE SELECTED FINALIZATION MODE.",
-    purpose: "Prepare a safe release handoff with clear rollback and branch finalization decision.",
-    whenToUse: [
-        "After review passes with APPROVED or APPROVED_WITH_CONCERNS verdict",
-        "Before creating PR/merge/final branch action",
-        "When release notes and rollback plan are required"
-    ],
-    whenNotToUse: [
-        "Review verdict is BLOCKED or unresolved critical findings remain",
-        "Preflight checks cannot run and no approved exception exists",
-        "The request is still design/spec/implementation work, not release handoff"
-    ],
-    checklist: [
-        "Validate upstream gates — verify review verdict is APPROVED or APPROVED_WITH_CONCERNS. If BLOCKED, stop immediately.",
-        "Run preflight checks — tests pass, build succeeds, linter clean, type-check clean, no uncommitted changes. Every check must produce fresh output in this message.",
-        "Merge-base detection — identify the correct base branch. Run `git merge-base HEAD <base>`. If the base has diverged significantly, flag for rebase-first.",
-        "Re-run tests on merged result — if merging locally, run the full test suite AFTER the merge, not just before. Post-merge failures are common.",
-        "Generate release notes — summarize what changed, why, and what it affects. Reference spec criteria. Include: breaking changes, new dependencies, migration steps if any.",
-        "Write rollback plan — trigger conditions (what tells you it is broken), rollback steps (exact commands/git operations), and verification (how to confirm rollback worked).",
-        "Monitoring checklist — what should be watched after deploy? Error rates, latency, key business metrics. If no monitoring exists, flag it as a risk.",
-        "Select finalization mode — exactly ONE enum: (A) FINALIZE_MERGE_LOCAL, (B) FINALIZE_OPEN_PR, (C) FINALIZE_KEEP_BRANCH, (D) FINALIZE_DISCARD_BRANCH. For discard: list what will be deleted, require typed confirmation.",
-        "Execute finalization — perform the selected action. For merge: verify clean merge. For PR: include structured body (summary, test plan, rollback). For discard: verify deletion.",
-        "Worktree cleanup — if using git worktrees, clean up the worktree after merge/discard. Keep it only for 'keep branch' mode."
-    ],
-    interactionProtocol: [
-        "Run preflight checks before any release action.",
-        "Document release notes and rollback plan explicitly.",
-        "For finalization mode: use the Decision Protocol — present modes as labeled options (A/B/C/D) with consequences, and mark one as (recommended). Do NOT use a numeric Completeness rubric; recommend the mode that best addresses release blast-radius, rollback readiness, observability, and stakeholder communication — ties go to the most reversible option. If AskQuestion/AskUserQuestion is available, send exactly ONE question per call, validate fields against runtime schema, and on schema error immediately fall back to plain-text question instead of retrying guessed payloads.",
-        "Do not proceed if critical blockers remain from review.",
-        "**STOP.** Present finalization options and wait for user selection before executing any finalization action."
-    ],
-    process: [
-        "Validate review and test gates.",
-        "Run preflight: build, test, lint, uncommitted-changes check.",
-        "Generate release notes and rollback procedure.",
-        "Choose one finalization enum: FINALIZE_MERGE_LOCAL, FINALIZE_OPEN_PR, FINALIZE_KEEP_BRANCH, or FINALIZE_DISCARD_BRANCH.",
-        "Execute finalization action.",
-        "Write ship artifact with decision, rationale, and execution result."
-    ],
-    requiredGates: [
-        { id: "ship_review_verdict_valid", description: "Review verdict is APPROVED or APPROVED_WITH_CONCERNS." },
-        { id: "ship_preflight_passed", description: "Preflight checks passed or exceptions documented and approved." },
-        { id: "ship_release_notes_written", description: "Release notes are complete and accurate." },
-        { id: "ship_rollback_plan_ready", description: "Rollback trigger, steps, and verification are documented." },
-        { id: "ship_finalization_mode_selected", description: "Exactly one finalization action is selected." },
-        { id: "ship_finalization_executed", description: "Selected finalization action was executed and verified." },
-        { id: "ship_post_merge_tests", description: "Full test suite re-run on the merged result (not just the branch). Post-merge failures caught before release." }
-    ],
-    requiredEvidence: [
-        "Artifact written to `.cclaw/artifacts/08-ship.md`.",
-        "Release notes section is complete.",
-        "Rollback section includes trigger conditions, steps, and verification.",
-        "Finalization section shows exactly one selected enum token.",
-        "Execution result documented."
-    ],
-    inputs: ["review verdict", "test/build outputs", "release context"],
-    requiredContext: ["review artifact", "changelog scope", "deployment constraints"],
-    outputs: ["release package handoff", "rollback plan", "final branch decision"],
-    blockers: [
-        "review verdict is BLOCKED",
-        "critical review blockers remain",
-        "rollback plan missing",
-        "finalization mode not selected"
-    ],
-    exitCriteria: [
-        "preflight completed",
-        "rollback and release notes complete",
-        "finalization action explicitly chosen and executed"
-    ],
-    antiPatterns: [
-        "Shipping without rollback strategy",
-        "Implicit finalization decision",
-        "Bypassing preflight due to urgency",
-        "Selecting multiple finalization modes",
-        "Shipping with BLOCKED review verdict"
-    ],
-    redFlags: [
-        "No rollback trigger/steps",
-        "More than one finalization mode implied",
-        "No explicit preflight result",
-        "Review verdict not referenced",
-        "Finalization not executed, only planned"
-    ],
-    policyNeedles: [
-        "Pre-Ship Checks",
-        "Release Notes",
-        "Rollback Plan",
-        "FINALIZE_MERGE_LOCAL",
-        "FINALIZE_OPEN_PR",
-        "FINALIZE_KEEP_BRANCH",
-        "FINALIZE_DISCARD_BRANCH"
-    ],
-    artifactFile: "08-ship.md",
-    next: "done",
-    reviewSections: [
-        {
-            title: "Preflight Verification",
-            evaluationPoints: [
-                "Test suite: full run, all pass, output captured",
-                "Build: clean build, exit code 0",
-                "Lint/format: no violations",
-                "Type-check: no errors",
-                "Working tree: no uncommitted changes"
-            ],
-            stopGate: true
-        },
-        {
-            title: "Release Readiness",
-            evaluationPoints: [
-                "Release notes are accurate and reference spec criteria",
-                "Breaking changes are documented with migration steps",
-                "Rollback plan has trigger, steps, and verification",
-                "If applicable: monitoring/alerting is in place for the change"
-            ],
-            stopGate: true
-        }
-    ],
-    completionStatus: ["SHIPPED", "SHIPPED_WITH_EXCEPTIONS", "BLOCKED"],
-    crossStageTrace: {
-        readsFrom: [".cclaw/artifacts/07-review.md", ".cclaw/artifacts/06-tdd.md", ".cclaw/artifacts/05-plan.md", ".cclaw/artifacts/04-spec.md"],
-        writesTo: [".cclaw/artifacts/08-ship.md"],
-        traceabilityRule: "Ship artifact must reference review verdict and resolution status. Release notes must reference spec criteria. Rollback plan must reference specific changes that could fail."
-    },
-    artifactValidation: [
-        { section: "Preflight Results", required: true, validationRule: "Build, test, lint, type-check results captured with fresh output. Exceptions documented if any." },
-        { section: "Release Notes", required: true, validationRule: "What changed, why, impact. References spec criteria. Breaking changes flagged." },
-        { section: "Rollback Plan", required: true, validationRule: "Trigger conditions, rollback steps (exact commands), verification steps." },
-        { section: "Monitoring", required: false, validationRule: "If applicable: what metrics/logs to watch post-deploy. Risk note if no monitoring." },
-        { section: "Finalization", required: true, validationRule: "Exactly one finalization enum token selected. Execution result documented. Worktree cleaned if applicable." },
-        { section: "Completion Status", required: false, validationRule: "If present: exactly one of SHIPPED, SHIPPED_WITH_EXCEPTIONS, BLOCKED. Exceptions documented when applicable." },
-        { section: "Compound Step", required: false, validationRule: "Optional retrospective: at least one bullet of the form 'Insight: ... | Action: append [compound] entry to .cclaw/knowledge.jsonl', or an explicit 'No compound insight this run.' line." }
-    ]
-};
 // ---------------------------------------------------------------------------
 // Stage map and accessors
 // ---------------------------------------------------------------------------