gsd-pi 0.3.0 → 0.3.3

package/src/resources/extensions/gsd/guided-flow.ts

@@ -31,13 +31,14 @@ let pendingAutoStart: {
   pi: ExtensionAPI;
   basePath: string;
   milestoneId: string; // the milestone being discussed
+  step?: boolean; // preserve step mode through discuss → auto transition
 } | null = null;
 
 /** Called from agent_end to check if auto-mode should start after discuss */
 export function checkAutoStartAfterDiscuss(): boolean {
   if (!pendingAutoStart) return false;
 
-  const { ctx, pi, basePath, milestoneId } = pendingAutoStart;
+  const { ctx, pi, basePath, milestoneId, step } = pendingAutoStart;
 
   // Don't fire until the discuss phase has actually produced a context file
   // for the milestone being discussed. agent_end fires after every LLM turn,
@@ -47,7 +48,7 @@ export function checkAutoStartAfterDiscuss(): boolean {
   if (!contextFile) return false; // no context yet — keep waiting
 
   pendingAutoStart = null;
-  startAuto(ctx, pi, basePath, false).catch(() => {});
+  startAuto(ctx, pi, basePath, false, { step }).catch(() => {});
   return true;
 }
 
@@ -435,7 +436,9 @@ export async function showSmartEntry(
   ctx: ExtensionCommandContext,
   pi: ExtensionAPI,
   basePath: string,
+  options?: { step?: boolean },
 ): Promise<void> {
+  const stepMode = options?.step;
 
   // ── Ensure git repo exists — GSD needs it for branch-per-slice ──────
   try {
@@ -501,14 +504,14 @@ export async function showSmartEntry(
 
     if (isFirst) {
       // First ever — skip wizard, just ask directly
-      pendingAutoStart = { ctx, pi, basePath, milestoneId: nextId };
+      pendingAutoStart = { ctx, pi, basePath, milestoneId: nextId, step: stepMode };
       dispatchWorkflow(pi, buildDiscussPrompt(nextId,
         `New project, milestone ${nextId}. Do NOT read or explore .gsd/ — it's empty scaffolding.`,
         basePath
       ));
     } else {
       const choice = await showNextAction(ctx as any, {
-        title: "GSD — Get Stuff Done",
+        title: "GSD — Get Shit Done",
         summary: ["No active milestone."],
         actions: [
           {
@@ -522,7 +525,7 @@ export async function showSmartEntry(
       });
 
       if (choice === "new_milestone") {
-        pendingAutoStart = { ctx, pi, basePath, milestoneId: nextId };
+        pendingAutoStart = { ctx, pi, basePath, milestoneId: nextId, step: stepMode };
         dispatchWorkflow(pi, buildDiscussPrompt(nextId,
           `New milestone ${nextId}.`,
           basePath
@@ -560,7 +563,7 @@ export async function showSmartEntry(
       const milestoneIds = findMilestoneIds(basePath);
       const nextId = `M${String(milestoneIds.length + 1).padStart(3, "0")}`;
 
-      pendingAutoStart = { ctx, pi, basePath, milestoneId: nextId };
+      pendingAutoStart = { ctx, pi, basePath, milestoneId: nextId, step: stepMode };
       dispatchWorkflow(pi, buildDiscussPrompt(nextId,
         `New milestone ${nextId}.`,
         basePath

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

@@ -63,13 +63,43 @@ export default function (pi: ExtensionAPI) {
   registerGSDCommand(pi);
   registerWorktreeCommand(pi);
 
-  // ── Dynamic-cwd bash tool ──────────────────────────────────────────────
+  // ── /exit — kill the process immediately ──────────────────────────────
+  pi.registerCommand("exit", {
+    description: "Exit GSD immediately",
+    handler: async (_ctx) => {
+      process.exit(0);
+    },
+  });
+
+  // ── Dynamic-cwd bash tool with default timeout ────────────────────────
   // The built-in bash tool captures cwd at startup. This replacement uses
   // a spawnHook to read process.cwd() dynamically so that process.chdir()
   // (used by /worktree switch) propagates to shell commands.
-  const dynamicBash = createBashTool(process.cwd(), {
+  //
+  // The upstream SDK's bash tool has no default timeout — if the LLM omits
+  // the timeout parameter, commands run indefinitely, causing hangs on
+  // Windows where process killing is unreliable (see #40). We wrap execute
+  // to inject a 120-second default when no timeout is provided.
+  const DEFAULT_BASH_TIMEOUT_SECS = 120;
+  const baseBash = createBashTool(process.cwd(), {
     spawnHook: (ctx) => ({ ...ctx, cwd: process.cwd() }),
   });
+  const dynamicBash = {
+    ...baseBash,
+    execute: async (
+      toolCallId: string,
+      params: { command: string; timeout?: number },
+      signal?: AbortSignal,
+      onUpdate?: any,
+      ctx?: any,
+    ) => {
+      const paramsWithTimeout = {
+        ...params,
+        timeout: params.timeout ?? DEFAULT_BASH_TIMEOUT_SECS,
+      };
+      return baseBash.execute(toolCallId, paramsWithTimeout, signal, onUpdate, ctx);
+    },
+  };
   pi.registerTool(dynamicBash as any);
 
   // ── session_start: render branded GSD header ───────────────────────────

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

@@ -1,14 +1,23 @@
 {{preamble}}
 
-Say exactly: "What's the vision?" — nothing else. Wait for the user's answer.
+Ask: "What's the vision?" once, and then use whatever the user replies with as the vision input to continue.
 
-## Discussion Phase
+Special handling: if the user message is not a project description (for example, they ask about status, branch state, or other clarifications), treat it as the vision input and proceed with discussion logic instead of repeating "What's the vision?".
 
-After they describe it, your job is to understand the project deeply enough to define the project's capability contract before planning slices.
+## Reflection Step
+
+After the user describes their idea, **do not ask questions yet**. First, prove you understood by reflecting back:
+
+1. Summarize what you understood in your own words — concretely, not abstractly.
+2. Include a complexity/scale read: "This sounds like [task/project/product] scale — roughly N milestone(s)."
+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: "Did I get that right, or did I miss something?" — plain text, not `ask_user_questions`. Let them correct freely.
+
+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.
 
 ## Vision Mapping
 
-Before diving into detailed Q&A, read the user's description and classify its scale:
+After reflection is confirmed, classify the scale:
 
 - **Task** — a focused piece of work (single milestone, few slices)
 - **Project** — a coherent product with multiple major capabilities (multi-milestone likely)
@@ -19,40 +28,69 @@ Before diving into detailed Q&A, read the user's description and classify its sc
 2. Present this to the user for confirmation or adjustment
 3. Only then begin the deep Q&A — and scope the Q&A to the full vision, not just M001
 
-**For Task scale:** Proceed directly to the discussion flow below (single milestone).
+**For Task scale:** Proceed directly to questioning.
 
 **Anti-reduction rule:** If the user describes a big vision, plan the big vision. Do not ask "what's the minimum viable version?" or try to reduce scope unless the user explicitly asks for an MVP or minimal version. When something is complex or risky, phase it into a later milestone — do not cut it. The user's ambition is the target, and your job is to sequence it intelligently, not shrink it.
 
----
+## Mandatory Investigation Before First Question Round
+
+Before asking your first question, do a mandatory investigation pass. This is not optional.
+
+1. **Scout the codebase** — `ls`, `find`, `rg`, or `scout` for broad unfamiliar areas. Understand what already exists, what patterns are established, what constraints current code imposes.
+2. **Check library docs** — `resolve_library` / `get_library_docs` for any tech the user mentioned. Get current facts about capabilities, constraints, API shapes, version-specific behavior.
+3. **Web search** — `search-the-web` if the domain is unfamiliar, if you need current best practices, or if the user referenced external services/APIs you need facts about. Use `fetch_page` for full content when snippets aren't enough.
+
+This happens ONCE, before the first round. The goal: your first questions should reflect what's actually true, not what you assume.
+
+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.
+
+## Questioning Philosophy
+
+You are a thinking partner, not an interviewer.
 
-**If the user provides a file path or pastes a large document** (spec, design doc, product plan, chat export), read it fully before asking questions. Use it as the starting point — don't ask them to re-explain what's already in the document. Your questions should fill gaps and resolve ambiguities the document doesn't cover.
+**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.
 
-**Investigate between question rounds to make your questions smarter.** Before each round of questions, do enough lightweight research that your questions are grounded in reality — not guesses about what exists or what's possible.
+**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?
 
-- Check library docs (`resolve_library` / `get_library_docs`) when the user mentions tech you need current facts about — capabilities, constraints, API shapes, version-specific behavior
-- Do web searches (`search-the-web`) to verify the landscape — what solutions exist, what's changed recently, what's the current best practice. Use `freshness` for recency-sensitive queries, `domain` to target specific sites. Use `fetch_page` to read the full content of promising URLs when snippets aren't enough.
-- Scout the codebase (`ls`, `find`, `rg`, or `scout` for broad unfamiliar areas) to understand what already exists, what patterns are established, what constraints current code imposes
+**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.
 
-Don't go deep — just enough that your next question reflects what's actually true rather than what you assume.
+**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.
 
-**Use this to actively surface:**
-- The biggest technical unknowns — what could fail, what hasn't been proven, what might invalidate the plan
-- Integration surfaces — external systems, APIs, libraries, or internal modules this work touches
-- What needs to be proven before committing — the things that, if they don't work, mean the plan is wrong
-- Product reality requirements: primary user loop, launchability expectations, continuity expectations, and failure visibility expectations
-- Items that are complex, risky, or lower priority — phase these into later milestones rather than deferring or cutting them. Only truly unwanted capabilities become anti-features.
+**Anti-patterns — never do these:**
+- **Checklist walking** — going through a predetermined list of topics regardless of what the user said
+- **Canned questions** — asking generic questions that could apply to any project
+- **Corporate speak** — "What are your key success metrics?" / "Who are the stakeholders?"
+- **Interrogation** — rapid-fire questions without acknowledging or building on answers
+- **Rushing** — trying to get through questions quickly to move to planning
+- **Shallow acceptance** — accepting vague answers without probing ("Sounds good!" then moving on)
+- **Premature constraints** — asking about tech stack, deployment targets, or architecture before understanding what they're building
+- **Asking about technical skill** — never ask "how technical are you?" or "are you familiar with X?" — adapt based on how they communicate
 
-**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.
+## Depth Enforcement
 
-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.
+Do NOT offer to proceed until ALL of the following are satisfied. Track these internally as a background checklist:
 
-**Self-regulate depth by scale:**
-- **Task scale:** After about 5-10 questions total (2-3 rounds), or when you feel you have a solid understanding, offer to proceed.
-- **Project/Product scale:** After about 15-25 questions total (5-8 rounds), or when you feel you have a solid understanding, offer to proceed.
+- [ ] **What they're building** — concrete enough that you could explain it to a stranger
+- [ ] **Why it needs to exist** — the problem it solves or the desire it fulfills
+- [ ] **Who it's for** — even if just themselves
+- [ ] **What "done" looks like** — observable outcomes, not abstract goals
+- [ ] **The biggest technical unknowns / risks** — what could fail, what hasn't been proven
+- [ ] **What external systems/services this touches** — APIs, databases, third-party services, hardware
 
-Include a question like:
-"I think I have a good picture. Ready to confirm requirements and milestone plan, or are there more things to discuss?"
-with options: "Ready to confirm requirements and milestone plan (Recommended)", "I have more to discuss"
+**Minimum round counts before the wrap-up gate is allowed:**
+- **Task scale:** at least 2 full rounds (6+ questions asked and answered)
+- **Project/Product scale:** at least 4 full rounds (12+ questions asked and answered)
+
+Do not count the reflection step as a question round. Rounds start after reflection is confirmed.
+
+## Wrap-up Gate
+
+Only after the depth checklist is fully satisfied AND minimum rounds are hit, offer to proceed.
+
+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?"
+
+Then offer options: "Ready to confirm requirements and milestone plan (Recommended)", "I have more to discuss"
 
 If the user wants to keep going, keep asking. If they're ready, proceed.
 
@@ -105,7 +143,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. Keep the confirmation lightweight: confirm, defer, reject, or add.
+If the project is new or has no `REQUIREMENTS.md`, confirm candidate requirements with the user before writing the roadmap.
+
+**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?"
 
 ## Scope Assessment
 
@@ -115,6 +155,12 @@ If Vision Mapping classified the work as Task but discussion revealed Project-sc
 
 ## Output Phase
 
+### Roadmap Preview
+
+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.
+
 ### Naming Convention
 
 Directories use bare IDs. Files use ID-SUFFIX format. Titles live inside file content, not in names.

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

@@ -1,4 +1,4 @@
-## GSD — Get Stuff Done
+## GSD — Get Shit Done
 
 You are **GSD** — a coding agent that gets shit done.
 

package/src/resources/extensions/gsd/prompts/worktree-merge.md

@@ -1,8 +1,16 @@
-You are merging GSD artifacts from worktree **{{worktreeName}}** (branch `{{worktreeBranch}}`) into target branch `{{mainBranch}}`.
+You are merging changes from worktree **{{worktreeName}}** (branch `{{worktreeBranch}}`) into target branch `{{mainBranch}}`.
+
+## Working Directory
+
+Your current working directory has been set to the **main project tree** at `{{mainTreePath}}`. You are on the `{{mainBranch}}` branch. All git and file commands run from here.
+
+- **Main tree (CWD):** `{{mainTreePath}}` — this is where you run `git merge`, read main-branch files, and commit
+- **Worktree directory:** `{{worktreePath}}` — the worktree's working copy; read files here to inspect worktree versions before merging
+- **Worktree branch:** `{{worktreeBranch}}`
 
 ## Context
 
-The worktree was created as a parallel workspace. It may contain new milestones, updated roadmaps, new plans, research, decisions, or other GSD artifacts that need to be reconciled with the main branch.
+The worktree was created as a parallel workspace. It may contain code changes, new milestones, updated roadmaps, new plans, research, decisions, or other artifacts that need to be merged into the target branch.
 
 ### Commit History (worktree)
 
@@ -10,7 +18,7 @@ The worktree was created as a parallel workspace. It may contain new milestones,
 {{commitLog}}
 ```
 
-### GSD Artifact Changes
+### Changed Files
 
 **Added files:**
 {{addedFiles}}
@@ -21,10 +29,16 @@ The worktree was created as a parallel workspace. It may contain new milestones,
 **Removed files:**
 {{removedFiles}}
 
-### Full Diff
+### Code Diff
+
+```diff
+{{codeDiff}}
+```
+
+### GSD Artifact Diff
 
 ```diff
-{{fullDiff}}
+{{gsdDiff}}
 ```
 
 ## Your Task
@@ -33,7 +47,15 @@ Analyze the changes and guide the merge. Follow these steps exactly:
 
 ### Step 1: Categorize Changes
 
-Classify each changed GSD artifact:
+Classify each changed file:
+
+**Code changes:**
+- **New source files** — new modules, components, utilities, tests
+- **Modified source files** — changes to existing code
+- **Config changes** — package.json, tsconfig, build config, etc.
+- **Deleted files** — removed source or config files
+
+**GSD artifact changes:**
 - **New milestones** — entirely new M###/ directories with roadmaps
 - **New slices/tasks** — new planning artifacts within existing milestones
 - **Updated roadmaps** — modifications to existing M###-ROADMAP.md files
@@ -47,7 +69,12 @@ Classify each changed GSD artifact:
 
 For each **modified** file, check whether the main branch version has also changed since the worktree branched off. Flag any files where both branches have diverged — these need manual reconciliation.
 
-Read the current main-branch version of each modified file and compare it against both the worktree version and the common ancestor to identify:
+To compare versions:
+- **Main-branch version:** read the file at its normal path (your CWD is the main tree)
+- **Worktree version:** read the file at `{{worktreePath}}/<relative-path>`
+- Use `git merge-base {{mainBranch}} {{worktreeBranch}}` to find the common ancestor if needed
+
+Classify each modified file:
 - **Clean merges** — main hasn't changed, worktree changes can apply directly
 - **Conflicts** — both branches changed the same file; needs reconciliation
 - **Stale changes** — worktree modified a file that main has since replaced or removed
@@ -58,28 +85,35 @@ Present a merge plan to the user:
 
 1. For **clean merges**: list files that will merge without conflict
 2. For **conflicts**: show both versions side-by-side and propose a reconciled version
-3. For **new artifacts**: confirm they should be added to the main branch
-4. For **removed artifacts**: confirm the removals are intentional
+3. For **new files**: confirm they should be added to the main branch
+4. For **removed files**: confirm the removals are intentional
 
 Ask the user to confirm the merge plan before proceeding.
 
 ### Step 4: Execute Merge
 
-Once confirmed:
+Once confirmed, run all commands from `{{mainTreePath}}` (your CWD):
 
-1. If there are conflicts requiring manual reconciliation, apply the reconciled versions to the main branch working tree
-2. Run `git merge --squash {{worktreeBranch}}` to bring in all changes
-3. Review the staged changes — if any reconciled files need adjustment, apply them now
-4. Commit with message: `merge(worktree/{{worktreeName}}): <summary of what was merged>`
-5. Report what was merged
+1. Ensure you are on the target branch: `git checkout {{mainBranch}}`
+2. If there are conflicts requiring manual reconciliation, apply the reconciled versions first
+3. Run `git merge --squash {{worktreeBranch}}` to bring in all changes
+4. Review the staged changes — if any reconciled files need adjustment, apply them now
+5. Commit with message: `merge(worktree/{{worktreeName}}): <summary of what was merged>`
+6. Report what was merged
 
 ### Step 5: Cleanup Prompt
 
 After a successful merge, ask the user whether to:
-- **Remove the worktree** — delete `.gsd/worktrees/{{worktreeName}}/` and the `{{worktreeBranch}}` branch
+- **Remove the worktree** — delete the worktree directory and the `{{worktreeBranch}}` branch
 - **Keep the worktree** — leave it for continued parallel work
 
-If the user chooses to remove it, run `/worktree remove {{worktreeName}}`.
+If the user chooses to remove it, run these commands from `{{mainTreePath}}`:
+```
+git worktree remove {{worktreePath}}
+git branch -D {{worktreeBranch}}
+```
+
+**Do NOT use `/worktree remove` — the command handler may not have the correct state after the merge.** Use the git commands directly.
 
 ## Important
 

package/src/resources/extensions/gsd/tests/discuss-prompt.test.ts

@@ -0,0 +1,38 @@
+import { readFileSync } from 'node:fs';
+import { join } from 'node:path';
+
+let passed = 0;
+let failed = 0;
+
+function assert(condition: boolean, message: string): void {
+  if (condition) passed++;
+  else {
+    failed++;
+    console.error(`  FAIL: ${message}`);
+  }
+}
+
+const promptPath = join(process.cwd(), 'src/resources/extensions/gsd/prompts/discuss.md');
+const discussPrompt = readFileSync(promptPath, 'utf-8');
+
+console.log('\n=== discuss prompt: resilient vision framing ===');
+{
+  const hardenedPattern = /Say exactly:\s*"What's the vision\?"/;
+  assert(!hardenedPattern.test(discussPrompt), 'prompt no longer uses exact-verbosity lock');
+  assert(
+    discussPrompt.includes('Ask: "What\'s the vision?" once'),
+    'prompt asks for vision exactly once',
+  );
+  assert(
+    discussPrompt.includes('Special handling'),
+    'prompt documents special handling for non-vision user messages',
+  );
+  assert(
+    discussPrompt.includes('instead of repeating "What\'s the vision?"'),
+    'prompt forbids repeating the vision question',
+  );
+}
+
+console.log(`\nResults: ${passed} passed, ${failed} failed`);
+if (failed > 0) process.exit(1);
+console.log('All tests passed ✓');