gsd-pi 2.41.0 → 2.42.0-dev.eedc83f

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

@@ -17,12 +17,36 @@
  * that aren't read until the end of a long auto-mode run.
  */
 
-import { readFileSync, readdirSync } from "node:fs";
+import { readFileSync, readdirSync, existsSync } from "node:fs";
 import { GSDError, GSD_PARSE_ERROR } from "./errors.js";
 import { join, dirname } from "node:path";
 import { fileURLToPath } from "node:url";
+import { homedir } from "node:os";
 
-const __extensionDir = dirname(fileURLToPath(import.meta.url));
+/**
+ * Resolve the GSD extension directory.
+ *
+ * `import.meta.url` resolves to whichever copy of this module is executing.
+ * On Windows (npm global install via MSYS2 / Git Bash) this can resolve to
+ * the npm-global `AppData/Roaming/npm/…` path, which does NOT contain the
+ * prompts/ and templates/ subtrees that initResources() copies to
+ * `~/.gsd/agent/extensions/gsd/`. Detect the mismatch and fall back to
+ * the user-local agent directory.
+ */
+function resolveExtensionDir(): string {
+  const moduleDir = dirname(fileURLToPath(import.meta.url));
+  if (existsSync(join(moduleDir, "prompts"))) return moduleDir;
+
+  // Fallback: user-local agent directory
+  const gsdHome = process.env.GSD_HOME || join(homedir(), ".gsd");
+  const agentGsdDir = join(gsdHome, "agent", "extensions", "gsd");
+  if (existsSync(join(agentGsdDir, "prompts"))) return agentGsdDir;
+
+  // Last resort: return the module dir (warmCache will silently handle the miss)
+  return moduleDir;
+}
+
+const __extensionDir = resolveExtensionDir();
 const promptsDir = join(__extensionDir, "prompts");
 const templatesDir = join(__extensionDir, "templates");
 
@@ -45,7 +69,11 @@ function warmCache(): void {
       }
     }
   } catch {
-    // prompts/ may not exist in test environments — lazy loading still works
+    // prompts/ may not exist in test environments — lazy loading still works.
+    // Emit a diagnostic when running outside tests so wrong-path bugs are visible.
+    if (!process.env.VITEST && !process.env.NODE_TEST) {
+      process.stderr.write(`[gsd:prompt-loader] warmCache: prompts dir not found: ${promptsDir}\n`);
+    }
   }
 
   try {
@@ -57,7 +85,10 @@ function warmCache(): void {
       }
     }
   } catch {
-    // templates/ may not exist in test environments — lazy loading still works
+    // templates/ may not exist in test environments — lazy loading still works.
+    if (!process.env.VITEST && !process.env.NODE_TEST) {
+      process.stderr.write(`[gsd:prompt-loader] warmCache: templates dir not found: ${templatesDir}\n`);
+    }
   }
 }
 

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

@@ -17,16 +17,17 @@ All relevant context has been preloaded below — the roadmap, all slice summari
 Then:
 1. Use the **Milestone Summary** output template from the inlined context above
 2. {{skillActivation}}
-3. Verify each **success criterion** from the milestone definition in `{{roadmapPath}}`. For each criterion, confirm it was met with specific evidence from slice summaries, test results, or observable behavior. List any criterion that was NOT met.
-4. Verify the milestone's **definition of done** — all slices are `[x]`, all slice summaries exist, and any cross-slice integration points work correctly.
-5. Validate **requirement status transitions**. For each requirement that changed status during this milestone, confirm the transition is supported by evidence. Requirements can move between Active, Validated, Deferred, Blocked, or Out of Scope — but only with proof.
-6. Write `{{milestoneSummaryPath}}` using the milestone-summary template. Fill all frontmatter fields and narrative sections. The `requirement_outcomes` field must list every requirement that changed status with `from_status`, `to_status`, and `proof`.
-7. Update `.gsd/REQUIREMENTS.md` if any requirement status transitions were validated in step 5.
-8. Update `.gsd/PROJECT.md` to reflect milestone completion and current project state.
-9. Review all slice summaries for cross-cutting lessons, patterns, or gotchas that emerged during this milestone. Append any non-obvious, reusable insights to `.gsd/KNOWLEDGE.md`.
-10. Do not commit manually — the system auto-commits your changes after this unit completes.
-
-**Important:** Do NOT skip the success criteria and definition of done verification (steps 3-4). The milestone summary must reflect actual verified outcomes, not assumed success. If any criterion was not met, document it clearly in the summary and do not mark the milestone as passing verification.
+3. **Verify code changes exist.** Run `git diff --stat HEAD $(git merge-base HEAD main) -- ':!.gsd/'` (or the equivalent for the integration branch). If no non-`.gsd/` files appear in the diff, the milestone produced only planning artifacts and no actual code. In that case, do NOT mark the milestone as passing verification — document the gap clearly in the summary and state that implementation is missing.
+4. Verify each **success criterion** from the milestone definition in `{{roadmapPath}}`. For each criterion, confirm it was met with specific evidence from slice summaries, test results, or observable behavior. List any criterion that was NOT met.
+5. Verify the milestone's **definition of done** — all slices are `[x]`, all slice summaries exist, and any cross-slice integration points work correctly.
+6. Validate **requirement status transitions**. For each requirement that changed status during this milestone, confirm the transition is supported by evidence. Requirements can move between Active, Validated, Deferred, Blocked, or Out of Scope — but only with proof.
+7. Write `{{milestoneSummaryPath}}` using the milestone-summary template. Fill all frontmatter fields and narrative sections. The `requirement_outcomes` field must list every requirement that changed status with `from_status`, `to_status`, and `proof`.
+8. Update `.gsd/REQUIREMENTS.md` if any requirement status transitions were validated in step 5.
+9. Update `.gsd/PROJECT.md` to reflect milestone completion and current project state.
+10. Review all slice summaries for cross-cutting lessons, patterns, or gotchas that emerged during this milestone. Append any non-obvious, reusable insights to `.gsd/KNOWLEDGE.md`.
+11. Do not commit manually — the system auto-commits your changes after this unit completes.
+
+**Important:** Do NOT skip the code change verification, success criteria, or definition of done verification (steps 3-5). The milestone summary must reflect actual verified outcomes, not assumed success. If any criterion was not met or no code changes exist, document it clearly in the summary and do not mark the milestone as passing verification.
 
 **File system safety:** When scanning milestone directories for evidence, use `ls` or `find` to list directory contents first — never pass a directory path (e.g. `tasks/`, `slices/`) directly to the `read` tool. The `read` tool only accepts file paths, not directories.
 

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

@@ -56,7 +56,7 @@ Use these templates exactly:
 9. Say exactly: "Milestone {{milestoneId}} ready."
 
 **For multi-milestone**, write in this order:
-1. For each milestone, call `gsd_generate_milestone_id` to get its ID — never invent milestone IDs manually. Then `mkdir -p .gsd/milestones/<ID>/slices` for each.
+1. For each milestone, call `gsd_milestone_generate_id` to get its ID — never invent milestone IDs manually. Then `mkdir -p .gsd/milestones/<ID>/slices` for each.
 2. Write `.gsd/PROJECT.md` — full vision across ALL milestones (using Project template)
 3. Write `.gsd/REQUIREMENTS.md` — full capability contract (using Requirements template)
 4. Seed `.gsd/DECISIONS.md` (using Decisions template)
@@ -82,5 +82,5 @@ Use these templates exactly:
 - **Investigate before writing** — always scout the codebase first
 - **Use depends_on frontmatter** for multi-milestone sequences (the state machine reads this field to determine execution order)
 - **Anti-reduction rule** — if the spec describes a big vision, plan the big vision. Do not ask "what's the minimum viable version?" or reduce scope. Phase complex/risky work into later milestones — do not cut it.
-- **Naming convention** — always use `gsd_generate_milestone_id` to get milestone IDs. Directories use bare IDs (e.g. `M001/` or `M001-r5jzab/`), files use ID-SUFFIX format (e.g. `M001-CONTEXT.md` or `M001-r5jzab-CONTEXT.md`). Never invent milestone IDs manually.
+- **Naming convention** — always use `gsd_milestone_generate_id` to get milestone IDs. Directories use bare IDs (e.g. `M001/` or `M001-r5jzab/`), files use ID-SUFFIX format (e.g. `M001-CONTEXT.md` or `M001-r5jzab-CONTEXT.md`). Never invent milestone IDs manually.
 - **End with "Milestone {{milestoneId}} ready."** — this triggers auto-start detection

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

@@ -214,7 +214,7 @@ Once the user confirms the milestone split:
 
 #### Phase 1: Shared artifacts
 
-1. For each milestone, call `gsd_generate_milestone_id` to get its ID — never invent milestone IDs manually. Then `mkdir -p .gsd/milestones/<ID>/slices`.
+1. For each milestone, call `gsd_milestone_generate_id` to get its ID — never invent milestone IDs manually. Then `mkdir -p .gsd/milestones/<ID>/slices`.
 2. Write `.gsd/PROJECT.md` — use the **Project** output template below.
 3. Write `.gsd/REQUIREMENTS.md` — use the **Requirements** output template below. Capture Active, Deferred, Out of Scope, and any already Validated requirements. Later milestones may have provisional ownership where slice plans do not exist yet.
 4. Seed `.gsd/DECISIONS.md` — use the **Decisions** output template below.

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

@@ -101,11 +101,19 @@ Explain your findings:
 - **Code snippet** — the problematic code and what it should do instead
 - **Recovery** — what the user can do right now to get unstuck
 
+{{dedupSection}}
+
 Then **offer GitHub issue creation**: "Would you like me to create a GitHub issue for this on gsd-build/gsd-2?"
 
-If yes, create using `gh issue create` with this format:
+**CRITICAL: The `github_issues` tool ONLY targets the current user's repository — it has no `repo` parameter. You MUST use `gh issue create --repo gsd-build/gsd-2` via the `bash` tool to file on the correct repo. Do NOT use the `github_issues` tool for this.**
 
-```
+If yes, create using the `bash` tool:
+
+```bash
+gh issue create --repo gsd-build/gsd-2 \
+  --title "..." \
+  --label "bug" --label "auto-generated" \
+  --body "$(cat <<'EOF'
 ## Problem
 [1-2 sentence summary]
 
@@ -128,11 +136,10 @@ If yes, create using `gh issue create` with this format:
 
 ---
 *Auto-generated by `/gsd forensics`*
+EOF
+)"
 ```
 
-**Repository:** gsd-build/gsd-2
-**Labels:** bug, auto-generated
-
 ### Redaction Rules (CRITICAL)
 
 Before creating the issue, you MUST:

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

@@ -107,7 +107,7 @@ The user confirms or corrects before you write. One depth verification per miles
 
 Once the user is satisfied, in a single pass for **each** new milestone:
 
-1. Call `gsd_generate_milestone_id` to get the milestone ID — never invent milestone IDs manually. Then `mkdir -p .gsd/milestones/<ID>/slices`.
+1. Call `gsd_milestone_generate_id` to get the milestone ID — never invent milestone IDs manually. Then `mkdir -p .gsd/milestones/<ID>/slices`.
 2. Write `.gsd/milestones/<ID>/<ID>-CONTEXT.md` — use the **Context** output template below. Capture intent, scope, risks, constraints, integration points, and relevant requirements. Mark the status as "Queued — pending auto-mode execution." **If this milestone depends on other milestones, add YAML frontmatter with `depends_on`:**
    ```yaml
    ---

package/src/resources/extensions/gsd/repo-identity.ts

@@ -8,9 +8,9 @@
 
 import { createHash } from "node:crypto";
 import { execFileSync } from "node:child_process";
-import { existsSync, lstatSync, mkdirSync, readFileSync, realpathSync, rmSync, symlinkSync, writeFileSync } from "node:fs";
+import { existsSync, lstatSync, mkdirSync, readdirSync, readFileSync, realpathSync, rmSync, symlinkSync, writeFileSync } from "node:fs";
 import { homedir } from "node:os";
-import { basename, join, resolve } from "node:path";
+import { basename, dirname, join, resolve } from "node:path";
 
 const gsdHome = process.env.GSD_HOME || join(homedir(), ".gsd");
 
@@ -95,6 +95,50 @@ export function readRepoMeta(externalPath: string): RepoMeta | null {
   }
 }
 
+// ─── Inherited-Repo Detection ───────────────────────────────────────────────
+
+/**
+ * Check whether `basePath` is inheriting a parent directory's git repo
+ * rather than being the git root itself.
+ *
+ * Returns true when ALL of:
+ *   1. basePath is inside a git repo (git rev-parse succeeds)
+ *   2. The resolved git root is a proper ancestor of basePath
+ *   3. There is no `.gsd` directory at the git root (the parent project
+ *      has not been initialised with GSD)
+ *
+ * When true, the caller should run `git init` at basePath so that
+ * `repoIdentity()` produces a hash unique to this directory, preventing
+ * cross-project state leaks (#1639).
+ *
+ * When the git root already has `.gsd`, the directory is a legitimate
+ * subdirectory of an existing GSD project — `cd src/ && /gsd` should
+ * still load the parent project's milestones.
+ */
+export function isInheritedRepo(basePath: string): boolean {
+  try {
+    const root = resolveGitRoot(basePath);
+    const normalizedBase = canonicalizeExistingPath(basePath);
+    const normalizedRoot = canonicalizeExistingPath(root);
+    if (normalizedBase === normalizedRoot) return false; // basePath IS the root
+
+    // The git root is a proper ancestor. Check whether it already has .gsd
+    // (i.e. the parent project was initialised with GSD).
+    if (existsSync(join(root, ".gsd"))) return false;
+
+    // Also walk up from basePath to the git root checking for .gsd
+    let dir = normalizedBase;
+    while (dir !== normalizedRoot && dir !== dirname(dir)) {
+      if (existsSync(join(dir, ".gsd"))) return false;
+      dir = dirname(dir);
+    }
+
+    return true;
+  } catch {
+    return false;
+  }
+}
+
 // ─── Repo Identity ──────────────────────────────────────────────────────────
 
 /**
@@ -120,7 +164,8 @@ function getRemoteUrl(basePath: string): string {
  */
 function canonicalizeExistingPath(path: string): string {
   try {
-    return realpathSync(path);
+    // Use native realpath on Windows to resolve 8.3 short paths (e.g. RUNNER~1)
+    return process.platform === "win32" ? realpathSync.native(path) : realpathSync(path);
   } catch {
     return resolve(path);
   }
@@ -226,15 +271,54 @@ export function externalProjectsRoot(): string {
   return join(base, "projects");
 }
 
+// ─── Numbered Variant Cleanup ────────────────────────────────────────────────
+
+/**
+ * macOS collision pattern: `.gsd 2`, `.gsd 3`, `.gsd 4`, etc.
+ *
+ * When `symlinkSync` (or Finder) tries to create `.gsd` but a real directory
+ * already exists at that path, macOS APFS silently renames the new entry to
+ * `.gsd 2`, then `.gsd 3`, and so on. These numbered variants confuse GSD
+ * because the canonical `.gsd` path no longer resolves to the external state
+ * directory, making tracked planning files appear deleted.
+ *
+ * This helper scans the project root for entries matching `.gsd <digits>` and
+ * removes them. It is called early in `ensureGsdSymlink()` so that the
+ * canonical `.gsd` path is always the one in use.
+ */
+const GSD_NUMBERED_VARIANT_RE = /^\.gsd \d+$/;
+
+export function cleanNumberedGsdVariants(projectPath: string): string[] {
+  const removed: string[] = [];
+  try {
+    const entries = readdirSync(projectPath);
+    for (const entry of entries) {
+      if (GSD_NUMBERED_VARIANT_RE.test(entry)) {
+        const fullPath = join(projectPath, entry);
+        try {
+          rmSync(fullPath, { recursive: true, force: true });
+          removed.push(entry);
+        } catch {
+          // Best-effort: if removal fails (e.g. permissions), continue with next
+        }
+      }
+    }
+  } catch {
+    // Non-fatal: readdir failure should not block symlink creation
+  }
+  return removed;
+}
+
 // ─── Symlink Management ─────────────────────────────────────────────────────
 
 /**
  * Ensure the `<project>/.gsd` symlink points to the external state directory.
  *
- * 1. mkdir -p the external dir
- * 2. If `<project>/.gsd` doesn't exist → create symlink
- * 3. If `<project>/.gsd` is already the correct symlink → no-op
- * 4. If `<project>/.gsd` is a real directory → return as-is (migration handles later)
+ * 1. Clean up any macOS numbered collision variants (`.gsd 2`, `.gsd 3`, etc.)
+ * 2. mkdir -p the external dir
+ * 3. If `<project>/.gsd` doesn't exist → create symlink
+ * 4. If `<project>/.gsd` is already the correct symlink → no-op
+ * 5. If `<project>/.gsd` is a real directory → return as-is (migration handles later)
  *
  * Returns the resolved external path.
  */
@@ -252,6 +336,10 @@ export function ensureGsdSymlink(projectPath: string): string {
     return localGsd;
   }
 
+  // Clean up macOS numbered collision variants (.gsd 2, .gsd 3, etc.) before
+  // any existence checks — otherwise they accumulate and confuse state (#2205).
+  cleanNumberedGsdVariants(projectPath);
+
   // Ensure external directory exists
   mkdirSync(externalPath, { recursive: true });