gsd-pi 2.71.0-dev.e17e0ce → 2.72.0-dev.3118184

package/src/resources/extensions/gsd/key-manager.ts

@@ -49,6 +49,8 @@ export const PROVIDER_REGISTRY: ProviderInfo[] = [
   { id: "custom-openai",    label: "Custom (OpenAI-compat)",  category: "llm", envVar: "CUSTOM_OPENAI_API_KEY" },
   { id: "cerebras",         label: "Cerebras",                category: "llm", envVar: "CEREBRAS_API_KEY" },
   { id: "azure-openai-responses", label: "Azure OpenAI",      category: "llm", envVar: "AZURE_OPENAI_API_KEY" },
+  { id: "alibaba-coding-plan", label: "Alibaba Coding Plan",  category: "llm", envVar: "ALIBABA_API_KEY",      dashboardUrl: "bailian.console.aliyun.com" },
+  { id: "alibaba-dashscope",   label: "Alibaba DashScope",    category: "llm", envVar: "DASHSCOPE_API_KEY",    dashboardUrl: "dashscope.console.aliyun.com" },
 
   // Tool Keys
   { id: "context7",  label: "Context7 Docs",     category: "tool", envVar: "CONTEXT7_API_KEY",  dashboardUrl: "context7.com/dashboard" },

package/src/resources/extensions/gsd/milestone-validation-gates.ts

@@ -6,19 +6,13 @@
  * records in the DB. This module inserts milestone-level validation gates
  * that correspond to the validation checks performed.
  *
- * Gate IDs for milestone validation:
- *   MV01 — Success criteria checklist
- *   MV02 — Slice delivery audit
- *   MV03 — Cross-slice integration
- *   MV04 — Requirement coverage
- *
- * These use the existing quality_gates table with scope "milestone".
+ * Gate IDs for milestone validation (MV01–MV04) are sourced from the
+ * gate registry so the definitions stay in lockstep with prompt builders,
+ * dispatch rules, and state derivation. See gate-registry.ts.
  */
 
 import { _getAdapter } from "./gsd-db.js";
-
-/** Milestone validation gate IDs. */
-const MILESTONE_GATE_IDS = ["MV01", "MV02", "MV03", "MV04"] as const;
+import { getGatesForTurn } from "./gate-registry.js";
 
 /**
  * Insert milestone-level quality_gates records for a validation run.
@@ -27,6 +21,9 @@ const MILESTONE_GATE_IDS = ["MV01", "MV02", "MV03", "MV04"] as const;
  * from the overall milestone validation verdict. Individual gate-level
  * verdicts are not available (the handler receives a single verdict),
  * so all gates share the overall verdict.
+ *
+ * Gate IDs come from the registry — adding/removing an MV-scoped gate
+ * in gate-registry.ts automatically flows through here.
  */
 export function insertMilestoneValidationGates(
   milestoneId: string,
@@ -38,8 +35,9 @@ export function insertMilestoneValidationGates(
   if (!db) return;
 
   const gateVerdict = verdict === "pass" ? "pass" : "flag";
+  const milestoneGates = getGatesForTurn("validate-milestone");
 
-  for (const gateId of MILESTONE_GATE_IDS) {
+  for (const def of milestoneGates) {
     db.prepare(
       `INSERT OR REPLACE INTO quality_gates
        (milestone_id, slice_id, gate_id, scope, task_id, status, verdict, rationale, findings, evaluated_at)
@@ -47,9 +45,9 @@ export function insertMilestoneValidationGates(
     ).run({
       ":mid": milestoneId,
       ":sid": sliceId,
-      ":gid": gateId,
+      ":gid": def.id,
       ":verdict": gateVerdict,
-      ":rationale": `Milestone validation verdict: ${verdict}`,
+      ":rationale": `${def.promptSection} — milestone validation verdict: ${verdict}`,
       ":evaluated_at": evaluatedAt,
     });
   }

package/src/resources/extensions/gsd/notification-overlay.ts

@@ -9,6 +9,7 @@ import {
   readNotifications,
   markAllRead,
   clearNotifications,
+  onNotificationStoreChange,
   type NotificationEntry,
   type NotifySeverity,
 } from "./notification-store.js";
@@ -82,6 +83,7 @@ export class GSDNotificationOverlay {
   private refreshTimer: ReturnType<typeof setInterval>;
   private disposed = false;
   private resizeHandler: (() => void) | null = null;
+  private unsubscribeStore: (() => void) | null = null;
 
   constructor(
     tui: { requestRender: () => void },
@@ -105,19 +107,17 @@ export class GSDNotificationOverlay {
     };
     process.stdout.on("resize", this.resizeHandler);
 
-    // Refresh every 3s for new notifications
+    // Subscribe to store mutations for immediate updates
+    this.unsubscribeStore = onNotificationStoreChange(() => {
+      if (this.disposed) return;
+      this._refreshFromDisk();
+    });
+
+    // 30s safety-net for cross-process edits (web subprocess, parallel workers)
     this.refreshTimer = setInterval(() => {
       if (this.disposed) return;
-      const fresh = readNotifications();
-      const signature = notificationSignature(fresh);
-      if (signature !== this.entriesSignature) {
-        markAllRead();
-        this.entries = readNotifications();
-        this.entriesSignature = notificationSignature(this.entries);
-        this.invalidate();
-        this.tui.requestRender();
-      }
-    }, 3000);
+      this._refreshFromDisk();
+    }, 30_000);
   }
 
   private get filter(): FilterMode {
@@ -215,12 +215,28 @@ export class GSDNotificationOverlay {
   dispose(): void {
     this.disposed = true;
     clearInterval(this.refreshTimer);
+    if (this.unsubscribeStore) {
+      this.unsubscribeStore();
+      this.unsubscribeStore = null;
+    }
     if (this.resizeHandler) {
       process.stdout.removeListener("resize", this.resizeHandler);
       this.resizeHandler = null;
     }
   }
 
+  private _refreshFromDisk(): void {
+    const fresh = readNotifications();
+    const signature = notificationSignature(fresh);
+    if (signature !== this.entriesSignature) {
+      markAllRead();
+      this.entries = readNotifications();
+      this.entriesSignature = notificationSignature(this.entries);
+      this.invalidate();
+      this.tui.requestRender();
+    }
+  }
+
   private wrapInBox(inner: string[], width: number): string[] {
     const th = this.theme;
     const border = (s: string) => th.fg("borderAccent", s);

package/src/resources/extensions/gsd/notification-store.ts

@@ -323,10 +323,11 @@ function _withLock<T>(basePath: string, fn: () => T): T {
     }
   }
 
-  // Only run the mutation if we actually own the lock
-  const ownsLock = fd !== null;
+  // Best-effort: mutation runs regardless of lock status (idempotent overwrites).
+  // createdLock gates cleanup only — never skip fn() on lock failure.
+  const createdLock = fd !== null;
   try {
-    if (ownsLock && fd !== null) {
+    if (createdLock && fd !== null) {
       // Write our PID timestamp into the lock for stale detection
       writeFileSync(lockPath, String(Date.now()), "utf-8");
       closeSync(fd);
@@ -334,7 +335,7 @@ function _withLock<T>(basePath: string, fn: () => T): T {
     return fn();
   } finally {
     // Only delete the lock if we created it — never remove another process's lock
-    if (ownsLock) {
+    if (createdLock) {
       try { unlinkSync(lockPath); } catch { /* best-effort cleanup */ }
     }
   }

package/src/resources/extensions/gsd/preferences-skills.ts

@@ -17,7 +17,6 @@ import type {
   SkillResolutionReport,
 } from "./preferences-types.js";
 import { validatePreferences } from "./preferences-validation.js";
-import { loadEffectiveGSDPreferences } from "./preferences.js";
 
 // Re-export types so existing consumers of ./preferences-skills.js keep working
 export type { GSDSkillRule, SkillDiscoveryMode, SkillResolution, SkillResolutionReport } from "./preferences-types.js";
@@ -143,38 +142,5 @@ export function resolveAllSkillReferences(preferences: GSDPreferences, cwd: stri
   return { resolutions, warnings };
 }
 
-/**
- * Format a skill reference for the system prompt.
- * If resolved, shows the path so the agent knows exactly where to read.
- * If unresolved, marks it clearly.
- */
-export function formatSkillRef(ref: string, resolutions: Map<string, SkillResolution>): string {
-  const resolution = resolutions.get(ref);
-  if (!resolution || resolution.method === "unresolved") {
-    return `${ref} (⚠ not found — check skill name or path)`;
-  }
-  // For absolute paths where SKILL.md is just appended, don't clutter the output
-  if (resolution.method === "absolute-path" || resolution.method === "absolute-dir") {
-    return ref;
-  }
-  // For bare names resolved from skill directories, show the resolved path
-  return `${ref} → \`${resolution.resolvedPath}\``;
-}
-
-/**
- * Resolve the skill discovery mode from effective preferences.
- * Defaults to "suggest" -- skills are identified during research but not installed automatically.
- */
-export function resolveSkillDiscoveryMode(): SkillDiscoveryMode {
-  const prefs = loadEffectiveGSDPreferences();
-  return prefs?.preferences.skill_discovery ?? "suggest";
-}
-
-/**
- * Resolve the skill staleness threshold in days.
- * Returns 0 if disabled, default 60 if not configured.
- */
-export function resolveSkillStalenessDays(): number {
-  const prefs = loadEffectiveGSDPreferences();
-  return prefs?.preferences.skill_staleness_days ?? 60;
-}
+// resolveSkillDiscoveryMode and resolveSkillStalenessDays moved to
+// preferences.ts to break circular dependency (they need loadEffectiveGSDPreferences).

package/src/resources/extensions/gsd/preferences-types.ts

@@ -384,3 +384,19 @@ export interface SkillResolutionReport {
   /** References that could not be resolved. */
   warnings: string[];
 }
+
+/**
+ * Format a skill reference for the system prompt.
+ * If resolved, shows the path so the agent knows exactly where to read.
+ * If unresolved, marks it clearly.
+ */
+export function formatSkillRef(ref: string, resolutions: Map<string, SkillResolution>): string {
+  const resolution = resolutions.get(ref);
+  if (!resolution || resolution.method === "unresolved") {
+    return `${ref} (⚠ not found — check skill name or path)`;
+  }
+  if (resolution.method === "absolute-path" || resolution.method === "absolute-dir") {
+    return ref;
+  }
+  return `${ref} → \`${resolution.resolvedPath}\``;
+}

package/src/resources/extensions/gsd/preferences.ts

@@ -29,9 +29,10 @@ import {
   type GSDPreferences,
   type LoadedGSDPreferences,
   type SkillResolution,
+  type SkillDiscoveryMode,
+  formatSkillRef,
 } from "./preferences-types.js";
 import { validatePreferences } from "./preferences-validation.js";
-import { formatSkillRef } from "./preferences-skills.js";
 
 // ─── Re-exports: types ──────────────────────────────────────────────────────
 // Every type/interface that was previously exported from this file is
@@ -60,11 +61,20 @@ export type {
 export { validatePreferences } from "./preferences-validation.js";
 
 // ─── Re-exports: skills ─────────────────────────────────────────────────────
-export {
-  resolveAllSkillReferences,
-  resolveSkillDiscoveryMode,
-  resolveSkillStalenessDays,
-} from "./preferences-skills.js";
+export { resolveAllSkillReferences } from "./preferences-skills.js";
+
+// These lived in preferences-skills.ts but imported loadEffectiveGSDPreferences
+// back from this file, creating a circular dependency. Moved here since they
+// are trivial wrappers over loadEffectiveGSDPreferences.
+export function resolveSkillDiscoveryMode(): SkillDiscoveryMode {
+  const prefs = loadEffectiveGSDPreferences();
+  return prefs?.preferences.skill_discovery ?? "suggest";
+}
+
+export function resolveSkillStalenessDays(): number {
+  const prefs = loadEffectiveGSDPreferences();
+  return prefs?.preferences.skill_staleness_days ?? 60;
+}
 
 // ─── Re-exports: models ─────────────────────────────────────────────────────
 export {
@@ -389,6 +399,9 @@ function mergePreferences(base: GSDPreferences, override: GSDPreferences): GSDPr
     github: (base.github || override.github)
       ? { ...(base.github ?? {}), ...(override.github ?? {}) } as import("../github-sync/types.js").GitHubSyncConfig
       : undefined,
+    experimental: (base.experimental || override.experimental)
+      ? { ...(base.experimental ?? {}), ...(override.experimental ?? {}) }
+      : undefined,
     service_tier: override.service_tier ?? base.service_tier,
     forensics_dedup: override.forensics_dedup ?? base.forensics_dedup,
     show_token_cost: override.show_token_cost ?? base.show_token_cost,

package/src/resources/extensions/gsd/prompt-loader.ts

@@ -143,10 +143,15 @@ export function loadPrompt(name: string, vars: Record<string, string> = {}): str
   }
 
   for (const [key, value] of Object.entries(effectiveVars)) {
+    const safeValue =
+      key === "workingDirectory" && typeof value === "string"
+        ? value.replaceAll("\\", "/")
+        : value;
+
     // Use split/join instead of replaceAll to avoid JavaScript's special
     // replacement patterns ($', $`, $&) being interpreted in the value.
     // See: https://github.com/gsd-build/gsd-2/issues/2968
-    content = content.split(`{{${key}}}`).join(value);
+    content = content.split(`{{${key}}}`).join(safeValue);
   }
 
   return content.trim();

package/src/resources/extensions/gsd/prompt-validation.ts

@@ -0,0 +1,157 @@
+/**
+ * GSD Prompt Validation — Validates enhanced context and turn output
+ * artifacts before writing.
+ *
+ * Implements R109 validation requirement: CONTEXT.md must have required
+ * sections before being written to disk. Additionally, per-turn validators
+ * check that artifacts produced by gate-owning turns contain the gate
+ * sections declared in gate-registry.ts, so a malformed summary/validation
+ * markdown file cannot silently drop a quality gate.
+ */
+
+import { getGatesForTurn, type OwnerTurn } from "./gate-registry.js";
+
+/**
+ * Result of validating enhanced context output.
+ */
+export interface ValidationResult {
+  /** Whether all required sections are present. */
+  valid: boolean;
+  /** List of missing required sections. */
+  missing: string[];
+}
+
+/**
+ * Validate that enhanced context content has all required sections.
+ *
+ * Required sections per R109:
+ * - Scope section (## Scope, ## Milestone Scope, or ## Why This Milestone)
+ * - Architectural Decisions section (## Architectural Decisions)
+ * - Acceptance Criteria section (## Acceptance Criteria or ## Final Integrated Acceptance)
+ *
+ * Additionally validates that the Architectural Decisions section contains
+ * at least one decision entry (### heading or **Decision marker).
+ *
+ * @param content - The enhanced context markdown content
+ * @returns ValidationResult with valid flag and list of missing sections
+ */
+export function validateEnhancedContext(content: string): ValidationResult {
+  const missing: string[] = [];
+
+  // Required section 1: Scope (multiple acceptable header variants)
+  const hasScopeSection =
+    /^## Scope\b/m.test(content) ||
+    /^## Milestone Scope\b/m.test(content) ||
+    /^## Why This Milestone\b/m.test(content);
+
+  if (!hasScopeSection) {
+    missing.push("Milestone Scope or Why This Milestone");
+  }
+
+  // Required section 2: Architectural Decisions
+  const hasArchitecturalDecisions = /^## Architectural Decisions\b/m.test(content);
+  if (!hasArchitecturalDecisions) {
+    missing.push("Architectural Decisions");
+  }
+
+  // Required section 3: Acceptance Criteria (multiple acceptable header variants)
+  const hasAcceptanceCriteria =
+    /^## Acceptance Criteria\b/m.test(content) ||
+    /^## Final Integrated Acceptance\b/m.test(content);
+
+  if (!hasAcceptanceCriteria) {
+    missing.push("Acceptance Criteria");
+  }
+
+  // Additional validation: Architectural Decisions must have at least one entry
+  if (hasArchitecturalDecisions) {
+    // Extract the section content between ## Architectural Decisions and the next ## heading.
+    // Uses indexOf-based extraction instead of regex with \z (which is invalid in JavaScript
+    // regex — it's PCRE/Ruby syntax and JS treats it as literal 'z').
+    const sectionStart = content.indexOf("## Architectural Decisions");
+    if (sectionStart === -1) {
+      missing.push("Architectural Decisions");
+    } else {
+      const afterHeading = content.slice(sectionStart + "## Architectural Decisions".length);
+      const nextSection = afterHeading.search(/^## /m);
+      const sectionContent = nextSection === -1 ? afterHeading : afterHeading.slice(0, nextSection);
+
+      // Check for actual decision entries:
+      // - ### heading (subsection per decision)
+      // - **Decision marker (inline decision format)
+      const hasDecisionEntry = /^### /m.test(sectionContent) || /^\*\*Decision/m.test(sectionContent);
+
+      if (!hasDecisionEntry) {
+        missing.push("At least one architectural decision entry");
+      }
+    }
+  }
+
+  return {
+    valid: missing.length === 0,
+    missing,
+  };
+}
+
+// ─── Per-Turn Gate Section Validators ─────────────────────────────────────
+//
+// Each validator checks that the artifact written by a turn contains a
+// heading for every gate owned by that turn. The registry is the source
+// of truth for which sections must exist; adding a new gate automatically
+// flows through via `getGatesForTurn(turn)`.
+
+/**
+ * Escape a string so it can be embedded safely inside a regular expression.
+ */
+function escapeRegExp(value: string): string {
+  return value.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
+}
+
+/**
+ * Validate that an artifact contains an `## H2` heading for every gate the
+ * named turn owns. Returns the list of missing gate section headers.
+ *
+ * Soft rule: a section counts as "present" if it is declared (H2 heading
+ * exists) — empty-body sections are allowed and handled by the tool
+ * handler, which will record such gates as `omitted`.
+ */
+export function validateGateSections(
+  content: string,
+  turn: OwnerTurn,
+): ValidationResult {
+  const missing: string[] = [];
+  for (const def of getGatesForTurn(turn)) {
+    const pattern = new RegExp(`^##\\s+${escapeRegExp(def.promptSection)}\\b`, "m");
+    if (!pattern.test(content)) {
+      missing.push(`${def.id} (## ${def.promptSection})`);
+    }
+  }
+  return { valid: missing.length === 0, missing };
+}
+
+/**
+ * Validate a SUMMARY.md produced by the complete-slice turn. Requires
+ * an H2 heading for every gate owned by complete-slice (e.g. Q8 →
+ * "## Operational Readiness"). Intended for use in the tool handler's
+ * pre-write checks or in the post-unit validation sweep.
+ */
+export function validateSliceSummaryOutput(content: string): ValidationResult {
+  return validateGateSections(content, "complete-slice");
+}
+
+/**
+ * Validate a task SUMMARY.md produced by the execute-task turn. Only
+ * flags gates that are still pending for the task; skips the check
+ * when no rows are seeded (simple task).
+ */
+export function validateTaskSummaryOutput(content: string): ValidationResult {
+  return validateGateSections(content, "execute-task");
+}
+
+/**
+ * Validate a VALIDATION.md produced by the validate-milestone turn.
+ * Requires an H2 heading for every MV gate declared in the registry.
+ */
+export function validateMilestoneValidationOutput(content: string): ValidationResult {
+  return validateGateSections(content, "validate-milestone");
+}

package/src/resources/extensions/gsd/prompts/complete-slice.md

@@ -16,6 +16,8 @@ All relevant context has been preloaded below — the slice plan, all task summa
 
 {{inlinedContext}}
 
+{{gatesToClose}}
+
 **Match effort to complexity.** A simple slice with 1-2 tasks needs a brief summary and lightweight verification. A complex slice with 5 tasks across multiple subsystems needs thorough verification and a detailed summary. Scale the work below accordingly.
 
 Then:
@@ -23,7 +25,7 @@ Then:
 2. {{skillActivation}}
 3. Run all slice-level verification checks defined in the slice plan. All must pass before marking the slice done. If any fail, fix them first. Task artifacts use a **flat file layout** directly inside `tasks/` (for example `T01-SUMMARY.md`, `T02-SUMMARY.md`) rather than per-task subdirectories. If you need to count or re-read task summaries during verification, use `find .gsd/milestones/{{milestoneId}}/slices/{{sliceId}}/tasks -name "*-SUMMARY.md"` or `ls .gsd/milestones/{{milestoneId}}/slices/{{sliceId}}/tasks/*-SUMMARY.md`. Never use `tasks/*/SUMMARY.md` — that glob expects subdirectories that do not exist.
 4. If the slice plan includes observability/diagnostic surfaces, confirm they work. Skip this for simple slices that don't have observability sections.
-5. If the slice involved runtime behavior, fill the **Operational Readiness** section (Q8) in the slice summary: health signal, failure signal, recovery procedure, and monitoring gaps. Omit entirely for simple slices with no runtime concerns.
+5. Address every gate listed in the **Gates to Close** section above — each gate maps to a specific slice-summary section the handler inspects (for example, Q8 maps to **Operational Readiness**: health signal, failure signal, recovery procedure, and monitoring gaps). Leaving a section empty records the gate as `omitted`.
 6. If this slice produced evidence that a requirement changed status (Active → Validated, Active → Deferred, etc.), call `gsd_requirement_update` with the requirement ID, updated `status`, and `validation` evidence. Do NOT write `.gsd/REQUIREMENTS.md` directly — the engine renders it from the database.
 7. Prepare the slice completion content you will pass to `gsd_complete_slice` using the camelCase fields `milestoneId`, `sliceId`, `sliceTitle`, `oneLiner`, `narrative`, `verification`, and `uatContent`. Do **not** manually write `{{sliceSummaryPath}}`. Do **not** manually write `{{sliceUatPath}}` — the DB-backed tool is the canonical write path for both artifacts.
 8. Draft the UAT content you will pass as `uatContent` — a concrete UAT script with real test cases derived from the slice plan and task summaries. Include preconditions, numbered steps with expected outcomes, and edge cases. This must NOT be a placeholder or generic template — tailor every test case to what this slice actually built.

package/src/resources/extensions/gsd/prompts/discuss.md

@@ -49,31 +49,132 @@ This happens ONCE, before the first round. The goal: your first questions should
 
 For subsequent rounds, continue investigating between rounds — check docs, search, or scout as needed to make each round's questions smarter. But the first-round investigation is mandatory and explicit. Distribute searches across turns rather than clustering them in one turn.
 
-## Question Rounds
+## Layered Question Rounds
 
-Ask **1–3 questions per round**. Keep each round tightly focused on one or two of the depth checklist dimensions — do not try to cover all six in one round.
+Questions are organized into four layers. Each layer targets a specific depth dimension. At each layer: ask 1-3 open questions per round, investigate between rounds as needed, and gate before advancing.
 
-**If `{{structuredQuestionsAvailable}}` is `true`:** use `ask_user_questions` for each round. 1–3 questions per call, each as a separate question object. Keep option labels short (3–5 words). Always include a freeform "Other / let me explain" option. When the user picks that option or writes a long freeform answer, switch to plain text follow-up for that thread before resuming structured questions. **IMPORTANT: Call `ask_user_questions` exactly once per turn. Never make multiple calls with the same or overlapping questions — wait for the user's response before asking the next round.**
+**Default to open questions.** Use `ask_user_questions` only when there are 2-3 genuinely distinct paths with clear tradeoffs (e.g., "REST vs GraphQL" or "Postgres vs SQLite"). For nuanced design questions, ask in plain text and let the user explain.
 
-**If `{{structuredQuestionsAvailable}}` is `false`:** ask questions in plain text. Keep each round to 1–3 focused questions. Wait for answers before asking the next round.
+**If `{{structuredQuestionsAvailable}}` is `true`:** use `ask_user_questions` for binary/ternary choices. Keep option labels short (3-5 words). Always include a freeform "Other / let me explain" option. When the user picks that option or writes a long freeform answer, switch to plain text follow-up for that thread before resuming structured questions. **IMPORTANT: Call `ask_user_questions` exactly once per turn. Never make multiple calls with the same or overlapping questions — wait for the user's response before asking the next round.**
 
-After each answer set, investigate further if any answer opens a new unknown, then ask the next round.
+**If `{{structuredQuestionsAvailable}}` is `false`:** ask questions in plain text. Keep each round to 1-3 focused questions. Wait for answers before asking the next round.
 
-### Round cadence
+**Incremental persistence:** After every 2 question rounds (across any layer), silently save a `{{milestoneId}}-CONTEXT-DRAFT.md` using `gsd_summary_save` with `artifact_type: "CONTEXT-DRAFT"` and `milestone_id: "{{milestoneId}}"`. This protects confirmed work against session crashes. Do NOT mention this save to the user.
 
-After each round of answers, decide whether you already have enough depth to write strong output.
+### Identify Work Type
 
-- **Incremental persistence:** After every 2 question rounds, silently save a `{{milestoneId}}-CONTEXT-DRAFT.md` using `gsd_summary_save` with `artifact_type: "CONTEXT-DRAFT"` and `milestone_id: "{{milestoneId}}"`. This protects confirmed work against session crashes. Do NOT mention this save to the user.
-- If not ready, continue to the next round immediately. Do **not** ask a meta "ready to wrap up?" question after every round.
-- **Depth-matching rule:** Simple, well-defined work needs fewer rounds — maybe 1–2. Large, ambiguous visions need more — maybe 4+. Do not pad rounds to hit a number. Stop when the Depth Enforcement checklist below is fully satisfied.
-- Do not count the reflection step as a question round. Rounds start after reflection is confirmed.
-- When you genuinely believe the depth checklist is satisfied, move to the Depth Verification step below. Do not ask a separate "ready to wrap up?" gate — the depth verification IS the gate.
+Before starting Layer 1, identify the primary work type and state it:
+
+"Based on your description and the codebase, this is primarily **[work type]** work."
+
+Work types include: API/backend, UI/frontend, CLI/developer tool, data pipeline, ML/AI, infrastructure/platform, refactoring/migration, or a combination. The user can correct this. The classification shapes which questions deserve deep exploration at each layer.
+
+### Layer 1 — Scope
+
+Resolve what's in and what's out. Ask about:
+- Feature boundaries — what exactly ships in this milestone vs later
+- Ambiguities in the user's description — anything you're unsure about, ask
+- Dependencies — what does this work depend on, what depends on it
+- Priority — if scope needs trimming, what matters most
+
+Adapt depth to work type:
+- **CLI work:** Focus on user mental model, command grammar, what existing commands do
+- **Refactoring:** Focus on what changes vs what must stay identical
+
+**Depth-matching:** Simple, well-defined scope may need 1 round. Ambiguous or large scope may need 3-4 rounds. Don't pad rounds to hit a number.
+
+#### Layer 1 Gate
+
+Summarize scope decisions in the user's own terminology:
+- What's included, what's excluded, what's deferred
+- Key boundaries and constraints
+
+Then ask: **"Does this capture the scope? Adjust anything before we move on."**
+
+If the user adjusts, reflect the updated understanding and ask again. Do not advance until the user explicitly confirms. If the user says "looks good, let's move faster" at any gate, respect that and advance.
+
+---
+
+### Layer 2 — Architecture
+
+Resolve how it's built. Ask about:
+- Per-slice technical decisions — what approach for each major piece
+- Inter-slice contracts — how do the pieces connect
+- Library/framework choices — with evidence from investigation, not assumptions
+- Integration with existing code — what patterns to follow, what to change
+
+Adapt depth to work type:
+- **API work:** Contracts, versioning, backwards compatibility, auth boundaries
+- **UI work:** Component boundaries, state management, data flow
+- **Infrastructure:** Deployment topology, failure domains, rollback
+
+Between rounds, use your available web search tools to research technologies from the Codebase Brief. Search for "[technology] [version] best practices [current year]" and "[technology] [version] known issues". Present findings alongside your questions.
+
+#### Layer 2 Gate
+
+Summarize architecture decisions, each with:
+- The decision and rationale
+- Evidence source (codebase patterns, library docs, web research)
+- Alternatives considered
+
+Then ask: **"Does this capture the architecture? Adjust anything before we move on."**
+
+Same gate rules: reflect adjustments, wait for confirmation.
+
+---
+
+### Layer 3 — Error States
+
+Resolve what happens when things fail. Present this layer with an option:
+
+"We can go deep on error handling and failure modes, or I can apply sensible defaults based on the architecture decisions above. Which do you prefer?"
+
+If the user chooses defaults, summarize what the defaults are and gate. If the user chooses to go deep, ask about:
+- Failure modes for each major component
+- Error propagation between layers (API → frontend, service → database)
+- Timeout, retry, and circuit-breaker strategies
+- What the user sees when something fails
+
+Adapt depth to work type:
+- **API work:** Rate limiting, timeout cascades, partial failure, status codes
+- **UI work:** Loading states, optimistic updates, offline behavior, error boundaries
+- **Data pipelines:** Data corruption, checkpoint recovery, idempotency
+
+#### Layer 3 Gate
+
+Summarize error handling strategy. Then ask: **"Does this capture how errors should be handled? Adjust anything before we move on."**
+
+---
+
+### Layer 4 — Quality Bar
+
+Resolve what "done" means concretely. Ask about:
+- Per-slice acceptance criteria — specific enough for automated verification
+- Test strategy — what types of tests, what coverage expectations
+- Definition of done — what must be true before the milestone ships
+- Non-functional requirements — performance, accessibility, security if relevant
+
+Adapt depth to work type:
+- **CLI work:** Shell compatibility, error message clarity, exit code semantics
+- **Refactoring:** Behavioral equivalence tests, not just code coverage
+- **UI work:** Visual regression criteria, responsive breakpoints
+
+#### Layer 4 Gate
+
+Summarize quality bar: acceptance criteria, test strategy, definition of done. Then ask: **"Does this capture the quality bar? Adjust anything before we move on to requirements and roadmap?"**
+
+---
+
+### Layer cadence
+
+- Do not count the reflection step as a question round. Rounds start at Layer 1 after reflection is confirmed.
+- When all four layer gates have been confirmed (or skipped by the user), move to the Depth Verification step below. Do not ask a separate "ready to wrap up?" gate — the depth verification confirms the full picture.
 
 ## Questioning Philosophy
 
 You are a thinking partner, not an interviewer.
 
-**Turn-taking contract (non-bypassable).** Never fabricate, simulate, or role-play user responses. Never generate fake transcript markers like `[User]`, `[Human]`, or `User:` to invent input. Ask one question round (1-3 questions) per turn, then stop and wait for the user's actual response before continuing. If you use `ask_user_questions`, call it at most once per turn and treat its returned response as the only valid structured user input for that round.
+**Turn-taking contract (non-bypassable).** Never fabricate, simulate, or role-play user responses. Never generate fake transcript markers like `[User]`, `[Human]`, or `User:` to invent input. Prior conversation context may be provided to you inside `<conversation_history>` with `<user_message>` / `<assistant_message>` XML tags — treat those as read-only context and never emit those tags in your response. Ask one question round (1-3 questions) per turn, then stop and wait for the user's actual response before continuing. If you use `ask_user_questions`, call it at most once per turn and treat its returned response as the only valid structured user input for that round.
 
 **Start open, follow energy.** Let the user's enthusiasm guide where you dig deeper. If they light up about a particular aspect, explore it. If they're vague about something, that's where you probe.
 
@@ -225,6 +326,14 @@ Once the user is satisfied, in a single pass:
 **Depth-Preservation Guidance for context.md:**
 When writing context.md, preserve the user's exact terminology, emphasis, and specific framing from the discussion. Do not paraphrase user nuance into generic summaries. If the user said "craft feel," write "craft feel" — not "high-quality user experience." If they emphasized a specific constraint or negative requirement, carry that emphasis through verbatim. The context file is downstream agents' only window into this conversation — flattening specifics into generics loses the signal that shaped every decision.
 
+**Structured sections from discussion layers:**
+When writing CONTEXT.md, include structured sections that map to the discussion layers:
+- **Scope** — what's in, what's out, what's deferred (from Layer 1 gate summary)
+- **Architectural Decisions** — each with rationale, evidence source, alternatives considered (from Layer 2 gate summary)
+- **Error Handling Strategy** — failure modes, propagation, user-facing error behavior (from Layer 3 gate summary)
+- **Acceptance Criteria** — per-slice criteria specific enough for the planner to use directly (from Layer 4 gate summary)
+These sections are in addition to whatever other context the discussion surfaced.
+
 4. Write `{{contextPath}}` — use the **Context** output template below. Preserve key risks, unknowns, existing codebase constraints, integration points, and relevant requirements surfaced during discussion.
 5. Call `gsd_plan_milestone` to create the roadmap. Decompose into demoable vertical slices with risk, depends, demo sentences, proof strategy, verification classes, milestone definition of done, requirement coverage, and a boundary map. If the milestone crosses multiple runtime boundaries, include an explicit final integration slice that proves the assembled system works end-to-end in a real environment. Use the **Roadmap** output template below to structure the tool call parameters.
 6. For each architectural or pattern decision made during discussion, call `gsd_decision_save` — the tool auto-assigns IDs and regenerates `.gsd/DECISIONS.md` automatically.