cclaw-cli 0.51.9 → 0.51.10

package/dist/artifact-linter.js

@@ -304,17 +304,21 @@ function tokensFromRule(rule) {
     return [];
 }
 /**
- * Extract required keywords from validation rules that contain comma-separated
- * concept lists. Activates only for rules with structured enumerations like
- * "failure modes, error surface, data-flow paths" — not for short rules.
+ * Extract required keywords from validation rules that contain *backticked*
+ * stable tokens after a colon. We only fire on machine-surface enumerations
+ * (e.g., `` Must contain: `Status:`, `WAIT_FOR_CONFIRM`, `Approved:` ``);
+ * descriptive English prose with bare comma lists is intentionally ignored so
+ * authors can write rationale freely without triggering hardcoded keyword
+ * matches. Sections that need richer structural enforcement use a dedicated
+ * `validateSectionBody` dispatch (see `validateScopeSummary`, etc.).
  */
 function extractRequiredKeywords(rule) {
     const colonMatch = /:\s*(.+)$/u.exec(rule);
     if (!colonMatch)
         return [];
     const tail = colonMatch[1];
-    const parts = tail.split(/,\s*(?:and\s+)?/u).map((p) => p.trim().replace(/\.$/u, ""));
-    const phrases = parts.filter((p) => p.length >= 4 && !/^(must|should|at least|if |or )/iu.test(p));
+    const backtickedTokens = Array.from(tail.matchAll(/`([^`]+)`/gu)).map((m) => m[1].trim());
+    const phrases = backtickedTokens.filter((p) => p.length >= 2);
     if (phrases.length < 3)
         return [];
     return phrases;
@@ -492,6 +496,126 @@ function validateFailureModeTable(sectionBody) {
         details: "Failure Mode Table header and critical-risk checks passed."
     };
 }
+// Canonical scope mode tokens (gstack CEO review). The four mode names live in
+// the scope skill, the artifact template, and downstream traces. Requiring one
+// of them in Scope Summary is **structural** — not free-form English keyword
+// matching on user prose. Authors may also use the canonical short form on a
+// `Mode:` / `Selected mode:` line (e.g. `Selected mode: hold`) as a courtesy.
+const SCOPE_MODE_FULL_TOKENS = [
+    "SCOPE EXPANSION",
+    "SELECTIVE EXPANSION",
+    "HOLD SCOPE",
+    "SCOPE REDUCTION"
+];
+const SCOPE_MODE_FULL_REGEX = new RegExp("\\b(?:" +
+    SCOPE_MODE_FULL_TOKENS
+        .map((token) => token.replace(/[.*+?^${}()|[\]\\]/g, "\\$&").replace(/\s+/g, "[\\s_-]+"))
+        .join("|") +
+    ")\\b", "iu");
+// Short-form synonyms accepted only when stamped on an explicit `Mode:` /
+// `Selected mode:` / `Scope mode:` line. Plain prose with the same word does
+// not count, so `strict` / `broad` / `narrow` / similar non-mode adjectives
+// remain rejected.
+const SCOPE_MODE_LINE_REGEX = /(?:^|\n)\s*[-*]?\s*\**\s*(?:Selected\s+|Scope\s+)?Mode\**\s*:\s*\**\s*([^\n]+)/iu;
+const SCOPE_MODE_SHORT_TOKEN_REGEX = /\b(?:hold(?:[\s_-]?scope)?|selective(?:[\s_-]?expansion)?|scope[\s_-]?expansion|expansion|scope[\s_-]?reduction|reduction|expand|reduce)\b/iu;
+// Next-stage handoff token. We only enforce the canonical machine-surface stage
+// IDs (`design`, `spec`) plus stable handoff phrases. The surrounding prose may
+// be written in any language — this guards the downstream cross-stage trace,
+// not the wording of the rationale.
+const NEXT_STAGE_HANDOFF_REGEX = /(?:`(?:design|spec)`|\bdesign\b|\bspec\b|next[-\s_]stage|next stage|handoff|hand[-\s]off)/iu;
+function hasCanonicalScopeMode(body) {
+    if (SCOPE_MODE_FULL_REGEX.test(body))
+        return true;
+    for (const match of body.matchAll(new RegExp(SCOPE_MODE_LINE_REGEX, "giu"))) {
+        const value = match[1] ?? "";
+        if (SCOPE_MODE_SHORT_TOKEN_REGEX.test(value))
+            return true;
+    }
+    return false;
+}
+function validatePremiseChallenge(sectionBody) {
+    // gstack-style premise challenge requires a real Q/A structure (table or
+    // list), not free-form prose. The validation is *structural* only — we do
+    // NOT keyword-grep for English phrases like "right problem"; authors may
+    // write the questions in any language, and the answers carry the meaning.
+    // The template ships with canonical question labels as scaffolding, but
+    // the linter only enforces that the section actually compares premise
+    // questions to answers.
+    const tableRows = getMarkdownTableRows(sectionBody);
+    const bulletRows = sectionBody
+        .split(/\r?\n/u)
+        .map((line) => line.trim())
+        .filter((line) => /^(?:[-*]|\d+\.)\s+\S/u.test(line));
+    const rowCount = Math.max(tableRows.length, bulletRows.length);
+    if (rowCount < 3) {
+        return {
+            ok: false,
+            details: `Premise Challenge needs at least 3 question/answer rows in a table or bullet list (right problem? / direct path? / what if nothing? are the gstack default trio). Found ${rowCount}.`
+        };
+    }
+    // For tables, each data row must have at least 2 non-empty cells so the
+    // section is genuinely a Q/A comparison, not a list of headlines. For
+    // bullet lists, each line must be substantive (>= 8 characters of letters
+    // or digits) so we don't accept three-letter placeholders like `- a`.
+    if (tableRows.length >= 3) {
+        const sparseRows = tableRows.filter((row) => {
+            const filledCells = row.filter((cell) => cell.replace(/[\s|]/gu, "").length >= 2);
+            return filledCells.length < 2;
+        });
+        if (sparseRows.length > 0) {
+            return {
+                ok: false,
+                details: "Premise Challenge table rows must populate at least the question and answer columns (no empty answers)."
+            };
+        }
+    }
+    else if (bulletRows.length >= 3) {
+        const sparseBullets = bulletRows.filter((line) => {
+            const cleaned = line.replace(/^[-*\d.\s]+/u, "").replace(/[`*_]/gu, "").trim();
+            const hasQuestionMark = /\?/u.test(cleaned);
+            const meaningful = cleaned.match(/[\p{L}\p{N}]/gu)?.length ?? 0;
+            return !hasQuestionMark && meaningful < 12;
+        });
+        if (sparseBullets.length > bulletRows.length - 3) {
+            return {
+                ok: false,
+                details: "Premise Challenge bullet list must include at least 3 substantive Q/A lines (a question mark plus the answer, or a labelled `Question: answer` pair)."
+            };
+        }
+    }
+    return {
+        ok: true,
+        details: `Premise Challenge structures ${rowCount} Q/A rows.`
+    };
+}
+function validateScopeSummary(sectionBody) {
+    const meaningfulLines = sectionBody
+        .split(/\r?\n/)
+        .map((line) => line.trim())
+        .filter((line) => line.length > 0 && /[\p{L}\p{N}]/u.test(line));
+    if (meaningfulLines.length < 2) {
+        return {
+            ok: false,
+            details: "Scope Summary must list at least 2 substantive lines covering the selected mode and the next-stage handoff."
+        };
+    }
+    if (!hasCanonicalScopeMode(sectionBody)) {
+        return {
+            ok: false,
+            details: "Scope Summary must name the selected mode using a canonical token (SCOPE EXPANSION, SELECTIVE EXPANSION, HOLD SCOPE, SCOPE REDUCTION) or a short form on a `Mode:` line (hold, selective, expansion, reduction)."
+        };
+    }
+    if (!NEXT_STAGE_HANDOFF_REGEX.test(sectionBody)) {
+        return {
+            ok: false,
+            details: "Scope Summary must record the track-aware next-stage handoff (mention `design` for standard, `spec` for medium, or include a `Next-stage handoff:` line)."
+        };
+    }
+    return {
+        ok: true,
+        details: "Scope Summary names the selected mode and the next-stage handoff."
+    };
+}
 const INTERACTION_EDGE_CASE_REQUIREMENTS = [
     { label: "double-click", pattern: /\bdouble[\s-]?click\b/iu },
     {
@@ -1212,6 +1336,12 @@ function validateSectionBody(sectionBody, rule, sectionName) {
     if (sectionNameNormalized === "pre-scope system audit") {
         return validatePreScopeSystemAudit(sectionBody);
     }
+    if (sectionNameNormalized === "scope summary") {
+        return validateScopeSummary(sectionBody);
+    }
+    if (sectionNameNormalized === "premise challenge") {
+        return validatePremiseChallenge(sectionBody);
+    }
     if (sectionNameNormalized === "data flow") {
         return validateInteractionEdgeCaseMatrix(sectionBody);
     }

package/dist/content/examples.js

@@ -142,9 +142,11 @@ The original premise (“add notifications”) was reframed to **“ensure users
 
 ## Scope Summary
 
+- Selected mode: SELECTIVE EXPANSION (cherry-pick durable feed on hold-scope baseline).
 - Accepted scope: durable feed + SSE + explicit degraded UX.
 - Deferred: WebSocket channel and rich-media/search enhancements.
-- Explicitly excluded: outbound channels and marketing workflows for v1.`,
+- Explicitly excluded: outbound channels and marketing workflows for v1.
+- Next-stage handoff: design — carry the durable-feed contract, SSE failover paths, and degraded-UX expectations into architecture lock-in.`,
     design: `## Codebase Investigation (blast-radius files)
 
 | File | Current responsibility | Patterns discovered |

package/dist/content/stages/brainstorm.js

@@ -36,23 +36,29 @@ export const BRAINSTORM = {
     },
     executionModel: {
         checklist: [
-            "**Explore project context** — inspect existing files/docs/recent activity before asking what to build.",
+            "**Explore project context** — inspect existing files/docs/recent activity before asking what to build; capture matching files/patterns/seeds in `Context > Discovered context` so downstream stages don't redo discovery.",
             "**Classify depth and scope** — pick Lightweight / Standard / Deep; decompose independent subsystems before deeper work.",
+            "**Premise check (one pass)** — answer the three gstack-style questions in the artifact body: *Right problem? Direct path? What if we do nothing?* Take a position; do not hedge.",
+            "**Reframe with How Might We** — write a single `How Might We …?` line that names the user, the desired outcome, and the constraint. This is the altitude check before approaches.",
+            "**Sharpening questions (3-5)** — capture decision-changing question/answer pairs in the `Sharpening Questions` table with the actual decision impact; if a question would not change architecture/scope/UX, state the assumption and skip it.",
             "**Use compact discovery for simple apps** — for concrete low-risk asks (todo app, landing page, local widget), do one context pass, compare one baseline and one challenger, then ask for one explicit approval; do not drag the user through a full workshop.",
             "**Short-circuit concrete asks** — for unambiguous implementation-only requests, write a compact brainstorm stub (context, problem, approved intent, constraints, assumptions) and ask for one explicit approval.",
             "**Ask only decision-changing questions** — one at a time; if answers would not change approach, state the assumption and continue.",
-            "**Compare 2-3 distinct approaches** — include real trade-offs, withhold recommendation, and include one higher-upside challenger.",
+            "**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 and reuse notes; 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 and tighten the artifact** — scale sections to complexity, optionally add a compact diagram, then patch contradictions, weak trade-offs, placeholders, ambiguity, and weak handoff language.",
+            "**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.",
+            "**Self-review before user approval** — re-read the artifact and patch contradictions, weak trade-offs, placeholders, ambiguity, and weak handoff language; record the patch list in `Self-Review Notes` (or `- None.`).",
             "**Request explicit approval** — state exactly what direction is being approved; do not advance without approval and artifact review.",
             "**Handoff** — only after approval, complete the stage and point to `/cc-next`."
         ],
         interactionProtocol: [
-            "Start from observed project context; if the idea is vague, first narrow the project type.",
+            "Start from observed project context; if the idea is vague, first narrow the project type with **one** structured question, then keep going.",
+            "Lead with the premise check (right problem / direct path / what if nothing) and the `How Might We` reframing before approaches; both go in the artifact, not just the chat.",
             "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.",
-            "If likely answers do not change architecture or scope boundaries, choose the default and state the assumption.",
-            "For simple greenfield web apps, present a compact A/B choice with one recommended path and one higher-upside challenger; keep the artifact concise but structurally complete.",
+            "If likely answers do not change architecture or scope boundaries, choose the default and state the assumption inline.",
+            "For simple greenfield web apps, 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."
         ],
         process: [
@@ -117,16 +123,21 @@ export const BRAINSTORM = {
             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: "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", required: true, validationRule: "Must define what we're solving, success criteria, and constraints." },
+            { section: "Premise Check", required: false, validationRule: "Recommended: explicit answers to `Right problem?`, `Direct path?`, `What if we do nothing?` — take a position, do not hedge." },
+            { section: "How Might We", required: false, validationRule: "Recommended: a single `How Might We …?` line naming the user, the outcome, and the binding constraint." },
+            { section: "Sharpening Questions", required: false, validationRule: "Recommended: 3-5 question/answer pairs with explicit `Decision impact` so downstream stages see what each answer changed." },
             { section: "Clarifying Questions", required: false, validationRule: "Must capture question, answer, and decision impact for each clarifying question." },
             { section: "Approach Tier", required: true, validationRule: "Must classify depth as Lightweight/Standard/Deep and explain why." },
             { 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: "Approaches", required: true, validationRule: "Must compare 2-3 distinct options with real trade-offs; include one option marked as a challenger with explicit high/higher upside." },
+            { 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." },
             { 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, an explicit approval marker, rationale traceable to the prior Approach Reaction, and a track-aware next-stage handoff." },
+            { 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: "Self-Review Notes", required: false, validationRule: "Recommended: list of patches applied during self-review (or `- None.`) — done before requesting user approval." },
             { section: "Assumptions and Open Questions", required: false, validationRule: "Must capture unresolved assumptions/open questions, or explicitly state none." }
         ],
         trivialOverrideSections: [

package/dist/content/stages/scope.js

@@ -46,13 +46,14 @@ export const SCOPE = {
     executionModel: {
         checklist: [
             "**Compact CEO pass first** — read brainstorm, name the job-to-be-done, challenge whether this is the right product slice, and propose the highest-leverage scope in one pass. For simple apps, keep this to a tight scope contract instead of a full strategy workshop.",
-            "**Pick one of four gstack modes with the user** — SCOPE EXPANSION, SELECTIVE EXPANSION, HOLD SCOPE, or SCOPE REDUCTION. Recommend one, state why and what signal would change it, then STOP for the user's mode/scope approval before writing the final artifact.",
+            "**Premise and leverage check** — answer in the artifact: *Right problem? Direct path? What if nothing? Where can we leverage existing code? What is the reversibility cost?* Take a position; do not hedge.",
             "**Draft the 10-star vs current-slice boundary** — show what would make the product meaningfully better, then explicitly choose what ships now, what is deferred, and what is excluded without using vague `later/for now` placeholders.",
-            "**Premise and leverage check** — test right problem, direct path, no-action outcome, existing-code leverage, and reversibility before asking the user anything.",
-            "**Compare implementation alternatives** — include minimum viable, product-grade, and ideal architecture options with effort/risk/reuse, then recommend one.",
+            "**Pick one of four gstack modes with the user** — SCOPE EXPANSION, SELECTIVE EXPANSION, HOLD SCOPE, or SCOPE REDUCTION. Recommend one, state why and what signal would change it, then STOP for the user's mode/scope approval before writing the final artifact.",
+            "**Run mode-specific analysis** — match the analysis to the chosen mode: SCOPE EXPANSION enumerates 10x opportunities + delight features; SELECTIVE EXPANSION lists baseline + cherry-picked additions with leverage rationale; HOLD SCOPE proves rigor on the current slice; SCOPE REDUCTION names the smallest useful wedge and what is cut, with follow-up split.",
+            "**Compare implementation alternatives** — include minimum viable, product-grade, and ideal architecture options with effort (S/M/L/XL), risk (Low/Med/High), pros, cons, and reuses. Recommend one and tie it to mode.",
             "**Run outside voice before final approval** — for simple/low-risk scope, record one concise adversarial self-check row; for complex/high-risk/configured scope, iterate until threshold. Record the loop summary in `## Spec Review Loop`, but do not treat it as user approval.",
             "**Ask only one decision-changing question** — if the user rejects the contract but is unsure, offer 3-4 concrete scope moves instead of open-ended interrogation.",
-            "**Write the scope contract after approval** — include in-scope/out-of-scope, discretion areas, deferred items, locked decisions, error/rescue notes, completion dashboard, scope summary, next-stage handoff, and explicit approval evidence."
+            "**Write the scope contract after approval** — include in-scope/out-of-scope, discretion areas, deferred items, locked decisions, error/rescue notes, completion dashboard, scope summary (with canonical mode token + next-stage handoff), and explicit approval evidence."
         ],
         interactionProtocol: [
             decisionProtocolInstruction("scope mode selection", "present expand/selective/hold/reduce as labeled options with trade-offs and mark one as (recommended)", "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"),
@@ -138,7 +139,7 @@ export const SCOPE = {
             { section: "Upstream Handoff", required: false, validationRule: "Summarizes brainstorm/idea decisions, constraints, open questions, and explicit drift before scope decisions." },
             { section: "Pre-Scope System Audit", required: false, validationRule: "When `.cclaw/config.yaml::optInAudits.scopePreAudit` is true: must capture git log -30, git diff --stat, git stash list, and debt-marker scan (TODO/FIXME/XXX/HACK) before premise challenge." },
             { section: "Prime Directives", required: false, 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: false, validationRule: "Must contain explicit answers to: right problem? direct path? what if nothing?" },
+            { section: "Premise Challenge", required: false, validationRule: "Must list at least 3 question/answer rows in a markdown table or bullet list (gstack default trio: right problem? direct path? what if we do nothing? — extend with leverage and reversibility for richer scope). The linter enforces structure, not English wording — answers may be in any language." },
             { section: "Landscape Check", required: false, validationRule: "When mode is EXPAND/SELECTIVE, include at least one external reference insight and its impact on scope." },
             { section: "Taste Calibration", required: false, validationRule: "Must reference 2-3 strong in-repo modules/files that define the quality bar or explicitly justify omission." },
             { section: "Requirements", required: false, 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`." },
@@ -153,7 +154,7 @@ export const SCOPE = {
             { section: "Outside Voice Findings", required: false, validationRule: "Must list external/adversarial findings and disposition (accept/reject/defer) with rationale." },
             { section: "Spec Review Loop", required: false, validationRule: `Must record iterations, quality score per iteration, stop reason, and unresolved concerns. Enforce ${reviewLoopPolicySummary("scope")}` },
             { section: "Completion Dashboard", required: true, validationRule: "Lists per-review-section status, count of critical/open gaps, resolved decisions, and unresolved decisions (or 'None')." },
-            { section: "Scope Summary", required: true, validationRule: "Clean summary: mode, strongest challenges, recommended path, accepted scope, deferred, excluded, and track-aware next-stage handoff." },
+            { section: "Scope Summary", required: true, validationRule: "Compact recap of the locked scope. Must name the selected mode using one of the canonical tokens (`SCOPE EXPANSION`, `SELECTIVE EXPANSION`, `HOLD SCOPE`, `SCOPE REDUCTION`) and record the track-aware next-stage handoff (`design` for standard, `spec` for medium); the linter checks structure, not English wording." },
             { 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." }
         ]

package/dist/content/templates.js

@@ -26,11 +26,29 @@ export const ARTIFACT_TEMPLATES = {
 - **Project state:**
 - **Relevant existing code/patterns:**
 
+### Discovered context
+- (paths, prior artifacts, seeds, prompt fragments — referenced by downstream stages, or \`- None.\`)
+
 ## Problem
 - **What we're solving:**
 - **Success criteria:**
 - **Constraints:**
 
+## Premise Check
+- **Right problem?** (yes/no + one-line justification — take a position)
+- **Direct path?** (yes/no + one-line justification)
+- **What if we do nothing?** (concrete consequence, not "nothing happens")
+
+## How Might We
+- *How might we …?* — one line naming the user, the desired outcome, and the binding constraint.
+
+## Sharpening Questions
+| # | Question | Answer / Assumption | Decision impact |
+|---|---|---|---|
+| 1 |  |  |  |
+| 2 |  |  |  |
+| 3 |  |  |  |
+
 ## Clarifying Questions
 | # | Question | Answer | Decision impact |
 |---|---|---|---|
@@ -46,10 +64,12 @@ export const ARTIFACT_TEMPLATES = {
 - Scope handoff:
 
 ## Approaches
-| Approach | Role | Upside | Architecture | Trade-offs | Recommendation |
-|---|---|---|---|---|---|
-| A | baseline | modest |  |  |  |
-| B | challenger | high |  |  |  |
+| Approach | Role | Upside | Architecture | Trade-offs | Reuses | Recommendation |
+|---|---|---|---|---|---|---|
+| A | baseline | modest |  |  |  |  |
+| B | challenger | high |  |  |  |  |
+
+> Role values: \`baseline\` | \`challenger\` | \`wild-card\`. Upside values: \`low\` | \`modest\` | \`high\` | \`higher\`. Exactly one row must be a \`challenger\` with \`high\` or \`higher\` upside.
 
 ## Approach Reaction
 - Closest option:
@@ -62,6 +82,9 @@ export const ARTIFACT_TEMPLATES = {
 - **Approval:** pending
 - **Next-stage handoff:** On standard track, hand this to \`scope\`; on medium track, hand this directly to \`spec\` with explicit requirements/constraints.
 
+## Not Doing
+- (3-5 things this brainstorm is *not* committing to — distinct from \`Deferred\`. These will not appear in scope unless the user explicitly opts in.)
+
 ${SEED_SHELF_SECTION}
 
 ## Design
@@ -69,6 +92,12 @@ ${SEED_SHELF_SECTION}
 - **Key components:**
 - **Data flow:**
 
+## Visual Companion
+- (compact ASCII/Mermaid diagram for medium+ complexity, or one-line justification for omission.)
+
+## Self-Review Notes
+- (list patches applied to this artifact during self-review, or \`- None.\`)
+
 ## Assumptions and Open Questions
 - **Assumptions:**
 - **Open questions (or "None"):**
@@ -101,9 +130,13 @@ ${SEED_SHELF_SECTION}
 - Four paths per data flow:
 
 ## Premise Challenge
-- Is this the right problem?
-- Why this path?
-- What if we do nothing?
+| Question | Answer (take a position) | Evidence / leverage |
+|---|---|---|
+| Right problem? |  |  |
+| Direct path? |  |  |
+| What if we do nothing? |  |  |
+| Existing-code leverage? |  |  |
+| Reversibility cost? |  |  |
 
 ## Dream State Mapping
 - CURRENT STATE:
@@ -198,7 +231,9 @@ ${SEED_SHELF_SECTION}
 - Unresolved decisions (or \`None\`):
 
 ## Scope Summary
-- Selected mode:
+- Selected mode: (one of \`SCOPE EXPANSION\` | \`SELECTIVE EXPANSION\` | \`HOLD SCOPE\` | \`SCOPE REDUCTION\`)
+- Strongest challenges resolved:
+- Recommended path:
 - Accepted scope:
 - Deferred:
 - Explicitly excluded:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cclaw-cli",
-  "version": "0.51.9",
+  "version": "0.51.10",
   "description": "Installer-first flow toolkit for coding agents",
   "type": "module",
   "bin": {