gsd-pi 2.37.1 → 2.38.0-dev.4d4d14a

package/dist/resources/extensions/gsd/index.js

@@ -41,6 +41,7 @@ import { join } from "node:path";
 import { existsSync, readFileSync } from "node:fs";
 import { homedir } from "node:os";
 import { shortcutDesc } from "../shared/mod.js";
+const gsdHome = process.env.GSD_HOME || join(homedir(), ".gsd");
 import { Text } from "@gsd/pi-tui";
 import { pauseAutoForProviderError, classifyProviderError } from "./provider-error-pause.js";
 import { toPosixPath } from "../shared/mod.js";
@@ -52,7 +53,7 @@ import { markCmuxPromptShown, shouldPromptToEnableCmux } from "../cmux/index.js"
 // Pi core natively supports AGENTS.md (with CLAUDE.md fallback) per directory.
 function warnDeprecatedAgentInstructions() {
     const paths = [
-        join(homedir(), ".gsd", "agent-instructions.md"),
+        join(gsdHome, "agent-instructions.md"),
         join(process.cwd(), ".gsd", "agent-instructions.md"),
     ];
     for (const p of paths) {
@@ -65,6 +66,24 @@ function warnDeprecatedAgentInstructions() {
 }
 // ── Depth verification state ──────────────────────────────────────────────
 let depthVerificationDone = false;
+// ── DB lazy-open helper ───────────────────────────────────────────────────
+// In manual sessions (no auto-mode), the DB is never opened by bootstrapAutoSession.
+// This helper ensures the DB is lazily opened on first tool call that needs it.
+async function ensureDbOpen() {
+    try {
+        const db = await import("./gsd-db.js");
+        if (db.isDbAvailable())
+            return true;
+        const dbPath = join(process.cwd(), ".gsd", "gsd.db");
+        if (existsSync(dbPath)) {
+            return db.openDatabase(dbPath);
+        }
+        return false;
+    }
+    catch {
+        return false;
+    }
+}
 // ── Queue phase tracking ──────────────────────────────────────────────────
 // When true, the LLM is in a queue flow writing CONTEXT.md files.
 // The write-gate applies during queue flows just like discussion flows.
@@ -227,13 +246,8 @@ export default function (pi) {
             when_context: Type.Optional(Type.String({ description: "When/context for the decision (e.g. milestone ID)" })),
         }),
         async execute(_toolCallId, params, _signal, _onUpdate, _ctx) {
-            // Check DB availability
-            let dbAvailable = false;
-            try {
-                const db = await import("./gsd-db.js");
-                dbAvailable = db.isDbAvailable();
-            }
-            catch { /* dynamic import failed */ }
+            // Ensure DB is open (lazy-open on first tool call in manual sessions)
+            const dbAvailable = await ensureDbOpen();
             if (!dbAvailable) {
                 return {
                     content: [{ type: "text", text: "Error: GSD database is not available. Cannot save decision." }],
@@ -289,12 +303,7 @@ export default function (pi) {
             supporting_slices: Type.Optional(Type.String({ description: "Supporting slices" })),
         }),
         async execute(_toolCallId, params, _signal, _onUpdate, _ctx) {
-            let dbAvailable = false;
-            try {
-                const db = await import("./gsd-db.js");
-                dbAvailable = db.isDbAvailable();
-            }
-            catch { /* dynamic import failed */ }
+            const dbAvailable = await ensureDbOpen();
             if (!dbAvailable) {
                 return {
                     content: [{ type: "text", text: "Error: GSD database is not available. Cannot update requirement." }],
@@ -364,12 +373,7 @@ export default function (pi) {
             content: Type.String({ description: "The full markdown content of the artifact" }),
         }),
         async execute(_toolCallId, params, _signal, _onUpdate, _ctx) {
-            let dbAvailable = false;
-            try {
-                const db = await import("./gsd-db.js");
-                dbAvailable = db.isDbAvailable();
-            }
-            catch { /* dynamic import failed */ }
+            const dbAvailable = await ensureDbOpen();
             if (!dbAvailable) {
                 return {
                     content: [{ type: "text", text: "Error: GSD database is not available. Cannot save artifact." }],

package/dist/resources/extensions/gsd/migrate/parsers.js

@@ -2,7 +2,7 @@
 // Pure functions that take file content (string) and return typed data.
 // Zero Pi dependencies — uses only exported helpers from files.ts.
 import { splitFrontmatter, parseFrontmatterMap, extractBoldField } from '../files.js';
-import { normalizeStringArray } from '../../shared/mod.js';
+import { normalizeStringArray } from '../../shared/format-utils.js';
 // Re-export PlanningProjectMeta — not in types.ts yet, use string for project field
 // Actually PlanningProjectMeta isn't in types.ts — project is stored as string | null.
 // We'll keep parseOldProject returning a simple shape.

package/dist/resources/extensions/gsd/observability-validator.js

@@ -209,6 +209,30 @@ export function validateTaskPlanContent(file, content) {
             }
         }
     }
+    // Rule: Inputs and Expected Output should contain backtick-wrapped file paths
+    const inputsSection = getSection(content, "Inputs", 2);
+    const outputSection = getSection(content, "Expected Output", 2);
+    const backtickPathPattern = /`[^`]*[./][^`]*`/;
+    if (outputSection === null || !backtickPathPattern.test(outputSection)) {
+        issues.push({
+            severity: "warning",
+            scope: "task-plan",
+            file,
+            ruleId: "missing_output_file_paths",
+            message: "Task plan `## Expected Output` is missing or has no backtick-wrapped file paths.",
+            suggestion: "List concrete output file paths in backticks (e.g. `src/types.ts`). These are machine-parsed to derive task dependencies.",
+        });
+    }
+    if (inputsSection !== null && inputsSection.trim().length > 0 && !backtickPathPattern.test(inputsSection)) {
+        issues.push({
+            severity: "info",
+            scope: "task-plan",
+            file,
+            ruleId: "missing_input_file_paths",
+            message: "Task plan `## Inputs` has content but no backtick-wrapped file paths.",
+            suggestion: "List input file paths in backticks (e.g. `src/config.json`). These are machine-parsed to derive task dependencies.",
+        });
+    }
     // ── Observability rules (gated by runtime relevance) ──
     const relevant = textSuggestsObservabilityRelevant(content);
     if (!relevant)

package/dist/resources/extensions/gsd/package.json

@@ -5,7 +5,7 @@
   "type": "module",
   "pi": {
     "extensions": [
-      "./index.ts"
+      "./index.js"
     ]
   }
 }

package/dist/resources/extensions/gsd/preferences-models.js

@@ -260,18 +260,6 @@ export function resolveInlineLevel() {
         case "quality": return "full";
     }
 }
-/**
- * Resolve the compression strategy from the active token profile.
- * budget/balanced -> "compress", quality -> "truncate".
- * Explicit preference always wins.
- */
-export function resolveCompressionStrategy() {
-    const prefs = loadEffectiveGSDPreferences();
-    if (prefs?.preferences.compression_strategy)
-        return prefs.preferences.compression_strategy;
-    const profile = resolveEffectiveProfile();
-    return profile === "quality" ? "truncate" : "compress";
-}
 /**
  * Resolve the context selection mode from the active token profile.
  * budget -> "smart", balanced/quality -> "full".

package/dist/resources/extensions/gsd/preferences-types.js

@@ -62,14 +62,15 @@ export const KNOWN_PREFERENCE_KEYS = new Set([
     "verification_auto_fix",
     "verification_max_retries",
     "search_provider",
-    "compression_strategy",
     "context_selection",
     "widget_mode",
+    "reactive_execution",
+    "github",
 ]);
 /** Canonical list of all dispatch unit types. */
 export const KNOWN_UNIT_TYPES = [
     "research-milestone", "plan-milestone", "research-slice", "plan-slice",
-    "execute-task", "complete-slice", "replan-slice", "reassess-roadmap",
+    "execute-task", "reactive-execute", "complete-slice", "replan-slice", "reassess-roadmap",
     "run-uat", "complete-milestone",
 ];
 export const SKILL_ACTIONS = new Set(["use", "prefer", "avoid"]);

package/dist/resources/extensions/gsd/preferences-validation.js

@@ -6,7 +6,7 @@
  * together with any errors and warnings.
  */
 import { VALID_BRANCH_NAME } from "./git-service.js";
-import { normalizeStringArray } from "../shared/mod.js";
+import { normalizeStringArray } from "../shared/format-utils.js";
 import { KNOWN_PREFERENCE_KEYS, KNOWN_UNIT_TYPES, SKILL_ACTIONS, } from "./preferences-types.js";
 const VALID_TOKEN_PROFILES = new Set(["budget", "balanced", "quality"]);
 export function validatePreferences(preferences) {
@@ -500,6 +500,48 @@ export function validatePreferences(preferences) {
             validated.parallel = parallel;
         }
     }
+    // ─── Reactive Execution ─────────────────────────────────────────────────
+    if (preferences.reactive_execution !== undefined) {
+        if (typeof preferences.reactive_execution === "object" && preferences.reactive_execution !== null) {
+            const re = preferences.reactive_execution;
+            const validRe = {};
+            if (re.enabled !== undefined) {
+                if (typeof re.enabled === "boolean")
+                    validRe.enabled = re.enabled;
+                else
+                    errors.push("reactive_execution.enabled must be a boolean");
+            }
+            if (re.max_parallel !== undefined) {
+                const mp = typeof re.max_parallel === "number" ? re.max_parallel : Number(re.max_parallel);
+                if (Number.isFinite(mp) && mp >= 1 && mp <= 8) {
+                    validRe.max_parallel = Math.floor(mp);
+                }
+                else {
+                    errors.push("reactive_execution.max_parallel must be a number between 1 and 8");
+                }
+            }
+            if (re.isolation_mode !== undefined) {
+                if (re.isolation_mode === "same-tree") {
+                    validRe.isolation_mode = "same-tree";
+                }
+                else {
+                    errors.push('reactive_execution.isolation_mode must be "same-tree"');
+                }
+            }
+            const knownReKeys = new Set(["enabled", "max_parallel", "isolation_mode"]);
+            for (const key of Object.keys(re)) {
+                if (!knownReKeys.has(key)) {
+                    warnings.push(`unknown reactive_execution key "${key}" — ignored`);
+                }
+            }
+            if (Object.keys(validRe).length > 0) {
+                validated.reactive_execution = validRe;
+            }
+        }
+        else {
+            errors.push("reactive_execution must be an object");
+        }
+    }
     // ─── Verification Preferences ───────────────────────────────────────────
     if (preferences.verification_commands !== undefined) {
         if (Array.isArray(preferences.verification_commands)) {
@@ -665,16 +707,6 @@ export function validatePreferences(preferences) {
             errors.push("auto_report must be a boolean");
         }
     }
-    // ─── Compression Strategy ───────────────────────────────────────────
-    if (preferences.compression_strategy !== undefined) {
-        const validStrategies = new Set(["truncate", "compress"]);
-        if (typeof preferences.compression_strategy === "string" && validStrategies.has(preferences.compression_strategy)) {
-            validated.compression_strategy = preferences.compression_strategy;
-        }
-        else {
-            errors.push(`compression_strategy must be one of: truncate, compress`);
-        }
-    }
     // ─── Context Selection ──────────────────────────────────────────────
     if (preferences.context_selection !== undefined) {
         const validModes = new Set(["full", "smart"]);
@@ -685,5 +717,63 @@ export function validatePreferences(preferences) {
             errors.push(`context_selection must be one of: full, smart`);
         }
     }
+    // ─── GitHub Sync ────────────────────────────────────────────────────────
+    if (preferences.github !== undefined) {
+        if (typeof preferences.github === "object" && preferences.github !== null) {
+            const gh = preferences.github;
+            const validGh = {};
+            if (gh.enabled !== undefined) {
+                if (typeof gh.enabled === "boolean")
+                    validGh.enabled = gh.enabled;
+                else
+                    errors.push("github.enabled must be a boolean");
+            }
+            if (gh.repo !== undefined) {
+                if (typeof gh.repo === "string" && gh.repo.includes("/"))
+                    validGh.repo = gh.repo;
+                else
+                    errors.push('github.repo must be a string in "owner/repo" format');
+            }
+            if (gh.project !== undefined) {
+                const p = typeof gh.project === "number" ? gh.project : Number(gh.project);
+                if (Number.isFinite(p) && p > 0)
+                    validGh.project = Math.floor(p);
+                else
+                    errors.push("github.project must be a positive number");
+            }
+            if (gh.labels !== undefined) {
+                if (Array.isArray(gh.labels) && gh.labels.every((l) => typeof l === "string")) {
+                    validGh.labels = gh.labels;
+                }
+                else {
+                    errors.push("github.labels must be an array of strings");
+                }
+            }
+            if (gh.auto_link_commits !== undefined) {
+                if (typeof gh.auto_link_commits === "boolean")
+                    validGh.auto_link_commits = gh.auto_link_commits;
+                else
+                    errors.push("github.auto_link_commits must be a boolean");
+            }
+            if (gh.slice_prs !== undefined) {
+                if (typeof gh.slice_prs === "boolean")
+                    validGh.slice_prs = gh.slice_prs;
+                else
+                    errors.push("github.slice_prs must be a boolean");
+            }
+            const knownGhKeys = new Set(["enabled", "repo", "project", "labels", "auto_link_commits", "slice_prs"]);
+            for (const key of Object.keys(gh)) {
+                if (!knownGhKeys.has(key)) {
+                    warnings.push(`unknown github key "${key}" — ignored`);
+                }
+            }
+            if (Object.keys(validGh).length > 0) {
+                validated.github = validGh;
+            }
+        }
+        else {
+            errors.push("github must be an object");
+        }
+    }
     return { preferences: validated, errors, warnings };
 }

package/dist/resources/extensions/gsd/preferences.js

@@ -12,9 +12,10 @@
 import { existsSync, readFileSync } from "node:fs";
 import { homedir } from "node:os";
 import { join } from "node:path";
+const gsdHome = process.env.GSD_HOME || join(homedir(), ".gsd");
 import { gsdRoot } from "./paths.js";
 import { parse as parseYaml } from "yaml";
-import { normalizeStringArray } from "../shared/mod.js";
+import { normalizeStringArray } from "../shared/format-utils.js";
 import { resolveProfileDefaults as _resolveProfileDefaults } from "./preferences-models.js";
 import { MODE_DEFAULTS, } from "./preferences-types.js";
 import { validatePreferences } from "./preferences-validation.js";
@@ -24,16 +25,16 @@ export { validatePreferences } from "./preferences-validation.js";
 // ─── Re-exports: skills ─────────────────────────────────────────────────────
 export { resolveAllSkillReferences, resolveSkillDiscoveryMode, resolveSkillStalenessDays, } from "./preferences-skills.js";
 // ─── Re-exports: models ─────────────────────────────────────────────────────
-export { resolveModelForUnit, resolveModelWithFallbacksForUnit, getNextFallbackModel, isTransientNetworkError, validateModelId, updatePreferencesModels, resolveDynamicRoutingConfig, resolveAutoSupervisorConfig, resolveProfileDefaults, resolveEffectiveProfile, resolveInlineLevel, resolveCompressionStrategy, resolveContextSelection, resolveSearchProviderFromPreferences, } from "./preferences-models.js";
+export { resolveModelForUnit, resolveModelWithFallbacksForUnit, getNextFallbackModel, isTransientNetworkError, validateModelId, updatePreferencesModels, resolveDynamicRoutingConfig, resolveAutoSupervisorConfig, resolveProfileDefaults, resolveEffectiveProfile, resolveInlineLevel, resolveContextSelection, resolveSearchProviderFromPreferences, } from "./preferences-models.js";
 // ─── Path Constants & Getters ───────────────────────────────────────────────
-const GLOBAL_PREFERENCES_PATH = join(homedir(), ".gsd", "preferences.md");
+const GLOBAL_PREFERENCES_PATH = join(gsdHome, "preferences.md");
 const LEGACY_GLOBAL_PREFERENCES_PATH = join(homedir(), ".pi", "agent", "gsd-preferences.md");
 function projectPreferencesPath() {
     return join(gsdRoot(process.cwd()), "preferences.md");
 }
 // Bootstrap in gitignore.ts historically created PREFERENCES.md (uppercase) by mistake.
 // Check uppercase as a fallback so those files aren't silently ignored.
-const GLOBAL_PREFERENCES_PATH_UPPERCASE = join(homedir(), ".gsd", "PREFERENCES.md");
+const GLOBAL_PREFERENCES_PATH_UPPERCASE = join(gsdHome, "PREFERENCES.md");
 function projectPreferencesPathUppercase() {
     return join(gsdRoot(process.cwd()), "PREFERENCES.md");
 }
@@ -199,10 +200,12 @@ function mergePreferences(base, override) {
         verification_auto_fix: override.verification_auto_fix ?? base.verification_auto_fix,
         verification_max_retries: override.verification_max_retries ?? base.verification_max_retries,
         search_provider: override.search_provider ?? base.search_provider,
-        compression_strategy: override.compression_strategy ?? base.compression_strategy,
         context_selection: override.context_selection ?? base.context_selection,
         auto_visualize: override.auto_visualize ?? base.auto_visualize,
         auto_report: override.auto_report ?? base.auto_report,
+        github: (base.github || override.github)
+            ? { ...(base.github ?? {}), ...(override.github ?? {}) }
+            : undefined,
     };
 }
 function mergeStringLists(base, override) {

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

@@ -11,7 +11,7 @@ After the user describes their idea, **do not ask questions yet**. First, prove
 1. Summarize what you understood in your own words — concretely, not abstractly.
 2. Give an honest size read: roughly how many milestones, roughly how many slices in the first one. Base this on the actual work involved, not a classification label. A config change might be 1 milestone with 1 slice. A social network might be 5 milestones with 8+ slices each. Use your judgment.
 3. Include scope honesty — a bullet list of the major capabilities you're hearing: "Here's what I'm hearing: [bullet list of major capabilities]."
-4. Ask: "Does that capture it? If not, tell me what I missed." — plain text, not `ask_user_questions`. Let them correct freely.
+4. Invite correction in one plain sentence: "Here's my read. Correct anything important I missed." — plain text, not `ask_user_questions`.
 
 This prevents runaway questioning by forcing comprehension proof before anything else. Do not skip this step. Do not combine it with the first question round.
 
@@ -21,7 +21,7 @@ After reflection is confirmed, decide the approach based on the actual scope —
 
 **If the work spans multiple milestones:** Before drilling into details, map the full landscape:
 1. Propose a milestone sequence — names, one-line intents, rough dependencies
-2. Present this to the user for confirmation or adjustment
+2. Present this as the working milestone sequence. Adjust it if the user objects, sharpens it, or adds constraints; otherwise keep moving.
 3. Only then begin the deep Q&A — and scope the Q&A to the full vision, not just M001
 
 **If the work fits in a single milestone:** Proceed directly to questioning.
@@ -48,7 +48,7 @@ You are a thinking partner, not an interviewer.
 
 **Challenge vagueness, make abstract concrete.** When the user says something abstract ("it should be smart" / "it needs to handle edge cases" / "good UX"), push for specifics. What does "smart" mean in practice? Which edge cases? What does good UX look like for this specific interaction?
 
-**Questions must be about the experience, not the implementation.** Never ask "what auth provider?" — ask "when someone logs in, what should that feel like?" Never ask "what database?" — ask "when they come back tomorrow, what should they see?" Implementation is your job. Understanding what they want to experience is the discussion's job.
+**Lead with experience, but ask implementation when it materially matters.** Default questions should target the experience and outcome. But when implementation choices materially change scope, proof, compliance, integration, deployment, or irreversible architecture, ask them directly instead of forcing a fake UX phrasing.
 
 **Freeform rule:** When the user selects "Other" or clearly wants to explain something freely, stop using `ask_user_questions` and switch to plain text follow-ups. Let them talk. Resume structured questions when appropriate.
 
@@ -105,16 +105,13 @@ Example flow:
 
 If they clarify, absorb the correction and re-verify.
 
-## Wrap-up Gate
-
-Only after the depth checklist is fully satisfied and you genuinely understand the work, offer to proceed.
+The depth verification is the required write-gate. Do **not** add another meta "ready to proceed?" checkpoint immediately after it unless there is still material ambiguity.
 
-The wrap-up gate must include a scope reflection:
-"Here's what I'm planning to build: [list of capabilities with rough complexity]. Does this match your vision, or did I miss something?"
+## Wrap-up Gate
 
-Then offer options: "Ready to confirm requirements and milestone plan (Recommended)", "I have more to discuss"
+Once the depth checklist is fully satisfied, move directly into requirements and roadmap preview. Do not insert a separate "are you ready to continue?" gate unless the user explicitly wants to keep brainstorming or you still see material ambiguity.
 
-If the user wants to keep going, keep asking. If they're ready, proceed.
+If you need a final scope reflection, fold it into the depth summary or roadmap preview rather than asking for permission twice.
 
 ## Focused Research
 
@@ -165,9 +162,9 @@ Rules:
 
 For multi-milestone projects, requirements should span the full vision. Requirements owned by later milestones get provisional ownership. The full requirement set captures the user's complete vision — milestones are the sequencing strategy, not the scope boundary.
 
-If the project is new or has no `REQUIREMENTS.md`, confirm candidate requirements with the user before writing the roadmap.
+If the project is new or has no `REQUIREMENTS.md`, surface candidate requirements in chat before writing the roadmap. Ask for correction only on material omissions, wrong ownership, or wrong scope. If the user has already been specific and raises no substantive objection, treat the requirement set as confirmed and continue.
 
-**Print the requirements in chat before asking for confirmation.** Do not say "here are the requirements" and then only write them to a file. The user must see them in the terminal. Print a markdown table with columns: ID, Title, Status, Owner, Source. Group by status (Active, Deferred, Out of Scope). After the table, ask: "Confirm, adjust, or add?"
+**Print the requirements in chat before writing the roadmap.** Do not say "here are the requirements" and then only write them to a file. The user must see them in the terminal. Print a markdown table with columns: ID, Title, Status, Owner, Source. Group by status (Active, Deferred, Out of Scope). After the table, ask: "Confirm, adjust, or add?"
 
 ## Scope Assessment
 
@@ -179,7 +176,7 @@ Before moving to output, confirm the size estimate from your reflection still ho
 
 Before writing any files, **print the planned roadmap in chat** so the user can see and approve it. Print a markdown table with columns: Slice, Title, Risk, Depends, Demo. One row per slice. Below the table, print the milestone definition of done as a bullet list.
 
-Ask: "Ready to write the plan, or want to adjust?" Only proceed to writing files after the user confirms.
+If the user raises a substantive objection, adjust the roadmap. Otherwise, present the roadmap and ask: "Ready to write, or want to adjust?" — one gate, not two.
 
 ### Naming Convention
 
@@ -236,7 +233,7 @@ If a milestone has no dependencies, omit the frontmatter. The dependency chain f
 
 #### Phase 3: Sequential readiness gate for remaining milestones
 
-For each remaining milestone **one at a time, in sequence**, use `ask_user_questions` to assess readiness. Present three options:
+For each remaining milestone **one at a time, in sequence**, decide the most likely readiness mode from the evidence you already have, then use `ask_user_questions` to let the user correct that recommendation. Present three options:
 
 - **"Discuss now"** — The user wants to conduct a focused discussion for this milestone in the current session, while the context from the broader discussion is still fresh. Proceed with a focused discussion for this milestone (reflection → investigation → questioning → depth verification). When the discussion concludes, write a full `CONTEXT.md`. Then move to the gate for the next milestone.
 - **"Write draft for later"** — This milestone has seed material from the current conversation but needs its own dedicated discussion in a future session. Write a `CONTEXT-DRAFT.md` capturing the seed material (what was discussed, key ideas, provisional scope, open questions). Mark it clearly as a draft, not a finalized context. **What happens downstream:** When auto-mode reaches this milestone, it pauses and notifies the user: "M00x has draft context — needs discussion. Run /gsd." The `/gsd` wizard shows a "Discuss from draft" option that seeds the new discussion with this draft, so nothing from the current conversation is lost. After the dedicated discussion produces a full CONTEXT.md, the draft file is automatically deleted.

package/dist/resources/extensions/gsd/prompts/execute-task.md

@@ -6,7 +6,7 @@ You are executing GSD auto-mode.
 
 Your working directory is `{{workingDirectory}}`. All file reads, writes, and shell commands MUST operate relative to this directory. Do NOT `cd` to any other directory.
 
-A researcher explored the codebase and a planner decomposed the work — you are the executor. The task plan below is your authoritative contract. It contains the specific files, steps, and verification you need. Don't re-research or re-plan — build what the plan says, verify it works, and document what happened.
+A researcher explored the codebase and a planner decomposed the work — you are the executor. The task plan below is your authoritative contract for the slice goal and verification bar, but it is not a substitute for local reality. Verify the referenced files and surrounding code before changing them. Do not do broad re-research or spontaneous re-planning. Small factual corrections, file-path fixes, and local implementation adaptations are part of execution. Escalate to `blocker_discovered: true` only when the slice contract or downstream task graph no longer holds.
 
 {{overridesSection}}
 
@@ -27,7 +27,7 @@ A researcher explored the codebase and a planner decomposed the work — you are
 Then:
 0. Narrate step transitions, key implementation decisions, and verification outcomes as you work. Keep it terse — one line between tool-call clusters, not between every call — but write complete sentences in user-facing prose, not shorthand notes or scratchpad fragments.
 1. **Load relevant skills before writing code.** Check the `GSD Skill Preferences` block in system context and the `<available_skills>` catalog in your system prompt. For each skill that matches this task's technology stack (e.g., React, Next.js, accessibility, component design), `read` its SKILL.md file now. Skills contain implementation rules and patterns that should guide your code. If no skills match this task, skip this step.
-2. Execute the steps in the inlined task plan
+2. Execute the steps in the inlined task plan, adapting minor local mismatches when the surrounding code differs from the planner's snapshot
 3. Build the real thing. If the task plan says "create login endpoint", build an endpoint that actually authenticates against a real store, not one that returns a hardcoded success response. If the task plan says "create dashboard page", build a page that renders real data from the API, not a component with hardcoded props. Stubs and mocks are for tests, not for the shipped feature.
 4. Write or update tests as part of execution — tests are verification, not an afterthought. If the slice plan defines test files in its Verification section and this is the first task, create them (they should initially fail).
 5. When implementing non-trivial runtime behavior (async flows, API boundaries, background processes, error paths), add or preserve agent-usable observability. Skip this for simple changes where it doesn't apply.

package/dist/resources/extensions/gsd/prompts/guided-discuss-milestone.md

@@ -33,19 +33,16 @@ Ask **1–3 questions per round**. Keep each question focused on one of:
 
 After the user answers, investigate further if any answer opens a new unknown, then ask the next round.
 
-### Check-in after each round
+### Round cadence
 
-After each round of answers, ask:
+After each round of answers, decide whether you already have enough depth to write a strong context file.
 
-> "I think I have a solid picture of this milestone. Ready to wrap up and write the context file, or is there more to cover?"
-
-**If `{{structuredQuestionsAvailable}}` is `true`:** use `ask_user_questions` with options:
-- "Wrap up — write the context file" *(recommended after ~2–3 rounds)*
-- "Keep going — more to discuss"
-
-**If `{{structuredQuestionsAvailable}}` is `false`:** ask in plain text.
-
-If the user wants to keep going, keep asking. Stop when they say wrap up.
+- If not, investigate any newly-opened unknowns and continue to the next round immediately. Do **not** ask a meta "ready to wrap up?" question after every round.
+- Use a single wrap-up prompt only when you genuinely believe the depth checklist is satisfied or the user signals they want to stop.
+- **If `{{structuredQuestionsAvailable}}` is `true` and you need that wrap-up prompt:** use `ask_user_questions` with options:
+  - "Write the context file" *(recommended when depth is satisfied)*
+  - "One more pass"
+- **If `{{structuredQuestionsAvailable}}` is `false`:** ask in plain text only once you believe you are ready to write.
 
 ---
 
@@ -55,7 +52,7 @@ If the user wants to keep going, keep asking. Stop when they say wrap up.
 
 **Challenge vagueness, make abstract concrete.** When the user says something abstract ("it should be smart" / "good UX"), push for specifics.
 
-**Questions must be about the experience, not the implementation.** Never ask "what auth provider?" — ask "when someone logs in, what should that feel like?" Implementation is your job. Understanding what they want to experience is the discussion's job.
+**Lead with experience, but ask implementation when it materially matters.** Default questions should target the experience and outcome. But when implementation choices materially change scope, proof, compliance, integration, deployment, or irreversible architecture, ask them directly instead of forcing a fake UX phrasing.
 
 **Position-first framing.** Have opinions. "I'd lean toward X because Y — does that match your thinking?" is better than "what do you think about X vs Y?"
 
@@ -95,6 +92,8 @@ Before moving to the wrap-up gate, verify you have covered:
 
 If they clarify, absorb the correction and re-verify.
 
+The depth verification is the only required confirmation gate. Do not add a second "ready to proceed?" gate after it.
+
 ---
 
 ## Output

package/dist/resources/extensions/gsd/prompts/guided-discuss-slice.md

@@ -1,6 +1,6 @@
 You are interviewing the user to surface behavioural, UX, and usage grey areas for slice **{{sliceId}}: {{sliceTitle}}** of milestone **{{milestoneId}}**.
 
-Your goal is **not** to settle tech stack, naming conventions, or architecture — that happens during research and planning. Your goal is to produce a context file that captures the human decisions: what this slice should feel like, how it should behave, what edge cases matter, where scope begins and ends, and what the user cares about that won't be obvious from the roadmap entry alone.
+Your goal is **not** to center the discussion on tech stack trivia, naming conventions, or speculative architecture. Your goal is to produce a context file that captures the human decisions: what this slice should feel like, how it should behave, what edge cases matter, where scope begins and ends, and what the user cares about that won't be obvious from the roadmap entry alone. If a technical choice materially changes scope, proof, or integration behavior, ask it directly and capture it.
 
 {{inlinedContext}}
 
@@ -27,17 +27,15 @@ Ask **1–3 questions per round** using `ask_user_questions`. Keep each question
 
 After the user answers, investigate further if any answer opens a new unknown, then ask the next round.
 
-### Check-in after each round
+### Round cadence
 
-After each round of answers, use `ask_user_questions` to ask:
+After each round of answers, decide whether you already have enough signal to write the slice context cleanly.
 
-> "I think I have a solid picture of this slice. Ready to wrap up and write the context file, or is there more to cover?"
-
-Options:
-- "Wrap up — write the context file" *(recommended after ~2–3 rounds)*
-- "Keep going — more to discuss"
-
-If the user wants to keep going, keep asking. Stop when they say wrap up.
+- If not, investigate any new unknowns and continue to the next round immediately. Do **not** ask a meta "ready to wrap up?" question after every round.
+- Ask a single wrap-up question only when you genuinely believe the slice is well understood or the user signals they want to stop.
+- When you do ask it, use `ask_user_questions` with:
+  - "Write the context file" *(recommended when the slice is well understood)*
+  - "One more pass"
 
 ---
 

package/dist/resources/extensions/gsd/prompts/guided-resume-task.md

@@ -1 +1 @@
-Resume interrupted work. Find the continue file (`{{sliceId}}-CONTINUE.md` or `continue.md`) in slice {{sliceId}} of milestone {{milestoneId}}, then pick up from where you left off. Delete the continue file after reading it. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during execution, without relaxing required verification or artifact rules.
+Resume interrupted work. Find the continue file (`{{sliceId}}-CONTINUE.md` or `continue.md`) in slice {{sliceId}} of milestone {{milestoneId}}, read it, and use it as the recovery contract for where to pick up. Do **not** delete the continue file immediately. Keep it until the task is successfully completed or you have written a newer summary/continue artifact that clearly supersedes it. If the resumed attempt fails again, update or replace the continue file so no recovery context is lost. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during execution, without relaxing required verification or artifact rules.

package/dist/resources/extensions/gsd/prompts/plan-slice.md

@@ -61,13 +61,14 @@ Then:
    - a concrete, action-oriented title
    - the inline task entry fields defined in the plan.md template (Why / Files / Do / Verify / Done when)
    - a matching task plan file with description, steps, must-haves, verification, inputs, and expected output
+   - **Inputs and Expected Output must list concrete backtick-wrapped file paths** (e.g. `` `src/types.ts` ``). These are machine-parsed to derive task dependencies — vague prose without paths breaks parallel execution. Every task must have at least one output file path.
    - Observability Impact section **only if the task touches runtime boundaries, async flows, or error paths** — omit it otherwise
 6. Write `{{outputPath}}`
 7. Write individual task plans in `{{slicePath}}/tasks/`: `T01-PLAN.md`, `T02-PLAN.md`, etc.
 8. **Self-audit the plan.** Walk through each check — if any fail, fix the plan files before moving on:
     - **Completion semantics:** If every task were completed exactly as written, the slice goal/demo should actually be true.
     - **Requirement coverage:** Every must-have in the slice maps to at least one task. No must-have is orphaned. If `REQUIREMENTS.md` exists, every Active requirement this slice owns maps to at least one task.
-    - **Task completeness:** Every task has steps, must-haves, verification, inputs, and expected output — none are blank or vague.
+    - **Task completeness:** Every task has steps, must-haves, verification, inputs, and expected output — none are blank or vague. Inputs and Expected Output list backtick-wrapped file paths, not prose descriptions.
     - **Dependency correctness:** Task ordering is consistent. No task references work from a later task.
     - **Key links planned:** For every pair of artifacts that must connect, there is an explicit step that wires them.
     - **Scope sanity:** Target 2–5 steps and 3–8 files per task. 10+ steps or 12+ files — must split. Each task must be completable in a single fresh context window.

package/dist/resources/extensions/gsd/prompts/queue.md

@@ -36,15 +36,11 @@ Don't go deep — just enough that your next question reflects what's actually t
 - How the new work relates to existing milestones — overlap, dependencies, prerequisites
 - If `.gsd/REQUIREMENTS.md` exists: which unmet Active or Deferred requirements this queued work advances
 
-**Then use ask_user_questions** to dig into gray areas — architecture choices, scope boundaries, tech preferences, what's in vs out. 1-3 questions per round.
+**Then use ask_user_questions** to dig into gray areas — scope boundaries, proof expectations, integration choices, tech preferences when they materially matter, and what's in vs out. 1-3 questions per round.
 
 If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during discuss/planning work, but do not let it override the required discuss flow or artifact requirements.
 
-**Self-regulate:** After about 10-15 questions total (3-5 rounds), or when you feel you have a solid understanding, include a question like:
-"I think I have a good picture. Ready to queue this, or are there more things to discuss?"
-with options: "Ready to queue (Recommended)", "I have more to discuss"
-
-If the user wants to keep going, keep asking. If they're ready, proceed.
+**Self-regulate:** Do **not** ask a meta "ready to queue?" question after every round. Keep going until you have enough depth to write the context well, then use a single wrap-up prompt if needed. If the user clearly keeps adding detail instead of objecting, treat that as permission to continue.
 
 ## Existing Milestone Awareness
 
@@ -88,7 +84,7 @@ For EACH milestone you are about to write context for, investigate the codebase
 1. **Read the actual code** — for every file or module you reference in "Existing Codebase / Prior Art", read enough to confirm your assumptions about what exists, what it does, and what it doesn't do. Do not guess from memory or training data.
 2. **Check for stale assumptions** — the codebase may have changed since the user's spec was written. Verify: do the APIs you reference still exist? Have modules been refactored? Has upstream merged features that change the landscape?
 3. **Identify phantom capabilities** — for every capability you list as "existing," confirm it actually works as described. Look for: functions that exist but are never called, fields that are set but never read, features that are piped but never connected.
-4. **Note what you found** — include verified findings in the context file's "Existing Codebase / Prior Art" section with "verified against v{version}" annotations.
+4. **Note what you found** — include verified findings in the context file's "Existing Codebase / Prior Art" section with annotations like "verified against current codebase state" or an actual concrete version/commit only if you truly have one.
 
 ### Step 2: Per-Milestone Depth Verification
 
@@ -103,7 +99,7 @@ This triggers the per-milestone write-gate. The question should present:
 - Key technical assumptions you verified (or couldn't verify)
 - Any risks or unknowns the investigation surfaced
 
-The user confirms or corrects before you write. One depth verification per milestone — not one for all milestones combined.
+The user confirms or corrects before you write. One depth verification per milestone — not one for all milestones combined. This is the required write-gate; do not add extra "ready to proceed?" prompts around it once you have enough signal.
 
 **If you skip this step, the system will block the CONTEXT.md write and return an error telling you to complete verification first.**