gsd-pi 2.38.0-dev.7209774 → 2.38.0-dev.785052f

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

@@ -20,7 +20,7 @@ All relevant context has been preloaded below — the slice plan, all task summa
 
 Then:
 1. Use the **Slice Summary** and **UAT** output templates from the inlined context above
-2. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during completion, without relaxing required verification or artifact rules
+2. {{skillActivation}}
 3. Run all slice-level verification checks defined in the slice plan. All must pass before marking the slice done. If any fail, fix them first.
 4. If the slice plan includes observability/diagnostic surfaces, confirm they work. Skip this for simple slices that don't have observability sections.
 5. If `.gsd/REQUIREMENTS.md` exists, update it based on what this slice actually proved. Move requirements between Active, Validated, Deferred, Blocked, or Out of Scope only when the evidence from execution supports that change.

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

@@ -28,7 +28,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.
+1. {{skillActivation}} Follow any activated skills before writing code. If no skills match this task, skip this step.
 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).

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

@@ -1,3 +1,3 @@
-Complete slice {{sliceId}} ("{{sliceTitle}}") of milestone {{milestoneId}}. Your working directory is `{{workingDirectory}}` — all file operations must use this path. All tasks are done. Your slice summary is the primary record of what was built — downstream agents (reassess-roadmap, future slice researchers) read it to understand what this slice delivered and what to watch out for. Use the **Slice Summary** and **UAT** output templates below. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during completion, without relaxing required verification or artifact rules. Write `{{sliceId}}-SUMMARY.md` (compress task summaries), write `{{sliceId}}-UAT.md`, and fill the `UAT Type` plus `Not Proven By This UAT` sections explicitly so the artifact states what class of acceptance it covers and what still remains unproven. Review task summaries for `key_decisions` and ensure any significant ones are in `.gsd/DECISIONS.md`. Mark the slice checkbox done in the roadmap, update milestone summary, Do not commit or merge manually — the system handles this after the unit completes.
+Complete slice {{sliceId}} ("{{sliceTitle}}") of milestone {{milestoneId}}. Your working directory is `{{workingDirectory}}` — all file operations must use this path. All tasks are done. Your slice summary is the primary record of what was built — downstream agents (reassess-roadmap, future slice researchers) read it to understand what this slice delivered and what to watch out for. Use the **Slice Summary** and **UAT** output templates below. {{skillActivation}} Write `{{sliceId}}-SUMMARY.md` (compress task summaries), write `{{sliceId}}-UAT.md`, and fill the `UAT Type` plus `Not Proven By This UAT` sections explicitly so the artifact states what class of acceptance it covers and what still remains unproven. Review task summaries for `key_decisions` and ensure any significant ones are in `.gsd/DECISIONS.md`. Mark the slice checkbox done in the roadmap, update milestone summary, Do not commit or merge manually — the system handles this after the unit completes.
 
 {{inlinedTemplates}}

package/src/resources/extensions/gsd/prompts/guided-execute-task.md

@@ -1,3 +1,3 @@
-Execute the next task: {{taskId}} ("{{taskTitle}}") in slice {{sliceId}} of milestone {{milestoneId}}. Read the task plan (`{{taskId}}-PLAN.md`), load relevant summaries from prior tasks, and execute each step. Verify must-haves when done. If the task touches UI, browser flows, DOM behavior, or user-visible web state, exercise the real flow in the browser, prefer `browser_batch` for obvious sequences, prefer `browser_assert` for explicit pass/fail verification, use `browser_diff` when an action's effect is ambiguous, and use browser diagnostics when validating async or failure-prone UI. If you made an architectural, pattern, or library decision, append it to `.gsd/DECISIONS.md`. Use the **Task Summary** output template below. Write `{{taskId}}-SUMMARY.md`, mark it done, commit, and advance. 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. If running long and not all steps are finished, stop implementing and prioritize writing a clean partial summary over attempting one more step — a recoverable handoff is more valuable than a half-finished step with no documentation. If verification fails, debug methodically: form a hypothesis and test that specific theory before changing anything, change one variable at a time, read entire functions not just the suspect line, distinguish observable facts from assumptions, and if 3+ fixes fail without progress stop and reassess your mental model — list what you know for certain, what you've ruled out, and form fresh hypotheses. Don't fix symptoms — understand why something fails before changing code.
+Execute the next task: {{taskId}} ("{{taskTitle}}") in slice {{sliceId}} of milestone {{milestoneId}}. Read the task plan (`{{taskId}}-PLAN.md`), load relevant summaries from prior tasks, and execute each step. Verify must-haves when done. If the task touches UI, browser flows, DOM behavior, or user-visible web state, exercise the real flow in the browser, prefer `browser_batch` for obvious sequences, prefer `browser_assert` for explicit pass/fail verification, use `browser_diff` when an action's effect is ambiguous, and use browser diagnostics when validating async or failure-prone UI. If you made an architectural, pattern, or library decision, append it to `.gsd/DECISIONS.md`. Use the **Task Summary** output template below. Write `{{taskId}}-SUMMARY.md`, mark it done, commit, and advance. {{skillActivation}} If running long and not all steps are finished, stop implementing and prioritize writing a clean partial summary over attempting one more step — a recoverable handoff is more valuable than a half-finished step with no documentation. If verification fails, debug methodically: form a hypothesis and test that specific theory before changing anything, change one variable at a time, read entire functions not just the suspect line, distinguish observable facts from assumptions, and if 3+ fixes fail without progress stop and reassess your mental model — list what you know for certain, what you've ruled out, and form fresh hypotheses. Don't fix symptoms — understand why something fails before changing code.
 
 {{inlinedTemplates}}

package/src/resources/extensions/gsd/prompts/guided-plan-milestone.md

@@ -1,4 +1,4 @@
-Plan milestone {{milestoneId}} ("{{milestoneTitle}}"). Read `.gsd/DECISIONS.md` if it exists — respect existing decisions. Read `.gsd/REQUIREMENTS.md` if it exists and treat Active requirements as the capability contract. If `REQUIREMENTS.md` is missing, continue in legacy compatibility mode but explicitly note missing requirement coverage. Use the **Roadmap** output template below. Create `{{milestoneId}}-ROADMAP.md` in the milestone directory with slices, risk levels, dependencies, demo sentences, verification classes, milestone definition of done, requirement coverage, and a boundary map. Write success criteria as observable truths, not implementation tasks. If the milestone crosses multiple runtime boundaries, include an explicit final integration slice that proves the assembled system works end-to-end in a real environment. If planning produces structural decisions, append them to `.gsd/DECISIONS.md`. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during planning, without overriding required roadmap formatting.
+Plan milestone {{milestoneId}} ("{{milestoneTitle}}"). Read `.gsd/DECISIONS.md` if it exists — respect existing decisions. Read `.gsd/REQUIREMENTS.md` if it exists and treat Active requirements as the capability contract. If `REQUIREMENTS.md` is missing, continue in legacy compatibility mode but explicitly note missing requirement coverage. Use the **Roadmap** output template below. Create `{{milestoneId}}-ROADMAP.md` in the milestone directory with slices, risk levels, dependencies, demo sentences, verification classes, milestone definition of done, requirement coverage, and a boundary map. Write success criteria as observable truths, not implementation tasks. If the milestone crosses multiple runtime boundaries, include an explicit final integration slice that proves the assembled system works end-to-end in a real environment. If planning produces structural decisions, append them to `.gsd/DECISIONS.md`. {{skillActivation}}
 
 ## Requirement Rules
 

package/src/resources/extensions/gsd/prompts/guided-plan-slice.md

@@ -1,3 +1,3 @@
-Plan slice {{sliceId}} ("{{sliceTitle}}") of milestone {{milestoneId}}. Read `.gsd/DECISIONS.md` if it exists — respect existing decisions. Read `.gsd/REQUIREMENTS.md` if it exists — identify which Active requirements the roadmap says this slice owns or supports, and ensure the plan delivers them. Read the roadmap boundary map, any existing context/research files, and dependency summaries. Use the **Slice Plan** and **Task Plan** output templates below. Decompose into tasks with must-haves. Fill the `Proof Level` and `Integration Closure` sections truthfully so the plan says what class of proof this slice really delivers and what end-to-end wiring still remains. Write `{{sliceId}}-PLAN.md` and individual `T##-PLAN.md` files in the `tasks/` subdirectory. If planning produces structural decisions, append them to `.gsd/DECISIONS.md`. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during planning, without overriding required plan formatting. Before committing, self-audit the plan: every must-have maps to at least one task, every task has complete sections (steps, must-haves, verification, observability impact, inputs, and expected output), task ordering is consistent with no circular references, every pair of artifacts that must connect has an explicit wiring step, task scope targets 2–5 steps and 3–8 files (6–8 steps or 8–10 files — consider splitting; 10+ steps or 12+ files — must split), the plan honors locked decisions from context/research/decisions artifacts, the proof-level wording does not overclaim live integration if only fixture/contract proof is planned, every Active requirement this slice owns has at least one task with verification that proves it is met, and every task produces real user-facing progress — if the slice has a UI surface at least one task builds the real UI, if it has an API at least one task connects it to a real data source, and showing the completed result to a non-technical stakeholder would demonstrate real product progress rather than developer artifacts.
+Plan slice {{sliceId}} ("{{sliceTitle}}") of milestone {{milestoneId}}. Read `.gsd/DECISIONS.md` if it exists — respect existing decisions. Read `.gsd/REQUIREMENTS.md` if it exists — identify which Active requirements the roadmap says this slice owns or supports, and ensure the plan delivers them. Read the roadmap boundary map, any existing context/research files, and dependency summaries. Use the **Slice Plan** and **Task Plan** output templates below. Decompose into tasks with must-haves. Fill the `Proof Level` and `Integration Closure` sections truthfully so the plan says what class of proof this slice really delivers and what end-to-end wiring still remains. Write `{{sliceId}}-PLAN.md` and individual `T##-PLAN.md` files in the `tasks/` subdirectory. If planning produces structural decisions, append them to `.gsd/DECISIONS.md`. {{skillActivation}} Before committing, self-audit the plan: every must-have maps to at least one task, every task has complete sections (steps, must-haves, verification, observability impact, inputs, and expected output), task ordering is consistent with no circular references, every pair of artifacts that must connect has an explicit wiring step, task scope targets 2–5 steps and 3–8 files (6–8 steps or 8–10 files — consider splitting; 10+ steps or 12+ files — must split), the plan honors locked decisions from context/research/decisions artifacts, the proof-level wording does not overclaim live integration if only fixture/contract proof is planned, every Active requirement this slice owns has at least one task with verification that proves it is met, and every task produces real user-facing progress — if the slice has a UI surface at least one task builds the real UI, if it has an API at least one task connects it to a real data source, and showing the completed result to a non-technical stakeholder would demonstrate real product progress rather than developer artifacts.
 
 {{inlinedTemplates}}

package/src/resources/extensions/gsd/prompts/guided-research-slice.md

@@ -1,4 +1,4 @@
-Research slice {{sliceId}} ("{{sliceTitle}}") of milestone {{milestoneId}}. Read `.gsd/DECISIONS.md` if it exists — respect existing decisions, don't contradict them. Read `.gsd/REQUIREMENTS.md` if it exists — identify which Active requirements this slice owns or supports and target research toward risks, unknowns, and constraints that could affect delivery of those requirements. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during research, without relaxing required verification or artifact rules. Explore the relevant code — use `rg`/`find` for targeted reads, or `scout` if the area is broad or unfamiliar. Check libraries with `resolve_library`/`get_library_docs` — skip this for libraries already used in the codebase. Use the **Research** output template below. Write `{{sliceId}}-RESEARCH.md` in the slice directory.
+Research slice {{sliceId}} ("{{sliceTitle}}") of milestone {{milestoneId}}. Read `.gsd/DECISIONS.md` if it exists — respect existing decisions, don't contradict them. Read `.gsd/REQUIREMENTS.md` if it exists — identify which Active requirements this slice owns or supports and target research toward risks, unknowns, and constraints that could affect delivery of those requirements. {{skillActivation}} Explore the relevant code — use `rg`/`find` for targeted reads, or `scout` if the area is broad or unfamiliar. Check libraries with `resolve_library`/`get_library_docs` — skip this for libraries already used in the codebase. Use the **Research** output template below. Write `{{sliceId}}-RESEARCH.md` in the slice directory.
 
 **You are the scout.** A planner agent reads your output in a fresh context to decompose this slice into tasks. Write for the planner — surface key files, where the work divides naturally, what to build first, and how to verify. If the research doc is vague, the planner re-explores code you already read. If it's precise, the planner decomposes immediately.
 

package/src/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}}, 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.
+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. {{skillActivation}}

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

@@ -44,7 +44,7 @@ Narrate your decomposition reasoning — why you're grouping work this way, what
 
 Then:
 1. Use the **Roadmap** output template from the inlined context above
-2. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during planning, without overriding required roadmap formatting
+2. {{skillActivation}}
 3. Create the roadmap: decompose into demoable vertical slices — as many as the work genuinely needs, no more. A simple feature might be 1 slice. Don't decompose for decomposition's sake.
 4. Order by risk (high-risk first)
 5. Write `{{outputPath}}` with checkboxes, risk, depends, demo sentences, proof strategy, verification classes, milestone definition of done, **requirement coverage**, and a boundary map. Write success criteria as observable truths, not implementation tasks. If the milestone crosses multiple runtime boundaries, include an explicit final integration slice that proves the assembled system works end-to-end in a real environment

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

@@ -47,7 +47,7 @@ Then:
 1. Read the templates:
    - `~/.gsd/agent/extensions/gsd/templates/plan.md`
    - `~/.gsd/agent/extensions/gsd/templates/task-plan.md`
-2. **Load relevant skills.** Check the `GSD Skill Preferences` block in system context and the `<available_skills>` catalog in your system prompt. `read` any skill files relevant to this slice's technology stack before decomposing. When writing task plans, note which installed skills are relevant in the task description so executors know which to load.
+2. {{skillActivation}} Record the installed skills you expect executors to use in each task plan's `skills_used` frontmatter.
 3. Define slice-level verification — the objective stopping condition for this slice:
    - For non-trivial slices: plan actual test files with real assertions. Name the files.
    - For simple slices: executable commands or script assertions are fine.

package/src/resources/extensions/gsd/prompts/reassess-roadmap.md

@@ -22,7 +22,7 @@ The following user thoughts were captured during execution and deferred to futur
 
 {{deferredCaptures}}
 
-If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during reassessment, without relaxing required verification or artifact rules.
+{{skillActivation}}
 
 Then assess whether the remaining roadmap still makes sense given what was just built.
 

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

@@ -21,7 +21,7 @@ Write for the roadmap planner. It needs to understand: what exists in the codeba
 A milestone adding a small feature to an established codebase needs targeted research — check the relevant code, confirm the approach, note constraints. A milestone introducing new technology, building a new system, or spanning multiple unfamiliar subsystems needs deep research — explore broadly, look up docs, investigate alternatives. Match your effort to the actual uncertainty, not the template's section count. Include only sections that have real content.
 
 Then research the codebase and relevant technologies. Narrate key findings and surprises as you go — what exists, what's missing, what constrains the approach.
-1. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during research, without relaxing required verification or artifact rules
+1. {{skillActivation}}
 2. **Skill Discovery ({{skillDiscoveryMode}}):**{{skillDiscoveryInstructions}}
 3. Explore relevant code. For small/familiar codebases, use `rg`, `find`, and targeted reads. For large or unfamiliar codebases, use `scout` to build a broad map efficiently before diving in.
 4. Use `resolve_library` / `get_library_docs` for unfamiliar libraries — skip this for libraries already used in the codebase

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

@@ -42,7 +42,7 @@ An honest "this is straightforward, here's the pattern to follow" is more valuab
 
 Research what this slice needs. Narrate key findings and surprises as you go — what exists, what's missing, what constrains the approach.
 0. If `REQUIREMENTS.md` was preloaded above, identify which Active requirements this slice owns or supports. Research should target these requirements — surfacing risks, unknowns, and implementation constraints that could affect whether the slice actually delivers them.
-1. **Load relevant skills.** Check the `GSD Skill Preferences` block in system context and the `<available_skills>` catalog in your system prompt. `read` any skill files relevant to this slice's technology stack before exploring code. Reference specific rules from loaded skills in your findings where they inform the implementation approach.
+1. {{skillActivation}} Reference specific rules from loaded skills in your findings where they inform the implementation approach.
 2. **Skill Discovery ({{skillDiscoveryMode}}):**{{skillDiscoveryInstructions}}
 3. Explore relevant code for this slice's scope. For targeted exploration, use `rg`, `find`, and reads. For broad or unfamiliar subsystems, use `scout` to map the relevant area first.
 4. Use `resolve_library` / `get_library_docs` for unfamiliar libraries — skip this for libraries already used in the codebase

package/src/resources/extensions/gsd/prompts/run-uat.md

@@ -10,7 +10,7 @@ All relevant context has been preloaded below. Start working immediately without
 
 {{inlinedContext}}
 
-If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during UAT execution, without relaxing required verification or artifact rules.
+{{skillActivation}}
 
 ---
 

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

@@ -126,7 +126,12 @@ export async function getActiveMilestoneId(basePath: string): Promise<string | n
       // A draft milestone is still "active" — this function only determines which milestone is current.
     }
     const roadmap = parseRoadmap(content);
-    if (!isMilestoneComplete(roadmap)) return mid;
+    if (!isMilestoneComplete(roadmap)) {
+      // Summary is the terminal artifact — if it exists, the milestone is
+      // complete even when roadmap checkboxes weren't ticked (#864).
+      const summaryFile = resolveMilestoneFile(basePath, mid, "SUMMARY");
+      if (!summaryFile) return mid;
+    }
   }
   return null;
 }
@@ -258,7 +263,13 @@ async function _deriveStateImpl(basePath: string): Promise<GSDState> {
     }
     const rmap = parseRoadmap(rc);
     roadmapCache.set(mid, rmap);
-    if (!isMilestoneComplete(rmap)) continue;
+    if (!isMilestoneComplete(rmap)) {
+      // Summary is the terminal artifact — if it exists, the milestone is
+      // complete even when roadmap checkboxes weren't ticked (#864).
+      const sf = resolveMilestoneFile(basePath, mid, "SUMMARY");
+      if (sf) completeMilestoneIds.add(mid);
+      continue;
+    }
     const sf = resolveMilestoneFile(basePath, mid, "SUMMARY");
     if (sf) completeMilestoneIds.add(mid);
   }
@@ -357,26 +368,33 @@ async function _deriveStateImpl(basePath: string): Promise<GSDState> {
       } else {
         registry.push({ id: mid, title, status: 'complete' });
       }
-    } else if (!activeMilestoneFound) {
-      // Check milestone-level dependencies before promoting to active
-      const contextFile = resolveMilestoneFile(basePath, mid, "CONTEXT");
-      const contextContent = contextFile ? await cachedLoadFile(contextFile) : null;
-      const deps = parseContextDependsOn(contextContent);
-      const depsUnmet = deps.some(dep => !completeMilestoneIds.has(dep));
-      if (depsUnmet) {
-        registry.push({ id: mid, title, status: 'pending', dependsOn: deps });
-        // Do NOT set activeMilestoneFound — let the loop continue to the next milestone
+    } else {
+      // Roadmap slices not all checked — but if a summary exists, the milestone
+      // is still complete. The summary is the terminal artifact (#864).
+      const summaryFile = resolveMilestoneFile(basePath, mid, "SUMMARY");
+      if (summaryFile) {
+        registry.push({ id: mid, title, status: 'complete' });
+      } else if (!activeMilestoneFound) {
+        // Check milestone-level dependencies before promoting to active
+        const contextFile = resolveMilestoneFile(basePath, mid, "CONTEXT");
+        const contextContent = contextFile ? await cachedLoadFile(contextFile) : null;
+        const deps = parseContextDependsOn(contextContent);
+        const depsUnmet = deps.some(dep => !completeMilestoneIds.has(dep));
+        if (depsUnmet) {
+          registry.push({ id: mid, title, status: 'pending', dependsOn: deps });
+          // Do NOT set activeMilestoneFound — let the loop continue to the next milestone
+        } else {
+          activeMilestone = { id: mid, title };
+          activeRoadmap = roadmap;
+          activeMilestoneFound = true;
+          registry.push({ id: mid, title, status: 'active', ...(deps.length > 0 ? { dependsOn: deps } : {}) });
+        }
       } else {
-        activeMilestone = { id: mid, title };
-        activeRoadmap = roadmap;
-        activeMilestoneFound = true;
-        registry.push({ id: mid, title, status: 'active', ...(deps.length > 0 ? { dependsOn: deps } : {}) });
+        const contextFile2 = resolveMilestoneFile(basePath, mid, "CONTEXT");
+        const contextContent2 = contextFile2 ? await cachedLoadFile(contextFile2) : null;
+        const deps2 = parseContextDependsOn(contextContent2);
+        registry.push({ id: mid, title, status: 'pending', ...(deps2.length > 0 ? { dependsOn: deps2 } : {}) });
       }
-    } else {
-      const contextFile2 = resolveMilestoneFile(basePath, mid, "CONTEXT");
-      const contextContent2 = contextFile2 ? await cachedLoadFile(contextFile2) : null;
-      const deps2 = parseContextDependsOn(contextContent2);
-      registry.push({ id: mid, title, status: 'pending', ...(deps2.length > 0 ? { dependsOn: deps2 } : {}) });
     }
   }
 

package/src/resources/extensions/gsd/templates/task-plan.md

@@ -3,6 +3,9 @@
 # Tasks with 10+ estimated steps or 12+ estimated files trigger a warning to consider splitting.
 estimated_steps: {{estimatedSteps}}
 estimated_files: {{estimatedFiles}}
+# Installed skills the planner expects the executor to load before coding.
+skills_used:
+  - {{skillName}}
 ---
 
 # {{taskId}}: {{taskTitle}}

package/src/resources/extensions/gsd/tests/auto-worktree-milestone-merge.test.ts

@@ -242,9 +242,10 @@ async function main(): Promise<void> {
       const remoteLog = run("git log --oneline main", bareDir);
       assertTrue(remoteLog.includes("feat(M040)"), "milestone commit reachable on remote after manual push");
 
-      // result.pushed will be false since prefs aren't loadable in temp repos
-      // (module-level const limitation) — that's expected
-      assertEq(result.pushed, false, "pushed is false without discoverable prefs");
+      // Temp-repo prefs may or may not be discoverable depending on process cwd and
+      // current preference-loading behavior. The important contract is that remote
+      // push mechanics work and the returned value reflects what happened.
+      assertTrue(typeof result.pushed === "boolean", "pushed flag remains boolean");
     }
 
     // ─── Test 5: Auto-resolve .gsd/ state file conflicts (#530) ───────

package/src/resources/extensions/gsd/tests/derive-state.test.ts

@@ -779,6 +779,49 @@ slice: S01
     }
   }
 
+  // ─── Test: unchecked roadmap slices + summary → complete (summary is terminal) ────
+  console.log('\n=== unchecked roadmap slices + summary → complete (summary is terminal) ===');
+  {
+    const base = createFixtureBase();
+    try {
+      // M001: roadmap has unchecked slices but a summary exists — should be complete
+      writeRoadmap(base, 'M001', `# M001: First Milestone\n\n**Vision:** Already done.\n\n## Slices\n\n- [ ] **S01: Unchecked slice** \`risk:low\` \`depends:[]\`\n  > Work was done but checkbox never ticked.\n- [ ] **S02: Another unchecked** \`risk:low\` \`depends:[]\`\n  > Same.\n`);
+      writeMilestoneSummary(base, 'M001', '---\nid: M001\n---\n\n# M001: First Milestone\n\n**Completed despite unchecked roadmap.**');
+      // M002: genuinely incomplete — should be the active milestone
+      writeRoadmap(base, 'M002', `# M002: Active Milestone\n\n**Vision:** Do stuff.\n\n## Slices\n\n- [ ] **S01: Work slice** \`risk:low\` \`depends:[]\`\n  > Needs work.\n`);
+
+      const state = await deriveState(base);
+      const m001Entry = state.registry.find(e => e.id === 'M001');
+      assertEq(m001Entry?.status, 'complete', 'M001 with unchecked roadmap + summary is complete');
+      assertEq(state.activeMilestone?.id, 'M002', 'active milestone is M002, not M001');
+    } finally {
+      cleanup(base);
+    }
+  }
+
+  // ─── Test: unchecked roadmap + summary counts toward completeMilestoneIds (deps) ────
+  console.log('\n=== unchecked roadmap + summary satisfies dependency ===');
+  {
+    const base = createFixtureBase();
+    try {
+      // M001: unchecked roadmap + summary → complete
+      writeRoadmap(base, 'M001', `# M001: Foundation\n\n**Vision:** Done.\n\n## Slices\n\n- [ ] **S01: Setup** \`risk:low\` \`depends:[]\`\n  > Done.\n`);
+      writeMilestoneSummary(base, 'M001', '---\nid: M001\n---\n\n# M001: Foundation\n\n**Done.**');
+      // M002: depends on M001 — should be active since M001 is complete
+      writeRoadmap(base, 'M002', `# M002: Dependent\n\n**Vision:** Depends on M001.\n\n## Slices\n\n- [ ] **S01: Work** \`risk:low\` \`depends:[]\`\n  > Work.\n`);
+      const contextDir = join(base, '.gsd', 'milestones', 'M002');
+      mkdirSync(contextDir, { recursive: true });
+      writeFileSync(join(contextDir, 'M002-CONTEXT.md'), '---\ndepends_on:\n  - M001\n---\n\n# M002 Context\n\nDepends on M001.');
+
+      const state = await deriveState(base);
+      assertEq(state.activeMilestone?.id, 'M002', 'M002 is active — M001 dependency satisfied via summary');
+      const m002Entry = state.registry.find(e => e.id === 'M002');
+      assertEq(m002Entry?.status, 'active', 'M002 status is active, not pending');
+    } finally {
+      cleanup(base);
+    }
+  }
+
   report();
 }
 

package/src/resources/extensions/gsd/tests/gitignore-tracked-gsd.test.ts

@@ -183,6 +183,28 @@ test("ensureGitignore with tracked .gsd/ does not cause git to see files as dele
   }
 });
 
+test("hasGitTrackedGsdFiles returns true (fail-safe) when git is not available", () => {
+  const dir = makeTempRepo();
+  try {
+    // Create and track .gsd/ files
+    mkdirSync(join(dir, ".gsd"), { recursive: true });
+    writeFileSync(join(dir, ".gsd", "PROJECT.md"), "# Project\n");
+    git(dir, "add", ".gsd/");
+    git(dir, "commit", "-m", "track gsd");
+
+    // Corrupt the git index to simulate git failure
+    const indexPath = join(dir, ".git", "index.lock");
+    writeFileSync(indexPath, "locked");
+
+    // Should fail safe — assume tracked rather than silently returning false
+    // (The index lock causes git ls-files to fail; rev-parse also fails → true)
+    const result = hasGitTrackedGsdFiles(dir);
+    assert.equal(result, true, "Should return true (fail-safe) when git is unavailable");
+  } finally {
+    cleanup(dir);
+  }
+});
+
 // ─── migrateToExternalState — tracked .gsd/ protection ──────────────
 
 test("migrateToExternalState aborts when .gsd/ has tracked files (#1364)", () => {
@@ -212,3 +234,31 @@ test("migrateToExternalState aborts when .gsd/ has tracked files (#1364)", () =>
     cleanup(dir);
   }
 });
+
+test("migrateToExternalState cleans git index so tracked files don't show as deleted (#1364 path 2)", () => {
+  const dir = makeTempRepo();
+  try {
+    // Track .gsd/ files, then untrack them so migration proceeds
+    mkdirSync(join(dir, ".gsd", "milestones", "M001"), { recursive: true });
+    writeFileSync(join(dir, ".gsd", "PROJECT.md"), "# Project\n");
+    writeFileSync(join(dir, ".gsd", "milestones", "M001", "PLAN.md"), "# Plan\n");
+    git(dir, "add", ".gsd/");
+    git(dir, "commit", "-m", "track gsd state");
+    git(dir, "rm", "-r", "--cached", ".gsd/");
+    git(dir, "commit", "-m", "untrack gsd (simulates pre-migration project)");
+
+    const result = migrateToExternalState(dir);
+    assert.equal(result.migrated, true, "Migration should succeed");
+
+    // git status must show NO deleted files after migration
+    const status = git(dir, "status", "--porcelain");
+    const deletions = status.split("\n").filter((l) => /^\s*D\s/.test(l) || /^D\s/.test(l));
+    assert.equal(
+      deletions.length,
+      0,
+      `Expected no deleted files after migration, but found:\n${deletions.join("\n")}`,
+    );
+  } finally {
+    cleanup(dir);
+  }
+});

package/src/resources/extensions/gsd/tests/health-widget.test.ts

@@ -80,66 +80,28 @@ test("buildHealthLines: initialized state shows continue setup copy", () => {
   ]);
 });
 
-test("buildHealthLines: active state leads with execution summary", () => {
-  const lines = buildHealthLines(activeData({
-    executionStatus: "Executing",
-    executionTarget: "Plan S01",
-    progress: {
-      milestones: { done: 0, total: 1 },
-      slices: { done: 0, total: 3 },
-      tasks: { done: 0, total: 5 },
-    },
-  }));
-
-  assert.equal(lines.length, 2);
-  assert.equal(lines[0], "  GSD  Executing - Plan S01");
-  assert.match(lines[1]!, /Progress: M 0\/1 · S 0\/3 · T 0\/5/);
-});
-
-test("buildHealthLines: active state keeps issues secondary", () => {
-  const lines = buildHealthLines(activeData({
-    executionStatus: "Planning",
-    executionTarget: "Execute T03",
-    providerIssue: "✗ Anthropic (Claude) key missing",
-    environmentWarningCount: 1,
-    budgetSpent: 0.42,
-  }));
-
-  assert.equal(lines.length, 2);
-  assert.equal(lines[0], "  GSD  Planning - Execute T03");
-  assert.match(lines[1]!, /✗ Anthropic \(Claude\) key missing/);
-  assert.match(lines[1]!, /Env: 1 warning/);
-  assert.match(lines[1]!, /Spent: 42\.0¢/);
-});
-
-test("buildHealthLines: blocked state explains wait reason", () => {
-  const lines = buildHealthLines(activeData({
-    executionStatus: "Blocked",
-    executionTarget: "waiting on unmet deps: M001",
-    blocker: "M002 is waiting on unmet deps: M001",
-  }));
-
-  assert.equal(lines[0], "  GSD  Blocked - waiting on unmet deps: M001");
+test("buildHealthLines: active state with ledger-driven spend shows spent summary", () => {
+  const lines = buildHealthLines(activeData({ budgetSpent: 0.42 }));
+  assert.equal(lines.length, 1);
+  assert.match(lines[0]!, /● System OK/);
+  assert.match(lines[0]!, /Spent: 42\.0¢/);
 });
 
-test("buildHealthLines: paused state can omit secondary line", () => {
-  const lines = buildHealthLines(activeData({
-    executionStatus: "Paused",
-    executionTarget: "waiting to resume",
-  }));
-
-  assert.deepEqual(lines, ["  GSD  Paused - waiting to resume"]);
+test("buildHealthLines: active state with budget ceiling shows percent summary", () => {
+  const lines = buildHealthLines(activeData({ budgetSpent: 2.5, budgetCeiling: 10 }));
+  assert.equal(lines.length, 1);
+  assert.match(lines[0]!, /Budget: \$2\.50\/\$10\.00 \(25%\)/);
 });
 
-test("buildHealthLines: active state with budget ceiling shows percent summary", () => {
+test("buildHealthLines: active state with issues reports issue summary", () => {
   const lines = buildHealthLines(activeData({
-    executionStatus: "Executing",
-    executionTarget: "Plan S01",
-    budgetSpent: 2.5,
-    budgetCeiling: 10,
+    providerIssue: "✗ OpenAI key missing",
+    environmentErrorCount: 1,
   }));
-  assert.equal(lines.length, 2);
-  assert.match(lines[1]!, /Budget: \$2\.50\/\$10\.00 \(25%\)/);
+  assert.equal(lines.length, 1);
+  assert.match(lines[0]!, /✗ 2 issues/);
+  assert.match(lines[0]!, /✗ OpenAI key missing/);
+  assert.match(lines[0]!, /Env: 1 error/);
 });
 
 test("detectHealthWidgetProjectState: metrics file alone does not imply project", () => {