@opengsd/gsd-pi 1.1.1-dev.b2556262 → 1.2.0-dev.4813ead6

package/dist/resources/extensions/gsd/preferences.js

@@ -98,37 +98,41 @@ export function normalizePreferencesShape(loaded) {
 }
 // ─── Loading ────────────────────────────────────────────────────────────────
 export function loadGlobalGSDPreferences() {
-    return loadPreferencesFile(globalPreferencesPath(), "global")
-        ?? loadPreferencesFile(legacyGlobalPreferencesPathLowercase(), "global")
-        ?? loadPreferencesFile(legacyGlobalPreferencesPath(), "global");
+    return loadFirstUsablePreferencesFile([
+        globalPreferencesPath(),
+        legacyGlobalPreferencesPathLowercase(),
+        legacyGlobalPreferencesPath(),
+    ], "global");
 }
 export function loadProjectGSDPreferences(basePath) {
-    return loadPreferencesFile(projectPreferencesPath(basePath), "project")
-        ?? loadPreferencesFile(legacyProjectPreferencesPathLowercase(basePath), "project");
+    return loadFirstUsablePreferencesFile([
+        projectPreferencesPath(basePath),
+        legacyProjectPreferencesPathLowercase(basePath),
+    ], "project");
 }
 export function loadEffectiveGSDPreferences(basePath, opts) {
     const globalPreferences = loadGlobalGSDPreferences();
     const projectPreferences = loadProjectGSDPreferences(basePath);
-    const projectHasPlanningDepth = projectPreferences?.preferences.planning_depth !== undefined;
-    if (!globalPreferences && !projectPreferences)
+    const effectiveGlobalPreferences = globalPreferences?.ignored ? null : globalPreferences;
+    const effectiveProjectPreferences = projectPreferences?.ignored ? null : projectPreferences;
+    const projectHasPlanningDepth = effectiveProjectPreferences?.preferences.planning_depth !== undefined;
+    if (!effectiveGlobalPreferences && !effectiveProjectPreferences)
         return null;
     let result;
-    if (!globalPreferences) {
-        result = projectPreferences;
+    if (!effectiveGlobalPreferences) {
+        result = effectiveProjectPreferences;
     }
-    else if (!projectPreferences) {
-        result = globalPreferences;
+    else if (!effectiveProjectPreferences) {
+        result = mergePreferenceMetadata(effectiveGlobalPreferences, projectPreferences);
     }
     else {
-        const mergedWarnings = [
-            ...(globalPreferences.warnings ?? []),
-            ...(projectPreferences.warnings ?? []),
-        ];
+        const metadata = mergePreferenceMetadata(effectiveGlobalPreferences, effectiveProjectPreferences);
         result = {
-            path: projectPreferences.path,
+            path: effectiveProjectPreferences.path,
             scope: "project",
-            preferences: mergePreferences(globalPreferences.preferences, projectPreferences.preferences),
-            ...(mergedWarnings.length > 0 ? { warnings: mergedWarnings } : {}),
+            preferences: mergePreferences(effectiveGlobalPreferences.preferences, effectiveProjectPreferences.preferences),
+            ...(metadata.warnings ? { warnings: metadata.warnings } : {}),
+            ...(metadata.diagnostics ? { diagnostics: metadata.diagnostics } : {}),
         };
     }
     // Apply token-profile defaults as the lowest-priority layer so that
@@ -152,6 +156,35 @@ export function loadEffectiveGSDPreferences(basePath, opts) {
     result = stripInheritedPlanningDepth(result, projectHasPlanningDepth);
     return result;
 }
+function mergePreferenceMetadata(primary, secondary) {
+    const mergedWarnings = [
+        ...(primary.warnings ?? []),
+        ...(secondary?.warnings ?? []),
+    ];
+    const mergedDiagnostics = [
+        ...(primary.diagnostics ?? []),
+        ...(secondary?.diagnostics ?? []),
+    ];
+    return {
+        ...primary,
+        ...(mergedWarnings.length > 0 ? { warnings: mergedWarnings } : {}),
+        ...(mergedDiagnostics.length > 0 ? { diagnostics: mergedDiagnostics } : {}),
+    };
+}
+function loadFirstUsablePreferencesFile(paths, scope) {
+    let ignoredPreferences = null;
+    for (const path of paths) {
+        const loaded = loadPreferencesFile(path, scope);
+        if (!loaded)
+            continue;
+        if (!loaded.ignored)
+            return mergePreferenceMetadata(loaded, ignoredPreferences);
+        ignoredPreferences = ignoredPreferences
+            ? mergePreferenceMetadata(ignoredPreferences, loaded)
+            : loaded;
+    }
+    return ignoredPreferences;
+}
 function stripInheritedPlanningDepth(loaded, projectHasPlanningDepth) {
     if (projectHasPlanningDepth || loaded.preferences.planning_depth === undefined) {
         return loaded;
@@ -167,16 +200,39 @@ function loadPreferencesFile(path, scope) {
     if (!existsSync(path))
         return null;
     const raw = readFileSync(path, "utf-8");
-    const preferences = parsePreferencesMarkdown(raw);
-    if (!preferences)
+    const parsed = parsePreferencesMarkdownWithDiagnostics(raw);
+    if (!parsed.preferences && parsed.diagnostics.length === 0)
         return null;
+    const ignored = parsed.diagnostics.some((diagnostic) => diagnostic.ignored === true);
+    const preferences = parsed.preferences ?? {};
     const validation = validatePreferences(preferences);
     const allWarnings = [...validation.warnings, ...validation.errors];
+    const diagnostics = [
+        ...parsed.diagnostics.map((diagnostic) => ({ ...diagnostic, path, scope })),
+        ...validation.errors.map((message) => ({
+            path,
+            scope,
+            severity: "error",
+            kind: "validation",
+            message,
+            sanitized: true,
+        })),
+        ...validation.warnings.map((message) => ({
+            path,
+            scope,
+            severity: "warning",
+            kind: "validation",
+            message,
+            sanitized: true,
+        })),
+    ];
     return {
         path,
         scope,
         preferences: validation.preferences,
+        ...(ignored ? { ignored: true } : {}),
         ...(allWarnings.length > 0 ? { warnings: allWarnings } : {}),
+        ...(diagnostics.length > 0 ? { diagnostics } : {}),
     };
 }
 let _warnedUnrecognizedFormat = false;
@@ -189,20 +245,35 @@ export function _resetParseWarningFlag() {
 }
 /** @internal Exported for testing only */
 export function parsePreferencesMarkdown(content) {
+    return parsePreferencesMarkdownWithDiagnostics(content).preferences;
+}
+function parsePreferencesMarkdownWithDiagnostics(content) {
     // Use indexOf instead of [\s\S]*? regex to avoid backtracking (#468)
     const startMarker = content.startsWith('---\r\n') ? '---\r\n' : '---\n';
     if (content.startsWith(startMarker)) {
         const searchStart = startMarker.length;
         const endIdx = content.indexOf('\n---', searchStart);
-        if (endIdx === -1)
-            return null;
+        if (endIdx === -1) {
+            return {
+                preferences: null,
+                diagnostics: [{
+                        severity: "error",
+                        kind: "parse",
+                        message: "preferences frontmatter is missing a closing --- delimiter",
+                        ignored: true,
+                    }],
+            };
+        }
         const block = content.slice(searchStart, endIdx);
-        return parseFrontmatterBlock(block.replace(/\r/g, ''));
+        return parseFrontmatterBlockWithDiagnostics(block.replace(/\r/g, ''), 1);
     }
     // Fallback: heading+list format (e.g. "## Git\n- isolation: none") (#2036)
     // GSD agents may write preferences files without frontmatter delimiters.
     if (/^##\s+\w/m.test(content)) {
-        return parseHeadingListFormat(content);
+        return {
+            preferences: parseHeadingListFormat(content),
+            diagnostics: [],
+        };
     }
     // Warn when a non-empty file exists but lacks frontmatter delimiters (#2036).
     if (content.trim().length > 0 && !_warnedUnrecognizedFormat) {
@@ -210,16 +281,37 @@ export function parsePreferencesMarkdown(content) {
         console.warn("[GSD] Warning: preferences file has unrecognized format — content does not use YAML frontmatter delimiters (---). " +
             "Wrap your preferences in --- fences. See https://github.com/open-gsd/gsd-pi/issues/2036");
     }
-    return null;
+    return {
+        preferences: null,
+        diagnostics: content.trim().length > 0
+            ? [{
+                    severity: "error",
+                    kind: "parse",
+                    message: "preferences file has unrecognized format; expected YAML frontmatter delimiters (---) or markdown preference sections",
+                    ignored: true,
+                }]
+            : [],
+    };
 }
 let _warnedFrontmatterParse = false;
-function parseFrontmatterBlock(frontmatter) {
+function parseFrontmatterBlockWithDiagnostics(frontmatter, lineOffset) {
     try {
         const parsed = parseYaml(frontmatter);
         if (typeof parsed !== 'object' || parsed === null) {
-            return {};
+            return {
+                preferences: {},
+                diagnostics: [{
+                        severity: "error",
+                        kind: "validation",
+                        message: "preferences frontmatter must be a YAML object",
+                        ignored: true,
+                    }],
+            };
         }
-        return normalizeParsedPreferences(parsed);
+        return {
+            preferences: normalizeParsedPreferences(parsed),
+            diagnostics: [],
+        };
     }
     catch (e) {
         // Warn at most once per session to avoid flooding TUI (#3376)
@@ -227,9 +319,35 @@ function parseFrontmatterBlock(frontmatter) {
             _warnedFrontmatterParse = true;
             logWarning("guided", `YAML parse error in preferences frontmatter (suppressing further): ${e.message}`);
         }
-        return {};
+        const location = extractYamlErrorLocation(e, lineOffset);
+        return {
+            preferences: {},
+            diagnostics: [{
+                    severity: "error",
+                    kind: "parse",
+                    message: cleanYamlErrorMessage(e),
+                    ...(location.line !== undefined ? { line: location.line } : {}),
+                    ...(location.column !== undefined ? { column: location.column } : {}),
+                    ignored: true,
+                }],
+        };
     }
 }
+function cleanYamlErrorMessage(error) {
+    const message = error instanceof Error ? error.message : String(error);
+    const firstLine = message.split("\n")[0]?.trim() ?? "unknown YAML parse error";
+    return firstLine.replace(/\s+at line \d+, column \d+:?$/, "");
+}
+function extractYamlErrorLocation(error, lineOffset) {
+    const linePos = error?.linePos;
+    const first = Array.isArray(linePos) ? linePos[0] : undefined;
+    const line = typeof first?.line === "number" ? first.line + lineOffset : undefined;
+    const column = typeof first?.col === "number" ? first.col : undefined;
+    return {
+        ...(line !== undefined ? { line } : {}),
+        ...(column !== undefined ? { column } : {}),
+    };
+}
 function normalizeParsedPreferences(preferences) {
     const remoteQuestions = preferences.remote_questions;
     if (remoteQuestions && typeof remoteQuestions === "object" && typeof remoteQuestions.channel_id === "number") {

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

@@ -37,6 +37,7 @@ Use `subagent` only when useful: reviewer, security, or tester. Apply findings b
 9. If requirement status changed, call `gsd_requirement_update`; do not write `.gsd/REQUIREMENTS.md` directly.
 10. Prepare `gsd_slice_complete` content with camelCase fields `milestoneId`, `sliceId`, `sliceTitle`, `oneLiner`, `narrative`, `verification`, and `uatContent`.
 11. Draft concrete UAT with preconditions, steps, expected outcomes, edge cases, and UAT Type.
+    **Web apps:** when inlined Web App UAT guidance is present, declare `browser-executable` or `runtime-executable` (not `artifact-driven`) for localhost/browser/screenshot steps; include dev-server preconditions and name Playwright specs when they exist.
 12. Review the inlined task-summary excerpts for DECISIONS.md/KNOWLEDGE.md-worthy decisions and gotchas. Read full `*-SUMMARY.md` only if needed. Capture with `capture_thought`; do not append knowledge files.
 13. When verification passes, call `gsd_slice_complete`. The DB-backed tool is the canonical write path. Do **not** manually write `{{sliceSummaryPath}}`. Do **not** manually write `{{sliceUatPath}}`. Do not edit roadmap checkboxes.
 14. Do not run git commands.

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/execute-task.md

@@ -32,6 +32,8 @@ You execute. The inlined task plan is authoritative. Verify referenced files and
 - Prior task summaries:
 {{priorTaskLines}}
 
+{{onDemandContext}}
+
 ## Execution Rules
 
 1. Tersely narrate transitions, decisions, and verification outcomes between tool-call clusters.

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

@@ -36,11 +36,11 @@ After the opening answer, classify project shape as **`simple`** or **`complex`*
 
 Persist the verdict through `gsd_summary_save` with `artifact_type: "PROJECT"` into `## Project Shape`; downstream `discuss-requirements`, `discuss-milestone`, and `discuss-slice` read the rendered projection.
 
+When the project is browser-facing (web app, SPA, static site with UI, Next/React/Vue, etc.), also record **`Web stack:`** under `## Project Shape` (framework + whether Playwright or browser UAT is expected). Downstream planning uses this to choose `browser-executable` / `runtime-executable` UAT instead of deferring UI proof to humans.
+
 ### 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 +53,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
 
@@ -105,7 +105,7 @@ Once the user confirms depth:
 
 1. Use the **Project** output template (inlined above).
 2. Call `gsd_summary_save` with `artifact_type: "PROJECT"` and full project markdown as `content`; omit `milestone_id`. The tool persists the DB-backed PROJECT artifact and renders `.gsd/PROJECT.md`. Preserve the user's terms and framing.
-3. The `## Project Shape` section MUST contain `**Complexity:** simple` or `**Complexity:** complex` (matching the verdict you announced) plus a one-line `**Why:**` rationale. Downstream stages read this line.
+3. The `## Project Shape` section MUST contain `**Complexity:** simple` or `**Complexity:** complex` (matching the verdict you announced) plus a one-line `**Why:**` rationale. For browser-facing projects, also include `**Web stack:**` (framework and expected browser/Playwright UAT approach). Downstream stages read these lines.
 4. The `## Capability Contract` section MUST reference `.gsd/REQUIREMENTS.md` — that file does not yet exist; the next stage (`discuss-requirements`) will produce it.
 5. The `## Milestone Sequence` MUST list at least M001 with title and one-liner. Subsequent milestones may be listed as known intents; they will be elaborated in their own discuss-milestone stages.
 6. Do NOT use `artifact_type: "CONTEXT"` and do NOT pass `milestone_id: "PROJECT"`; that creates a fake milestone named PROJECT.

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-milestone.md

@@ -47,6 +47,8 @@ If milestone research is inlined, trust it and skip redundant exploration. If fi
 
 Narrate decomposition reasoning in complete sentences: grouping, risk order, verification strategy.
 
+**Web apps:** when inlined Web App UAT guidance is present, set milestone `Verification Classes` → UAT to browser-observable acceptance (Playwright spec or `browser_*` checks). Order an early slice to add Playwright smoke scaffolding when the dependency is missing.
+
 Then:
 1. Use the **Roadmap** output template from the inlined context above
 2. {{skillActivation}}

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

@@ -38,9 +38,10 @@ 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/`.
+   **Web apps:** when inlined Web App UAT guidance is present, follow it — add Playwright smoke scaffolding on the first UI slice if missing, name localhost preconditions, and plan verification commands that match browser-capable UAT modes at slice closeout.
 6. Include Threat Surface (Q3), Requirement Impact (Q4), proof level, observability, integration closure, Failure Modes (Q5), Load Profile (Q6), and Negative Tests (Q7) only where applicable.
 7. Right-size tasks. Simple slices can be one task; split only when context, ownership, or verification boundaries justify it.
 8. Task `verify` commands must be safe, simple commands. Do not use shell pipes, redirects, semicolons, backticks, command substitution, output trimming, or grep regex alternation with `|`. If multiple checks are needed, create a small test file and run it with `node --test` or a package test script, or use separate simple commands joined only with `&&`. For absence checks, verify a pattern does not exist with `! grep -q 'pattern' file` or `! rg -q 'pattern' file`; do not use `grep -c` or `rg -c` to assert zero matches because count commands exit 1 when they find zero matches, and the verification gate treats that as failure.

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

@@ -63,6 +63,7 @@ Then:
    - `{{taskPlanTemplatePath}}`
 2. {{skillActivation}} Record the installed skills you expect executors to use in each task plan's `skills_used` frontmatter.
 3. Define slice-level verification: the objective stopping condition. Plan real test files with real assertions; for simple slices, executable commands are fine.
+   **Web apps:** when inlined Web App UAT guidance is present, follow it for Playwright scaffolding and browser-capable verification commands.
 4. For non-trivial slices, plan observability / proof level / integration closure, threat surface, and requirement impact. Omit entirely for simple slices.
 5. Decompose the slice into tasks that fit one context window each. Every task passed to `gsd_plan_slice` must use the exact keys `taskId`, `title`, `description`, `estimate`, `files`, `verify`, `inputs`, `expectedOutput`, and optional `observabilityImpact`. Put Why / Do / Done-when detail in `description`. `files`, `inputs`, and `expectedOutput` must be JSON arrays of strings, even for one path (for example, `"expectedOutput": ["src/index.ts"]`, never `"expectedOutput": "src/index.ts"`). `expectedOutput` is path-only: list only files the task creates or overwrites, and use `[]` for pure verification tasks.
 6. **Persist planning state through `gsd_plan_slice`.** Call it with the full payload. The tool writes to the DB and renders `{{outputPath}}` and `{{slicePath}}/tasks/T##-PLAN.md` automatically. Do NOT rely on direct `PLAN.md` writes.

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/system.md

@@ -158,7 +158,7 @@ Fix root causes, not symptoms. If applying temporary mitigation, label it and pr
 - State uncertainty plainly: "Not sure this handles X - testing it." No performed confidence, no hedging paragraphs.
 - All user-visible narration must be grammatical English. Do not emit compressed planner notes like "Need inspect X". If it fits a commit comment or standup note, it is acceptable.
 - When debugging, stay curious. Problems are puzzles. Say what's interesting about the failure before reaching for fixes.
-- After completing a task, give a brief summary and 2-4 numbered next-step options; last option is always "Other". Omit the list for strict output formats.
+- After completing a task, give a brief summary and 2-4 numbered next-step options; last option is always "Other". Omit the list for strict output formats, or when the active workflow prompt already ends with its own explicit "Next steps:" handoff block — in that case follow the workflow's handoff and do not add a second list.
 
   If any next step is destructive/outward-facing, present it via `ask_user_questions` and wait for the user's answer before execution. Do not execute a next-step item from a prior plain-text numbered list without fresh confirmation.
 

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/provider-payload-policy.js

@@ -0,0 +1,83 @@
+/**
+ * Provider Payload Policy - ordered shaping of provider request payloads.
+ *
+ * The order is intentional:
+ * 1. observation budgeting masks old tool results in auto-mode,
+ * 2. display truncation caps tool-result text for every mode,
+ * 3. the protected Source Context Block is appended after truncation,
+ * 4. supported models receive the configured service tier.
+ */
+import { createObservationMask, createResponsesInputObservationMask, truncateContextResultMessages, truncateResponsesInputResultItems, } from "./context-masker.js";
+import { getSourceObservationStore, isAutoActive } from "./auto-runtime-state.js";
+import { loadEffectiveGSDPreferences } from "./preferences.js";
+import { getEffectiveServiceTier, supportsServiceTier } from "./service-tier.js";
+import { injectSourceContextBlockIntoPayload } from "./source-observations.js";
+const DEFAULT_OBSERVATION_MASK_TURNS = 8;
+const DEFAULT_TOOL_RESULT_MAX_CHARS = 800;
+export const DEFAULT_PROVIDER_PAYLOAD_POLICY_DEPS = {
+    isAutoActive,
+    loadContextManagementConfig: () => loadEffectiveGSDPreferences()?.preferences.context_management,
+    renderSourceContextBlock: () => getSourceObservationStore().renderActiveBlock(),
+    getEffectiveServiceTier,
+    supportsServiceTier,
+};
+export function applyProviderPayloadPolicy({ payload, modelId, deps: overrides, }) {
+    const deps = { ...DEFAULT_PROVIDER_PAYLOAD_POLICY_DEPS, ...overrides };
+    try {
+        applyContextManagement(payload, deps);
+    }
+    catch {
+        // Provider payload shaping should not block a request when optional
+        // context management preferences or adapters fail.
+    }
+    try {
+        applySourceContextBlock(payload, deps);
+    }
+    catch {
+        // Source observations are opportunistic; execution can continue without
+        // an injected block.
+    }
+    applyServiceTier(payload, modelId, deps);
+    return payload;
+}
+function applyContextManagement(payload, deps) {
+    const config = deps.loadContextManagementConfig();
+    applyObservationBudget(payload, config, deps.isAutoActive());
+    applyDisplayTruncation(payload, config);
+}
+function applyObservationBudget(payload, config, autoActive) {
+    if (!autoActive || config?.observation_masking === false)
+        return;
+    const keepTurns = config?.observation_mask_turns ?? DEFAULT_OBSERVATION_MASK_TURNS;
+    if (Array.isArray(payload.messages)) {
+        payload.messages = createObservationMask(keepTurns)(payload.messages);
+    }
+    if (Array.isArray(payload.input)) {
+        payload.input = createResponsesInputObservationMask(keepTurns)(payload.input);
+    }
+}
+function applyDisplayTruncation(payload, config) {
+    const maxChars = config?.tool_result_max_chars ?? DEFAULT_TOOL_RESULT_MAX_CHARS;
+    if (Array.isArray(payload.messages)) {
+        payload.messages = truncateContextResultMessages(payload.messages, maxChars);
+    }
+    if (Array.isArray(payload.input)) {
+        payload.input = truncateResponsesInputResultItems(payload.input, maxChars);
+    }
+}
+function applySourceContextBlock(payload, deps) {
+    if (!deps.isAutoActive())
+        return;
+    const sourceContextBlock = deps.renderSourceContextBlock();
+    if (!sourceContextBlock)
+        return;
+    Object.assign(payload, injectSourceContextBlockIntoPayload(payload, sourceContextBlock));
+}
+function applyServiceTier(payload, modelId, deps) {
+    if (!modelId)
+        return;
+    const tier = deps.getEffectiveServiceTier();
+    if (!tier || !deps.supportsServiceTier(modelId))
+        return;
+    payload.service_tier = tier;
+}

package/dist/resources/extensions/gsd/pull-request-process.js

@@ -0,0 +1,13 @@
+// Project/App: gsd-pi
+// File Purpose: Process-level pull request policy for GSD-generated PRs.
+import { createDraftPR } from "./git-service.js";
+import { buildPrEvidence, } from "./pr-evidence.js";
+export function buildPullRequestEvidence(input) {
+    return buildPrEvidence({
+        ...input,
+        aiAssisted: false,
+    });
+}
+export function createDraftPullRequestFromEvidence(basePath, milestoneId, evidence, options, deps = { createDraftPR }) {
+    return deps.createDraftPR(basePath, milestoneId, evidence.title, evidence.body, options);
+}