gsd-pi 2.71.0 → 2.72.0-dev.de4c4b3

package/dist/resources/extensions/gsd/notification-store.js

@@ -9,16 +9,23 @@ import { randomUUID } from "node:crypto";
 const MAX_ENTRIES = 500;
 const FILENAME = "notifications.jsonl";
 const LOCKFILE = "notifications.lock";
+const DEDUP_WINDOW_MS = 30_000;
+const DEDUP_PRUNE_THRESHOLD = 200;
 // ─── Module State ───────────────────────────────────────────────────────
 let _basePath = null;
 let _lineCount = 0; // Hint for rotation — not authoritative for public API
 let _suppressCount = 0;
+let _recentMessageTimestamps = new Map();
+const _changeListeners = new Set();
 // ─── Public API ─────────────────────────────────────────────────────────
 /**
  * Initialize the notification store. Call once at session start with the
  * project root. Seeds in-memory counters from the existing file on disk.
  */
 export function initNotificationStore(basePath) {
+    if (_basePath !== basePath) {
+        _recentMessageTimestamps.clear();
+    }
     _basePath = basePath;
     // Seed line count hint for rotation — public counters read from disk
     _lineCount = _readEntriesFromDisk(basePath).length;
@@ -32,11 +39,24 @@ export function appendNotification(message, severity, source = "notify") {
         return;
     if (_suppressCount > 0)
         return;
+    const persistedMessage = message.length > 500 ? message.slice(0, 500) + "…" : message;
+    const dedupKey = `${_basePath}:${severity}:${source}:${persistedMessage}`;
+    const now = Date.now();
+    const lastSeen = _recentMessageTimestamps.get(dedupKey);
+    if (lastSeen !== undefined && now - lastSeen < DEDUP_WINDOW_MS)
+        return;
+    _recentMessageTimestamps.set(dedupKey, now);
+    if (_recentMessageTimestamps.size > DEDUP_PRUNE_THRESHOLD) {
+        for (const [key, ts] of _recentMessageTimestamps) {
+            if (now - ts > DEDUP_WINDOW_MS)
+                _recentMessageTimestamps.delete(key);
+        }
+    }
     const entry = {
         id: randomUUID(),
         ts: new Date().toISOString(),
         severity,
-        message: message.length > 500 ? message.slice(0, 500) + "…" : message,
+        message: persistedMessage,
         source,
         read: false,
     };
@@ -49,6 +69,7 @@ export function appendNotification(message, severity, source = "notify") {
         if (_lineCount > MAX_ENTRIES) {
             _rotate();
         }
+        _emitChange();
     }
     catch {
         // Non-fatal — never let persistence break the caller
@@ -77,6 +98,7 @@ export function markAllRead(basePath) {
     const hasUnread = entries.some((e) => !e.read);
     if (!hasUnread)
         return;
+    let changed = false;
     try {
         _withLock(bp, () => {
             // Re-read inside lock to get freshest state
@@ -85,11 +107,14 @@ export function markAllRead(basePath) {
                 return;
             const lines = fresh.map((e) => JSON.stringify({ ...e, read: true }));
             _atomicWrite(bp, lines.join("\n") + "\n");
+            changed = true;
         });
     }
     catch {
         // Non-fatal
     }
+    if (changed)
+        _emitChange();
 }
 /**
  * Clear all notifications. Atomic write of empty content under lock.
@@ -102,6 +127,8 @@ export function clearNotifications(basePath) {
         _withLock(bp, () => {
             _atomicWrite(bp, "");
         });
+        _lineCount = 0;
+        _emitChange();
     }
     catch {
         // Non-fatal
@@ -146,6 +173,16 @@ export function suppressPersistence() {
 export function unsuppressPersistence() {
     _suppressCount = Math.max(0, _suppressCount - 1);
 }
+/**
+ * Subscribe to notification-store mutations (append, mark-read, clear).
+ * Returns an unsubscribe function.
+ */
+export function onNotificationStoreChange(listener) {
+    _changeListeners.add(listener);
+    return () => {
+        _changeListeners.delete(listener);
+    };
+}
 // ─── Test Helpers ───────────────────────────────────────────────────────
 /**
  * Reset module state. Only for use in tests.
@@ -154,6 +191,8 @@ export function _resetNotificationStore() {
     _basePath = null;
     _lineCount = 0;
     _suppressCount = 0;
+    _recentMessageTimestamps = new Map();
+    _changeListeners.clear();
 }
 // ─── Internal ───────────────────────────────────────────────────────────
 function _readEntriesFromDisk(basePath) {
@@ -191,12 +230,23 @@ function _rotate() {
             const trimmed = entries.slice(entries.length - MAX_ENTRIES);
             const lines = trimmed.map((e) => JSON.stringify(e));
             _atomicWrite(_basePath, lines.join("\n") + "\n");
+            _lineCount = trimmed.length;
         });
     }
     catch {
         // Non-fatal
     }
 }
+function _emitChange() {
+    for (const listener of _changeListeners) {
+        try {
+            listener();
+        }
+        catch {
+            // Non-fatal
+        }
+    }
+}
 /**
  * Atomic file rewrite via temp-file + rename. Prevents partial reads
  * by other processes (web API subprocess, parallel workers).
@@ -251,10 +301,11 @@ function _withLock(basePath, fn) {
             break;
         }
     }
-    // Only run the mutation if we actually own the lock
-    const ownsLock = fd !== null;
+    // Best-effort: mutation runs regardless of lock status (idempotent overwrites).
+    // createdLock gates cleanup only — never skip fn() on lock failure.
+    const createdLock = fd !== null;
     try {
-        if (ownsLock && fd !== null) {
+        if (createdLock && fd !== null) {
             // Write our PID timestamp into the lock for stale detection
             writeFileSync(lockPath, String(Date.now()), "utf-8");
             closeSync(fd);
@@ -263,7 +314,7 @@ function _withLock(basePath, fn) {
     }
     finally {
         // Only delete the lock if we created it — never remove another process's lock
-        if (ownsLock) {
+        if (createdLock) {
             try {
                 unlinkSync(lockPath);
             }

package/dist/resources/extensions/gsd/notification-widget.js

@@ -2,24 +2,14 @@
 // Always-on ambient widget rendered belowEditor showing unread count and
 // the most recent notification message. Refreshes every 5 seconds.
 // Widget key: "gsd-notifications", placement: "belowEditor"
-import { getUnreadCount, readNotifications } from "./notification-store.js";
-import { formatShortcut } from "./files.js";
+import { getUnreadCount, onNotificationStoreChange } from "./notification-store.js";
+import { formattedShortcutPair } from "./shortcut-defs.js";
 // ─── Pure rendering ──���────────────────────────���─────────────────────────
 export function buildNotificationWidgetLines() {
     const unread = getUnreadCount();
     if (unread === 0)
         return [];
-    const entries = readNotifications();
-    const latest = entries[0]; // newest-first
-    if (!latest)
-        return [];
-    const icon = latest.severity === "error" ? "✗" : latest.severity === "warning" ? "⚠" : "●";
-    const badge = `${unread} unread`;
-    const msgMax = 80;
-    const truncated = latest.message.length > msgMax
-        ? latest.message.slice(0, msgMax - 1) + "…"
-        : latest.message;
-    return [`  ${icon} [${badge}]  ${truncated}  (${formatShortcut("Ctrl+Alt+N")} to view)`];
+    return [`  🔔 Notifications: ${unread} unread  (${formattedShortcutPair("notifications")})`];
 }
 // ─── Widget init ────────────────────────────────────────────────────────
 const REFRESH_INTERVAL_MS = 5_000;
@@ -39,6 +29,7 @@ export function initNotificationWidget(ctx) {
             cachedLines = undefined;
             _tui.requestRender();
         };
+        const unsubscribe = onNotificationStoreChange(refresh);
         const refreshTimer = setInterval(refresh, REFRESH_INTERVAL_MS);
         return {
             render(_width) {
@@ -50,6 +41,7 @@ export function initNotificationWidget(ctx) {
                 cachedLines = undefined;
             },
             dispose() {
+                unsubscribe();
                 clearInterval(refreshTimer);
             },
         };

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

@@ -2,7 +2,8 @@
  * GSD Parallel Monitor Overlay
  *
  * Full-screen TUI overlay showing real-time parallel worker progress.
- * Opened via `/gsd parallel watch` or Ctrl+Alt+P (⌃⌥P on macOS).
+ * 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.
  */
@@ -11,6 +12,7 @@ import { join } from "node:path";
 import { spawnSync } from "node:child_process";
 import { matchesKey, Key } from "@gsd/pi-tui";
 import { formatDuration } from "../shared/mod.js";
+import { formattedShortcutPair } from "./shortcut-defs.js";
 // ─── Data Helpers ─────────────────────────────────────────────────────────
 function readJsonSafe(filePath) {
     try {
@@ -285,7 +287,10 @@ export class ParallelMonitorOverlay {
         }
     }
     handleInput(data) {
-        if (matchesKey(data, Key.escape) || data === "q") {
+        if (matchesKey(data, Key.escape) ||
+            matchesKey(data, Key.ctrlAlt("p")) ||
+            matchesKey(data, Key.ctrlShift("p")) ||
+            data === "q") {
             this.dispose();
             this.onClose();
             return;
@@ -403,7 +408,7 @@ 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 to close  │  ↑↓ scroll"));
+        lines.push(t.fg("muted", `  ESC/q/${formattedShortcutPair("parallel")} close  │  ↑↓ scroll`));
         // Apply scroll — use terminal rows as height estimate
         const termHeight = process.stdout.rows || 40;
         const maxScroll = Math.max(0, lines.length - termHeight);

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

@@ -229,6 +229,33 @@ function extractPathFromAnnotation(raw) {
     // Fall back to the original behavior for already-plain paths.
     return trimmed.replace(/`/g, "");
 }
+/**
+ * Planning units sometimes use task.inputs for prose like "Current enum shape"
+ * instead of concrete file paths. Those entries should not fail path checks.
+ * Keep validation for anything that still looks like a real file reference:
+ * explicit backticks, globs, separators, dot-paths, or single-token basenames
+ * like Dockerfile.
+ */
+function shouldValidateInputAsPath(raw) {
+    const trimmed = raw.trim();
+    if (!trimmed)
+        return false;
+    if (/^`+[^`]+`+/.test(trimmed)) {
+        return true;
+    }
+    const candidate = extractPathFromAnnotation(trimmed);
+    if (!candidate)
+        return false;
+    if (!/\s/.test(candidate)) {
+        return true;
+    }
+    return (candidate.startsWith("/") ||
+        candidate.startsWith("./") ||
+        candidate.startsWith("../") ||
+        candidate.startsWith("~/") ||
+        /[\\/]/.test(candidate) ||
+        /[*?[\]{}]/.test(candidate));
+}
 /**
  * Build a set of files that will be created by tasks up to (but not including) taskIndex.
  * All paths are normalized for consistent comparison.
@@ -262,6 +289,8 @@ export function checkFilePathConsistency(tasks, basePath) {
             // Skip empty strings
             if (!file.trim())
                 continue;
+            if (!shouldValidateInputAsPath(file))
+                continue;
             // Normalize path for consistent comparison
             const normalizedFile = normalizeFilePath(file);
             // Check if file exists on disk
@@ -289,7 +318,7 @@ export function checkFilePathConsistency(tasks, basePath) {
  *
  * All paths are normalized before comparison to ensure ./src/a.ts matches src/a.ts.
  */
-export function checkTaskOrdering(tasks, _basePath) {
+export function checkTaskOrdering(tasks, basePath) {
     const results = [];
     // Build map: normalized file → task index that creates it
     const fileCreators = new Map();
@@ -309,9 +338,13 @@ export function checkTaskOrdering(tasks, _basePath) {
         const task = tasks[i];
         const filesToCheck = [...task.inputs];
         for (const file of filesToCheck) {
+            if (!shouldValidateInputAsPath(file))
+                continue;
             const normalizedFile = normalizeFilePath(file);
             const creator = fileCreators.get(normalizedFile);
-            if (creator && creator.index > i) {
+            const absolutePath = resolve(basePath, normalizedFile);
+            const existsOnDisk = existsSync(absolutePath);
+            if (creator && creator.index > i && !existsOnDisk) {
                 // Task reads file that is created later — impossible ordering
                 results.push({
                     category: "file",

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

@@ -0,0 +1,126 @@
+/**
+ * GSD Prompt Validation — Validates enhanced context and turn output
+ * artifacts before writing.
+ *
+ * Implements R109 validation requirement: CONTEXT.md must have required
+ * sections before being written to disk. Additionally, per-turn validators
+ * check that artifacts produced by gate-owning turns contain the gate
+ * sections declared in gate-registry.ts, so a malformed summary/validation
+ * markdown file cannot silently drop a quality gate.
+ */
+import { getGatesForTurn } from "./gate-registry.js";
+/**
+ * Validate that enhanced context content has all required sections.
+ *
+ * Required sections per R109:
+ * - Scope section (## Scope, ## Milestone Scope, or ## Why This Milestone)
+ * - Architectural Decisions section (## Architectural Decisions)
+ * - Acceptance Criteria section (## Acceptance Criteria or ## Final Integrated Acceptance)
+ *
+ * Additionally validates that the Architectural Decisions section contains
+ * at least one decision entry (### heading or **Decision marker).
+ *
+ * @param content - The enhanced context markdown content
+ * @returns ValidationResult with valid flag and list of missing sections
+ */
+export function validateEnhancedContext(content) {
+    const missing = [];
+    // Required section 1: Scope (multiple acceptable header variants)
+    const hasScopeSection = /^## Scope\b/m.test(content) ||
+        /^## Milestone Scope\b/m.test(content) ||
+        /^## Why This Milestone\b/m.test(content);
+    if (!hasScopeSection) {
+        missing.push("Milestone Scope or Why This Milestone");
+    }
+    // Required section 2: Architectural Decisions
+    const hasArchitecturalDecisions = /^## Architectural Decisions\b/m.test(content);
+    if (!hasArchitecturalDecisions) {
+        missing.push("Architectural Decisions");
+    }
+    // Required section 3: Acceptance Criteria (multiple acceptable header variants)
+    const hasAcceptanceCriteria = /^## Acceptance Criteria\b/m.test(content) ||
+        /^## Final Integrated Acceptance\b/m.test(content);
+    if (!hasAcceptanceCriteria) {
+        missing.push("Acceptance Criteria");
+    }
+    // Additional validation: Architectural Decisions must have at least one entry
+    if (hasArchitecturalDecisions) {
+        // Extract the section content between ## Architectural Decisions and the next ## heading.
+        // Uses indexOf-based extraction instead of regex with \z (which is invalid in JavaScript
+        // regex — it's PCRE/Ruby syntax and JS treats it as literal 'z').
+        const sectionStart = content.indexOf("## Architectural Decisions");
+        if (sectionStart === -1) {
+            missing.push("Architectural Decisions");
+        }
+        else {
+            const afterHeading = content.slice(sectionStart + "## Architectural Decisions".length);
+            const nextSection = afterHeading.search(/^## /m);
+            const sectionContent = nextSection === -1 ? afterHeading : afterHeading.slice(0, nextSection);
+            // Check for actual decision entries:
+            // - ### heading (subsection per decision)
+            // - **Decision marker (inline decision format)
+            const hasDecisionEntry = /^### /m.test(sectionContent) || /^\*\*Decision/m.test(sectionContent);
+            if (!hasDecisionEntry) {
+                missing.push("At least one architectural decision entry");
+            }
+        }
+    }
+    return {
+        valid: missing.length === 0,
+        missing,
+    };
+}
+// ─── Per-Turn Gate Section Validators ─────────────────────────────────────
+//
+// Each validator checks that the artifact written by a turn contains a
+// heading for every gate owned by that turn. The registry is the source
+// of truth for which sections must exist; adding a new gate automatically
+// flows through via `getGatesForTurn(turn)`.
+/**
+ * Escape a string so it can be embedded safely inside a regular expression.
+ */
+function escapeRegExp(value) {
+    return value.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
+}
+/**
+ * Validate that an artifact contains an `## H2` heading for every gate the
+ * named turn owns. Returns the list of missing gate section headers.
+ *
+ * Soft rule: a section counts as "present" if it is declared (H2 heading
+ * exists) — empty-body sections are allowed and handled by the tool
+ * handler, which will record such gates as `omitted`.
+ */
+export function validateGateSections(content, turn) {
+    const missing = [];
+    for (const def of getGatesForTurn(turn)) {
+        const pattern = new RegExp(`^##\\s+${escapeRegExp(def.promptSection)}\\b`, "m");
+        if (!pattern.test(content)) {
+            missing.push(`${def.id} (## ${def.promptSection})`);
+        }
+    }
+    return { valid: missing.length === 0, missing };
+}
+/**
+ * Validate a SUMMARY.md produced by the complete-slice turn. Requires
+ * an H2 heading for every gate owned by complete-slice (e.g. Q8 →
+ * "## Operational Readiness"). Intended for use in the tool handler's
+ * pre-write checks or in the post-unit validation sweep.
+ */
+export function validateSliceSummaryOutput(content) {
+    return validateGateSections(content, "complete-slice");
+}
+/**
+ * Validate a task SUMMARY.md produced by the execute-task turn. Only
+ * flags gates that are still pending for the task; skips the check
+ * when no rows are seeded (simple task).
+ */
+export function validateTaskSummaryOutput(content) {
+    return validateGateSections(content, "execute-task");
+}
+/**
+ * Validate a VALIDATION.md produced by the validate-milestone turn.
+ * Requires an H2 heading for every MV gate declared in the registry.
+ */
+export function validateMilestoneValidationOutput(content) {
+    return validateGateSections(content, "validate-milestone");
+}

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

@@ -16,14 +16,16 @@ All relevant context has been preloaded below — the slice plan, all task summa
 
 {{inlinedContext}}
 
+{{gatesToClose}}
+
 **Match effort to complexity.** A simple slice with 1-2 tasks needs a brief summary and lightweight verification. A complex slice with 5 tasks across multiple subsystems needs thorough verification and a detailed summary. Scale the work below accordingly.
 
 Then:
 1. Use the **Slice Summary** and **UAT** output templates from the inlined context above
 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.
+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. Task artifacts use a **flat file layout** directly inside `tasks/` (for example `T01-SUMMARY.md`, `T02-SUMMARY.md`) rather than per-task subdirectories. If you need to count or re-read task summaries during verification, use `find .gsd/milestones/{{milestoneId}}/slices/{{sliceId}}/tasks -name "*-SUMMARY.md"` or `ls .gsd/milestones/{{milestoneId}}/slices/{{sliceId}}/tasks/*-SUMMARY.md`. Never use `tasks/*/SUMMARY.md` — that glob expects subdirectories that do not exist.
 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 the slice involved runtime behavior, fill the **Operational Readiness** section (Q8) in the slice summary: health signal, failure signal, recovery procedure, and monitoring gaps. Omit entirely for simple slices with no runtime concerns.
+5. Address every gate listed in the **Gates to Close** section above — each gate maps to a specific slice-summary section the handler inspects (for example, Q8 maps to **Operational Readiness**: health signal, failure signal, recovery procedure, and monitoring gaps). Leaving a section empty records the gate as `omitted`.
 6. If this slice produced evidence that a requirement changed status (Active → Validated, Active → Deferred, etc.), call `gsd_requirement_update` with the requirement ID, updated `status`, and `validation` evidence. Do NOT write `.gsd/REQUIREMENTS.md` directly — the engine renders it from the database.
 7. Prepare the slice completion content you will pass to `gsd_complete_slice` using the camelCase fields `milestoneId`, `sliceId`, `sliceTitle`, `oneLiner`, `narrative`, `verification`, and `uatContent`. Do **not** manually write `{{sliceSummaryPath}}`. Do **not** manually write `{{sliceUatPath}}` — the DB-backed tool is the canonical write path for both artifacts.
 8. Draft the UAT content you will pass as `uatContent` — a concrete UAT script with real test cases derived from the slice plan and task summaries. Include preconditions, numbered steps with expected outcomes, and edge cases. This must NOT be a placeholder or generic template — tailor every test case to what this slice actually built.
@@ -35,7 +37,7 @@ Then:
 
 **Autonomous execution:** Do not call `ask_user_questions` or `secure_env_collect`. You are running in auto-mode — there is no human available to answer questions. Make reasonable assumptions and document them in the slice summary. If a decision genuinely requires human input, note it in the summary and proceed with the best available option.
 
-**File system safety:** Task summaries are preloaded in the inlined context above. If you need to re-read any of them, use `find .gsd/milestones/{{milestoneId}}/slices/{{sliceId}}/tasks -name "*-SUMMARY.md"` to list file paths first — never pass `{{slicePath}}` or any other directory path directly to the `read` tool. The `read` tool only accepts file paths, not directories.
+**File system safety:** Task summaries are preloaded in the inlined context above. Task artifacts use a **flat file layout** — files such as `T01-SUMMARY.md` and `T02-SUMMARY.md` live directly inside the `tasks/` directory, not inside per-task subdirectories like `tasks/T01/SUMMARY.md`. If you need to re-read any of them, use `find .gsd/milestones/{{milestoneId}}/slices/{{sliceId}}/tasks -name "*-SUMMARY.md"` to list file paths first. Never use `tasks/*/SUMMARY.md`, and never pass `{{slicePath}}` or any other directory path directly to the `read` tool. The `read` tool only accepts file paths, not directories.
 
 **You MUST call `gsd_complete_slice` with the slice summary and UAT content before finishing. The tool persists to both DB and disk and renders `{{sliceSummaryPath}}` and `{{sliceUatPath}}` automatically.**
 

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

@@ -73,6 +73,8 @@ After each round of answers, decide whether you already have enough depth to wri
 
 You are a thinking partner, not an interviewer.
 
+**Turn-taking contract (non-bypassable).** Never fabricate, simulate, or role-play user responses. Never generate fake transcript markers like `[User]`, `[Human]`, or `User:` to invent input. Ask one question round (1-3 questions) per turn, then stop and wait for the user's actual response before continuing. If you use `ask_user_questions`, call it at most once per turn and treat its returned response as the only valid structured user input for that round.
+
 **Start open, follow energy.** Let the user's enthusiasm guide where you dig deeper. If they light up about a particular aspect, explore it. If they're vague about something, that's where you probe.
 
 **Challenge vagueness, make abstract concrete.** When the user says something abstract ("it should be smart" / "it needs to handle edge cases" / "good UX"), push for specifics. What does "smart" mean in practice? Which edge cases? What does good UX look like for this specific interaction?

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

@@ -22,6 +22,8 @@ A researcher explored the codebase and a planner decomposed the work — you are
 
 {{slicePlanExcerpt}}
 
+{{gatesToClose}}
+
 ## Backing Source Artifacts
 - Slice plan: `{{planPath}}`
 - Task plan source: `{{taskPlanPath}}`
@@ -32,29 +34,30 @@ 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. {{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).
-5. When implementing non-trivial runtime behavior (async flows, API boundaries, background processes, error paths), add or preserve agent-usable observability. Skip this for simple changes where it doesn't apply.
+3. 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. "Create" in the plan does **not** mean the file is missing — a prior session may already have started it.
+4. 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.
+5. 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).
+6. When implementing non-trivial runtime behavior (async flows, API boundaries, background processes, error paths), add or preserve agent-usable observability. Skip this for simple changes where it doesn't apply.
 
    **Background process rule:** Never use bare `command &` to run background processes. The shell's `&` operator leaves stdout/stderr attached to the parent, which causes the Bash tool to hang indefinitely waiting for those streams to close. Always redirect output before backgrounding:
    - Correct: `command > /dev/null 2>&1 &` or `nohup command > /dev/null 2>&1 &`
    - Example: `python -m http.server 8080 > /dev/null 2>&1 &` (NOT `python -m http.server 8080 &`)
    - Preferred: use the `bg_shell` tool if available — it manages process lifecycle correctly without stream-inheritance issues
-6. If the task plan includes a **Failure Modes** section (Q5), implement the error/timeout/malformed handling specified. Verify each dependency's failure path is handled. Skip if the section is absent.
-7. If the task plan includes a **Load Profile** section (Q6), implement protections for the identified 10x breakpoint (connection pooling, rate limiting, pagination, etc.). Skip if absent.
-8. If the task plan includes a **Negative Tests** section (Q7), write the specified negative test cases alongside the happy-path tests — malformed inputs, error paths, and boundary conditions. Skip if absent.
-9. Verify must-haves are met by running concrete checks (tests, commands, observable behaviors)
-10. Run the slice-level verification checks defined in the slice plan's Verification section. Track which pass. On the final task of the slice, all must pass before marking done. On intermediate tasks, partial passes are expected — note which ones pass in the summary.
-11. After the verification gate runs (you'll see gate results in stderr/notify output), populate the `## Verification Evidence` table in your task summary with the check results. Use the `formatEvidenceTable` format: one row per check with command, exit code, verdict (✅ pass / ❌ fail), and duration. If no verification commands were discovered, note that in the section.
-12. If the task touches UI, browser flows, DOM behavior, or user-visible web state:
+7. If the task plan includes a **Failure Modes** section (Q5), implement the error/timeout/malformed handling specified. Verify each dependency's failure path is handled. Skip if the section is absent.
+8. If the task plan includes a **Load Profile** section (Q6), implement protections for the identified 10x breakpoint (connection pooling, rate limiting, pagination, etc.). Skip if absent.
+9. If the task plan includes a **Negative Tests** section (Q7), write the specified negative test cases alongside the happy-path tests — malformed inputs, error paths, and boundary conditions. Skip if absent.
+10. Verify must-haves are met by running concrete checks (tests, commands, observable behaviors)
+11. Run the slice-level verification checks defined in the slice plan's Verification section. Track which pass. On the final task of the slice, all must pass before marking done. On intermediate tasks, partial passes are expected — note which ones pass in the summary.
+12. After the verification gate runs (you'll see gate results in stderr/notify output), populate the `## Verification Evidence` table in your task summary with the check results. Use the `formatEvidenceTable` format: one row per check with command, exit code, verdict (✅ pass / ❌ fail), and duration. If no verification commands were discovered, note that in the section.
+13. If the task touches UI, browser flows, DOM behavior, or user-visible web state:
    - exercise the real flow in the browser
    - prefer `browser_batch` when the next few actions are obvious and sequential
    - prefer `browser_assert` for explicit pass/fail verification of the intended outcome
    - use `browser_diff` when an action's effect is ambiguous
    - use console/network/dialog diagnostics when validating async, stateful, or failure-prone UI
    - record verification in terms of explicit checks passed/failed, not only prose interpretation
-13. If the task plan includes an Observability Impact section, verify those signals directly. Skip this step if the task plan omits the section.
-14. **If execution is running long or verification fails:**
+14. If the task plan includes an Observability Impact section, verify those signals directly. Skip this step if the task plan omits the section.
+15. **If execution is running long or verification fails:**
 
     **Context budget:** You have approximately **{{verificationBudget}}** reserved for verification context. If you've used most of your context and haven't finished all steps, stop implementing and prioritize writing the task summary with clear notes on what's done and what remains. A partial summary that enables clean resumption is more valuable than one more half-finished step with no documentation. Never sacrifice summary quality for one more implementation step.
 
@@ -65,13 +68,13 @@ Then:
     - Distinguish "I know" from "I assume." Observable facts (the error says X) are strong evidence. Assumptions (this library should work this way) need verification.
     - Know when to stop. If you've tried 3+ fixes without progress, your mental model is probably wrong. Stop. List what you know for certain. List what you've ruled out. Form fresh hypotheses from there.
     - Don't fix symptoms. Understand *why* something fails before changing code. A test that passes after a change you don't understand is luck, not a fix.
-15. **Blocker discovery:** If execution reveals that the remaining slice plan is fundamentally invalid — not just a bug or minor deviation, but a plan-invalidating finding like a wrong API, missing capability, or architectural mismatch — set `blocker_discovered: true` in the task summary frontmatter and describe the blocker clearly in the summary narrative. Do NOT set `blocker_discovered: true` for ordinary debugging, minor deviations, or issues that can be fixed within the current task or the remaining plan. This flag triggers an automatic replan of the slice.
-16. If you made an architectural, pattern, library, or observability decision during this task that downstream work should know about, append it to `.gsd/DECISIONS.md` (read the template at `~/.gsd/agent/extensions/gsd/templates/decisions.md` if the file doesn't exist yet). Not every task produces decisions — only append when a meaningful choice was made.
-17. If you discover a non-obvious rule, recurring gotcha, or useful pattern during execution, append it to `.gsd/KNOWLEDGE.md`. Only add entries that would save future agents from repeating your investigation. Don't add obvious things.
-18. Read the template at `~/.gsd/agent/extensions/gsd/templates/task-summary.md`
-19. Use that template to prepare the completion content you will pass to `gsd_complete_task` using the camelCase fields `milestoneId`, `sliceId`, `taskId`, `oneLiner`, `narrative`, `verification`, and `verificationEvidence`. Do **not** manually write `{{taskSummaryPath}}` — the DB-backed tool is the canonical write path and renders the summary file for you.
-20. Call `gsd_complete_task` with milestoneId, sliceId, taskId, and the completion fields derived from the template. This is your final required step — do NOT manually edit PLAN.md checkboxes. The tool marks the task complete, updates the DB, renders `{{taskSummaryPath}}`, and updates PLAN.md automatically.
-21. Do not run git commands — the system reads your task summary after completion and creates a meaningful commit from it (type inferred from title, message from your one-liner, key files from frontmatter). Write a clear, specific one-liner in the summary — it becomes the commit message.
+16. **Blocker discovery:** If execution reveals that the remaining slice plan is fundamentally invalid — not just a bug or minor deviation, but a plan-invalidating finding like a wrong API, missing capability, or architectural mismatch — set `blocker_discovered: true` in the task summary frontmatter and describe the blocker clearly in the summary narrative. Do NOT set `blocker_discovered: true` for ordinary debugging, minor deviations, or issues that can be fixed within the current task or the remaining plan. This flag triggers an automatic replan of the slice.
+17. If you made an architectural, pattern, library, or observability decision during this task that downstream work should know about, append it to `.gsd/DECISIONS.md` (read the template at `~/.gsd/agent/extensions/gsd/templates/decisions.md` if the file doesn't exist yet). Not every task produces decisions — only append when a meaningful choice was made.
+18. If you discover a non-obvious rule, recurring gotcha, or useful pattern during execution, append it to `.gsd/KNOWLEDGE.md`. Only add entries that would save future agents from repeating your investigation. Don't add obvious things.
+19. Read the template at `~/.gsd/agent/extensions/gsd/templates/task-summary.md`
+20. Use that template to prepare the completion content you will pass to `gsd_complete_task` using the camelCase fields `milestoneId`, `sliceId`, `taskId`, `oneLiner`, `narrative`, `verification`, and `verificationEvidence`. Do **not** manually write `{{taskSummaryPath}}` — the DB-backed tool is the canonical write path and renders the summary file for you.
+21. Call `gsd_complete_task` with milestoneId, sliceId, taskId, and the completion fields derived from the template. This is your final required step — do NOT manually edit PLAN.md checkboxes. The tool marks the task complete, updates the DB, renders `{{taskSummaryPath}}`, and updates PLAN.md automatically.
+22. Do not run git commands — the system reads your task summary after completion and creates a meaningful commit from it (type inferred from title, message from your one-liner, key files from frontmatter). Write a clear, specific one-liner in the summary — it becomes the commit message.
 
 All work stays in your working directory: `{{workingDirectory}}`.
 

package/dist/resources/extensions/gsd/prompts/guided-discuss-milestone.md

@@ -32,6 +32,8 @@ Ask **1–3 questions per round**. Keep each question focused on one of:
 - **The biggest technical unknowns / risks** — what could fail, what hasn't been proven
 - **What external systems/services this touches** — APIs, databases, third-party services
 
+**Never fabricate or simulate user input.** Never generate fake transcript markers like `[User]`, `[Human]`, or `User:`. Ask one question round, then wait for the user's actual response before continuing.
+
 **If `{{structuredQuestionsAvailable}}` is `true`:** use `ask_user_questions` for each round. 1–3 questions per call, each as a separate question object. Keep option labels short (3–5 words). Always include a freeform "Other / let me explain" option. When the user picks that option or writes a long freeform answer, switch to plain text follow-up for that thread before resuming structured questions. **IMPORTANT: Call `ask_user_questions` exactly once per turn. Never make multiple calls with the same or overlapping questions — wait for the user's response before asking the next round.**
 
 **If `{{structuredQuestionsAvailable}}` is `false`:** ask questions in plain text. Keep each round to 1–3 focused questions. Wait for answers before asking the next round.

package/dist/resources/extensions/gsd/prompts/guided-discuss-slice.md

@@ -22,6 +22,8 @@ Do **not** go deep — just enough that your questions reflect what's actually t
 
 ### Question rounds
 
+**Never fabricate or simulate user input.** Never generate fake transcript markers like `[User]`, `[Human]`, or `User:`. Ask one question round, then wait for the user's actual response before continuing.
+
 **If `{{structuredQuestionsAvailable}}` is `true`:** Ask **1–3 questions per round** using `ask_user_questions`. **Call `ask_user_questions` exactly once per turn — never make multiple calls with the same or overlapping questions. Wait for the user's response before asking the next round.**
 **If `{{structuredQuestionsAvailable}}` is `false`:** Ask **1–3 questions per round** in plain text. Number them and wait for the user's response before asking the next round.
 Keep each question focused on one of:

package/dist/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. {{skillActivation}}
+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. Before you create any expected artifact or output file, check whether it already exists and read it first — a prior session may already have started or completed that work. 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/dist/resources/extensions/gsd/prompts/queue.md

@@ -18,6 +18,7 @@ Say exactly: "What do you want to add?" — nothing else. Wait for the user's an
 ## Discussion Phase
 
 After they describe it, your job is to understand the new work deeply enough to create context files that a future planning session can use.
+Never fabricate or simulate user input during this discussion. Never generate fake transcript markers like `[User]`, `[Human]`, or `User:`. Ask one question round, then wait for the user's actual response before continuing.
 
 **If the user provides a file path or pastes a large document** (spec, design doc, product plan, chat export), read it fully before asking questions. Use it as the starting point — don't ask them to re-explain what's already in the document. Your questions should fill gaps and resolve ambiguities the document doesn't cover.
 
@@ -36,11 +37,11 @@ Don't go deep — just enough that your next question reflects what's actually t
 - How the new work relates to existing milestones — overlap, dependencies, prerequisites
 - If `.gsd/REQUIREMENTS.md` exists: which unmet Active or Deferred requirements this queued work advances
 
-**Then use ask_user_questions** to dig into gray areas — scope boundaries, proof expectations, integration choices, tech preferences when they materially matter, and what's in vs out. 1-3 questions per round.
+**Then use ask_user_questions** to dig into gray areas — scope boundaries, proof expectations, integration choices, tech preferences when they materially matter, and what's in vs out. Ask 1-3 questions per round, then wait for the user's response before asking the next round.
 
 If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during discuss/planning work, but do not let it override the required discuss flow or artifact requirements.
 
-**Self-regulate:** Do **not** ask a meta "ready to queue?" question after every round. Keep going until you have enough depth to write the context well, then use a single wrap-up prompt if needed. If the user clearly keeps adding detail instead of objecting, treat that as permission to continue.
+**Self-regulate:** Do **not** ask a meta "ready to queue?" question after every round. Keep going until you have enough depth to write the context well, then use a single wrap-up prompt if needed. Do not infer permission to continue from silence or from partial prior answers — each new round requires an actual user response.
 
 ## Existing Milestone Awareness
 

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

@@ -35,6 +35,7 @@ GSD ships with bundled skills. Load the relevant skill file with the `read` tool
 - Read before edit.
 - Reproduce before fix when possible.
 - Work is not done until the relevant verification has passed.
+- **Never fabricate, simulate, or role-play user responses.** Never generate markers like `[User]`, `[Human]`, `User:`, or similar to represent user input inside your own output. Ask one question round (1-3 questions), then stop and wait for the user's actual response before continuing. If `ask_user_questions` is available, treat its returned response as the only valid structured user input for that round.
 - Never print, echo, log, or restate secrets or credentials. Report only key names and applied/skipped status.
 - Never ask the user to edit `.env` files or set secrets manually. Use `secure_env_collect`.
 - In enduring files, write current state only unless the file is explicitly historical.