@opengsd/gsd-pi 1.1.1-dev.b2556262 → 1.2.0-dev.844675c9

package/src/resources/extensions/gsd/debug-logger.ts

@@ -25,6 +25,7 @@ const _counters = {
   parsePlanTotalMs: 0,
   dispatches: 0,
   renders: 0,
+  gitInvocations: 0,
 };
 
 /** Max debug log files to keep. Older ones are pruned on enable. */
@@ -131,6 +132,15 @@ export function debugCount(counter: keyof typeof _counters, value = 1): void {
   _counters[counter] += value;
 }
 
+/**
+ * Snapshot the current debug counters. Used by the per-dispatch benchmark
+ * harness (#442) to read counts without disabling debug (which is what
+ * writeDebugSummary does). Returns a copy so callers can't mutate internal state.
+ */
+export function getDebugCounters(): Readonly<typeof _counters> {
+  return { ..._counters };
+}
+
 /** Record a peak value (only updates if new value is higher). */
 export function debugPeak(counter: keyof typeof _counters, value: number): void {
   if (!_enabled) return;
@@ -168,6 +178,7 @@ export function writeDebugSummary(): string | null {
     avgTtsrCheck_ms,
     ttsrPeakBuffer: _counters.ttsrPeakBuffer,
     renders: _counters.renders,
+    gitInvocations: _counters.gitInvocations,
   });
 
   return disableDebug();

package/src/resources/extensions/gsd/doctor-proactive.ts

@@ -267,12 +267,18 @@ export async function preDispatchHealthGate(basePath: string): Promise<PreDispat
     // Non-fatal — dispatch continues without STATE.md if rebuild fails
   }
 
+  // #442 Phase 1.7: resolve repo-ness once per gate. ensureWorkspaceGitReady
+  // has already run, and nothing below initializes/deinitializes the repo, so
+  // the two downstream blocks (integration-branch check, stale-changes
+  // snapshot) can share one nativeIsRepo result instead of querying twice.
+  const isRepo = nativeIsRepo(basePath);
+
   // ── Integration branch existence check ──
   // If the active milestone's recorded integration branch no longer exists in
   // git, the merge-back at the end of the milestone will fail. Block dispatch
   // now to surface this before work is lost.
   try {
-    if (nativeIsRepo(basePath)) {
+    if (isRepo) {
       const state = await deriveState(basePath);
       if (state.activeMilestone) {
         const gitPrefs = loadEffectiveGSDPreferences()?.preferences?.git ?? {};
@@ -296,7 +302,7 @@ export async function preDispatchHealthGate(basePath: string): Promise<PreDispat
   // If the working tree is dirty and no commit has happened recently,
   // create a safety snapshot so work isn't lost if the next unit crashes.
   try {
-    if (nativeIsRepo(basePath)) {
+    if (isRepo) {
       const prefs = loadEffectiveGSDPreferences()?.preferences ?? {};
       // `git.snapshots: false` is the canonical toggle that disables WIP
       // snapshot commits — honour it before touching the threshold path (#4420).

package/src/resources/extensions/gsd/guided-flow.ts

@@ -1387,8 +1387,8 @@ async function buildDiscussPreparationContext(
     if (parts.length === 0) return "";
 
     const guidance = mode === "milestone"
-      ? "Use these findings as background only — they describe what already exists, NOT what the user wants next. After investigation, send **one** message: a short recap (at most 2-3 sentences) plus 1-3 focused questions, then **stop**. Do not dump a feature-menu brainstorm or send a second message restating the same question."
-      : "Use these findings as background context — they describe what already exists, NOT what the user wants to build. Always ask the user what they want to build first.";
+      ? "Use these findings as background only — they describe what already exists, NOT what the user wants next. This snapshot already covers code reality: do NOT survey the codebase before asking. Send **one** message: a short recap (at most 2-3 sentences) plus 1-3 focused questions, then **stop**. Do not dump a feature-menu brainstorm or send a second message restating the same question."
+      : "Use these findings as background context — they describe what already exists, NOT what the user wants to build. This snapshot already covers code reality: do NOT survey the codebase before asking. Always ask the user what they want to build first.";
     return `\n\n## Preparation Context\n\nThe system analyzed the codebase before this discussion. ${guidance}\n\n${parts.join("\n\n")}`;
   } catch (err) {
     logWarning("guided", `preparation failed, proceeding without context: ${(err as Error).message}`);

package/src/resources/extensions/gsd/markdown-renderer.ts

@@ -9,11 +9,10 @@
 // Critical invariant: rendered markdown must round-trip through
 // parseRoadmap(), parsePlan(), parseSummary() in files.ts.
 
-import { readFileSync, existsSync, mkdirSync } from "node:fs";
+import { readFileSync, existsSync, mkdirSync, statSync } from "node:fs";
 import { logWarning } from "./workflow-logger.js";
 import { isClosedStatus } from "./status-guards.js";
 import { dirname, join, relative } from "node:path";
-import { createRequire } from "node:module";
 import {
   getAllMilestones,
   getMilestone,
@@ -38,7 +37,8 @@ import {
   buildTaskFileName,
   buildSliceFileName,
 } from "./paths.js";
-import { saveFile, clearParseCache } from "./files.js";
+import { saveFile, clearParseCache, registerCacheClearCallback } from "./files.js";
+import { parseRoadmap, parsePlan } from "./parsers-legacy.js";
 import { invalidateStateCache } from "./state.js";
 import { clearPathCache } from "./paths.js";
 import type { RiskLevel } from "./types.js";
@@ -738,20 +738,41 @@ export interface StaleEntry {
  * Returns a list of stale entries with file path and reason.
  * Logs to stderr when stale files are detected.
  */
-export function detectStaleRenders(basePath: string): StaleEntry[] {
-  // Lazy-load parsers — intentional disk-vs-DB comparison requires parsers
-  const _require = createRequire(import.meta.url);
-  let parseRoadmap: Function, parsePlan: Function;
-  try {
-    // Prefer compiled JS for packaged/runtime installs; TS exists only in source/dev contexts.
-    const m = _require("./parsers-legacy.js");
-    parseRoadmap = m.parseRoadmap; parsePlan = m.parsePlan;
-  } catch (e) {
-    logWarning("renderer", `parsers-legacy.js require failed, falling back to .ts: ${(e as Error).message}`);
-    const m = _require("./parsers-legacy.ts");
-    parseRoadmap = m.parseRoadmap; parsePlan = m.parsePlan;
+// #442 Phase 1.5: cache parsed ROADMAP/PLAN projections by file identity
+// (path + mtimeMs + size) so an unchanged projection skips readFileSync AND
+// the parse entirely on repeated dispatches. The DB-vs-disk comparison below
+// still runs every call against fresh DB rows — only the disk-parse half is
+// memoized, and parsed output depends solely on file bytes, so this is
+// behavior-preserving. Invalidation rides the existing clearParseCache()
+// callback chain (fired by invalidateCaches() after every projection write and
+// by reconcileBeforeDispatch repairs), so a changed file always re-parses.
+interface CachedProjection { mtimeMs: number; size: number; parsed: unknown }
+const _projectionParseCache = new Map<string, CachedProjection>();
+registerCacheClearCallback(() => _projectionParseCache.clear());
+
+function parseProjectionByIdentity(path: string, parse: (content: string) => unknown): unknown {
+  let st: ReturnType<typeof statSync> | null = null;
+  try { st = statSync(path); } catch { st = null; }
+  if (st) {
+    const hit = _projectionParseCache.get(path);
+    if (hit && hit.mtimeMs === st.mtimeMs && hit.size === st.size) {
+      return hit.parsed;
+    }
+    const parsed = parse(readFileSync(path, "utf-8"));
+    _projectionParseCache.set(path, { mtimeMs: st.mtimeMs, size: st.size, parsed });
+    return parsed;
   }
+  // stat failed (e.g. file vanished between existsSync and here) — fall back to
+  // the original plain read+parse so error handling is unchanged.
+  return parse(readFileSync(path, "utf-8"));
+}
 
+export function detectStaleRenders(basePath: string): StaleEntry[] {
+  // parseRoadmap/parsePlan are statically imported (#442 Phase 1.4): the
+  // per-call createRequire("./parsers-legacy") that used to live here ran on
+  // every dispatch. The static `./parsers-legacy.js` specifier resolves in
+  // both packaged (.js) and source (.ts via the strip-types loader) contexts —
+  // the same form a dozen other modules already use.
   const stale: StaleEntry[] = [];
   const milestones = getAllMilestones();
 
@@ -762,8 +783,7 @@ export function detectStaleRenders(basePath: string): StaleEntry[] {
     const roadmapPath = resolveRoadmapProjectionPath(basePath, milestone.id);
     if (existsSync(roadmapPath)) {
       try {
-        const content = readFileSync(roadmapPath, "utf-8");
-        const parsed = parseRoadmap(content);
+        const parsed = parseProjectionByIdentity(roadmapPath, parseRoadmap) as ReturnType<typeof parseRoadmap>;
 
         for (const slice of slices) {
           const isCompleteInDb = isClosedStatus(slice.status);
@@ -795,8 +815,7 @@ export function detectStaleRenders(basePath: string): StaleEntry[] {
       const planPath = resolveSliceFile(basePath, milestone.id, slice.id, "PLAN");
       if (planPath && existsSync(planPath)) {
         try {
-          const content = readFileSync(planPath, "utf-8");
-          const parsed = parsePlan(content);
+          const parsed = parseProjectionByIdentity(planPath, parsePlan) as ReturnType<typeof parsePlan>;
 
           for (const task of tasks) {
             const isDoneInDb = isClosedStatus(task.status);

package/src/resources/extensions/gsd/mcp-filter.ts

@@ -1,4 +1,5 @@
 import { existsSync, readFileSync } from "node:fs";
+import { homedir } from "node:os";
 import { resolve } from "node:path";
 
 import type { ClaudeCodeMcpConfig } from "./preferences-types.js";
@@ -115,6 +116,12 @@ export function discoverMcpServerNames(projectDir: string): string[] {
   return discoverMcpServers(projectDir).map((server) => server.name);
 }
 
+export function discoverUserMcpServerNames(): string[] {
+  const userSettingsPath = resolve(homedir(), ".claude", "settings.json");
+  const userSettings = readJsonFile(userSettingsPath, true) as ClaudeSettingsFile | undefined;
+  return collectServerEntries(userSettings?.mcpServers).map((s) => s.name);
+}
+
 export function computeMcpDisallowedTools(
   modelId: string,
   mcpConfig: ClaudeCodeMcpConfig | undefined,

package/src/resources/extensions/gsd/native-git-bridge.ts

@@ -13,6 +13,7 @@ import { GSDError, GSD_GIT_ERROR } from "./errors.js";
 import { GIT_NO_PROMPT_ENV } from "./git-constants.js";
 import { getErrorMessage } from "./error-utils.js";
 import { isInfrastructureError } from "./auto/infra-errors.js";
+import { debugCount } from "./debug-logger.js";
 
 // Issue #453: keep auto-mode bookkeeping on the stable git CLI path unless a
 // caller explicitly opts into the native helper.
@@ -140,6 +141,8 @@ function loadNative(): typeof nativeModule {
 
 /** Run a git command via execFileSync. Returns trimmed stdout. */
 function gitExec(basePath: string, args: string[], allowFailure = false): string {
+  // Counts git CLI shell-outs only (native libgit2 paths bypass this helper).
+  debugCount("gitInvocations");
   try {
     return execFileSync("git", args, {
       cwd: basePath,
@@ -169,6 +172,8 @@ function execGitFileSyncWithRetry(
   args: string[],
   options: Partial<ExecFileSyncOptionsWithStringEncoding>,
 ): string {
+  // Counts git CLI shell-outs only (native libgit2 paths bypass this helper).
+  debugCount("gitInvocations");
   try {
     return execFileSync("git", args, {
       cwd: basePath,
@@ -180,6 +185,8 @@ function execGitFileSyncWithRetry(
   } catch (err) {
     if (!isRetryableGitError(err)) throw err;
     sleepSync(GIT_RETRY_DELAY_MS);
+    // Retry is a second physical shell-out — count it too.
+    debugCount("gitInvocations");
     return execFileSync("git", args, {
       cwd: basePath,
       stdio: ["ignore", "pipe", "pipe"],
@@ -192,6 +199,8 @@ function execGitFileSyncWithRetry(
 
 /** Run a git command via execFileSync. Returns trimmed stdout. */
 function gitFileExec(basePath: string, args: string[], allowFailure = false): string {
+  // Counts git CLI shell-outs only (native libgit2 paths bypass this helper).
+  debugCount("gitInvocations");
   try {
     return execFileSync("git", args, {
       cwd: basePath,
@@ -1092,6 +1101,45 @@ export function nativeMergeSquash(basePath: string, branch: string): GitMergeRes
   }
 }
 
+/**
+ * Regular (non-squash) merge a branch (stages changes, does NOT commit).
+ * Uses --no-ff to ensure a proper merge commit and --no-commit so the caller
+ * can supply a custom commit message via nativeCommit.
+ * Respects the user's global git merge.ff config; --no-ff is additive here.
+ */
+export function nativeMergeRegular(basePath: string, branch: string): GitMergeResult {
+  try {
+    execFileSync("git", ["merge", "--no-ff", "--no-commit", branch], {
+      cwd: basePath,
+      stdio: ["ignore", "pipe", "pipe"],
+      encoding: "utf-8",
+      env: GIT_NO_PROMPT_ENV,
+    });
+    return { success: true, conflicts: [] };
+  } catch (err: unknown) {
+    const stderr =
+      err instanceof Error ? (err as Error & { stderr?: string }).stderr ?? err.message : String(err);
+    if (
+      stderr.includes("local changes would be overwritten") ||
+      stderr.includes("not possible because you have unmerged files") ||
+      stderr.includes("overwritten by merge")
+    ) {
+      const dirtyFiles = stderr
+        .split("\n")
+        .filter((line) => line.startsWith("\t"))
+        .map((line) => line.trim())
+        .filter(Boolean);
+      return { success: false, conflicts: ["__dirty_working_tree__"], dirtyFiles };
+    }
+    const conflictOutput = gitExec(basePath, ["diff", "--name-only", "--diff-filter=U"], true);
+    const conflicts = conflictOutput ? conflictOutput.split("\n").filter(Boolean) : [];
+    if (conflicts.length > 0) {
+      return { success: false, conflicts };
+    }
+    throw err;
+  }
+}
+
 /**
  * Abort an in-progress merge.
  * Native: libgit2 reset + cleanup.

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

@@ -31,18 +31,17 @@ After reflection is confirmed, choose the approach from actual scope, not a labe
 
 {{preparationContext}}
 
-## Mandatory Investigation Before First Question Round
+## Ground the First Question Round
 
-Before the first question round, gather enough evidence for grounded questions:
-1. Scout relevant code with `ls`, `find`, `rg`, or `scout`.
-2. Check mentioned tech with `resolve_library` / `get_library_docs`.
-3. Use web tools only for current external facts.
+Ground your questions in the **Preparation Context above** (codebase snapshot, prior context) plus the user's reflected vision — that is authoritative. **Do not survey the codebase** with `ls`/`find`/`rg`/`scout` before asking; the snapshot already covers code reality. Read a specific file only when a question's answer genuinely hinges on it.
+1. Check mentioned tech with `resolve_library` / `get_library_docs`.
+2. Use web tools only for current external facts.
 
-Budget searches across the discussion; prefer docs and one-shot `search_and_read`. Re-investigate only when answers expose new gaps.
+Budget searches across the discussion; prefer docs and one-shot `search_and_read`. Read on-demand only when an answer exposes a specific gap.
 
 ## Layered Question Rounds
 
-Questions have four layers. At each layer, ask 1-3 open questions per round, investigate as needed, and gate before advancing.
+Questions have four layers. At each layer, ask 1-3 open questions per round, read a specific file on-demand if an answer needs it, and gate before advancing.
 
 **Default to open questions.** Use `ask_user_questions` only for 2-3 distinct paths with clear tradeoffs. Use plain text for nuanced design questions.
 

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

@@ -19,15 +19,13 @@ Discuss milestone {{milestoneId}} ("{{milestoneTitle}}"). Identify real gray are
 Before asking, read `.gsd/PROJECT.md` and find `## Project Shape` -> `**Complexity:**`. Use `simple` or `complex`; default to `complex` if missing, stale, or unclear.
 
 - `simple`: 1-2 plain-text rounds; skip parallel-research investigation; use `ask_user_questions` only for concrete alternatives.
-- `complex`: investigate first, use 3-4-option structured questions, and expect multiple rounds.
+- `complex`: ground in the preloaded context first, use 3-4-option structured questions, and expect multiple rounds.
 
 ### Before your first question round
 
-Investigate enough to avoid assumption-driven questions:
-- Scout existing code with `rg`, `find`, or `scout`.
-- Check roadmap context above for surrounding scope.
-- Use `resolve_library` / `get_library_docs` for unfamiliar libraries; prefer them over web search.
+Ground your questions in the **preloaded context above** (milestone roadmap/context/research, the decisions register, prior-milestone summaries) plus any Preparation Context snapshot — those are authoritative. **Do not survey the codebase** with `rg`/`find`/`scout` before asking; the preloaded files are marked do-not-re-read. Read a specific file only when a question's answer genuinely hinges on it.
 - Identify the 3-5 behavioral or architectural unknowns that materially change what gets built.
+- Use `resolve_library` / `get_library_docs` for unfamiliar libraries; prefer them over web search.
 
 **Web search budget:** Limited per turn, typically 3-5. Prefer docs tools and `search_and_read`; use 2-3 searches in the first pass and save the rest.
 
@@ -43,13 +41,13 @@ Ask **1–3 questions per round**. Target one focus at a time:
 
 **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.
 
-**Single user-facing message (NON-BYPASSABLE):** After investigation, send **one** assistant message that contains your questions (and at most a short recap — 2-3 sentences, not a feature catalog). **End the turn there.** Do not send a second message that restates the same ask ("what do you want M00X to be?", "before I can write the context file…", etc.). If you already asked, stop — do not elaborate in a follow-up message in the same turn.
+**Single user-facing message (NON-BYPASSABLE):** After grounding in the preloaded context, send **one** assistant message that contains your questions (and at most a short recap — 2-3 sentences, not a feature catalog). **End the turn there.** Do not send a second message that restates the same ask ("what do you want M00X to be?", "before I can write the context file…", etc.). If you already asked, stop — do not elaborate in a follow-up message in the same turn.
 
 **If `{{structuredQuestionsAvailable}}` is `true`:** use `ask_user_questions` exactly once per turn with 1-3 question objects. Keep labels short (3-5 words). In `complex` mode, multi-choice questions MUST offer **3 or 4 concrete, researched options** plus **"Other — let me discuss"**; options must be grounded in the investigation, not placeholders. In `simple` mode, 2 options is fine for binary alternatives. Binary depth-check/wrap-up gates are exempt. If the user chooses "Other — let me discuss" or gives a long freeform answer, switch to plain-text follow-up before resuming structured questions.
 
 **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.
 
-After each answer, investigate only new unknowns, then ask the next round.
+After each answer, resolve only the new unknowns from context (re-read a specific file only if one is needed), then ask the next round.
 
 ### Round cadence
 

package/src/resources/extensions/gsd/prompts/guided-discuss-project.md

@@ -38,9 +38,7 @@ Persist the verdict through `gsd_summary_save` with `artifact_type: "PROJECT"` i
 
 ### Before deeper rounds
 
-Investigate enough to avoid assumption-driven questions:
-- Scout code with `rg`, `find`, or `scout` for greenfield/brownfield and framework signals.
-- Check prior `.planning/` or `.gsd/` artifacts.
+Ground your questions in the **Preparation Context snapshot above** (stack, structure, greenfield/brownfield and framework signals) plus any prior `.planning/` or `.gsd/` artifacts — those are authoritative. **Do not survey the codebase** with `rg`/`find`/`scout` before asking; read a specific file only when a question's answer genuinely hinges on it.
 - Use `resolve_library` / `get_library_docs` for unfamiliar mentioned libraries.
 
 **Web search budget:** typically 3-5 per turn. Prefer docs tools; use 2-3 searches first and save the rest.
@@ -53,13 +51,13 @@ Ask **1–3 questions per round**, one focus at a time: what, who, core value, a
 
 **Shape-dependent cadence:**
 - **`simple`**: 1-2 plain-text rounds; use `ask_user_questions` only for concrete alternatives; reach the depth checklist quickly.
-- **`complex`**: full investigation, multiple rounds, structured questions when meaningful alternatives exist.
+- **`complex`**: ground in the snapshot and prior artifacts, multiple rounds, structured questions when meaningful alternatives exist.
 
 **If `{{structuredQuestionsAvailable}}` is `true` and you use `ask_user_questions`:** ask 1-3 questions per call. Every question needs stable lowercase `id`. Keep labels short (3-5 words). In **`complex`** mode, multi-choice questions MUST offer **3 or 4 concrete, researched options** plus **"Other — let me discuss"**; options must be grounded in the investigation, not placeholders. In **`simple`** mode, 2 options is fine. Binary depth-check/wrap-up gates are exempt. Wait for each tool result before the next round.
 
 **If `{{structuredQuestionsAvailable}}` is `false`:** ask questions in plain text. Keep each round to 1–3 focused questions.
 
-After each round, investigate only new unknowns, then ask the next round.
+After each round, resolve only new unknowns from context (read a specific file only if one is needed), then ask the next round.
 
 ### Round cadence
 

package/src/resources/extensions/gsd/prompts/guided-discuss-requirements.md

@@ -34,8 +34,7 @@ Before your first action, print this banner verbatim in chat:
 
 ### Before your first question round
 
-Before questioning, investigate enough to avoid assumption-driven requirements:
-- Scout existing capabilities; already-built work is `Validated` or `Active`.
+Ground your requirements in **PROJECT.md, any existing REQUIREMENTS.md, and the Preparation Context snapshot** — those are authoritative for what already exists (already-built work is `Validated` or `Active`). **Do not survey the codebase**; read a specific file only when a requirement's scope genuinely hinges on it.
 - Cross-check milestone sequence; every milestone needs at least one owned Active requirement.
 - Use `resolve_library` / `get_library_docs` for libraries that imply capabilities.
 - Identify domain table-stakes only when PROJECT.md confidence is low.

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

@@ -13,12 +13,11 @@ Do **not** center the discussion on tech stack trivia, naming, or speculative ar
 Before the first question round, read `.gsd/PROJECT.md` and look for `## Project Shape` → `**Complexity:**`. Verdicts are **`simple`** or **`complex`**; default to `complex` if missing or unclear.
 
 - **`simple`** — use 1–2 plain-text rounds, then write context. Skip parallel-research investigation.
-- **`complex`** — investigate first, then ask structured 3–4-option questions.
+- **`complex`** — ground in the preloaded context first, then ask structured 3–4-option questions.
 
-### Investigation
+### Grounding
 
-Do enough targeted investigation that questions reflect reality:
-- Scout touched code with `rg`, `find`, or `scout` for broad unfamiliar areas.
+Ground your questions in the **preloaded slice context above** plus any Preparation Context snapshot — those are authoritative. **Do not survey the codebase** with `rg`/`find`/`scout` before asking; read a specific file only when a question's answer genuinely hinges on it.
 - Check roadmap context for predecessor and dependent work.
 - For unfamiliar libraries, prefer `resolve_library` / `get_library_docs` over `search-the-web`.
 - Identify the 3–5 biggest behavioural unknowns where the user's answer materially changes the build.
@@ -31,7 +30,7 @@ Do **not** go deep; stop when you can ask grounded questions.
 
 **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`. In **`complex`** mode, each multi-choice question MUST present **3 or 4 concrete, researched options** plus final **"Other — let me discuss"** option; options must be grounded in the investigation above (codebase signals, library docs, prior `.gsd/` artifacts), not placeholders. In **`simple`** mode, 2 options is fine. Binary wrap-up gates are exempt. **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 `true`:** Ask **1–3 questions per round** using `ask_user_questions`. In **`complex`** mode, each multi-choice question MUST present **3 or 4 concrete, researched options** plus final **"Other — let me discuss"** option; options must be grounded in the preloaded context above (slice context, codebase snapshot, library docs, prior `.gsd/` artifacts), not placeholders. In **`simple`** mode, 2 options is fine. Binary wrap-up gates are exempt. **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 numbered plain-text questions per round**, then wait.
 Focus questions on:
 - **UX and user-facing behaviour** — what users see, click, trigger, or experience.
@@ -39,7 +38,7 @@ Focus questions on:
 - **Scope boundaries** — what is in, out, or deferred.
 - **Feel and experience** — tone, responsiveness, feedback, transitions, and what "done" feels like.
 
-After answers, investigate new unknowns if needed, then ask the next round.
+After answers, resolve new unknowns from context (read a specific file only if needed), then ask the next round.
 
 ### Round cadence
 

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

@@ -38,7 +38,7 @@ If slice research is inlined, trust its architectural findings, but verify every
 
 1. If requirements are preloaded, identify owned and supporting Active requirements.
 2. Call `memory_query` with keywords from the slice title and source files.
-3. Read `{{planTemplatePath}}` and `{{taskPlanTemplatePath}}`.
+3. Use the inlined Output Template sections already present in this prompt. Do not read template files from disk.
 4. {{skillActivation}} Record expected executor skills in each task plan's `skills_used` frontmatter.
 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.

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

@@ -25,12 +25,12 @@ A milestone adding a small feature to an established codebase needs targeted res
 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. {{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.
+3. **Ground in the preloaded context, do not re-survey.** The Codebase Snapshot and Project Classification above describe current code reality and project size — treat them as authoritative. Do NOT open-endedly survey the tree (`rg`/`find`/`scout`) to rediscover what they already cover. Read a specific file with a targeted `read` only when a research question's answer hinges on that file's exact contents. Match research depth to the classified project size: a tiny project needs a short, targeted research note, not a broad survey.
 4. Use `resolve_library` / `get_library_docs` for unfamiliar libraries — skip this for libraries already used in the codebase
 5. **Web search budget:** You have a limited budget of web searches (max ~15 per session). Use them strategically — prefer `resolve_library` / `get_library_docs` for library documentation. Do NOT repeat the same or similar queries. If a search didn't find what you need, rephrase once or move on. Target 3-5 total web searches for a typical research unit.
 6. Use the **Research** output template from the inlined context above — include only sections that have real content
 7. If `.gsd/REQUIREMENTS.md` exists, research against it. Identify which Active requirements are table stakes, likely omissions, overbuilt risks, or domain-standard behaviors the user may or may not want.
-8. Call `gsd_summary_save` with `milestone_id: {{milestoneId}}`, `artifact_type: "RESEARCH"`, and the full research markdown as `content` — the tool computes the file path and persists to both DB and disk.
+8. Call `gsd_summary_save` with `milestone_id: {{milestoneId}}`, `artifact_type: "RESEARCH"`, and the full research markdown as `content` — the tool computes the file path and persists to both DB and disk. Save **incrementally**: once you have substantive findings, save them, then enrich and re-save as you learn more. This makes your research durable — if this unit is interrupted, a re-dispatch resumes from your last saved draft instead of restarting. If a "Resume — Prior Partial Research" block is present above, extend that draft rather than starting over.
 
 ## Strategic Questions to Answer
 

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

@@ -24,16 +24,18 @@ Roadmap, slice summaries, assessments, requirements, decisions, and project cont
 
 ### Step 1 - Dispatch Parallel Reviewers
 
+The Inlined Context above already preloads the evidence reviewers need — the roadmap, per-slice SUMMARY/ASSESSMENT excerpts, requirements, and verification classes. **Embed the relevant preloaded evidence directly into each reviewer's task prompt** so reviewers work from it instead of re-reading the same artifacts from disk. Each reviewer should read a full file only when its excerpt is missing, truncated, or internally inconsistent — never as a routine first step. This avoids three reviewers independently re-surveying artifacts the orchestrator already holds.
+
 Call `subagent` with `tasks: [...]` containing ALL THREE reviewers simultaneously:
 
 **Reviewer A - Requirements Coverage**
-Prompt: "Review milestone {{milestoneId}} requirements coverage. Working directory: {{workingDirectory}}. Read `.gsd/REQUIREMENTS.md` or use the inlined requirements context. For each requirement, check slice SUMMARY files under `.gsd/milestones/{{milestoneId}}/slices/` and mark COVERED, PARTIAL, or MISSING. Output table: Requirement | Status | Evidence. End with one-line verdict: PASS if all covered, NEEDS-ATTENTION if partials exist, FAIL if any missing."
+Prompt: "Review milestone {{milestoneId}} requirements coverage. Working directory: {{workingDirectory}}. Use the preloaded requirements and slice SUMMARY evidence embedded in this task — do not re-read them from disk. For each requirement, mark COVERED, PARTIAL, or MISSING against that evidence. Read a full SUMMARY under `.gsd/milestones/{{milestoneId}}/slices/` only if its preloaded excerpt is missing, truncated, or inconsistent. Output table: Requirement | Status | Evidence. End with one-line verdict: PASS if all covered, NEEDS-ATTENTION if partials exist, FAIL if any missing."
 
 **Reviewer B - Cross-Slice Integration**
-Prompt: "Review milestone {{milestoneId}} cross-slice integration. Working directory: {{workingDirectory}}. Read `{{roadmapPath}}` and find the boundary map (produces/consumes contracts). For each boundary, confirm producer SUMMARY produced the artifact and consumer SUMMARY consumed it. Output table: Boundary | Producer Summary | Consumer Summary | Status. End with one-line verdict: PASS if all boundaries honored, NEEDS-ATTENTION if any gaps."
+Prompt: "Review milestone {{milestoneId}} cross-slice integration. Working directory: {{workingDirectory}}. Use the preloaded roadmap and slice SUMMARY evidence embedded in this task — do not re-read them from disk. Find the boundary map (produces/consumes contracts) in the roadmap. For each boundary, confirm producer SUMMARY produced the artifact and consumer SUMMARY consumed it. Read `{{roadmapPath}}` or a full SUMMARY only if the preloaded evidence is missing, truncated, or inconsistent. Output table: Boundary | Producer Summary | Consumer Summary | Status. End with one-line verdict: PASS if all boundaries honored, NEEDS-ATTENTION if any gaps."
 
 **Reviewer C - Assessment & Acceptance Criteria**
-Prompt: "Review milestone {{milestoneId}} assessment evidence and acceptance criteria. Working directory: {{workingDirectory}}. Read `.gsd/milestones/{{milestoneId}}/{{milestoneId}}-CONTEXT.md` for criteria. Check slice SUMMARY and ASSESSMENT files under `.gsd/milestones/{{milestoneId}}/slices/`; UAT files are specs, not evidence. Verify each criterion maps to passing evidence. Then review the inlined `Verification Classes (from planning)` table. For every planned row in that table, output a `Verification Classes` table with columns `Class | Planned Check | Evidence | Verdict`. Preserve every planned non-empty class row; do not summarize, rename, combine, or omit planned classes. The first cell of each row must be exactly `Contract`, `Integration`, `Operational`, or `UAT` when that class is present in planning. If a planned class lacks evidence, still include its canonical row and mark the verdict NEEDS-ATTENTION or FAIL. If a planned browser/UAT class has no ASSESSMENT with browser/runtime actions and assertions, return NEEDS-ATTENTION. If no verification classes were planned, say that explicitly. Output sections `Acceptance Criteria` with checklist `[ ] Criterion | Evidence`, and `Verification Classes` with the table. End with one-line verdict: PASS if all criteria and classes are covered by evidence, NEEDS-ATTENTION if gaps exist."
+Prompt: "Review milestone {{milestoneId}} assessment evidence and acceptance criteria. Working directory: {{workingDirectory}}. Use the preloaded milestone context, slice SUMMARY, and ASSESSMENT evidence embedded in this task — do not re-read them from disk. Read `.gsd/milestones/{{milestoneId}}/{{milestoneId}}-CONTEXT.md`, a full SUMMARY, or a full ASSESSMENT only if the preloaded excerpt is missing, truncated, or inconsistent. UAT files are specs, not evidence. Verify each criterion maps to passing evidence. Then review the inlined `Verification Classes (from planning)` table. For every planned row in that table, output a `Verification Classes` table with columns `Class | Planned Check | Evidence | Verdict`. Preserve every planned non-empty class row; do not summarize, rename, combine, or omit planned classes. The first cell of each row must be exactly `Contract`, `Integration`, `Operational`, or `UAT` when that class is present in planning. If a planned class lacks evidence, still include its canonical row and mark the verdict NEEDS-ATTENTION or FAIL. If a planned browser/UAT class has no ASSESSMENT with browser/runtime actions and assertions, return NEEDS-ATTENTION. If no verification classes were planned, say that explicitly. Output sections `Acceptance Criteria` with checklist `[ ] Criterion | Evidence`, and `Verification Classes` with the table. End with one-line verdict: PASS if all criteria and classes are covered by evidence, NEEDS-ATTENTION if gaps exist."
 
 ### Step 2 - Synthesize Findings
 

package/src/resources/extensions/gsd/schemas/parsers.ts

@@ -67,7 +67,12 @@ export interface ParsedRoadmap {
 const TEMPLATE_TOKEN_RE = /\{\{[^}]+\}\}/;
 const H2_RE = /^##\s+(.+)$/gm;
 const H3_RE = /^###\s+(.+)$/gm;
-const MILESTONE_LINE_RE = /^-\s+\[([ x])\]\s+(M\d{3}):\s+(.+?)\s+(?:—|--|-)\s+(.+)$/gm;
+// A milestone line is single-line by construction. Every inter-token gap uses
+// horizontal-whitespace classes (`[^\S\n]`) rather than `\s`, because `\s`
+// matches newlines: a line missing a valid separator would otherwise let the
+// `\s+(?:—|--|-)\s+` clause "bridge" onto the NEXT bullet's `- `, consuming it
+// as the separator and silently swallowing the following well-formed milestone.
+const MILESTONE_LINE_RE = /^-[^\S\n]+\[([ x])\][^\S\n]+(M\d{3}):[^\S\n]+(.+?)[^\S\n]+(?:—|--|-)[^\S\n]+(.+)$/gm;
 const SLICE_HEADER_RE = /^###\s+(S\d{2})\s*(?:—|--|-)\s+(.+)$/m;
 const REQUIREMENT_HEADER_RE = /^###\s+(R\d{3})\s*(?:—|--|-)\s+(.+)$/m;
 

package/src/resources/extensions/gsd/state-reconciliation/drift/artifact-db.ts

@@ -335,21 +335,42 @@ function detectDiskSliceIdDivergenceForMilestone(
   return drifts;
 }
 
+type ArtifactDbDrift =
+  | DiskSliceIdDivergenceDrift
+  | ArtifactDbStatusDivergenceDrift
+  | CompletedMilestoneReopenedDrift;
+
+// #442 Phase 1.6: the three artifact/DB drift handlers (disk-slice-id,
+// artifact-db-status, completed-milestone-reopened) each call
+// detectArtifactDbDrift and then filter for their own kind — so the full
+// milestone→slice→task walk + artifact SQL + disk scan would run THREE times
+// per detection pass and discard 2/3 of the work. Memoize the result per
+// DriftContext so the three handlers share one computation. The key is the
+// ctx object, which detectAllDrift rebuilds for every pass (and which is
+// unreferenced once the pass ends, so the WeakMap entry is GC'd) — DB/disk
+// state is immutable within a single pass (repairs run only after detection),
+// so this is behavior-preserving. A fresh ctx (e.g. the maintenance command's
+// inline { basePath, state }) always recomputes.
+const _artifactDbDriftMemo = new WeakMap<DriftContext, ArtifactDbDrift[]>();
+
 export function detectArtifactDbDrift(
+  state: GSDState,
+  ctx: DriftContext,
+): ArtifactDbDrift[] {
+  const cached = _artifactDbDriftMemo.get(ctx);
+  if (cached) return cached;
+  const computed = computeArtifactDbDrift(state, ctx);
+  _artifactDbDriftMemo.set(ctx, computed);
+  return computed;
+}
+
+function computeArtifactDbDrift(
   _state: GSDState,
   ctx: DriftContext,
-): Array<
-  | DiskSliceIdDivergenceDrift
-  | ArtifactDbStatusDivergenceDrift
-  | CompletedMilestoneReopenedDrift
-> {
+): ArtifactDbDrift[] {
   if (!isDbAvailable()) return [];
 
-  const drifts: Array<
-    | DiskSliceIdDivergenceDrift
-    | ArtifactDbStatusDivergenceDrift
-    | CompletedMilestoneReopenedDrift
-  > = [];
+  const drifts: ArtifactDbDrift[] = [];
 
   for (const milestone of getAllMilestones()) {
     if (isClosedStatus(milestone.status)) continue;

package/src/resources/extensions/gsd/tests/artifact-db-drift-memo.test.ts

@@ -0,0 +1,66 @@
+// Project/App: gsd-pi
+// File Purpose: #442 Phase 1.6 — detectArtifactDbDrift is memoized per
+// DriftContext so the three artifact/DB drift handlers share one
+// milestone→slice→task walk per detection pass instead of recomputing it
+// three times. Asserts external behavior: same ctx returns the same result
+// (shared within a pass); a fresh ctx recomputes identical content (no
+// cross-pass leakage).
+
+import test from "node:test";
+import assert from "node:assert/strict";
+import { mkdtempSync, mkdirSync, rmSync, writeFileSync } from "node:fs";
+import { join } from "node:path";
+import { tmpdir } from "node:os";
+
+import { openDatabase, closeDatabase, insertMilestone, insertSlice } from "../gsd-db.ts";
+import { detectArtifactDbDrift } from "../state-reconciliation/drift/artifact-db.ts";
+import type { DriftContext } from "../state-reconciliation/types.ts";
+import type { GSDState } from "../types.ts";
+
+function stubState(): GSDState {
+  return {
+    activeMilestone: { id: "M001", title: "M" },
+    activeSlice: null,
+    activeTask: null,
+    phase: "executing",
+    recentDecisions: [],
+    blockers: [],
+    nextAction: "",
+    registry: [],
+    requirements: { active: 0, validated: 0, deferred: 0, outOfScope: 0, blocked: 0, total: 0 },
+    progress: { milestones: { done: 0, total: 1 } },
+  };
+}
+
+test("#442: detectArtifactDbDrift is memoized per DriftContext", (t) => {
+  const base = mkdtempSync(join(tmpdir(), "gsd-artifact-memo-"));
+  const sliceDir = join(base, ".gsd", "milestones", "M001", "slices", "S01");
+  mkdirSync(sliceDir, { recursive: true });
+  t.after(() => {
+    try { closeDatabase(); } catch { /* noop */ }
+    rmSync(base, { recursive: true, force: true });
+  });
+
+  openDatabase(join(base, ".gsd", "gsd.db"));
+  insertMilestone({ id: "M001", title: "M", status: "active" });
+  insertSlice({ id: "S01", milestoneId: "M001", title: "Slice", status: "pending", risk: "low", depends: [], sequence: 1 });
+  // A SUMMARY on disk while the slice is still pending = artifact/DB divergence.
+  writeFileSync(join(sliceDir, "S01-SUMMARY.md"), "# S01 Summary\n");
+
+  const state = stubState();
+
+  const ctx1: DriftContext = { basePath: base, state };
+  const first = detectArtifactDbDrift(state, ctx1);
+  const firstAgain = detectArtifactDbDrift(state, ctx1);
+
+  // Same ctx → cache hit → identical array reference (the 3 handlers in one
+  // pass share this exact result).
+  assert.strictEqual(firstAgain, first, "same ctx must return the memoized result");
+  assert.ok(first.length > 0, "fixture should produce at least one drift record");
+
+  // Fresh ctx → recomputed (distinct instance) but identical content.
+  const ctx2: DriftContext = { basePath: base, state };
+  const second = detectArtifactDbDrift(state, ctx2);
+  assert.notStrictEqual(second, first, "a fresh ctx must recompute, not reuse the prior pass");
+  assert.deepEqual(second, first, "recomputed result must be identical content");
+});