gsd-pi 2.80.0-dev.fbe7c8c6f → 2.81.0-dev.3cddbbba2

package/dist/resources/extensions/gsd/parallel-monitor-overlay.js

@@ -1,12 +1,5 @@
-/**
- * GSD Parallel Monitor Overlay
- *
- * Full-screen TUI overlay showing real-time parallel worker progress.
- * Opened via `/gsd parallel watch`, Ctrl+Alt+P (⌃⌥P on macOS),
- * or Ctrl+Shift+P fallback.
- * Reads the same data sources as `scripts/parallel-monitor.mjs` but
- * renders as a native pi-tui overlay with theme integration.
- */
+// Project/App: GSD-2
+// File Purpose: Parallel worker monitor overlay with width-safe operations-console rendering.
 import { existsSync, statSync, readFileSync, openSync, readSync, closeSync, readdirSync } from "node:fs";
 import { join } from "node:path";
 import { spawnSync } from "node:child_process";
@@ -14,6 +7,7 @@ import { matchesKey, Key } from "@gsd/pi-tui";
 import { formatDuration } from "../shared/mod.js";
 import { formattedShortcutPair } from "./shortcut-defs.js";
 import { resolveGsdPathContract } from "./paths.js";
+import { renderBar, renderKeyHints, renderProgressBar, safeLine, statusGlyph, } from "./tui/render-kit.js";
 // ─── Data Helpers ─────────────────────────────────────────────────────────
 function readJsonSafe(filePath) {
     try {
@@ -226,17 +220,6 @@ function unitTypeLabel(unitType) {
     };
     return labels[unitType || ""] || (unitType || "---").toUpperCase().slice(0, 5);
 }
-function progressBar(done, total, width) {
-    if (total === 0)
-        return "░".repeat(width);
-    const filled = Math.round((done / total) * width);
-    return "█".repeat(filled) + "░".repeat(width - filled);
-}
-function healthGlyph(alive, heartbeatAge) {
-    if (!alive)
-        return "○";
-    return "●";
-}
 // ─── Overlay Class ────────────────────────────────────────────────────────
 export class ParallelMonitorOverlay {
     tui;
@@ -247,6 +230,7 @@ export class ParallelMonitorOverlay {
     workers = [];
     events = [];
     cachedLines;
+    cachedWidth;
     scrollOffset = 0;
     disposed = false;
     resizeHandler = null;
@@ -279,6 +263,7 @@ export class ParallelMonitorOverlay {
         }
         this.events = this.events.slice(-10);
         this.cachedLines = undefined;
+        this.cachedWidth = undefined;
         this.tui.requestRender();
     }
     dispose() {
@@ -313,13 +298,14 @@ export class ParallelMonitorOverlay {
     }
     invalidate() {
         this.cachedLines = undefined;
+        this.cachedWidth = undefined;
     }
     render(width) {
-        if (this.cachedLines)
+        if (this.cachedLines && this.cachedWidth === width)
             return this.cachedLines;
         const t = this.theme;
         const lines = [];
-        const w = Math.max(width, 60);
+        const w = Math.max(1, width);
         // Header
         const totalCost = this.workers.reduce((s, wk) => s + wk.cost, 0);
         const aliveCount = this.workers.filter((wk) => wk.alive).length;
@@ -328,7 +314,7 @@ export class ParallelMonitorOverlay {
         lines.push(t.fg("muted", `  ${now}  │  ${aliveCount}/${this.workers.length} alive  │  Total: `) +
             t.bold(`$${totalCost.toFixed(2)}`) +
             t.fg("muted", "  │  5s refresh"));
-        lines.push(t.fg("muted", "─".repeat(w)));
+        lines.push(renderBar(t, w));
         if (this.workers.length === 0) {
             lines.push("");
             lines.push(t.fg("warning", "  No parallel workers found."));
@@ -339,7 +325,7 @@ export class ParallelMonitorOverlay {
                 lines.push("");
                 // Health + ID + state
                 const healthColor = wk.alive ? "success" : "error";
-                const glyph = healthGlyph(wk.alive, wk.heartbeatAge);
+                const glyph = statusGlyph(t, wk.alive ? "active" : "idle");
                 const stateText = wk.alive
                     ? t.fg("success", "RUNNING")
                     : t.fg("error", t.bold("DEAD"));
@@ -374,21 +360,25 @@ export class ParallelMonitorOverlay {
                     });
                     lines.push(`     ${t.fg("muted", "slices")}  ${chips.join("  ")}`);
                     // Task progress bar
-                    const bar = progressBar(wk.doneTasks, wk.totalTasks, 25);
+                    const barWidth = Math.max(6, Math.min(25, w - 32));
+                    const bar = renderProgressBar(t, wk.doneTasks, wk.totalTasks, barWidth, {
+                        filledChar: "█",
+                        emptyChar: "░",
+                        emptyColor: "dim",
+                    });
                     const pct = wk.totalTasks > 0 ? Math.round((wk.doneTasks / wk.totalTasks) * 100) : 0;
-                    lines.push(`     ${t.fg("muted", "tasks")}   ${t.fg("success", bar)}  ${wk.doneTasks}/${wk.totalTasks} ` +
+                    lines.push(`     ${t.fg("muted", "tasks")}   ${bar}  ${wk.doneTasks}/${wk.totalTasks} ` +
                         t.fg("muted", `(${pct}%)  │  slices done ${wk.doneSlices}/${wk.totalSlices}`));
                 }
                 // Errors
                 for (const err of wk.errors.slice(-2)) {
-                    const truncated = err.length > w - 10 ? err.slice(0, w - 11) + "…" : err;
-                    lines.push(`     ${t.fg("error", "⚠ " + truncated)}`);
+                    lines.push(`     ${t.fg("error", "! " + err)}`);
                 }
             }
         }
         // Event feed
         lines.push("");
-        lines.push(t.fg("muted", "─".repeat(w)));
+        lines.push(renderBar(t, w));
         lines.push(`  ${t.bold("Recent Events")}`);
         if (this.events.length === 0) {
             lines.push(t.fg("muted", "  No events yet..."));
@@ -396,8 +386,7 @@ export class ParallelMonitorOverlay {
         else {
             for (const evt of this.events.slice(-8)) {
                 const mid = evt.match(/^✓ (M\d+)\//)?.[1] || "";
-                const truncated = evt.length > w - 10 ? evt.slice(0, w - 11) + "…" : evt;
-                lines.push(`  ${t.fg("muted", "│")} ${t.fg("accent", mid)} ${truncated.replace(/^✓ M\d+\//, "")}`);
+                lines.push(`  ${t.fg("muted", "│")} ${t.fg("accent", mid)} ${evt.replace(/^✓ M\d+\//, "")}`);
             }
         }
         // Footer
@@ -411,13 +400,16 @@ export class ParallelMonitorOverlay {
             }
             lines.push(`  ${t.bold("Total: $" + this.workers.reduce((s, wk) => s + wk.cost, 0).toFixed(2))}`);
         }
-        lines.push(t.fg("muted", `  ESC/q/${formattedShortcutPair("parallel")} close  │  ↑↓ scroll`));
+        lines.push(renderKeyHints(t, [`ESC/q/${formattedShortcutPair("parallel")} close`, "↑↓ scroll"], w));
         // Apply scroll — use terminal rows as height estimate
         const termHeight = process.stdout.rows || 40;
         const maxScroll = Math.max(0, lines.length - termHeight);
         this.scrollOffset = Math.min(Math.max(this.scrollOffset, 0), maxScroll);
-        const visible = lines.slice(this.scrollOffset, this.scrollOffset + termHeight);
+        const visible = lines
+            .slice(this.scrollOffset, this.scrollOffset + termHeight)
+            .map((line) => safeLine(line, w));
         this.cachedLines = visible;
+        this.cachedWidth = width;
         return visible;
     }
 }

package/dist/resources/extensions/gsd/parallel-orchestrator.js

@@ -12,7 +12,7 @@ import { join, dirname } from "node:path";
 import { fileURLToPath } from "node:url";
 import { gsdRoot } from "./paths.js";
 import { createWorktree, worktreePath } from "./worktree-manager.js";
-import { autoWorktreeBranch, runWorktreePostCreateHook, syncGsdStateToWorktree } from "./auto-worktree.js";
+import { autoWorktreeBranch, fastForwardReusedMilestoneBranchIfSafe, runWorktreePostCreateHook, syncGsdStateToWorktree } from "./auto-worktree.js";
 import { nativeBranchExists } from "./native-git-bridge.js";
 import { readIntegrationBranch } from "./git-service.js";
 import { resolveParallelConfig } from "./preferences.js";
@@ -368,7 +368,7 @@ export async function startParallel(basePath, milestoneIds, prefs) {
             // Create the worktree (without chdir — coordinator stays in project root)
             let wtPath;
             try {
-                wtPath = createMilestoneWorktree(basePath, mid);
+                wtPath = _createMilestoneWorktree(basePath, mid);
             }
             catch (e) {
                 logWarning("parallel", `createMilestoneWorktree fallback for ${mid}: ${e.message}`);
@@ -421,12 +421,22 @@ export async function startParallel(basePath, milestoneIds, prefs) {
 /**
  * Create a git worktree for a milestone without changing the coordinator's cwd.
  * Uses milestone/<MID> branch naming (same as auto-worktree.ts).
+ *
+ * Exported with the `_` prefix purely for tests — production callers stay on
+ * the closure-private name `createMilestoneWorktree` below.
  */
-function createMilestoneWorktree(basePath, milestoneId) {
+export function _createMilestoneWorktree(basePath, milestoneId) {
     const branch = autoWorktreeBranch(milestoneId);
     const branchExists = nativeBranchExists(basePath, branch);
     let info;
     if (branchExists) {
+        // #5549 post-merge audit (R3): match the fast-forward behavior added to
+        // `createAutoWorktree` in commit 8996cb68e. When a worker reuses an
+        // existing milestone branch, fast-forward it onto the integration branch
+        // when safe so per-worker worktrees don't fork from a stale base after a
+        // sibling milestone has merged. Same `nativeIsAncestor` + worktree-list
+        // safety guards apply.
+        fastForwardReusedMilestoneBranchIfSafe(basePath, milestoneId, branch);
         info = createWorktree(basePath, milestoneId, { branch, reuseExistingBranch: true });
     }
     else {

package/dist/resources/extensions/gsd/planning-path-scope.js

@@ -0,0 +1,26 @@
+import { isAbsolute, relative, resolve } from "node:path";
+import { normalizePlannedFileReference } from "./files.js";
+function isInsideBase(basePath, candidate) {
+    const base = resolve(basePath);
+    const abs = resolve(candidate);
+    const rel = relative(base, abs);
+    return rel === "" || (!!rel && !rel.startsWith("..") && !isAbsolute(rel));
+}
+/**
+ * Planning IO fields are execution contracts. Absolute paths are only safe when
+ * they stay inside the active working directory; in worktree mode, an absolute
+ * path to the original checkout makes executors edit the wrong tree.
+ */
+export function validatePlanningPathScope(basePath, fields) {
+    for (const { field, values } of fields) {
+        for (const raw of values) {
+            const candidate = normalizePlannedFileReference(raw);
+            if (!isAbsolute(candidate))
+                continue;
+            if (isInsideBase(basePath, candidate))
+                continue;
+            return `${field} contains absolute path outside working directory: ${candidate}. Use a path relative to ${basePath}.`;
+        }
+    }
+    return null;
+}

package/dist/resources/extensions/gsd/pre-execution-checks.js

@@ -328,6 +328,8 @@ function shouldValidateInputAsPath(raw) {
     const trimmed = raw.trim();
     if (!trimmed)
         return false;
+    if (isRuntimeOnlyInput(trimmed))
+        return false;
     const candidate = extractPathFromAnnotation(trimmed);
     if (!candidate)
         return false;
@@ -349,6 +351,9 @@ function shouldValidateInputAsPath(raw) {
         /[\\/]/.test(candidate) ||
         /[*?[\]{}]/.test(candidate));
 }
+function isRuntimeOnlyInput(raw) {
+    return /\(\s*runtime\s*\)/i.test(raw);
+}
 function containsGlobPattern(candidate) {
     return ["*", "?", "[", "]", "{", "}"].some((char) => candidate.includes(char));
 }
@@ -386,6 +391,15 @@ function getExpectedOutputsUpTo(tasks, taskIndex) {
  */
 export function checkFilePathConsistency(tasks, basePath) {
     const results = [];
+    // Build a set of all files created by any task at any position (normalized).
+    // Used to suppress consistency errors for files that will be caught with a
+    // more precise message by checkTaskOrdering (sequence violation).
+    const allTaskOutputs = new Set();
+    for (const t of tasks) {
+        for (const f of t.expected_output) {
+            allTaskOutputs.add(normalizeFilePath(f));
+        }
+    }
     for (let i = 0; i < tasks.length; i++) {
         const task = tasks[i];
         const priorOutputs = getExpectedOutputsUpTo(tasks, i);
@@ -416,6 +430,12 @@ export function checkFilePathConsistency(tasks, basePath) {
                         anyOutputUnderDirectory(normalizedFile, ownOutputs);
             }
             if (!existsOnDisk && !inPriorOutputs && !inOwnOutputs && !directorySatisfied) {
+                // If a later task claims to create this file, the ordering check will
+                // fire a more precise "sequence violation" error for the same file.
+                // Suppress the consistency error here to avoid duplicate noise.
+                if (allTaskOutputs.has(normalizedFile) && !ownOutputs.has(normalizedFile)) {
+                    continue;
+                }
                 results.push({
                     category: "file",
                     target: file,
@@ -461,6 +481,8 @@ export function checkTaskOrdering(tasks, basePath) {
         const task = tasks[i];
         const filesToCheck = [...task.inputs];
         for (const file of filesToCheck) {
+            if (isRuntimeOnlyInput(file))
+                continue;
             if (!shouldValidateInputAsPath(file))
                 continue;
             const normalizedFile = normalizeFilePath(file);

package/dist/resources/extensions/gsd/prompt-loader.js

@@ -111,15 +111,41 @@ function warmCache() {
     }
 }
 let warmCacheScheduled = false;
+let warmCacheRan = false;
+let warmCacheTimer;
+/**
+ * Synchronously snapshot the prompt/template tree into the cache.
+ *
+ * Safe to call immediately after `initResources()` because that function uses
+ * synchronous fs APIs — there is no race window that requires deferring the
+ * cache warm via setTimeout. Idempotent: subsequent calls are no-ops.
+ *
+ * Cancels the fallback `scheduleWarmCache` timer if it is still pending.
+ */
+export function primeCache() {
+    if (warmCacheRan)
+        return;
+    if (warmCacheTimer) {
+        clearTimeout(warmCacheTimer);
+        warmCacheTimer = undefined;
+    }
+    warmCacheScheduled = true;
+    warmCacheRan = true;
+    warmCache();
+}
 function scheduleWarmCache() {
     if (warmCacheScheduled)
         return;
     warmCacheScheduled = true;
     const run = () => {
+        warmCacheTimer = undefined;
+        if (warmCacheRan)
+            return;
+        warmCacheRan = true;
         warmCache();
     };
-    const timer = setTimeout(run, 1000);
-    timer.unref?.();
+    warmCacheTimer = setTimeout(run, 1000);
+    warmCacheTimer.unref?.();
 }
 // Snapshot the full prompt/template tree after import so extension startup only
 // pays for prompts that are actually needed immediately.

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

@@ -6,6 +6,8 @@ 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.
 
+If any inlined plan, summary, verification command, or prior artifact names an absolute path outside `{{workingDirectory}}`, treat that path as stale context. Convert it to the equivalent relative path under `{{workingDirectory}}` before reading, writing, or executing. If no equivalent path exists under `{{workingDirectory}}`, record a verification failure and stop; do not edit or run commands in another checkout.
+
 ## Mission
 
 All slices are complete. Verify the integrated work, persist milestone completion, refresh project state, and write the final record future milestones will rely on.
@@ -14,7 +16,7 @@ Preloaded context includes roadmap, requirements, decisions, project context, an
 
 Start with what the excerpts give you. Read full files when the section heads signal richer context you need.
 
-**On-demand Read ordering:** Complete all slice SUMMARY Reads you need for cross-slice synthesis, the Decision Re-evaluation table, and LEARNINGS **before** calling `gsd_complete_milestone` (step 12). Once that tool runs, the milestone is marked complete in the DB, so it must be the final persistent milestone-closeout write.
+**On-demand Read ordering:** Complete all slice SUMMARY Reads you need for cross-slice synthesis, the Decision Re-evaluation table, and LEARNINGS **before** calling `gsd_complete_milestone` (step 13). Once that tool runs, the milestone is marked complete in the DB, so it must be the final persistent milestone-closeout write.
 
 ### Closeout Review Mode
 
@@ -29,20 +31,21 @@ Subagents report only; they do not write user source. Fold any findings into Dec
 
 ## Steps
 
-1. Use the **Milestone Summary** output template from the inlined context above
-2. {{skillActivation}}
-3. **Verify code changes exist.** Compare milestone work against the integration branch (`main`, `master`, or recorded branch), using merge-base as older revision and `HEAD` as newer. If the diff lists non-`.gsd/` files, pass. If `HEAD` equals the integration branch/merge-base, treat it as a self-diff retry: inspect milestone-scoped commit evidence (`GSD-Unit: {{milestoneId}}` or production `GSD-Task: Sxx/Tyy` trailers touching `.gsd/milestones/{{milestoneId}}/`) and verify those commits touched non-`.gsd/` files. Record **verification failure** only when neither source shows implementation files.
-4. Verify every **success criterion** from `{{roadmapPath}}`. If passing validation is present, summarize the validation evidence instead of re-auditing it; otherwise verify with evidence from summaries, tests, or observable behavior. Record unmet criteria as **verification failure**.
-5. Verify **definition of done**: all slices `[x]`, summaries exist, and integrations work. If passing validation is present, trust its integration/verification verdict unless inconsistent with current artifacts. Record unmet items as **verification failure**.
-6. If the roadmap includes a **Horizontal Checklist**, verify each item and note unchecked items in the summary.
-7. Fill the **Decision Re-evaluation** table: compare each key `.gsd/DECISIONS.md` decision from this milestone with what shipped, and flag decisions to revisit.
-8. Validate **requirement status transitions**. For each changed requirement, confirm evidence supports the new status. Requirements may move between Active, Validated, Deferred, Blocked, or Out of Scope only with proof.
+1. **Duplicate completion guard:** Call `gsd_milestone_status` for `{{milestoneId}}` before any durable writes. If the returned milestone **status is `complete`**, this is a stale or duplicate closeout turn: do NOT mutate requirements, do NOT refresh the project document, do NOT write LEARNINGS, and do NOT persist milestone completion again. Say: "Milestone {{milestoneId}} is already complete." and stop.
+2. Use the **Milestone Summary** output template from the inlined context above
+3. {{skillActivation}}
+4. **Verify code changes exist.** Compare milestone work against the integration branch (`main`, `master`, or recorded branch), using merge-base as older revision and `HEAD` as newer. If the diff lists non-`.gsd/` files, pass. If `HEAD` equals the integration branch/merge-base, treat it as a self-diff retry: inspect milestone-scoped commit evidence (`GSD-Unit: {{milestoneId}}` or production `GSD-Task: Sxx/Tyy` trailers touching `.gsd/milestones/{{milestoneId}}/`) and verify those commits touched non-`.gsd/` files. Record **verification failure** only when neither source shows implementation files.
+5. Verify every **success criterion** from `{{roadmapPath}}`. If passing validation is present, summarize the validation evidence instead of re-auditing it; otherwise verify with evidence from summaries, tests, or observable behavior. Record unmet criteria as **verification failure**.
+6. Verify **definition of done**: all slices `[x]`, summaries exist, and integrations work. If passing validation is present, trust its integration/verification verdict unless inconsistent with current artifacts. Record unmet items as **verification failure**.
+7. If the roadmap includes a **Horizontal Checklist**, verify each item and note unchecked items in the summary.
+8. Fill the **Decision Re-evaluation** table: compare each key `.gsd/DECISIONS.md` decision from this milestone with what shipped, and flag decisions to revisit.
+9. Validate **requirement status transitions**. For each changed requirement, confirm evidence supports the new status. Requirements may move between Active, Validated, Deferred, Blocked, or Out of Scope only with proof.
 
 **DB access safety:** Do NOT query `.gsd/gsd.db` directly via `sqlite3` or `node -e require('better-sqlite3')`; the engine owns the WAL connection. Use `gsd_milestone_status`, inlined context, or `gsd_*` tools; never direct SQL.
 
 ### Verification Gate — STOP if verification failed
 
-**If ANY verification failure was recorded in steps 3, 4, or 5, you MUST follow the failure path below. Do NOT proceed with steps 9–13.**
+**If ANY verification failure was recorded in steps 4, 5, or 6, you MUST follow the failure path below. Do NOT proceed with steps 10–14.**
 
 **Failure path** (verification failed):
 - Do NOT call `gsd_complete_milestone`.
@@ -53,34 +56,36 @@ Subagents report only; they do not write user source. Fold any findings into Dec
 
 **Success path** (all verifications passed):
 
-9. For each requirement whose status changed in step 8, call `gsd_requirement_update` with the requirement ID and updated `status` and `validation` fields — the tool regenerates `.gsd/REQUIREMENTS.md` automatically. Do this BEFORE completing the milestone so requirement updates are persisted.
-10. Update `.gsd/PROJECT.md`: use the `write` tool with `path: ".gsd/PROJECT.md"` and `content` containing the full updated document reflecting milestone completion and current project state. Do NOT use the `edit` tool for this — PROJECT.md is a full-document refresh.
-11. Extract structured learnings from this milestone and persist them to the GSD memory store. Follow the procedure block immediately below — it writes `{{milestoneId}}-LEARNINGS.md` as the audit trail and persists Patterns, Lessons, and Decisions via `capture_thought` (categories: pattern, gotcha/convention, architecture). The memory store is the single source of truth for cross-session durable knowledge (ADR-013).
+10. For each requirement whose status changed in step 9, call `gsd_requirement_update` with the requirement ID and updated `status` and `validation` fields — the tool regenerates `.gsd/REQUIREMENTS.md` automatically. Do this BEFORE completing the milestone so requirement updates are persisted.
+11. Update `.gsd/PROJECT.md`: use the `write` tool with `path: ".gsd/PROJECT.md"` and `content` containing the full updated document reflecting milestone completion and current project state. Do NOT use the `edit` tool for this — PROJECT.md is a full-document refresh.
+12. Extract structured learnings from this milestone and persist them to the GSD memory store. Follow the procedure block immediately below — it writes `{{milestoneId}}-LEARNINGS.md` as the audit trail and persists Patterns, Lessons, and Decisions via `capture_thought` (categories: pattern, gotcha/convention, architecture). The memory store is the single source of truth for cross-session durable knowledge (ADR-013).
 
 {{extractLearningsSteps}}
 
-12. **Persist completion through `gsd_complete_milestone`.** Call it with the parameters below. This must be the final persistent write in the unit. The tool updates the milestone status in the DB, renders `{{milestoneSummaryPath}}`, and validates all slices are complete.
+13. **Persist completion through `gsd_complete_milestone`.** Call it with the parameters below. This must be the final persistent write in the unit. The tool updates the milestone status in the DB, renders `{{milestoneSummaryPath}}`, and validates all slices are complete.
 
    **Required parameters:**
    - `milestoneId` (string) — Milestone ID (e.g. M001)
    - `title` (string) — Milestone title
    - `oneLiner` (string) — One-sentence summary of what the milestone achieved
    - `narrative` (string) — Detailed narrative of what happened during the milestone
+   - `verificationPassed` (boolean) — Must be `true`; confirms code-change verification, success criteria, and definition-of-done checks all passed
+
+   **Recommended parameters** (the schema accepts these as optional, but always fill them in — omitted values render as placeholders such as "Not provided.", "None.", or "(none)"):
    - `successCriteriaResults` (string) — Markdown detailing how each success criterion was met or not met
    - `definitionOfDoneResults` (string) — Markdown detailing how each definition-of-done item was met
    - `requirementOutcomes` (string) — Markdown detailing requirement status transitions with evidence
    - `keyDecisions` (array of strings) — Key architectural/pattern decisions made during the milestone
    - `keyFiles` (array of strings) — Key files created or modified during the milestone
    - `lessonsLearned` (array of strings) — Lessons learned during the milestone
-   - `verificationPassed` (boolean) — Must be `true`; confirms code-change verification, success criteria, and definition-of-done checks all passed
 
    **Optional parameters:**
    - `followUps` (string) — Follow-up items for future milestones
    - `deviations` (string) — Deviations from the original plan
 
-13. Do not commit manually — the system auto-commits your changes after this unit completes.
+14. Do not commit manually — the system auto-commits your changes after this unit completes.
 - Say: "Milestone {{milestoneId}} complete."
 
-**Important:** Do NOT skip code-change, success-criteria, or definition-of-done verification (steps 3-5). The summary must reflect verified outcomes. Verification failures block completion; there is no override. If a verification tool fails, errors, or returns unexpected output, treat it as failure.
+**Important:** Do NOT skip code-change, success-criteria, or definition-of-done verification (steps 4-6). The summary must reflect verified outcomes. Verification failures block completion; there is no override. If a verification tool fails, errors, or returns unexpected output, treat it as failure.
 
 **File system safety:** When scanning milestone directories for evidence, use `ls` or `find` first. Never pass a directory path (e.g. `tasks/`, `slices/`) to `read`; it only accepts file paths.

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

@@ -22,22 +22,24 @@ Use `subagent` only for fresh-context review when useful: reviewer for cross-cut
 
 1. Use the inlined Slice Summary and UAT templates.
 2. {{skillActivation}}
-3. Run all slice-level verification checks from the slice plan. Fix failures before marking done; refresh current state if needed.
-4. Task summaries use a flat file layout under `tasks/` such as `T01-SUMMARY.md`, not inside per-task subdirectories like `tasks/T01/SUMMARY.md`. Never use `tasks/*/SUMMARY.md`.
-5. If observability/diagnostics were planned, verify them unless the slice is simple.
-6. Address every gate in Gates to Close. Q8 maps to **Operational Readiness**: health signal, failure signal, recovery procedure, monitoring gaps. Empty sections are recorded as omitted.
-7. If requirement status changed, call `gsd_requirement_update`; do not write `.gsd/REQUIREMENTS.md` directly.
-8. Prepare `gsd_slice_complete` content with camelCase fields `milestoneId`, `sliceId`, `sliceTitle`, `oneLiner`, `narrative`, `verification`, and `uatContent`.
-9. Draft concrete UAT with preconditions, numbered steps, expected outcomes, edge cases, UAT Type, and Not Proven By This UAT.
-10. Review task summaries for DECISIONS.md and KNOWLEDGE.md-worthy decisions, patterns, and gotchas. Capture significant items with `capture_thought`; do not append knowledge files directly.
-11. Call `gsd_slice_complete`. The DB-backed tool is the canonical write path. Do **not** manually write `{{sliceSummaryPath}}`. Do **not** manually write `{{sliceUatPath}}`. Do not edit roadmap checkboxes; the tool renders files and updates projections.
-12. Do not run git commands.
-13. Update `.gsd/PROJECT.md` with a full `write` only if the current project state needs refresh.
+3. Run all slice-level verification checks from the slice plan through the closeout-safe verification surface (`gsd_exec` / Context Mode verification evidence); refresh current state if needed. Do not use direct `bash` for verification commands.
+4. Complete the slice only when every required verification check passes. If verification fails or the fix requires source changes, do **not** edit source files in this unit and do **not** call `gsd_slice_complete`.
+5. For task-specific failures, call `gsd_task_reopen` with the failing completed task and a concrete reason so execution can redo the work. For plan-invalidating failures, call `gsd_replan_slice` with the blocker and updated execution tasks. Then stop with: "Slice {{sliceId}} needs execution follow-up."
+6. Task summaries use a flat file layout under `tasks/` such as `T01-SUMMARY.md`, not inside per-task subdirectories like `tasks/T01/SUMMARY.md`. Never use `tasks/*/SUMMARY.md`.
+7. If observability/diagnostics were planned, verify them unless the slice is simple.
+8. Address every gate in Gates to Close. Q8 maps to **Operational Readiness**: health signal, failure signal, recovery procedure, monitoring gaps. Empty sections are recorded as omitted.
+9. If requirement status changed, call `gsd_requirement_update`; do not write `.gsd/REQUIREMENTS.md` directly.
+10. Prepare `gsd_slice_complete` content with camelCase fields `milestoneId`, `sliceId`, `sliceTitle`, `oneLiner`, `narrative`, `verification`, and `uatContent`.
+11. Draft concrete UAT with preconditions, numbered steps, expected outcomes, edge cases, UAT Type, and Not Proven By This UAT.
+12. Review the inlined task-summary excerpts for DECISIONS.md and KNOWLEDGE.md-worthy decisions, patterns, and gotchas. Read full `*-SUMMARY.md` files only when an excerpt is absent, truncated, or lacks the specific evidence needed for the slice narrative. Capture significant items with `capture_thought`; do not append knowledge files directly.
+13. When verification passes, call `gsd_slice_complete`. The DB-backed tool is the canonical write path. Do **not** manually write `{{sliceSummaryPath}}`. Do **not** manually write `{{sliceUatPath}}`. Do not edit roadmap checkboxes; the tool renders files and updates projections.
+14. Do not run git commands.
+15. Update `.gsd/PROJECT.md` with a full `write` only if the current project state needs refresh.
 
 **Autonomous execution:** no human is available. Do not call `ask_user_questions` or `secure_env_collect`; make reasonable assumptions and document them.
 
 **File system safety:** if re-reading task summaries, use `find .gsd/milestones/{{milestoneId}}/slices/{{sliceId}}/tasks -name "*-SUMMARY.md"` or `ls .gsd/milestones/{{milestoneId}}/slices/{{sliceId}}/tasks/*-SUMMARY.md`. Never pass `{{slicePath}}` or any directory path directly to the `read` tool.
 
-**You MUST call `gsd_slice_complete` with summary and UAT content before finishing.**
+**You MUST call `gsd_slice_complete` with summary and UAT content before finishing only after verification passes.**
 
 When done, say: "Slice {{sliceId}} complete."

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

@@ -129,7 +129,16 @@ If ANY box is unchecked, **STOP**. Do NOT emit the ready phrase. Emit the missin
 
 Do not announce the ready phrase as something you are "about to" do. The ready phrase is a post-write signal, not an intent signal.
 
-After completing steps 1–7 above, say exactly: "Milestone {{milestoneId}} ready." — nothing else. Auto-mode will start automatically.
+After completing steps 1–7 above, end with this concise user-facing handoff:
+
+```
+Milestone {{milestoneId}} ready.
+
+Next steps:
+- Run `/gsd auto` to start execution if it does not begin automatically.
+- Use `/gsd status` or `/gsd visualize` to inspect the roadmap.
+- Use `/gsd notifications` to review or configure delivery alerts.
+```
 
 ### Multi-Milestone
 
@@ -215,7 +224,16 @@ If ANY box is unchecked, **STOP**. Do NOT emit the ready phrase. Emit the missin
 
 Do not announce the ready phrase as something you are "about to" do. The ready phrase is a post-write signal, not an intent signal.
 
-After completing every step above, say exactly: "Milestone {{milestoneId}} ready." — nothing else. Auto-mode will start automatically.
+After completing every step above, end with this concise user-facing handoff:
+
+```
+Milestone {{milestoneId}} ready.
+
+Next steps:
+- Run `/gsd auto` to start execution if it does not begin automatically.
+- Use `/gsd status` or `/gsd visualize` to inspect the roadmap.
+- Use `/gsd notifications` to review or configure delivery alerts.
+```
 
 ## Critical Rules
 

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

@@ -252,7 +252,16 @@ If ANY box is unchecked, **STOP**. Do NOT emit the ready phrase. Emit the missin
 
 Do not announce the ready phrase as something you are "about to" do. It is a post-write signal, not intent.
 
-After completing steps 1–7 above, say exactly: "Milestone {{milestoneId}} ready." — nothing else. Auto-mode will start automatically.
+After completing steps 1–7 above, end with this concise user-facing handoff:
+
+```
+Milestone {{milestoneId}} ready.
+
+Next steps:
+- Run `/gsd auto` to start execution if it does not begin automatically.
+- Use `/gsd status` or `/gsd visualize` to inspect the roadmap.
+- Use `/gsd notifications` to review or configure delivery alerts.
+```
 
 ### Multi-Milestone
 
@@ -345,6 +354,15 @@ If ANY box is unchecked, **STOP**. Do NOT emit the ready phrase. Emit the missin
 
 Do not announce the ready phrase as something you are "about to" do. It is a post-write signal, not intent.
 
-After completing all phases above, say exactly: "Milestone M001 ready." — nothing else. Auto-mode will start automatically.
+After completing all phases above, end with this concise user-facing handoff:
+
+```
+Milestone M001 ready.
+
+Next steps:
+- Run `/gsd auto` to start execution if it does not begin automatically.
+- Use `/gsd status` or `/gsd visualize` to inspect the roadmap.
+- Use `/gsd notifications` to review or configure delivery alerts.
+```
 
 {{inlinedTemplates}}

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

@@ -33,7 +33,7 @@ You execute. The inlined task plan is authoritative. Verify referenced files and
 ## Execution Rules
 
 1. Tersely narrate transitions, decisions, and verification outcomes between tool-call clusters.
-2. Call `memory_query` with 2-4 keywords from the task title and touched files unless this is purely mechanical.
+2. Use the injected memory/context blocks first. Call `memory_query` with 2-4 keywords from the task title and touched files only when no injected memory block exists or the inlined memory/context is insufficient for this task.
 3. {{skillActivation}} Follow activated skills before code edits.
 4. Execute the task plan. Before any `Write` that creates an artifact or output file, check whether that path already exists. If it does, read it first and decide whether the work is already done, should be extended, or truly needs replacement.
 5. Build real behavior through the intended surface; stubs/mocks belong in tests only.
@@ -59,11 +59,13 @@ Keep about **{{verificationBudget}}** for verification and summary. If context i
 - If the plan is fundamentally invalid, set `blocker_discovered: true` in the summary and explain.
 - For downstream-impacting ambiguity that cannot be resolved from code, plans, or decisions, include an `escalation` object with question, options, recommendation, rationale, and `continueWithDefault`.
 - Capture meaningful architecture/pattern/observability decisions with `capture_thought`; capture non-obvious gotchas or conventions only when they save future investigation.
-- Read the template at `{{taskSummaryTemplatePath}}`.
+- Use the inlined Task Summary template below. Read `{{taskSummaryTemplatePath}}` only if the inlined template is absent or visibly truncated.
 - Call `gsd_task_complete` with camelCase fields `milestoneId`, `sliceId`, `taskId`, `oneLiner`, `narrative`, `verification`, and `verificationEvidence`.
 - The DB-backed tool is the canonical write path. Do **not** manually write `{{taskSummaryPath}}` or edit PLAN.md checkboxes; the tool renders the summary and updates state.
 - Do not run git commands; the system commits from your summary.
 
+{{inlinedTemplates}}
+
 **Autonomous execution:** no human is available. Do not call `ask_user_questions` or `secure_env_collect`; make reasonable assumptions and document them.
 
 **You MUST call `gsd_task_complete` before finishing.**

package/dist/resources/extensions/gsd/prompts/parallel-research-slices.md

@@ -16,7 +16,7 @@ Dispatch ALL slices simultaneously using the `subagent` tool in **parallel mode*
 
 1. Call `subagent` with `tasks: [...]` containing one entry per slice below
 2. Wait for ALL subagents to complete
-3. Verify each slice's RESEARCH file was written (check the `.gsd/{{mid}}/` directory)
+3. Verify each slice's RESEARCH file was written (check `.gsd/milestones/{{mid}}/slices/<slice-id>/`)
 4. If a subagent failed to write its RESEARCH file, retry it **once** individually
 5. If it fails a second time, write a partial RESEARCH file for that slice with a `## BLOCKER` section explaining the failure — do NOT retry again
 6. Report which slices completed research and which (if any) needed a blocker note

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

@@ -39,7 +39,7 @@ If slice research is inlined, trust it. Explore enough code to confirm paths, bo
 5. Define slice verification before tasks. Non-trivial slices need real tests or executable assertions; boundary contracts need contract-exercising checks. Tests must not read .gitignore/gitignored paths such as `.gsd/`, `.planning/`, or `.audits/`.
 6. Include Threat Surface (Q3), Requirement Impact (Q4), proof level, observability, integration closure, Failure Modes (Q5), Load Profile (Q6), and Negative Tests (Q7) only where applicable.
 7. Right-size tasks. Simple slices can be one task; split only when context, ownership, or verification boundaries justify it.
-8. Each task needs a concrete title, Why / Files / Do / Verify / Done when, plus task-plan description, steps, must-haves, verification, inputs, and expected output. Inputs and Expected Output must include concrete backtick-wrapped paths; each task needs at least one output path.
+8. Each task needs a concrete title, Why / Files / Do / Verify / Done when, plus task-plan description, steps, must-haves, verification, inputs, and expected output. Inputs and Expected Output must include concrete backtick-wrapped paths. Use paths relative to `{{workingDirectory}}`; do not put absolute paths to the original checkout or any directory outside `{{workingDirectory}}` in `files`, `inputs`, `expectedOutput`, or verification commands. **`expected_output` must only list files the task actually creates or overwrites on disk.** Do NOT include files the task merely reads, verifies, or tests — those belong only in `inputs`. If a task is a pure verification or test task that produces no new files, its `expected_output` may be empty or limited to test-result artifacts (e.g. a log or assertion output). A file that does not yet exist on disk and is needed as an `input` must be produced by an earlier task's `expected_output` — if no prior task creates it, add a task before this one that does.
 9. Persist with `gsd_plan_slice` using goal, successCriteria, optional proofLevel/integrationClosure/observabilityImpact, and tasks. `gsd_plan_slice` handles task persistence transactionally and renders `{{outputPath}}` plus task plans; do not call `gsd_plan_task`. The DB-backed tool is the canonical write path. Do **not** rely on direct `PLAN.md` writes as the source of truth.
 10. Self-audit before finishing: goal/demo closure, requirement coverage, locked decisions, concrete paths, dependency order, wiring, scope size, proof truthfulness, feature completeness, and quality gates. Quality gates: non-trivial slices/tasks include specific Q3-Q7 coverage where applicable.
 11. If planning creates structural decisions, append them to `.gsd/DECISIONS.md`.

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

@@ -17,11 +17,7 @@ You are executing a GSD quick task — a lightweight, focused unit of work outsi
 5. Verify your work:
    - Run tests if applicable.
    - Verify both happy path and failure modes for non-trivial changes.
-6. Commit your changes atomically:
-   - Use conventional commit messages (feat:, fix:, refactor:, etc.)
-   - Stage only relevant files — never commit secrets or runtime files.
-   - Commit logical units separately if the task involves distinct changes.
-   - Quick tasks run outside the auto-mode lifecycle — there is no system auto-commit, so commit directly here.
+6. {{commitInstruction}}
 7. Write a brief summary to `{{summaryPath}}`:
    - Quick tasks operate outside the milestone/slice/task DB structure, so `gsd_summary_save` (which requires a `milestone_id`) cannot be used here. Write the file directly.
 

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

@@ -8,7 +8,7 @@ Your working directory is `{{workingDirectory}}`. All file reads, writes, and sh
 
 A completed task reported `blocker_discovered: true`, meaning the current slice plan cannot be executed as-is. Your job is to rewrite the remaining tasks in the slice plan to address the blocker while preserving all completed work.
 
-All relevant context has been preloaded below — the roadmap, current slice plan, the blocker task summary, and decisions are inlined. Start working immediately without re-reading these files.
+All relevant context has been preloaded below — the roadmap, current slice plan, blocker task summary excerpt, and decisions are inlined. Start working immediately without re-reading these files.
 
 {{inlinedContext}}
 
@@ -30,7 +30,7 @@ Consider these captures when rewriting the remaining tasks — they represent th
 
 ## Instructions
 
-1. Read the blocker task summary carefully. Understand exactly what was discovered and why it blocks the current plan.
+1. Use the inlined blocker summary excerpt first. Read the full blocker task summary only if the excerpt is absent, marked truncated, or lacks the specific blocker evidence needed to replan.
 2. Analyze the remaining `[ ]` tasks in the slice plan. Determine which are still valid, which need modification, and which should be replaced.
 3. **Persist replan state through `gsd_replan_slice`.** Call it with: `milestoneId`, `sliceId`, `blockerTaskId`, `blockerDescription`, `whatChanged`, `updatedTasks` (array of task objects with taskId, title, description, estimate, files, verify, inputs, expectedOutput), `removedTaskIds` (array of task ID strings). The tool structurally enforces preservation of completed tasks, writes replan history to the DB, re-renders `{{planPath}}`, and renders `{{replanPath}}`. Preserve or update the Threat Surface and Requirement Impact sections if the replan changes the slice's security posture or requirement coverage.
 4. If any incomplete task had a `T0x-PLAN.md`, remove or rewrite it to match the new task description.