gsd-pi 2.41.0-dev.0acbce9 → 2.41.0-dev.3557dc4

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/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

@@ -10,7 +10,7 @@ import { createHash } from "node:crypto";
 import { execFileSync } from "node:child_process";
 import { existsSync, lstatSync, mkdirSync, 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);
   }