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

package/dist/resources/extensions/gsd/doctor-proactive.js

@@ -205,12 +205,17 @@ export async function preDispatchHealthGate(basePath) {
     catch {
         // 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 ?? {};
@@ -231,7 +236,7 @@ export async function preDispatchHealthGate(basePath) {
     // 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/dist/resources/extensions/gsd/guided-flow.js

@@ -1056,8 +1056,8 @@ async function buildDiscussPreparationContext(ctx, basePath, mode = "greenfield"
         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) {

package/dist/resources/extensions/gsd/markdown-renderer.js

@@ -8,14 +8,14 @@
 //
 // 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, getMilestoneSlices, getSliceTasks, getTask, getSlice, insertArtifact, getGateResults, } from "./gsd-db.js";
 import { resolveDir, resolveFile, resolveSliceFile, resolveSlicePath, gsdProjectionRoot, gsdRoot, buildMilestoneFileName, 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";
 // ─── Helpers ──────────────────────────────────────────────────────────────
@@ -562,34 +562,35 @@ export async function renderAllFromDb(basePath) {
     }
     return result;
 }
-/**
- * Detect stale renders by comparing DB state against file content.
- *
- * Checks:
- * 1. Roadmap checkbox states vs DB slice statuses
- * 2. Plan checkbox states vs DB task statuses
- * 3. Missing SUMMARY.md files for complete tasks with full_summary_md
- * 4. Missing SUMMARY.md/UAT.md files for complete slices with content
- *
- * Returns a list of stale entries with file path and reason.
- * Logs to stderr when stale files are detected.
- */
-export function detectStaleRenders(basePath) {
-    // Lazy-load parsers — intentional disk-vs-DB comparison requires parsers
-    const _require = createRequire(import.meta.url);
-    let parseRoadmap, parsePlan;
+const _projectionParseCache = new Map();
+registerCacheClearCallback(() => _projectionParseCache.clear());
+function parseProjectionByIdentity(path, parse) {
+    let st = null;
     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;
+        st = statSync(path);
     }
-    catch (e) {
-        logWarning("renderer", `parsers-legacy.js require failed, falling back to .ts: ${e.message}`);
-        const m = _require("./parsers-legacy.ts");
-        parseRoadmap = m.parseRoadmap;
-        parsePlan = m.parsePlan;
+    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) {
+    // 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 = [];
     const milestones = getAllMilestones();
     for (const milestone of milestones) {
@@ -598,8 +599,7 @@ export function detectStaleRenders(basePath) {
         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);
                 for (const slice of slices) {
                     const isCompleteInDb = isClosedStatus(slice.status);
                     const roadmapSlice = parsed.slices.find((s) => s.id === slice.id);
@@ -630,8 +630,7 @@ export function detectStaleRenders(basePath) {
             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);
                     for (const task of tasks) {
                         const isDoneInDb = isClosedStatus(task.status);
                         const planTask = parsed.tasks.find((t) => t.id === task.id);

package/dist/resources/extensions/gsd/mcp-filter.js

@@ -1,4 +1,5 @@
 import { existsSync, readFileSync } from "node:fs";
+import { homedir } from "node:os";
 import { resolve } from "node:path";
 import { resolveModelMcpConfig } from "./preferences-mcp.js";
 function isRecord(value) {
@@ -88,6 +89,11 @@ export function discoverBrowserMcpServerName(projectDir) {
 export function discoverMcpServerNames(projectDir) {
     return discoverMcpServers(projectDir).map((server) => server.name);
 }
+export function discoverUserMcpServerNames() {
+    const userSettingsPath = resolve(homedir(), ".claude", "settings.json");
+    const userSettings = readJsonFile(userSettingsPath, true);
+    return collectServerEntries(userSettings?.mcpServers).map((s) => s.name);
+}
 export function computeMcpDisallowedTools(modelId, mcpConfig, discoveredServers, workflowServerName) {
     if (!mcpConfig)
         return [];

package/dist/resources/extensions/gsd/native-git-bridge.js

@@ -11,6 +11,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.
 const NATIVE_GSD_GIT_ENABLED = process.env.GSD_ENABLE_NATIVE_GSD_GIT === "1";
@@ -40,6 +41,8 @@ function loadNative() {
 // ─── Fallback Helpers ──────────────────────────────────────────────────────
 /** Run a git command via execFileSync. Returns trimmed stdout. */
 function gitExec(basePath, args, allowFailure = false) {
+    // Counts git CLI shell-outs only (native libgit2 paths bypass this helper).
+    debugCount("gitInvocations");
     try {
         return execFileSync("git", args, {
             cwd: basePath,
@@ -64,6 +67,8 @@ function isRetryableGitError(err) {
     return code !== null && TRANSIENT_GIT_RETRY_CODES.has(code);
 }
 function execGitFileSyncWithRetry(basePath, args, options) {
+    // Counts git CLI shell-outs only (native libgit2 paths bypass this helper).
+    debugCount("gitInvocations");
     try {
         return execFileSync("git", args, {
             cwd: basePath,
@@ -77,6 +82,8 @@ function execGitFileSyncWithRetry(basePath, args, options) {
         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"],
@@ -88,6 +95,8 @@ function execGitFileSyncWithRetry(basePath, args, options) {
 }
 /** Run a git command via execFileSync. Returns trimmed stdout. */
 function gitFileExec(basePath, args, allowFailure = false) {
+    // Counts git CLI shell-outs only (native libgit2 paths bypass this helper).
+    debugCount("gitInvocations");
     try {
         return execFileSync("git", args, {
             cwd: basePath,
@@ -921,6 +930,42 @@ export function nativeMergeSquash(basePath, branch) {
         throw err;
     }
 }
+/**
+ * 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, branch) {
+    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) {
+        const stderr = err instanceof Error ? err.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/dist/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/dist/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/dist/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/dist/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/dist/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/dist/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/dist/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/dist/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/dist/resources/extensions/gsd/schemas/parsers.js

@@ -6,7 +6,12 @@
 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;
 function splitH2Sections(content) {

package/dist/resources/extensions/gsd/state-reconciliation/drift/artifact-db.js

@@ -250,7 +250,27 @@ function detectDiskSliceIdDivergenceForMilestone(basePath, milestoneId) {
     }
     return drifts;
 }
-export function detectArtifactDbDrift(_state, ctx) {
+// #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();
+export function detectArtifactDbDrift(state, ctx) {
+    const cached = _artifactDbDriftMemo.get(ctx);
+    if (cached)
+        return cached;
+    const computed = computeArtifactDbDrift(state, ctx);
+    _artifactDbDriftMemo.set(ctx, computed);
+    return computed;
+}
+function computeArtifactDbDrift(_state, ctx) {
     if (!isDbAvailable())
         return [];
     const drifts = [];