gsd-pi 2.71.0 → 2.72.0-dev.8f83716

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

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

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

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

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

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

package/dist/resources/extensions/gsd/prompts/guided-resume-task.md

@@ -1 +1 @@
-Resume interrupted work. Find the continue file (`{{sliceId}}-CONTINUE.md` or `continue.md`) in slice {{sliceId}} of milestone {{milestoneId}}, read it, and use it as the recovery contract for where to pick up. Do **not** delete the continue file immediately. Keep it until the task is successfully completed or you have written a newer summary/continue artifact that clearly supersedes it. If the resumed attempt fails again, update or replace the continue file so no recovery context is lost. {{skillActivation}}
+Resume interrupted work. Find the continue file (`{{sliceId}}-CONTINUE.md` or `continue.md`) in slice {{sliceId}} of milestone {{milestoneId}}, read it, and use it as the recovery contract for where to pick up. Before you create any expected artifact or output file, check whether it already exists and read it first — a prior session may already have started or completed that work. Do **not** delete the continue file immediately. Keep it until the task is successfully completed or you have written a newer summary/continue artifact that clearly supersedes it. If the resumed attempt fails again, update or replace the continue file so no recovery context is lost. {{skillActivation}}

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

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

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

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

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

@@ -18,6 +18,8 @@ All relevant context has been preloaded below — the roadmap, all slice summari
 
 {{inlinedContext}}
 
+{{gatesToEvaluate}}
+
 ## Execution Protocol
 
 ### Step 1 — Dispatch Parallel Reviewers
@@ -31,7 +33,7 @@ Prompt: "Review milestone {{milestoneId}} requirements coverage. Working directo
 Prompt: "Review milestone {{milestoneId}} cross-slice integration. Working directory: {{workingDirectory}}. Read `{{roadmapPath}}` and find the boundary map (produces/consumes contracts). For each boundary, check that the producing slice's SUMMARY confirms it produced the artifact, and the consuming slice's SUMMARY confirms it consumed it. Output a markdown table: Boundary | Producer Summary | Consumer Summary | Status. End with a 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/{{milestoneId}}/CONTEXT.md` for acceptance criteria. Check for ASSESSMENT files in each slice directory. Verify each acceptance criterion maps to either a passing assessment result or clear SUMMARY evidence. Output a checklist: [ ] Criterion | Evidence. End with a one-line verdict: PASS if all criteria met, NEEDS-ATTENTION if gaps exist."
+Prompt: "Review milestone {{milestoneId}} assessment evidence and acceptance criteria. Working directory: {{workingDirectory}}. Read `.gsd/{{milestoneId}}/CONTEXT.md` for acceptance criteria. Check for ASSESSMENT files in each slice directory. Verify each acceptance criterion maps to either a passing assessment result or clear SUMMARY evidence. Then review the inlined milestone verification classes from planning. For each non-empty planned class, output a markdown table: Class | Planned Check | Evidence | Verdict. Use the exact class names `Contract`, `Integration`, `Operational`, and `UAT` whenever those classes are present. If no verification classes were planned, say that explicitly. Output two sections: `Acceptance Criteria` with a checklist `[ ] Criterion | Evidence`, and `Verification Classes` with the table. End with a one-line verdict: PASS if all criteria and verification classes are covered, NEEDS-ATTENTION if gaps exist."
 
 ### Step 2 — Synthesize Findings
 
@@ -70,6 +72,7 @@ reviewers: 3
 ```
 
 Call `gsd_validate_milestone` with the camelCase fields `milestoneId`, `verdict`, `remediationRound`, `successCriteriaChecklist`, `sliceDeliveryAudit`, `crossSliceIntegration`, `requirementCoverage`, `verdictRationale`, and `remediationPlan` when needed. If you include verification-class analysis, pass it in `verificationClasses`.
+Extract the `Verification Classes` subsection from Reviewer C and pass it verbatim in `verificationClasses` so the persisted validation output uses the canonical class names `Contract`, `Integration`, `Operational`, and `UAT`.
 
 **DB access safety:** Do NOT query `.gsd/gsd.db` directly via `sqlite3` or `node -e require('better-sqlite3')` — the engine owns the WAL connection. Use `gsd_milestone_status` to read milestone and slice state. All data you need is already inlined in the context above or accessible via the `gsd_*` tools. Direct DB access corrupts the WAL and bypasses tool-level validation.
 

package/dist/resources/extensions/gsd/session-model-override.js

@@ -0,0 +1,25 @@
+const sessionOverrides = new Map();
+function normalizeSessionId(sessionId) {
+    return typeof sessionId === "string" ? sessionId.trim() : "";
+}
+export function setSessionModelOverride(sessionId, override) {
+    const key = normalizeSessionId(sessionId);
+    if (!key)
+        return;
+    sessionOverrides.set(key, {
+        provider: override.provider,
+        id: override.id,
+    });
+}
+export function getSessionModelOverride(sessionId) {
+    const key = normalizeSessionId(sessionId);
+    if (!key)
+        return undefined;
+    return sessionOverrides.get(key);
+}
+export function clearSessionModelOverride(sessionId) {
+    const key = normalizeSessionId(sessionId);
+    if (!key)
+        return;
+    sessionOverrides.delete(key);
+}

package/dist/resources/extensions/gsd/shortcut-defs.js

@@ -0,0 +1,40 @@
+// Canonical GSD shortcut definitions used by registration, help text, and overlays.
+import { formatShortcut } from "./files.js";
+export const GSD_SHORTCUTS = {
+    dashboard: {
+        key: "g",
+        action: "Open GSD dashboard",
+        command: "/gsd status",
+        hasFallback: true,
+    },
+    notifications: {
+        key: "n",
+        action: "Open notification history",
+        command: "/gsd notifications",
+        hasFallback: true,
+    },
+    parallel: {
+        key: "p",
+        action: "Open parallel worker monitor",
+        command: "/gsd parallel watch",
+        hasFallback: false, // Ctrl+Shift+P conflicts with cycleModelBackward
+    },
+};
+function combo(prefix, key) {
+    return `${prefix}${key.toUpperCase()}`;
+}
+export function primaryShortcutCombo(id) {
+    return combo("Ctrl+Alt+", GSD_SHORTCUTS[id].key);
+}
+export function fallbackShortcutCombo(id) {
+    return combo("Ctrl+Shift+", GSD_SHORTCUTS[id].key);
+}
+export function shortcutPair(id, formatter = (combo) => combo) {
+    const primary = formatter(primaryShortcutCombo(id));
+    if (!GSD_SHORTCUTS[id].hasFallback)
+        return primary;
+    return `${primary} / ${formatter(fallbackShortcutCombo(id))}`;
+}
+export function formattedShortcutPair(id) {
+    return shortcutPair(id, formatShortcut);
+}

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

@@ -13,7 +13,7 @@ import { existsSync, readdirSync, readFileSync } from 'node:fs';
 import { debugCount, debugTime } from './debug-logger.js';
 import { logWarning, logError } from './workflow-logger.js';
 import { extractVerdict } from './verdict-parser.js';
-import { isDbAvailable, wasDbOpenAttempted, getAllMilestones, getMilestone, getMilestoneSlices, getSliceTasks, getReplanHistory, getSlice, insertMilestone, insertSlice, insertTask, updateTaskStatus, getPendingSliceGateCount, } from './gsd-db.js';
+import { isDbAvailable, wasDbOpenAttempted, getAllMilestones, getMilestone, getMilestoneSlices, getSliceTasks, getReplanHistory, getSlice, insertMilestone, insertSlice, insertTask, updateTaskStatus, getPendingGateCountForTurn, } from './gsd-db.js';
 /**
  * A "ghost" milestone directory contains only META.json (and no substantive
  * files like CONTEXT, CONTEXT-DRAFT, ROADMAP, or SUMMARY).  These appear when
@@ -724,7 +724,14 @@ export async function deriveStateFromDb(basePath) {
             };
         }
     }
-    const pendingGateCount = getPendingSliceGateCount(activeMilestone.id, activeSlice.id);
+    // ── Quality gate evaluation check ──────────────────────────────────
+    // Pause before execution only when gates owned by the `gate-evaluate`
+    // turn (Q3/Q4) are still pending. Q8 is also `scope:"slice"` but is
+    // owned by `complete-slice`, so it must NOT block the evaluating-gates
+    // phase — otherwise auto-loop stalls forever waiting for a gate that
+    // this turn never evaluates. See gate-registry.ts for the ownership map.
+    // Slices with zero gate rows (pre-feature or simple) skip straight through.
+    const pendingGateCount = getPendingGateCountForTurn(activeMilestone.id, activeSlice.id, "gate-evaluate");
     if (pendingGateCount > 0) {
         return {
             activeMilestone, activeSlice, activeTask: null,

package/dist/resources/extensions/gsd/tools/complete-slice.js

@@ -9,7 +9,8 @@
 import { join } from "node:path";
 import { mkdirSync } from "node:fs";
 import { isClosedStatus } from "../status-guards.js";
-import { transaction, insertMilestone, insertSlice, getSlice, getSliceTasks, getMilestone, updateSliceStatus, setSliceSummaryMd, } from "../gsd-db.js";
+import { transaction, insertMilestone, insertSlice, getSlice, getSliceTasks, getMilestone, updateSliceStatus, setSliceSummaryMd, saveGateResult, getPendingGatesForTurn, } from "../gsd-db.js";
+import { getGatesForTurn } from "../gate-registry.js";
 import { resolveSlicePath, clearPathCache } from "../paths.js";
 import { checkOwnership, sliceUnitKey } from "../unit-ownership.js";
 import { saveFile, clearParseCache } from "../files.js";
@@ -19,6 +20,19 @@ import { renderAllProjections } from "../workflow-projections.js";
 import { writeManifest } from "../workflow-manifest.js";
 import { appendEvent } from "../workflow-events.js";
 import { logWarning, logError } from "../workflow-logger.js";
+/**
+ * Map a complete-slice-owned gate id to the CompleteSliceParams field
+ * whose presence drives `pass` vs. `omitted`. Keep this in lockstep with
+ * the gates declared in gate-registry.ts under ownerTurn "complete-slice".
+ */
+function sliceGateFieldForId(id, params) {
+    switch (id) {
+        case "Q8":
+            return params.operationalReadiness;
+        default:
+            return undefined;
+    }
+}
 /**
  * Render slice summary markdown matching the template format.
  * YAML frontmatter uses snake_case keys for parseSummary() compatibility.
@@ -134,6 +148,10 @@ ${reqSurfaced}
 
 ${reqInvalidated}
 
+## Operational Readiness
+
+${params.operationalReadiness?.trim() || "None."}
+
 ## Deviations
 
 ${params.deviations || "None."}
@@ -271,6 +289,39 @@ export async function handleCompleteSlice(params, basePath) {
     }
     // Store rendered markdown in DB for D004 recovery
     setSliceSummaryMd(params.milestoneId, params.sliceId, summaryMd, uatMd);
+    // ── Close gates owned by complete-slice (Q8) ───────────────────────────
+    // Each owned gate maps to a specific summary section via the registry.
+    // If the caller populated the corresponding field, record `pass`; if the
+    // field is empty, record `omitted`. Without this loop, Q8 would stay
+    // pending forever and block future state derivation (see gate-registry).
+    try {
+        const pendingGates = getPendingGatesForTurn(params.milestoneId, params.sliceId, "complete-slice");
+        if (pendingGates.length > 0) {
+            const ownedDefs = new Map(getGatesForTurn("complete-slice").map((g) => [g.id, g]));
+            for (const row of pendingGates) {
+                const def = ownedDefs.get(row.gate_id);
+                if (!def)
+                    continue;
+                // Map gate id → param field it maps to. Keep the map local so
+                // adding a new complete-slice gate is a single place change.
+                const field = sliceGateFieldForId(def.id, params);
+                const hasContent = typeof field === "string" && field.trim().length > 0;
+                saveGateResult({
+                    milestoneId: params.milestoneId,
+                    sliceId: params.sliceId,
+                    gateId: def.id,
+                    verdict: hasContent ? "pass" : "omitted",
+                    rationale: hasContent
+                        ? `${def.promptSection} section populated in slice summary`
+                        : `${def.promptSection} section left empty — recorded as omitted`,
+                    findings: hasContent ? field.trim() : "",
+                });
+            }
+        }
+    }
+    catch (gateErr) {
+        logWarning("tool", `complete-slice gate close warning for ${params.milestoneId}/${params.sliceId}: ${gateErr.message}`);
+    }
     // Invalidate all caches
     invalidateStateCache();
     clearPathCache();

package/dist/resources/extensions/gsd/tools/complete-task.js

@@ -9,7 +9,8 @@
 import { join } from "node:path";
 import { mkdirSync } from "node:fs";
 import { isClosedStatus } from "../status-guards.js";
-import { transaction, insertMilestone, insertSlice, insertTask, insertVerificationEvidence, getMilestone, getSlice, getTask, updateTaskStatus, setTaskSummaryMd, deleteVerificationEvidence, } from "../gsd-db.js";
+import { transaction, insertMilestone, insertSlice, insertTask, insertVerificationEvidence, getMilestone, getSlice, getTask, updateTaskStatus, setTaskSummaryMd, deleteVerificationEvidence, saveGateResult, getPendingGatesForTurn, } from "../gsd-db.js";
+import { getGatesForTurn } from "../gate-registry.js";
 import { resolveSliceFile, resolveTasksDir, clearPathCache } from "../paths.js";
 import { checkOwnership, taskUnitKey } from "../unit-ownership.js";
 import { saveFile, clearParseCache } from "../files.js";
@@ -19,6 +20,23 @@ import { renderAllProjections, renderSummaryContent } from "../workflow-projecti
 import { writeManifest } from "../workflow-manifest.js";
 import { appendEvent } from "../workflow-events.js";
 import { logWarning, logError } from "../workflow-logger.js";
+/**
+ * Map an execute-task-owned gate id to the CompleteTaskParams field whose
+ * presence drives `pass` vs. `omitted`. Keep in lockstep with the gates
+ * declared in gate-registry.ts under ownerTurn "execute-task".
+ */
+function taskGateFieldForId(id, params) {
+    switch (id) {
+        case "Q5":
+            return params.failureModes;
+        case "Q6":
+            return params.loadProfile;
+        case "Q7":
+            return params.negativeTests;
+        default:
+            return undefined;
+    }
+}
 /**
  * Normalize a list parameter that may arrive as a string (newline-delimited
  * bullet list from the LLM) into a string array (#3361).
@@ -189,6 +207,38 @@ export async function handleCompleteTask(params, basePath) {
     }
     // Store rendered markdown in DB for D004 recovery
     setTaskSummaryMd(params.milestoneId, params.sliceId, params.taskId, summaryMd);
+    // ── Close gates owned by execute-task (Q5/Q6/Q7) for this task ────────
+    // Each gate id maps to a specific params field via taskGateFieldForId.
+    // When the model populates the field, record `pass`; when it's empty,
+    // record `omitted`. Task-scoped rows are filtered by taskId so a single
+    // task's completion doesn't touch sibling tasks' gate rows.
+    try {
+        const pendingGates = getPendingGatesForTurn(params.milestoneId, params.sliceId, "execute-task", params.taskId);
+        if (pendingGates.length > 0) {
+            const ownedDefs = new Map(getGatesForTurn("execute-task").map((g) => [g.id, g]));
+            for (const row of pendingGates) {
+                const def = ownedDefs.get(row.gate_id);
+                if (!def)
+                    continue;
+                const field = taskGateFieldForId(def.id, params);
+                const hasContent = typeof field === "string" && field.trim().length > 0;
+                saveGateResult({
+                    milestoneId: params.milestoneId,
+                    sliceId: params.sliceId,
+                    taskId: params.taskId,
+                    gateId: def.id,
+                    verdict: hasContent ? "pass" : "omitted",
+                    rationale: hasContent
+                        ? `${def.promptSection} section populated in task summary`
+                        : `${def.promptSection} section left empty — recorded as omitted`,
+                    findings: hasContent ? field.trim() : "",
+                });
+            }
+        }
+    }
+    catch (gateErr) {
+        logWarning("tool", `complete-task gate close warning for ${params.milestoneId}/${params.sliceId}/${params.taskId}: ${gateErr.message}`);
+    }
     // Invalidate all caches
     invalidateStateCache();
     clearPathCache();

package/dist/resources/extensions/gsd/tools/workflow-tool-executors.js

@@ -2,6 +2,7 @@ import { ensureDbOpen } from "../bootstrap/dynamic-tools.js";
 import { sanitizeCompleteMilestoneParams } from "../bootstrap/sanitize-complete-milestone.js";
 import { loadWriteGateSnapshot, shouldBlockContextArtifactSaveInSnapshot } from "../bootstrap/write-gate.js";
 import { getMilestone, getSliceStatusSummary, getSliceTaskCounts, _getAdapter, saveGateResult, } from "../gsd-db.js";
+import { GATE_REGISTRY } from "../gate-registry.js";
 import { saveArtifactToDb } from "../db-writer.js";
 import { handleCompleteMilestone } from "./complete-milestone.js";
 import { handleCompleteTask } from "./complete-task.js";
@@ -323,7 +324,9 @@ export async function executeSaveGateResult(params, basePath = process.cwd()) {
             isError: true,
         };
     }
-    const validGates = ["Q3", "Q4", "Q5", "Q6", "Q7", "Q8"];
+    // Source of truth: gate-registry.ts. Every declared GateId is accepted,
+    // so adding a new gate in one place automatically flows through here.
+    const validGates = Object.keys(GATE_REGISTRY);
     if (!validGates.includes(params.gateId)) {
         return {
             content: [{ type: "text", text: `Error: Invalid gateId "${params.gateId}". Must be one of: ${validGates.join(", ")}` }],

package/dist/resources/extensions/ollama/index.js

@@ -49,8 +49,15 @@ async function probeAndRegister(pi) {
         return false;
     }
     const models = await discoverModels();
-    if (models.length === 0)
-        return true; // Running but no models pulled
+    if (models.length === 0) {
+        // No local models means there's nothing usable to register in GSD.
+        // Keep the footer/status clean instead of advertising Ollama availability.
+        if (providerRegistered) {
+            pi.unregisterProvider("ollama");
+            providerRegistered = false;
+        }
+        return false;
+    }
     const baseUrl = client.getOllamaHost();
     // Use authMode "apiKey" with a dummy key (#3440).
     // authMode "none" requires a custom streamSimple handler, but Ollama uses
@@ -102,10 +109,11 @@ export default function ollama(pi) {
         else {
             probeAndRegister(pi)
                 .then((found) => {
-                if (found)
-                    ctx.ui.setStatus("ollama", "Ollama");
+                ctx.ui.setStatus("ollama", found ? "Ollama" : undefined);
             })
-                .catch(() => { });
+                .catch(() => {
+                ctx.ui.setStatus("ollama", undefined);
+            });
         }
     });
     pi.on("session_shutdown", async () => {

package/dist/resources/extensions/shared/gsd-phase-state.js

@@ -0,0 +1,35 @@
+/**
+ * GSD Phase State — cross-extension coordination
+ * Copyright (c) 2026 Jeremy McSpadden <jeremy@fluxlabs.net>
+ *
+ * Lightweight module-level state that GSD auto-mode writes to and the
+ * subagent tool reads from. Both extensions run in the same process so
+ * a module variable is sufficient — no file I/O needed.
+ */
+let _active = false;
+let _currentPhase = null;
+/** Mark GSD auto-mode as active. */
+export function activateGSD() {
+    _active = true;
+}
+/** Mark GSD auto-mode as inactive and clear the current phase. */
+export function deactivateGSD() {
+    _active = false;
+    _currentPhase = null;
+}
+/** Set the currently dispatched GSD phase (e.g. "plan-milestone"). */
+export function setCurrentPhase(phase) {
+    _currentPhase = phase;
+}
+/** Clear the current phase (unit completed or aborted). */
+export function clearCurrentPhase() {
+    _currentPhase = null;
+}
+/** Returns true if GSD auto-mode is currently active. */
+export function isGSDActive() {
+    return _active;
+}
+/** Returns the current GSD phase, or null if none is active. */
+export function getCurrentPhase() {
+    return _active ? _currentPhase : null;
+}

package/dist/resources/extensions/subagent/agents.js

@@ -5,6 +5,12 @@ import * as fs from "node:fs";
 import * as path from "node:path";
 import { getAgentDir, parseFrontmatter } from "@gsd/pi-coding-agent";
 const PROJECT_AGENT_DIR_CANDIDATES = [".gsd", ".pi"];
+export function parseConflictsWith(value) {
+    if (typeof value !== "string")
+        return undefined;
+    const conflicts = value.split(",").map((s) => s.trim()).filter(Boolean);
+    return conflicts.length > 0 ? conflicts : undefined;
+}
 function parseAgentTools(value) {
     if (typeof value === "string") {
         const tools = value
@@ -52,11 +58,13 @@ function loadAgentsFromDir(dir, source) {
             continue;
         }
         const tools = parseAgentTools(frontmatter.tools);
+        const conflictsWith = parseConflictsWith(frontmatter.conflicts_with);
         agents.push({
             name: frontmatter.name,
             description: frontmatter.description,
             tools: tools && tools.length > 0 ? tools : undefined,
             model: frontmatter.model,
+            conflictsWith,
             systemPrompt: body,
             source,
             filePath,

package/dist/resources/extensions/subagent/index.js

@@ -21,6 +21,7 @@ import { getMarkdownTheme } from "@gsd/pi-coding-agent";
 import { Container, Markdown, Spacer, Text } from "@gsd/pi-tui";
 import { Type } from "@sinclair/typebox";
 import { formatTokenCount } from "../shared/mod.js";
+import { getCurrentPhase } from "../shared/gsd-phase-state.js";
 import { discoverAgents } from "./agents.js";
 import { createIsolation, mergeDeltaPatches, readIsolationMode, } from "./isolation.js";
 import { registerWorker, updateWorker } from "./worker-registry.js";
@@ -268,6 +269,22 @@ async function runSingleAgent(defaultCwd, agents, agentName, task, cwd, step, si
             step,
         };
     }
+    // GSD phase guard: block agents that conflict with the active GSD phase
+    if (agent.conflictsWith && agent.conflictsWith.length > 0) {
+        const activePhase = getCurrentPhase();
+        if (activePhase && agent.conflictsWith.includes(activePhase)) {
+            return {
+                agent: agentName,
+                agentSource: agent.source,
+                task,
+                exitCode: 1,
+                messages: [],
+                stderr: `Agent "${agentName}" is blocked: it conflicts with the active GSD phase "${activePhase}". Use the built-in GSD workflow instead.`,
+                usage: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0, cost: 0, contextTokens: 0, turns: 0 },
+                step,
+            };
+        }
+    }
     let tmpPromptDir = null;
     let tmpPromptPath = null;
     const currentResult = {

package/dist/resources/skills/create-skill/SKILL.md

@@ -78,6 +78,8 @@ Based on the user's message, route directly to the appropriate workflow:
 **If user intent is unclear, ask minimal clarifying questions:**
 - "Create a MIDI skill" → "Task-execution skill (does MIDI tasks) or domain expertise (complete MIDI knowledge base)?"
 - "Work on my skill" → "Which skill? What do you want to do with it?"
+- Ask one clarifying question round at a time, then wait for the user's actual response before asking another.
+- Never fabricate or simulate user responses while clarifying (for example, fake `[User]` markers or imagined answers).
 
 Then proceed directly to the workflow.
 </routing>

package/dist/startup-model-validation.d.ts

@@ -13,7 +13,6 @@ interface MinimalModel {
     id: string;
 }
 interface MinimalModelRegistry {
-    getAll(): MinimalModel[];
     getAvailable(): MinimalModel[];
 }
 type ThinkingLevel = 'off' | 'minimal' | 'low' | 'medium' | 'high' | 'xhigh';

package/dist/startup-model-validation.js

@@ -23,10 +23,14 @@ import { getPiDefaultModelAndProvider } from './pi-migration.js';
 export function validateConfiguredModel(modelRegistry, settingsManager) {
     const configuredProvider = settingsManager.getDefaultProvider();
     const configuredModel = settingsManager.getDefaultModel();
-    const allModels = modelRegistry.getAll();
     const availableModels = modelRegistry.getAvailable();
+    // Check against availableModels (configured + auth'd) rather than getAll()
+    // so a stale default pointing at an unconfigured provider triggers the
+    // fallback. Previously a model present in the registry but missing API
+    // key / OAuth would satisfy configuredExists and survive startup, ending
+    // up as ctx.model even though it couldn't actually be used.
     const configuredExists = configuredProvider && configuredModel &&
-        allModels.some((m) => m.provider === configuredProvider && m.id === configuredModel);
+        availableModels.some((m) => m.provider === configuredProvider && m.id === configuredModel);
     if (!configuredModel || !configuredExists) {
         // Model not configured at all, or removed from registry — pick a fallback.
         // Only fires when the model is genuinely unknown (not just temporarily unavailable).

package/dist/web/standalone/.next/BUILD_ID

@@ -1 +1 @@
-nPky_WQC28aBD77eZsRAB
+nCL1Ivw47iAAoKVgerXNi