cclaw-cli 7.7.0 → 8.1.0

package/dist/content/stages/_lint-metadata/index.d.ts

@@ -1,2 +0,0 @@
-import type { FlowStage, FlowTrack } from "../../../types.js";
-export declare function stagePolicyNeedlesFromMetadata(stage: FlowStage, track?: FlowTrack): string[];

package/dist/content/stages/_lint-metadata/index.js

@@ -1,97 +0,0 @@
-import { SHIP_FINALIZATION_MODES } from "../../../constants.js";
-import { renderTrackTerminology, trackRenderContext } from "../../track-render-context.js";
-import { referencePatternPolicyNeedles } from "../../reference-patterns.js";
-const STAGE_POLICY_NEEDLES = {
-    brainstorm: [
-        "Explore project context",
-        "One question at a time",
-        "2-3 architecturally distinct approaches",
-        "Embedded Grill",
-        "Victory Detector",
-        "Critic Pass",
-        "State what is being approved",
-        "Self-review before handoff",
-        "Do NOT implement, scaffold, or modify behavior"
-    ],
-    scope: [
-        "Scope mode",
-        "In Scope",
-        "Out of Scope",
-        "Discretion Areas",
-        "Premise Drift",
-        "Locked Decisions",
-        "Victory Detector",
-        "Critic Pass"
-    ],
-    design: [
-        "Parallel Research Fleet",
-        "Architecture",
-        "Data Flow",
-        "Failure Modes and Mitigation",
-        "Performance Budget",
-        "Long-Term Trajectory",
-        "Victory Detector",
-        "Critic Pass",
-        "One issue at a time"
-    ],
-    spec: [
-        "Acceptance Criteria",
-        "Constraints",
-        "Assumptions Before Finalization",
-        "Testability",
-        "Spec Self-Review",
-        "single subsystem",
-        "approved spec",
-        "Edge Cases"
-    ],
-    plan: [
-        "WAIT_FOR_CONFIRM",
-        "Task Graph",
-        "Dependency Batches",
-        "Acceptance Mapping",
-        "verification steps",
-        "Execution Posture",
-        "Calibrated Findings",
-        "Regression Iron Rule",
-        "Locked Decision Coverage"
-    ],
-    tdd: [
-        "RED",
-        "GREEN",
-        "REFACTOR",
-        "failing test",
-        "Iron Law Acknowledgement",
-        "Watched-RED Proof",
-        "Vertical Slice Cycle",
-        "Test Discovery",
-        "System-Wide Impact Check",
-        "TDD Blocker Taxonomy",
-        "Per-Slice Review",
-        "full test suite",
-        "acceptance criteria",
-        "traceable to plan slice"
-    ],
-    review: [
-        "Layer 1",
-        "Layer 2",
-        "Critical",
-        "Review Findings",
-        "Ready to Ship",
-        "ROUTE_BACK_TO_TDD",
-        "One issue at a time"
-    ],
-    ship: [
-        "Pre-Ship Checks",
-        "Release Notes",
-        "Rollback Plan",
-        ...SHIP_FINALIZATION_MODES
-    ]
-};
-export function stagePolicyNeedlesFromMetadata(stage, track = "standard") {
-    const needles = [...STAGE_POLICY_NEEDLES[stage], ...referencePatternPolicyNeedles(stage)];
-    const renderContext = trackRenderContext(track);
-    if (stage === "tdd" && !renderContext.usesPlanTerminology) {
-        return needles.map((needle) => renderTrackTerminology(needle, renderContext));
-    }
-    return needles;
-}

package/dist/content/stages/brainstorm.d.ts

@@ -1,2 +0,0 @@
-import type { StageSchemaInput } from "./schema-types.js";
-export declare const BRAINSTORM: StageSchemaInput;

package/dist/content/stages/brainstorm.js

@@ -1,184 +0,0 @@
-// ---------------------------------------------------------------------------
-// BRAINSTORM — reference: superpowers brainstorming
-// ---------------------------------------------------------------------------
-export const BRAINSTORM = {
-    schemaShape: "v2",
-    stage: "brainstorm",
-    complexityTier: "standard",
-    skillFolder: "brainstorm",
-    skillName: "brainstorm",
-    skillDescription: "Problem-discovery stage. Build a concise Problem Decision Record, compare distinct directions under the run's discovery mode (lean / guided / deep), and hand approved decisions to scope.",
-    philosophy: {
-        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 problem frame and direction, using domain-neutral problem discovery (product, technical-maintenance, research, ops, or infrastructure framing) 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)"
-        ],
-        commonRationalizations: [
-            "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",
-            "Revealing recommendation before collecting user reaction",
-            "Three same-altitude approaches with no higher-upside challenger",
-            "Jumping directly into implementation",
-            "Requesting approval without stating what decision is being approved",
-            "Questions that only gather preferences without design impact",
-            "Options that are variants of one approach, not distinct alternatives"
-        ]
-    },
-    executionModel: {
-        checklist: [
-            "**ADAPTIVE ELICITATION COMES FIRST (no exceptions, no subagent dispatch before).** Load `.cclaw/skills/adaptive-elicitation/SKILL.md`. Walk the brainstorm forcing questions one-at-a-time via the harness-native question tool, append one row to `## Q&A Log` (`Turn | Question | User answer (1-line) | Decision impact`) after each user answer **and stamp the row's `Decision impact` cell with the matching `[topic:<id>]` tag** (e.g. `[topic:pain]`). Continue until every forcing-question topic id is tagged on a row OR the Q&A Ralph Loop convergence detector says no new decision-changing rows in last 2 iterations OR user records an explicit stop-signal row. Only then proceed to delegations, drafts, or analysis. The linter `qa_log_unconverged` rule will block `stage-complete` if convergence is not reached.",
-            "**Explore project context** — after the elicitation loop converges, inspect existing files/docs/recent activity to refine the Discovered context section; capture matching files/patterns/seeds in `Context > Discovered context` so downstream stages don't redo discovery.",
-            "**Brainstorm forcing questions (must be covered or explicitly waived)** — `pain: what pain are we solving`; `direct-path: what is the direct path`; `operator: who is the first operator/user affected`; `no-go: what no-go boundaries are non-negotiable`. Tag the matching `## Q&A Log` row's `Decision impact` cell with `[topic:<id>]` (e.g. `[topic:pain]`) so the linter can verify coverage in any natural language. Tags are MANDATORY for forcing-question rows; un-tagged rows do NOT count toward coverage. removed the counterfactual `do-nothing` topic; the Problem Decision Record already captures `Do-nothing consequence`.",
-            "**Discovery posture (flow-state `discoveryMode`)** — follow `lean` / `guided` / `deep` from the active run. Use lean for smallest safe discovery pass; guided as the default balanced pass; escalate to deep when ambiguity, architecture, external dependency, security/data risk, or explicit think-bigger requests warrant fuller option pressure and mandatory specialist coverage.",
-            "**Write the Problem Decision Record** — pick a free-form `Frame type` label that names how this work is framed (examples: product, technical-maintenance, research-spike, ops-incident, infrastructure), then fill the universal Framing fields: affected user/role/operator, current state/failure mode/opportunity, desired observable outcome, evidence/signal, why now, do-nothing consequence, and non-goals.",
-            "**Premise check (one pass)** — answer the two gstack-style questions in the artifact body: *Right problem? Direct path?* Take a position; do not hedge. The counterfactual premise line is intentionally absent; Do-nothing consequence lives in the Problem Decision Record.",
-            "**Reframe with How Might We** — write a single `How Might We …?` line that names the user/operator, the desired outcome, and the constraint. This is the altitude check before approaches.",
-            "**Run Clarity Gate** — record ambiguity score (0.00-1.00), decision boundaries, reaffirmed non-goals, and residual-risk handoff before locking recommendations. If ambiguity remains high (>0.40), ask one decision-changing question before recommending.",
-            "**Sharpening question discipline** — ask one decision-changing question at a time. Do not default to 3-5 batched questions; record only questions that changed the direction or a critical stop decision.",
-            "**Use compact discovery for low-risk asks** — for concrete bounded requests, do one context pass, compare one baseline and one challenger, and move to draft once context is sufficient; do not drag the user through a full workshop.",
-            "**Early-exit concrete asks** — for unambiguous implementation-only requests, write a compact Problem Decision Record plus short-circuit handoff (context, approved intent, constraints, assumptions, next-stage risks) and request explicit approval when the draft is ready.",
-            "**Ask only decision-changing questions** — one at a time; if answers would not change approach and are non-critical preference/default assumptions, state the assumption and continue; STOP on scope, architecture, security, data loss, public API, migration, auth/pricing, or user approval uncertainty.",
-            "**Idea-evidence carry-forward (when applicable).** If `flow-state.interactionHints.brainstorm.fromIdeaArtifact` is set, read that idea artifact and reuse its `Title`, `Why-now`, `Expected impact`, `Risk`, `Counter-argument` for the chosen `I-#` (`fromIdeaCandidateId`) as the seed of `## Selected Direction` and as one row of `## Approaches` (role: `baseline`, evidence: idea-artifact path). Generate ONLY the missing higher-upside `challenger` row(s); do NOT re-generate the candidate that came from `/cc-ideate`. Record the carry-forward in `## Idea Evidence Carry-forward` with at minimum `- Source: <path>`, `- Candidate: <I-#>`, `- Reused fields: Title, Why-now, Expected impact, Risk, Counter-argument`, `- Newly generated: challenger(s) only`.",
-            "**Compare 2-3 distinct approaches with stable Role/Upside columns** — Role values are `baseline` | `challenger` | `wild-card`; Upside is `low` | `modest` | `high` | `higher`; include real trade-offs, reuse notes, and reference-pattern source/disposition when a known pattern influenced the option; include exactly one challenger with explicit `high` or `higher` upside.",
-            "**Collect reaction before recommending** — ask which option feels closest and what concern remains, then recommend based on that reaction.",
-            "**Write the `Not Doing` list** — name 3-5 things this brainstorm explicitly is not committing to (vs. deferred). This protects scope from silent enlargement and the next stage from rework.",
-            "**Run Early-Loop / Concern Ledger discipline** — after each producer iteration, append a `Critic Pass` JSONL row to `.cclaw/state/early-loop-log.jsonl`, refresh `.cclaw/state/early-loop.json`, and iterate until open concerns clear or convergence guard escalates. (This is the producer-critic concern ledger, not the Q&A Ralph Loop used for elicitation convergence.)",
-            "**Embedded Grill (post-pick, one-at-a-time)** — after `Selected Direction` is named, if grilling triggers fire (irreversibility, security/auth boundary, domain-model ambiguity per `adaptive-elicitation:Conditional Grilling`), continue the elicitation loop with sharper questions **one at a time**, appended to `## Q&A Log` and reflected as rows in `## Embedded Grill`. Do NOT batch the 3-5 grill checks — each one follows the Core Protocol (ask, wait, log, self-eval, ask next).",
-            "**Self-review before user approval** — re-read the artifact and patch contradictions, weak trade-offs, placeholders, ambiguity, and weak handoff language. Record the result in `Self-Review Notes` using the calibrated review format: `- Status: Approved` (or `Issues Found`), `- Patches applied:` with inline note or sub-bullets, `- Remaining concerns:` with inline note or sub-bullets. Use `Patches applied: None` and `Remaining concerns: None` when there is nothing to record.",
-            "**Request explicit approval to close the stage** — state exactly what direction is being approved after the adaptive elicitation loop converges; do not advance without approval and artifact review.",
-            "**Handoff packet** — only after approval, produce a scope handoff packet with selected direction, why rejected options were rejected, explicit non-goals, unresolved questions, risk hints, and explicit drift from the initial ask so scope starts from locked upstream decisions instead of rediscovering intent."
-        ],
-        interactionProtocol: [
-            "\"If something is unclear, stop. Name what's confusing. Ask.\"",
-            "Start from observed project context; if the idea is vague, first narrow the project type with **one** structured question, then keep going.",
-            "Honor the run's `discoveryMode` (`lean` | `guided` | `deep`) from flow-state: lean stays fastest, guided is the default breadth, deep pulls in fuller critique and mandatory delegations when the run is classified that way.",
-            "Lead with the premise check (right problem / direct path) and the `How Might We` reframing before approaches; both go in the artifact, not just the chat. removed the counterfactual premise line; Do-nothing consequence still lives in the Problem Decision Record.",
-            "Ask at most one question per turn, only when decision-changing; if using a structured question tool, send exactly one question object, not a multi-question form.",
-            "Run the shared adaptive elicitation cycle from `.cclaw/skills/adaptive-elicitation/SKILL.md`, including stop-signal handling (RU/EN/UA), smart-skip, conditional grilling triggers, and append-only `## Q&A Log` updates.",
-            "Only non-critical preference/default assumptions may continue inline. STOP and ask when uncertainty affects scope, architecture, security, data loss, public API, migration, auth/pricing, or user approval.",
-            "For simple low-risk greenfield work, present a compact A/B choice with one recommended path and one higher-upside challenger; keep the artifact concise but structurally complete (Context, Premise, How Might We, Sharpening Questions, Approaches, Reaction, Selected Direction, Not Doing).",
-            "Show approaches before the recommendation; include a higher-upside challenger and gather reaction first.",
-            "Self-review before approval: re-read the artifact, fix contradictions/placeholders/weak trade-offs, then ask for approval. Do not ask for approval on a draft you have not re-read.",
-            "State exactly what is being approved, then **STOP** until the user explicitly approves the artifact.",
-            "Investigation discipline: follow the shared `## Investigation Discipline` block (search -> graph/impact -> narrow read of 1-3 files -> draft) before any drafting or delegation; pass repo-relative paths and refs (never file bodies) in delegations.",
-            "Behavior anchor: see the shared `## Behavior anchor` block in this skill — the bad/good pair anchors how this stage's `Problem Decision Record` must be filled."
-        ],
-        process: [
-            "Explore project context and align work to the run's discovery mode (lean / guided / deep).",
-            "Use compact discovery for simple apps, short-circuit implementation-only asks, or ask one decision-changing question at a time.",
-            "Compare 2-3 distinct approaches, including a higher-upside challenger.",
-            "Collect reaction, then recommend with rationale tied to that reaction.",
-            "Optionally park promising non-selected ideas in `.cclaw/seeds/`.",
-            "Write and self-review `.cclaw/artifacts/01-brainstorm-<slug>.md`.",
-            "Request explicit approval before handoff to scope."
-        ],
-        requiredGates: [
-            { 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-<slug>.md`.",
-            "Project context was explored (files, docs, or recent activity referenced).",
-            "Problem Decision Record includes a `Frame type` label and the universal Framing fields (affected user/role/operator, current state/failure mode/opportunity, desired observable outcome, evidence/signal, why now, do-nothing consequence, non-goals).",
-            "Clarity Gate records ambiguity score, decision boundaries, reaffirmed non-goals, and residual-risk handoff.",
-            "Clarifying questions are one-at-a-time and captured only when they change a decision or stop condition.",
-            "2-3 approaches with trade-offs are recorded, including one higher-upside challenger option and reference-pattern source/disposition when applicable.",
-            "When `flow-state.interactionHints.brainstorm.fromIdeaArtifact` is set, the `## Idea Evidence Carry-forward` section cites the idea artifact + `I-#` and only the challenger rows are newly generated (idea candidate is reused as `baseline`, never re-derived).",
-            "User reaction to approaches is captured before final recommendation.",
-            "Final recommendation explicitly reflects user reaction.",
-            "Early-loop status is reflected via `Victory Detector` / `Critic Pass` sections and `.cclaw/state/early-loop.json` when concerns remain.",
-            "Selected Direction includes the handoff to the track-aware next stage: scope on standard, spec on medium when scope/design are skipped.",
-            "When a promising option is parked, a seed file is created under `.cclaw/seeds/` and referenced in the artifact.",
-            "Approved direction and approval marker are present.",
-            "Assumptions and open questions are captured (or explicitly marked as none).",
-            "Scope handoff packet includes selected direction, upstream decisions used, explicit drift, confidence, unresolved questions, next-stage risk hints, and non-goals."
-        ],
-        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"
-        ],
-        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"
-        ],
-        platformNotes: [
-            "Write artifact paths in POSIX form (`.cclaw/artifacts/01-brainstorm-<slug>.md`) even on Windows — the runtime normalizes separators. Do NOT commit Windows-style backslashes into the artifact or flow-state.",
-            "Slugify titles with lowercase ASCII letters, digits, and single dashes only — avoid spaces and case-sensitive names so the file resolves identically on case-insensitive filesystems (macOS/Windows default).",
-            "When linking to files inside the artifact, use repo-relative forward-slash paths (`src/foo/bar.ts`) so reviewers on any OS can click through."
-        ]
-    },
-    artifactRules: {
-        artifactFile: "01-brainstorm-<slug>.md",
-        completionStatus: ["DONE", "DONE_WITH_CONCERNS", "BLOCKED"],
-        crossStageTrace: {
-            readsFrom: [],
-            writesTo: [".cclaw/artifacts/01-brainstorm-<slug>.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. A `Discovered context` subsection (or list) is recommended for downstream traceability." },
-            { section: "Problem Decision Record", required: true, validationRule: "Must include a free-form `Frame type` label (examples only: product, technical-maintenance, research-spike, ops-incident, infrastructure) and the universal Framing fields: affected user/role/operator, current state/failure mode/opportunity, desired observable outcome, evidence/signal, why now, do-nothing consequence, non-goals. The linter checks that the section has meaningful content; the field labels themselves are the structural contract." },
-            { section: "Premise Check", required: false, validationRule: "Recommended: explicit answers to `Right problem?` and `Direct path?` — take a position, do not hedge. retired the counterfactual premise line; Do-nothing consequence already lives in the Problem Decision Record." },
-            { section: "How Might We", required: false, validationRule: "Recommended: a single `How Might We …?` line naming the user, the outcome, and the binding constraint." },
-            { section: "Clarity Gate", required: false, validationRule: "Recommended before recommendation lock: include ambiguity score (0.00-1.00), decision boundaries, reaffirmed non-goals, and residual-risk handoff for scope." },
-            { section: "Sharpening Questions", required: false, validationRule: "Recommended only when needed: one decision-changing question per turn with explicit `Decision impact`; compact tasks may record `None - early exit` with rationale." },
-            { section: "Clarifying Questions", required: false, validationRule: "Must capture question, answer, and decision impact for each clarifying question." },
-            { section: "Approach Tier", required: true, validationRule: "Must record how much discovery/evidence breadth is warranted in discoveryMode terms (`lean`, `guided`, or `deep`) relative to flow-state—and explain what risk or uncertainty drives that calibration (not merely the label)." },
-            { section: "Short-Circuit Decision", required: false, validationRule: "Must include Status/Why/Scope handoff lines when short-circuit is discussed; compact stubs are valid for concrete asks." },
-            { section: "Reference Pattern Candidates", required: false, validationRule: "Recommended when examples influence direction: list pattern/source, reusable invariant, accept/reject/defer disposition, and reason before approaches are finalized." },
-            { section: "Idea Evidence Carry-forward", required: false, validationRule: "when `flow-state.interactionHints.brainstorm.fromIdeaArtifact` is set, this section MUST cite the idea artifact path and the chosen `I-#`, list reused fields (Title, Why-now, Expected impact, Risk, Counter-argument), and explicitly state that only challenger row(s) were newly generated. Honors `/cc-ideate` handoff so divergent + critique + rank work is reused, not redone." },
-            { section: "Approaches", required: true, validationRule: "Must compare 2-3 distinct options with real trade-offs. Use the canonical `Role` column with `baseline` | `challenger` | `wild-card` and the `Upside` column with `low` | `modest` | `high` | `higher`; include exactly one challenger row with `high` or `higher` upside, and cite reference-pattern source/disposition when applicable." },
-            { section: "Approach Reaction", required: true, validationRule: "Must appear before Selected Direction and summarize user reaction before recommendation, including `Closest option`, `Concerns`, and what changed after reaction." },
-            { section: "Selected Direction", required: true, validationRule: "Must include the selected approach, explicit approval marker, rationale traceable to Approach Reaction, and a scope handoff packet with selected direction, decisions, drift, confidence, unresolved questions, risk hints, and non-goals." },
-            { section: "Embedded Grill", required: false, validationRule: "Recommended after Selected Direction: 3-5 rows covering hidden constraints, reversibility/rollback, scope boundaries, existing-pattern fit, and domain-language alignment. Each row records question, recommended answer, and disposition (accept/refine/reject)." },
-            { section: "Not Doing", required: false, validationRule: "Recommended: 3-5 explicitly non-committed items (distinct from deferred). Protects scope from silent enlargement and the next stage from rework." },
-            { section: "Design", required: false, validationRule: "Must cover architecture, key components, and data flow scaled to complexity." },
-            { section: "Visual Companion", required: false, validationRule: "If architecture/data-flow complexity is medium+, include compact ASCII/Mermaid diagram or explicitly justify omission." },
-            { section: "Victory Detector", required: false, validationRule: "Recommended early-loop checkpoint: cite `.cclaw/state/early-loop.json`, current iteration/maxIterations, open concern count, convergence status, and iterate/ready/escalate decision." },
-            { section: "Critic Pass", required: false, validationRule: "Recommended producer/critic log contract: each iteration appends one JSONL row to `.cclaw/state/early-loop-log.jsonl` with runId, stage, iteration, and open concerns." },
-            { section: "Self-Review Notes", required: false, validationRule: "Recommended: use the calibrated review format — `- Status: Approved` (or `Issues Found`), `- Patches applied:` (inline note or sub-bullets, use `None` if nothing changed), `- Remaining concerns:` (inline note or sub-bullets, use `None` if nothing remains). Done before requesting user approval." },
-            { section: "Assumptions and Open Questions", required: false, validationRule: "Must capture unresolved assumptions/open questions, or explicitly state none." }
-        ],
-        trivialOverrideSections: [
-            "Context",
-            "Problem Decision Record",
-            "Approach Tier",
-            "Short-Circuit Decision",
-            "Selected Direction"
-        ]
-    },
-    reviewLens: {
-        outputs: [
-            "Problem Decision Record",
-            "approved direction",
-            "alternatives with trade-offs",
-            "brainstorm artifact"
-        ],
-        reviewSections: []
-    },
-    next: "scope"
-};

package/dist/content/stages/design.d.ts

@@ -1,2 +0,0 @@
-import type { StageSchemaInput } from "./schema-types.js";
-export declare const DESIGN: StageSchemaInput;

package/dist/content/stages/design.js

@@ -1,288 +0,0 @@
-import { REVIEW_LOOP_CHECKLISTS, reviewLoopPolicySummary } from "../review-loop.js";
-import { decisionProtocolInstruction } from "../decision-protocol.js";
-// ---------------------------------------------------------------------------
-// DESIGN — reference: gstack Eng review
-// ---------------------------------------------------------------------------
-export const DESIGN = {
-    schemaShape: "v2",
-    stage: "design",
-    complexityTier: "standard",
-    skillFolder: "design",
-    skillName: "design",
-    skillDescription: "Engineering lock stage. Convert the approved scope contract into a buildable architecture with adversarial alternatives, failure/rescue paths, and spec handoff.",
-    philosophy: {
-        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 how the scoped slice works: architecture boundary, existing fit, data/state flow, critical path, trust boundaries, failure/rescue behavior, verification, rollout, and spec handoff.",
-        whenToUse: [
-            "After scope agreement 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"
-        ],
-        commonRationalizations: [
-            "Architecture deferred to implementation phase",
-            "Missing data-flow edge cases",
-            "No interaction-edge-case matrix (double-click, navigate-away, stale-state, large-result)",
-            "No performance budget for critical path",
-            "Failure mode table omits rescue path or user-visible impact",
-            "Skipping security/observability/deployment review for non-trivial change",
-            "Skipping outside-voice review loop and treating first draft as final",
-            "Batching multiple design issues into one question",
-            "Agreeing with user's architecture choice without evaluating alternatives",
-            "Re-authoring scope's out-of-scope list instead of citing it via Upstream Handoff",
-            "Re-authoring scope's repo audit instead of diffing the blast radius since scope baseline",
-            "Design decisions made without reading the actual code first"
-        ]
-    },
-    executionModel: {
-        checklist: [
-            "**ADAPTIVE ELICITATION COMES FIRST (no exceptions, no subagent dispatch before).** Load `.cclaw/skills/adaptive-elicitation/SKILL.md`. Walk the design forcing questions one-at-a-time via the harness-native question tool, append one row to `## Q&A Log` (`Turn | Question | User answer (1-line) | Decision impact`) after each user answer **and stamp the row's `Decision impact` cell with the matching `[topic:<id>]` tag** (e.g. `[topic:data-flow]`). Continue until every forcing-question topic id is tagged on a row OR the Q&A Ralph Loop convergence detector says no new decision-changing rows in last 2 iterations OR user records an explicit stop-signal row. Only then proceed to research, investigator pass, architecture lock, or any delegations. The linter `qa_log_unconverged` rule will block `stage-complete` if convergence is not reached.",
-            "**Design forcing questions (must be covered or explicitly waived)** — `data-flow: what is the end-to-end data flow`; `seams: where are seams/ownership boundaries`; `invariants: which invariants must hold`; `not-refactor: what will explicitly NOT be refactored now`. Tag the matching `## Q&A Log` row's `Decision impact` cell with `[topic:<id>]` (e.g. `[topic:data-flow]`) so the linter can verify coverage in any natural language. Tags are MANDATORY for forcing-question rows; un-tagged rows do NOT count toward coverage.",
-            "**Out-of-scope carry-forward (do NOT re-author)** — scope OWNS the out-of-scope list. Cite scope's `## In Scope / Out of Scope > Out of Scope` via `## Upstream Handoff > Decisions carried forward`; do NOT add a separate `## NOT in scope` section in the design artifact. Add a row to `## Spec Handoff` only if a design-stage decision NEWLY excludes something not already in scope's out-of-scope.",
-            "Compact design lock — design does not decide what to build; it decides how the approved scope works. For simple slices, produce a tight lock: upstream handoff, existing fit, architecture boundary, one labeled diagram, data/state flow, critical path, failure/rescue, trust boundaries, test/perf expectations, rollout/rollback, rejected alternative, and spec handoff.",
-            "Trivial-Change Escape Hatch — for <=3 files, no new interfaces, and no cross-module data flow, produce a mini-design (rationale, changed files, one risk) and proceed to spec.",
-            "**Architecture choice (design OWNS the tier decision)** — pick the architecture tier (minimum-viable / product-grade / ideal) using scope's `## Scope Contract > Design handoff` as the input. Record the tier and rationale in `## Architecture Decision Record (ADR)` and `## Engineering Lock`. Scope only locked the SCOPE MODE; it did NOT enumerate Implementation Alternatives.",
-            "Tiered Research — for simple/medium work, do compact inline codebase/research synthesis in `Research Fleet Synthesis`; write `.cclaw/artifacts/02a-research.md` and run the full fleet only for deep/high-risk work or when external framework/architecture uncertainty exists.",
-            "Design Doc Check — read upstream artifacts and current design docs; latest superseding doc wins.",
-            "**Blast-radius diff (do NOT re-audit the whole repo)** — scope OWNS the full repo audit (`## Pre-Scope System Audit`). Design only diffs the blast radius SINCE scope baseline: `git diff <scope-artifact-head-sha>..HEAD -- <touched-paths>`. Record touched files, current responsibilities, reuse candidates, and existing patterns in `## Codebase Investigation` and `## Blast-radius Diff`. Do NOT re-author scope's git log/diff/stash audit.",
-            "Scope Challenge + Search Before Building — find existing solutions, minimum change set, reference-grade contracts to mirror, and complexity smells before custom architecture.",
-            "Architecture Review — lock boundaries, chosen path, shadow alternative, switch trigger, failure/rescue/degraded behavior, and verification evidence for every high-risk choice; include tier-required diagrams.",
-            "Review core risk areas — existing system fit, data/state flow, critical path, security/trust boundaries, tests, performance budget, observability/debuggability, rollout/rollback, rejected alternatives, and spec handoff.",
-            "**ADR + pre-mortem contract** — capture ADR-style decision rows (context, decision, alternatives, consequences), run a pre-mortem on likely failures, and map each critical flow to a validating test and diagram anchor before lock.",
-            "Critic pass — run/reconcile adversarial second opinion on architecture, coupling, failure modes, and cheaper alternatives; record outcomes per the Design Outside Voice Loop policy.",
-            "**Run Early-Loop / Concern Ledger discipline** — after each producer iteration, append a `Critic Pass` JSONL row to `.cclaw/state/early-loop-log.jsonl`, refresh `.cclaw/state/early-loop.json`, and iterate until open concerns clear or convergence guard escalates. (This is the producer-critic concern ledger, not the Q&A Ralph Loop used for elicitation convergence.)",
-            "Run stale-diagram audit as a design freshness gate (default-on; explicit config opt-out allowed).",
-            "Capture leftovers — seed high-upside deferred ideas, list unresolved decisions with defaults, document distribution for new artifact types, and cross-reference deferred items to scope or unresolved decisions."
-        ],
-        interactionProtocol: [
-            "\"Constrain, don't micromanage - enforce invariants, separate the doer from the checker.\"",
-            "Review section-by-section: investigator first, critic second, then reconcile. For simple apps, collapse this into one compact design lock with explicit risks and a single approval stop.",
-            "Present each issue one at a time; do not batch issues or move sections until current issues are resolved.",
-            "Run the shared adaptive elicitation cycle from `.cclaw/skills/adaptive-elicitation/SKILL.md`, including stop-signal handling (RU/EN/UA), smart-skip, conditional grilling triggers, and append-only `## Q&A Log` updates.",
-            decisionProtocolInstruction("each issue", "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)", "recommend the option that closes the issue with the smallest blast radius and clearest verification path"),
-            "If a section has no issues, say 'No issues found' and move on.",
-            "Do not skip failure-mode mapping; use Method/Exception/Rescue/UserSees and treat silent user impact without rescue as critical.",
-            "Take a firm position, push back on weak framing, and call out suboptimal architecture with concrete alternatives.",
-            "Classify ambiguity before acting. Only non-critical preference/default assumptions may continue; STOP on uncertainty about scope, architecture, security, data loss, public API, migration, auth/pricing, or required user approval. Design hypotheses must name validation path, rollback trigger, and owner before they can be carried forward.",
-            "Before final approval, run the critic pass, reconcile material findings, and bound retries with the review-loop policy.",
-            "For baseline approval, present the full design plus exact spec handoff and **STOP** until explicit approval.",
-            "**STOP BEFORE ADVANCE.** Mandatory delegation `planner` runs **AFTER user approval of the design lock**, not before Q&A. Sequence is: Q&A loop -> draft design lock -> user approval -> `planner` delegation -> `stage-complete`. Legal fulfillment modes for `planner`: (a) **harness-native Task tool** — run the delegation, then record via `node .cclaw/hooks/delegation-record.mjs --stage=design --agent=planner --mode=mandatory --status=completed --span-id=<uuid> --dispatch-surface=cursor-task --agent-definition-path=<agent-md-path> --evidence-ref=<artifact#section>`; (b) **role-switch** — write planner output into the design artifact, then record with `--dispatch-surface=role-switch`; (c) **cclaw subagent helper** with `--dispatch-surface=isolated`. Run `node .cclaw/hooks/stage-complete.mjs design` from the tool layer (do not paste the command into chat); report only the resulting summary.",
-            "Investigation discipline: follow the shared `## Investigation Discipline` block before drafting architecture — populate `Codebase Investigation` from a search/graph trace and pass paths/refs (never file bodies) to investigator/critic delegations.",
-            "Behavior anchor: see the shared `## Behavior anchor` block in this skill — the bad/good pair anchors how `Codebase Investigation` must precede any ADR commitment."
-        ],
-        process: [
-            "Read upstream artifacts and current design docs.",
-            "Run compact research by default; write `.cclaw/artifacts/02a-research.md` only when deep/high-risk uncertainty requires a separate research artifact.",
-            "Run investigator pass plus scope challenge/search-before-building.",
-            "Walk review sections interactively and lock boundaries, data flow, state transitions, edge cases, and failure modes.",
-            "Cover security, observability, deployment, tests, and performance for guided/deep-shaped design work; lean slices may omit heavy add-ons only when scope and risk justify the compact path.",
-            "Run stale-diagram audit (enabled by default unless explicitly disabled).",
-            "Produce required outputs: blast-radius diff (scope owns full repo audit), tier diagrams, failure table, completion dashboard. Out-of-scope is carried from scope via Upstream Handoff — do NOT re-author it.",
-            "Plant high-upside deferred ideas when useful and reconcile critic/outside-voice findings.",
-            "Write design lock artifact for downstream spec/plan with design decisions, rejected alternatives, verification evidence, and exact spec handoff."
-        ],
-        requiredGates: [
-            { id: "design_research_complete", description: "Research is complete: compact inline synthesis by default, or a separate research artifact for deep/high-risk work, and findings are mapped to design decisions." },
-            { id: "design_architecture_locked", description: "Architecture boundaries are explicit and approved." },
-            { id: "design_diagram_freshness", description: "Stale Diagram Audit is clear, or explicitly skipped for compact trivial-override slices without diagram markers." },
-            { 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: [
-            "Research Fleet Synthesis is filled in `.cclaw/artifacts/03-design-<slug>.md`; for deep/high-risk work, `.cclaw/artifacts/02a-research.md` is also written with stack/features/architecture/pitfalls sections plus synthesis.",
-            "Artifact written to `.cclaw/artifacts/03-design-<slug>.md`.",
-            "Failure-mode table exists in Method/Exception/Rescue/UserSees format.",
-            "Tier-required diagram markers are present: architecture (all tiers). Standard/Deep add-ons (shadow/error) and Deep add-ons (state-machine/rollback/deployment-sequence) are included only when risk warrants them.",
-            "Stale diagram audit finding is clear: no blast-radius file newer than diagram markers without explicit update.",
-            "Security & threat model findings are documented with mitigations.",
-            "Observability and deployment plans are explicit for critical flows.",
-            "Outside-voice findings and dispositions are recorded (accept/reject/defer).",
-            "Design outside-voice loop summary includes iteration count and quality-score trajectory with explicit stop reason and unresolved concerns.",
-            "Early-loop status is reflected via `Victory Detector` / `Critic Pass` sections and `.cclaw/state/early-loop.json` when concerns remain.",
-            "When a second opinion is used, record source, critique frame, and disposition (accept/reject/defer) with rationale.",
-            "Adversarial lock table includes chosen path, shadow alternative, switch trigger, failure/rescue/degraded behavior, and verification evidence, with reference-grade contracts for mirrored patterns when applicable.",
-            "Architecture Decision Record (ADR) section captures context, decision, alternatives, consequences, and reversal trigger for major choices.",
-            "Pre-mortem section lists top failure scenarios, early signals, mitigations, and owner before implementation begins.",
-            "Test-Diagram Mapping links critical flows to both validating tests and diagram anchors.",
-            "Test strategy includes unit/integration/e2e expectations.",
-            "When a high-upside idea is deferred, a seed file is created under `.cclaw/seeds/` and referenced in the artifact.",
-            "Out-of-scope is carried forward from scope's `## In Scope / Out of Scope > Out of Scope` via `## Upstream Handoff > Decisions carried forward`; design does NOT author its own NOT-in-scope section.",
-            "Blast-radius Diff section produced (git diff since scope artifact baseline) — scope owns the full repo audit; design only diffs touched paths.",
-            "Completion dashboard lists review section status, critical/open gap counts, decision count, and unresolved items (or 'None')."
-        ],
-        inputs: ["scope agreement artifact", "system constraints", "non-functional requirements"],
-        requiredContext: [
-            "compact inline Research Fleet Synthesis, plus `.cclaw/artifacts/02a-research.md` only when deep/high-risk research was needed",
-            "existing architecture and boundaries",
-            "operational constraints",
-            "security and reliability expectations"
-        ],
-        researchPlaybooks: [
-            "research/research-fleet.md",
-            "research/framework-docs-lookup.md",
-            "research/best-practices-lookup.md"
-        ],
-        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"
-        ],
-        platformNotes: [
-            "Architecture diagrams (ASCII, Mermaid) must use plain ASCII punctuation — avoid smart quotes and em-dashes that render differently across Windows CMD (cp1252), macOS Terminal (UTF-8), and Linux consoles.",
-            "When referencing build or runtime tools in the design, name them by binary (`node`, `python`, `go`) rather than by IDE-specific run configurations (`npm: start (WebStorm)`, `launch.json:Debug`) so the design stays OS-agnostic.",
-            "File system layouts drawn in the artifact use forward slashes; explicitly note when a platform-specific path style is required (e.g. Windows long-path `\\\\?\\` prefix, macOS bundle `.app/Contents/MacOS/`)."
-        ]
-    },
-    artifactRules: {
-        artifactFile: "03-design-<slug>.md",
-        completionStatus: ["DONE", "DONE_WITH_CONCERNS", "BLOCKED"],
-        crossStageTrace: {
-            readsFrom: [
-                ".cclaw/artifacts/01-brainstorm-<slug>.md",
-                ".cclaw/artifacts/02-scope-<slug>.md",
-                ".cclaw/artifacts/02a-research.md"
-            ],
-            writesTo: [".cclaw/artifacts/03-design-<slug>.md"],
-            traceabilityRule: "Every architecture decision must trace to a scope boundary. Every downstream spec requirement must trace to a design decision."
-        },
-        artifactValidation: [
-            { section: "Upstream Handoff", required: false, validationRule: "Summarizes scope/research decisions, constraints, open questions, and explicit drift before design choices." },
-            { section: "Research Fleet Synthesis", required: true, validationRule: "Must summarize the tiered lenses actually run and map findings to concrete design decisions. Default may be compact inline synthesis; full separate research pack is Deep/high-risk only." },
-            { section: "Codebase Investigation", required: false, validationRule: "Investigator pass: list blast-radius files with current responsibilities, discovered patterns, reuse candidates, and existing system fit." },
-            { section: "Engineering Lock", required: true, validationRule: "Canonical lock: chosen path, shadow alternative, switch trigger, failure/rescue/degraded behavior, verification evidence, critical path, rollout/rollback, and confidence." },
-            { section: "Architecture Decision Record (ADR)", required: false, validationRule: "Recommended: rows for context, decision, alternatives, consequences, and reversal trigger for each major architecture choice." },
-            { section: "Search Before Building", required: false, 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: "Must include `<!-- diagram: architecture -->` marker. Diagram must label concrete nodes, label arrows, mark direction, distinguish sync/async edges, and include at least one failure/degraded edge." },
-            { section: "Data-Flow Shadow Paths", required: false, validationRule: "Standard/Deep add-on: include `<!-- diagram: data-flow-shadow-paths -->` marker plus a table for high-risk choices: chosen path, shadow alternative, switch trigger, failure/rescue/degraded behavior, and verification evidence." },
-            { section: "Error Flow Diagram", required: false, validationRule: "Standard/Deep add-on: include `<!-- diagram: error-flow -->` marker and failure-detection -> rescue -> user-visible outcome flow." },
-            { section: "Data Flow", required: false, validationRule: "Must include data/state flow, happy path, nil input, empty input, upstream error paths, plus Interaction Edge Case matrix rows for double-click, nav-away-mid-request, 10K-result dataset, background-job abandonment, zombie connection. Each row declares handled yes/no and deferred item when not handled." },
-            { section: "Stale Diagram Audit", required: false, validationRule: "Blast-radius files from Codebase Investigation must not be newer than the current design diagram-marker baseline unless explicitly refreshed." },
-            { section: "Failure Mode Table", required: true, validationRule: "Use Method/Exception/Rescue/UserSees columns and treat silent user impact without rescue as critical." },
-            { section: "Pre-mortem", required: false, validationRule: "Recommended: list top failure scenarios, early warning signal, mitigation owner, and containment action before implementation." },
-            { section: "Security & Threat Model", required: true, validationRule: "Must list trust boundaries, abuse/failure scenarios, mitigations, and residual risks." },
-            { section: "Test Strategy", required: false, validationRule: "Must define unit/integration/e2e expectations with coverage targets." },
-            { section: "Test-Diagram Mapping", required: false, validationRule: "Recommended: map each critical flow to at least one validating test ID and one diagram marker/anchor." },
-            { section: "Performance Budget", required: false, validationRule: "For each critical path: metric name, target threshold, and measurement method." },
-            { section: "Observability & Debuggability", required: true, validationRule: "Must define logs/metrics/traces plus alerting/debug path for critical failure modes." },
-            { section: "Deployment & Rollout", required: true, validationRule: "Must define migration/flag strategy, rollout/rollback plan, switch trigger, and post-deploy verification steps." },
-            { section: "Blast-radius Diff", required: false, validationRule: "Diff since scope artifact baseline (`git diff <scope-sha>..HEAD -- <touched-paths>`): for each touched file, summarize change since scope, current responsibility, reuse candidate, and existing pattern. Scope OWNS the full repo audit; design only diffs the blast radius." },
-            { section: "Reference-Grade Contracts", required: false, validationRule: "For every mirrored pattern: source, reusable invariant, local adaptation, rejection boundary, and verification signal. Omit with `None - no external or in-repo pattern mirrored` for compact local changes." },
-            { section: "Rejected Alternatives", required: false, validationRule: "List alternatives considered, why rejected, and what signal would revive them." },
-            { section: "Design Decisions", required: false, validationRule: "Stable design decisions with requirement/locked-decision refs and downstream spec impact." },
-            { section: "Spec Handoff", required: true, validationRule: "Exact requirements, design decisions, risks, test/perf expectations, and unresolved questions that spec must carry forward." },
-            { section: "Long-Term Trajectory", required: false, validationRule: "Recommended (1-3 lines, present-only): name what comes after this ships (Phase 2 / Phase 3 / platform promotion) and whether the locked architecture can absorb that path without major rework. Use `None - tactical change only` for compact slices." },
-            { section: "Outside Voice Findings", required: false, validationRule: "Critic pass: list adversarial findings and disposition (accept/reject/defer) with rationale per material finding." },
-            { section: "Design Outside Voice Loop", required: false, validationRule: `Record iteration table with quality score per iteration, stop reason, and unresolved concerns. Enforce ${reviewLoopPolicySummary("design")}` },
-            { section: "Victory Detector", required: false, validationRule: "Recommended early-loop checkpoint: cite `.cclaw/state/early-loop.json`, current iteration/maxIterations, open concern count, convergence status, and iterate/ready/escalate decision." },
-            { section: "Critic Pass", required: false, validationRule: "Recommended producer/critic log contract: each iteration appends one JSONL row to `.cclaw/state/early-loop-log.jsonl` with runId, stage, iteration, and open concerns." },
-            { section: "Completion Dashboard", required: true, validationRule: "Lists every review section with status (clear / issues-found-resolved / issues-open), critical/open gap counts, decision count, and unresolved items (or 'None')." }
-        ],
-        trivialOverrideSections: ["Architecture Boundaries", "Completion Dashboard"]
-    },
-    reviewLens: {
-        outputs: [
-            "parallel research synthesis artifact",
-            "architecture lock",
-            "risk and failure map",
-            "test and performance baseline",
-            "blast-radius diff since scope baseline",
-            "design decisions and spec handoff",
-            "design completion dashboard"
-        ],
-        reviewLoop: {
-            stage: "design",
-            checklist: REVIEW_LOOP_CHECKLISTS.design.map((dimension) => dimension.id),
-            maxIterations: 3,
-            targetScore: 0.8
-        },
-        reviewSections: [
-            {
-                title: "Architecture Review",
-                evaluationPoints: [
-                    "System design, boundaries, coupling, and bottlenecks",
-                    "For each new codepath: one realistic production failure scenario"
-                ],
-                stopGate: true
-            },
-            {
-                title: "Security & Threat Model",
-                evaluationPoints: [
-                    "Trust boundaries, authz rules, and sensitive data flows are explicit",
-                    "Mitigation ownership and residual risk are documented"
-                ],
-                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: "Data Flow & Interaction Edge Cases",
-                evaluationPoints: [
-                    "Happy/nil/empty/error paths are explicit",
-                    "Interaction edge cases and Standard+ shadow/error diagrams are present",
-                    "Error-flow includes rescue path and user-visible outcome"
-                ],
-                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: "Observability & Debuggability",
-                evaluationPoints: [
-                    "Logs/metrics/traces exist for critical failure modes",
-                    "Alerting and debug path from symptom to root cause are documented"
-                ],
-                stopGate: true
-            },
-            {
-                title: "Deployment & Rollout Review",
-                evaluationPoints: [
-                    "Migration sequencing, rollout/rollback, and compatibility window are explicit",
-                    "Post-deploy verification and distribution/build story are documented"
-                ],
-                stopGate: true
-            }
-        ]
-    },
-    next: "spec"
-};