gsd-pi 2.38.0-dev.8f5c161 → 2.38.0-dev.98b44dc

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

@@ -11,12 +11,10 @@ import { runProviderChecks, summariseProviderIssues } from "./doctor-providers.j
 import { runEnvironmentChecks } from "./doctor-environment.js";
 import { loadEffectiveGSDPreferences } from "./preferences.js";
 import { loadLedgerFromDisk, getProjectTotals } from "./metrics.js";
-import { describeNextUnit, estimateTimeRemaining, updateSliceProgressCache } from "./auto-dashboard.js";
 import { projectRoot } from "./commands.js";
-import { deriveState, invalidateStateCache } from "./state.js";
 import { buildHealthLines, detectHealthWidgetProjectState, } from "./health-widget-core.js";
 // ── Data loader ────────────────────────────────────────────────────────────────
-function loadBaseHealthWidgetData(basePath) {
+function loadHealthWidgetData(basePath) {
     let budgetCeiling;
     let budgetSpent = 0;
     let providerIssue = null;
@@ -58,86 +56,6 @@ function loadBaseHealthWidgetData(basePath) {
         lastRefreshed: Date.now(),
     };
 }
-function compactText(text, max = 64) {
-    const trimmed = text.replace(/\s+/g, " ").trim();
-    if (trimmed.length <= max)
-        return trimmed;
-    return `${trimmed.slice(0, max - 1).trimEnd()}…`;
-}
-function summarizeExecutionStatus(state) {
-    switch (state.phase) {
-        case "blocked": return "Blocked";
-        case "paused": return "Paused";
-        case "complete": return "Complete";
-        case "executing": return "Executing";
-        case "planning": return "Planning";
-        case "pre-planning": return "Pre-planning";
-        case "summarizing": return "Summarizing";
-        case "validating-milestone": return "Validating";
-        case "completing-milestone": return "Completing";
-        case "needs-discussion": return "Needs discussion";
-        case "replanning-slice": return "Replanning";
-        default: return "Active";
-    }
-}
-function summarizeExecutionTarget(state) {
-    switch (state.phase) {
-        case "needs-discussion":
-            return state.activeMilestone ? `Discuss ${state.activeMilestone.id}` : "Discuss milestone draft";
-        case "pre-planning":
-            return state.activeMilestone ? `Plan ${state.activeMilestone.id}` : "Research & plan milestone";
-        case "planning":
-            return state.activeSlice ? `Plan ${state.activeSlice.id}` : "Plan next slice";
-        case "executing":
-            return state.activeTask ? `Execute ${state.activeTask.id}` : "Execute next task";
-        case "summarizing":
-            return state.activeSlice ? `Complete ${state.activeSlice.id}` : "Complete current slice";
-        case "validating-milestone":
-            return state.activeMilestone ? `Validate ${state.activeMilestone.id}` : "Validate milestone";
-        case "completing-milestone":
-            return state.activeMilestone ? `Complete ${state.activeMilestone.id}` : "Complete milestone";
-        case "replanning-slice":
-            return state.activeSlice ? `Replan ${state.activeSlice.id}` : "Replan current slice";
-        case "blocked":
-            return `waiting on ${compactText(state.blockers[0] ?? state.nextAction, 56)}`;
-        case "paused":
-            return compactText(state.nextAction || "waiting to resume", 56);
-        case "complete":
-            return "All milestones complete";
-        default:
-            return compactText(describeNextUnit(state).label, 56);
-    }
-}
-async function enrichHealthWidgetData(basePath, baseData) {
-    if (baseData.projectState !== "active")
-        return baseData;
-    try {
-        invalidateStateCache();
-        const state = await deriveState(basePath);
-        if (state.activeMilestone) {
-            // Warm the slice-progress cache so estimateTimeRemaining() has data
-            updateSliceProgressCache(basePath, state.activeMilestone.id, state.activeSlice?.id);
-        }
-        return {
-            ...baseData,
-            executionPhase: state.phase,
-            executionStatus: summarizeExecutionStatus(state),
-            executionTarget: summarizeExecutionTarget(state),
-            nextAction: state.nextAction,
-            blocker: state.blockers[0] ?? null,
-            activeMilestoneId: state.activeMilestone?.id,
-            activeSliceId: state.activeSlice?.id,
-            activeTaskId: state.activeTask?.id,
-            progress: state.progress,
-            eta: state.phase === "blocked" || state.phase === "paused" || state.phase === "complete"
-                ? null
-                : estimateTimeRemaining(),
-        };
-    }
-    catch {
-        return baseData;
-    }
-}
 // ── Widget init ────────────────────────────────────────────────────────────────
 const REFRESH_INTERVAL_MS = 60_000;
 /**
@@ -149,7 +67,7 @@ export function initHealthWidget(ctx) {
         return;
     const basePath = projectRoot();
     // String-array fallback — used in RPC mode (factory is a no-op there)
-    const initialData = loadBaseHealthWidgetData(basePath);
+    const initialData = loadHealthWidgetData(basePath);
     ctx.ui.setWidget("gsd-health", buildHealthLines(initialData), { placement: "belowEditor" });
     // Factory-based widget for TUI mode — replaces the string-array above
     ctx.ui.setWidget("gsd-health", (_tui, _theme) => {
@@ -161,8 +79,7 @@ export function initHealthWidget(ctx) {
                 return;
             refreshInFlight = true;
             try {
-                const baseData = loadBaseHealthWidgetData(basePath);
-                data = await enrichHealthWidgetData(basePath, baseData);
+                data = loadHealthWidgetData(basePath);
                 cachedLines = undefined;
                 _tui.requestRender();
             }

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

@@ -66,6 +66,24 @@ function warnDeprecatedAgentInstructions() {
 }
 // ── Depth verification state ──────────────────────────────────────────────
 let depthVerificationDone = false;
+// ── DB lazy-open helper ───────────────────────────────────────────────────
+// In manual sessions (no auto-mode), the DB is never opened by bootstrapAutoSession.
+// This helper ensures the DB is lazily opened on first tool call that needs it.
+async function ensureDbOpen() {
+    try {
+        const db = await import("./gsd-db.js");
+        if (db.isDbAvailable())
+            return true;
+        const dbPath = join(process.cwd(), ".gsd", "gsd.db");
+        if (existsSync(dbPath)) {
+            return db.openDatabase(dbPath);
+        }
+        return false;
+    }
+    catch {
+        return false;
+    }
+}
 // ── Queue phase tracking ──────────────────────────────────────────────────
 // When true, the LLM is in a queue flow writing CONTEXT.md files.
 // The write-gate applies during queue flows just like discussion flows.
@@ -228,13 +246,8 @@ export default function (pi) {
             when_context: Type.Optional(Type.String({ description: "When/context for the decision (e.g. milestone ID)" })),
         }),
         async execute(_toolCallId, params, _signal, _onUpdate, _ctx) {
-            // Check DB availability
-            let dbAvailable = false;
-            try {
-                const db = await import("./gsd-db.js");
-                dbAvailable = db.isDbAvailable();
-            }
-            catch { /* dynamic import failed */ }
+            // Ensure DB is open (lazy-open on first tool call in manual sessions)
+            const dbAvailable = await ensureDbOpen();
             if (!dbAvailable) {
                 return {
                     content: [{ type: "text", text: "Error: GSD database is not available. Cannot save decision." }],
@@ -290,12 +303,7 @@ export default function (pi) {
             supporting_slices: Type.Optional(Type.String({ description: "Supporting slices" })),
         }),
         async execute(_toolCallId, params, _signal, _onUpdate, _ctx) {
-            let dbAvailable = false;
-            try {
-                const db = await import("./gsd-db.js");
-                dbAvailable = db.isDbAvailable();
-            }
-            catch { /* dynamic import failed */ }
+            const dbAvailable = await ensureDbOpen();
             if (!dbAvailable) {
                 return {
                     content: [{ type: "text", text: "Error: GSD database is not available. Cannot update requirement." }],
@@ -365,12 +373,7 @@ export default function (pi) {
             content: Type.String({ description: "The full markdown content of the artifact" }),
         }),
         async execute(_toolCallId, params, _signal, _onUpdate, _ctx) {
-            let dbAvailable = false;
-            try {
-                const db = await import("./gsd-db.js");
-                dbAvailable = db.isDbAvailable();
-            }
-            catch { /* dynamic import failed */ }
+            const dbAvailable = await ensureDbOpen();
             if (!dbAvailable) {
                 return {
                     content: [{ type: "text", text: "Error: GSD database is not available. Cannot save artifact." }],

package/dist/resources/extensions/gsd/migrate-external.js

@@ -5,11 +5,13 @@
  * `~/.gsd/projects/<hash>/` state directory. After migration, a
  * symlink replaces the original directory so all paths remain valid.
  */
+import { execFileSync } from "node:child_process";
 import { existsSync, lstatSync, mkdirSync, readdirSync, realpathSync, renameSync, cpSync, rmSync, symlinkSync } from "node:fs";
 import { join } from "node:path";
 import { externalGsdRoot } from "./repo-identity.js";
 import { getErrorMessage } from "./error-utils.js";
 import { hasGitTrackedGsdFiles } from "./gitignore.js";
+import { GIT_NO_PROMPT_ENV } from "./git-constants.js";
 /**
  * Migrate a legacy in-project `.gsd/` directory to external storage.
  *
@@ -142,7 +144,22 @@ export function migrateToExternalState(basePath) {
             catch { /* best-effort restore */ }
             return { migrated: false, error: `Migration verification failed: ${getErrorMessage(verifyErr)}` };
         }
-        // Remove .gsd.migrating only after symlink is verified
+        // Clean the git index — any .gsd/* files tracked before migration now
+        // sit behind the symlink and git can't follow it, causing them to show
+        // as deleted. Remove them from the index so the working tree stays clean.
+        // --ignore-unmatch makes this a no-op on fresh projects with no tracked .gsd/.
+        try {
+            execFileSync("git", ["rm", "-r", "--cached", "--ignore-unmatch", ".gsd"], {
+                cwd: basePath,
+                stdio: ["ignore", "pipe", "ignore"],
+                env: GIT_NO_PROMPT_ENV,
+                timeout: 10_000,
+            });
+        }
+        catch {
+            // Non-fatal — git may be unavailable or nothing was tracked
+        }
+        // Remove .gsd.migrating only after symlink is verified and index is clean
         rmSync(migratingPath, { recursive: true, force: true });
         return { migrated: true };
     }

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

@@ -518,6 +518,43 @@ export function nativeAddAll(basePath) {
     }
     gitFileExec(basePath, ["add", "-A"]);
 }
+/**
+ * Stage all files with pathspec exclusions (git add -A -- ':!pattern' ...).
+ * Excluded paths are never hashed by git, preventing hangs on large
+ * untracked artifact trees (57GB+, 11K+ files). See #1605.
+ *
+ * Falls back to plain `git add -A` when no exclusions are provided.
+ * Always uses the CLI path (not libgit2) because libgit2's add_all
+ * does not support pathspec exclusion syntax.
+ *
+ * When excluded paths are already covered by .gitignore, git may exit
+ * with code 1 and an "ignored by .gitignore" warning. This is harmless
+ * (the staging succeeds for all non-ignored files) and is suppressed.
+ */
+export function nativeAddAllWithExclusions(basePath, exclusions) {
+    if (exclusions.length === 0) {
+        nativeAddAll(basePath);
+        return;
+    }
+    const pathspecs = exclusions.map(e => `:!${e}`);
+    try {
+        execFileSync("git", ["add", "-A", "--", ...pathspecs], {
+            cwd: basePath,
+            stdio: ["ignore", "pipe", "pipe"],
+            encoding: "utf-8",
+            env: GIT_NO_PROMPT_ENV,
+        });
+    }
+    catch (err) {
+        // git exits 1 when pathspec exclusions reference paths already covered
+        // by .gitignore. The staging itself succeeds — only suppress that case.
+        const stderr = err?.stderr ?? "";
+        if (stderr.includes("ignored by one of your .gitignore files")) {
+            return;
+        }
+        throw new GSDError(GSD_GIT_ERROR, `git add -A with exclusions failed in ${basePath}: ${getErrorMessage(err)}`);
+    }
+}
 /**
  * Stage specific files.
  * Native: libgit2 index add.

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

@@ -343,6 +343,9 @@ function probeGsdRoot(rawBasePath) {
 export function milestonesDir(basePath) {
     return join(gsdRoot(basePath), "milestones");
 }
+export function resolveRuntimeFile(basePath) {
+    return join(gsdRoot(basePath), "RUNTIME.md");
+}
 export function resolveGsdRootFile(basePath, key) {
     const root = gsdRoot(basePath);
     const canonical = join(root, GSD_ROOT_FILES[key]);

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

@@ -65,6 +65,7 @@ export const KNOWN_PREFERENCE_KEYS = new Set([
     "context_selection",
     "widget_mode",
     "reactive_execution",
+    "github",
 ]);
 /** Canonical list of all dispatch unit types. */
 export const KNOWN_UNIT_TYPES = [

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

@@ -717,5 +717,63 @@ export function validatePreferences(preferences) {
             errors.push(`context_selection must be one of: full, smart`);
         }
     }
+    // ─── GitHub Sync ────────────────────────────────────────────────────────
+    if (preferences.github !== undefined) {
+        if (typeof preferences.github === "object" && preferences.github !== null) {
+            const gh = preferences.github;
+            const validGh = {};
+            if (gh.enabled !== undefined) {
+                if (typeof gh.enabled === "boolean")
+                    validGh.enabled = gh.enabled;
+                else
+                    errors.push("github.enabled must be a boolean");
+            }
+            if (gh.repo !== undefined) {
+                if (typeof gh.repo === "string" && gh.repo.includes("/"))
+                    validGh.repo = gh.repo;
+                else
+                    errors.push('github.repo must be a string in "owner/repo" format');
+            }
+            if (gh.project !== undefined) {
+                const p = typeof gh.project === "number" ? gh.project : Number(gh.project);
+                if (Number.isFinite(p) && p > 0)
+                    validGh.project = Math.floor(p);
+                else
+                    errors.push("github.project must be a positive number");
+            }
+            if (gh.labels !== undefined) {
+                if (Array.isArray(gh.labels) && gh.labels.every((l) => typeof l === "string")) {
+                    validGh.labels = gh.labels;
+                }
+                else {
+                    errors.push("github.labels must be an array of strings");
+                }
+            }
+            if (gh.auto_link_commits !== undefined) {
+                if (typeof gh.auto_link_commits === "boolean")
+                    validGh.auto_link_commits = gh.auto_link_commits;
+                else
+                    errors.push("github.auto_link_commits must be a boolean");
+            }
+            if (gh.slice_prs !== undefined) {
+                if (typeof gh.slice_prs === "boolean")
+                    validGh.slice_prs = gh.slice_prs;
+                else
+                    errors.push("github.slice_prs must be a boolean");
+            }
+            const knownGhKeys = new Set(["enabled", "repo", "project", "labels", "auto_link_commits", "slice_prs"]);
+            for (const key of Object.keys(gh)) {
+                if (!knownGhKeys.has(key)) {
+                    warnings.push(`unknown github key "${key}" — ignored`);
+                }
+            }
+            if (Object.keys(validGh).length > 0) {
+                validated.github = validGh;
+            }
+        }
+        else {
+            errors.push("github must be an object");
+        }
+    }
     return { preferences: validated, errors, warnings };
 }

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

@@ -12,7 +12,6 @@
 import { existsSync, readFileSync } from "node:fs";
 import { homedir } from "node:os";
 import { join } from "node:path";
-const gsdHome = process.env.GSD_HOME || join(homedir(), ".gsd");
 import { gsdRoot } from "./paths.js";
 import { parse as parseYaml } from "yaml";
 import { normalizeStringArray } from "../shared/format-utils.js";
@@ -27,31 +26,40 @@ export { resolveAllSkillReferences, resolveSkillDiscoveryMode, resolveSkillStale
 // ─── Re-exports: models ─────────────────────────────────────────────────────
 export { resolveModelForUnit, resolveModelWithFallbacksForUnit, getNextFallbackModel, isTransientNetworkError, validateModelId, updatePreferencesModels, resolveDynamicRoutingConfig, resolveAutoSupervisorConfig, resolveProfileDefaults, resolveEffectiveProfile, resolveInlineLevel, resolveContextSelection, resolveSearchProviderFromPreferences, } from "./preferences-models.js";
 // ─── Path Constants & Getters ───────────────────────────────────────────────
-const GLOBAL_PREFERENCES_PATH = join(gsdHome, "preferences.md");
-const LEGACY_GLOBAL_PREFERENCES_PATH = join(homedir(), ".pi", "agent", "gsd-preferences.md");
+function gsdHome() {
+    return process.env.GSD_HOME || join(homedir(), ".gsd");
+}
+function globalPreferencesPath() {
+    return join(gsdHome(), "preferences.md");
+}
+function legacyGlobalPreferencesPath() {
+    return join(homedir(), ".pi", "agent", "gsd-preferences.md");
+}
 function projectPreferencesPath() {
     return join(gsdRoot(process.cwd()), "preferences.md");
 }
 // Bootstrap in gitignore.ts historically created PREFERENCES.md (uppercase) by mistake.
 // Check uppercase as a fallback so those files aren't silently ignored.
-const GLOBAL_PREFERENCES_PATH_UPPERCASE = join(gsdHome, "PREFERENCES.md");
+function globalPreferencesPathUppercase() {
+    return join(gsdHome(), "PREFERENCES.md");
+}
 function projectPreferencesPathUppercase() {
     return join(gsdRoot(process.cwd()), "PREFERENCES.md");
 }
 export function getGlobalGSDPreferencesPath() {
-    return GLOBAL_PREFERENCES_PATH;
+    return globalPreferencesPath();
 }
 export function getLegacyGlobalGSDPreferencesPath() {
-    return LEGACY_GLOBAL_PREFERENCES_PATH;
+    return legacyGlobalPreferencesPath();
 }
 export function getProjectGSDPreferencesPath() {
     return projectPreferencesPath();
 }
 // ─── Loading ────────────────────────────────────────────────────────────────
 export function loadGlobalGSDPreferences() {
-    return loadPreferencesFile(GLOBAL_PREFERENCES_PATH, "global")
-        ?? loadPreferencesFile(GLOBAL_PREFERENCES_PATH_UPPERCASE, "global")
-        ?? loadPreferencesFile(LEGACY_GLOBAL_PREFERENCES_PATH, "global");
+    return loadPreferencesFile(globalPreferencesPath(), "global")
+        ?? loadPreferencesFile(globalPreferencesPathUppercase(), "global")
+        ?? loadPreferencesFile(legacyGlobalPreferencesPath(), "global");
 }
 export function loadProjectGSDPreferences() {
     return loadPreferencesFile(projectPreferencesPath(), "project")
@@ -203,6 +211,9 @@ function mergePreferences(base, override) {
         context_selection: override.context_selection ?? base.context_selection,
         auto_visualize: override.auto_visualize ?? base.auto_visualize,
         auto_report: override.auto_report ?? base.auto_report,
+        github: (base.github || override.github)
+            ? { ...(base.github ?? {}), ...(override.github ?? {}) }
+            : undefined,
     };
 }
 function mergeStringLists(base, override) {

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

@@ -74,6 +74,10 @@ export function loadPrompt(name, vars = {}) {
         content = readFileSync(path, "utf-8");
         templateCache.set(name, content);
     }
+    const effectiveVars = {
+        skillActivation: "If a `GSD Skill Preferences` block is present in system context, use it and the `<available_skills>` catalog in your system prompt to decide which skills to load and follow for this unit, without relaxing required verification or artifact rules.",
+        ...vars,
+    };
     // Check BEFORE substitution: find all {{varName}} placeholders the template
     // declares and verify every one has a value in vars. Checking after substitution
     // would also flag {{...}} patterns injected by inlined content (e.g. template
@@ -82,14 +86,14 @@ export function loadPrompt(name, vars = {}) {
     if (declared) {
         const missing = [...new Set(declared)]
             .map(m => m.slice(2, -2))
-            .filter(key => !(key in vars));
+            .filter(key => !(key in effectiveVars));
         if (missing.length > 0) {
             throw new GSDError(GSD_PARSE_ERROR, `loadPrompt("${name}"): template declares {{${missing.join("}}, {{")}}}} but no value was provided. ` +
                 `This usually means the extension code in memory is older than the template on disk. ` +
                 `Restart pi to reload the extension.`);
         }
     }
-    for (const [key, value] of Object.entries(vars)) {
+    for (const [key, value] of Object.entries(effectiveVars)) {
         content = content.replaceAll(`{{${key}}}`, value);
     }
     return content.trim();

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

@@ -16,7 +16,7 @@ All relevant context has been preloaded below — the roadmap, all slice summari
 
 Then:
 1. Use the **Milestone Summary** output template from the inlined context above
-2. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during completion, without relaxing required verification or artifact rules
+2. {{skillActivation}}
 3. Verify each **success criterion** from the milestone definition in `{{roadmapPath}}`. For each criterion, confirm it was met with specific evidence from slice summaries, test results, or observable behavior. List any criterion that was NOT met.
 4. Verify the milestone's **definition of done** — all slices are `[x]`, all slice summaries exist, and any cross-slice integration points work correctly.
 5. Validate **requirement status transitions**. For each requirement that changed status during this milestone, confirm the transition is supported by evidence. Requirements can move between Active, Validated, Deferred, Blocked, or Out of Scope — but only with proof.

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

@@ -20,7 +20,7 @@ All relevant context has been preloaded below — the slice plan, all task summa
 
 Then:
 1. Use the **Slice Summary** and **UAT** output templates from the inlined context above
-2. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during completion, without relaxing required verification or artifact rules
+2. {{skillActivation}}
 3. Run all slice-level verification checks defined in the slice plan. All must pass before marking the slice done. If any fail, fix them first.
 4. If the slice plan includes observability/diagnostic surfaces, confirm they work. Skip this for simple slices that don't have observability sections.
 5. If `.gsd/REQUIREMENTS.md` exists, update it based on what this slice actually proved. Move requirements between Active, Validated, Deferred, Blocked, or Out of Scope only when the evidence from execution supports that change.

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

@@ -10,6 +10,8 @@ A researcher explored the codebase and a planner decomposed the work — you are
 
 {{overridesSection}}
 
+{{runtimeContext}}
+
 {{resumeSection}}
 
 {{carryForwardSection}}
@@ -26,7 +28,7 @@ A researcher explored the codebase and a planner decomposed the work — you are
 
 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. **Load relevant skills before writing code.** Check the `GSD Skill Preferences` block in system context and the `<available_skills>` catalog in your system prompt. For each skill that matches this task's technology stack (e.g., React, Next.js, accessibility, component design), `read` its SKILL.md file now. Skills contain implementation rules and patterns that should guide your code. If no skills match this task, skip this step.
+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).

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

@@ -1,3 +1,3 @@
-Complete slice {{sliceId}} ("{{sliceTitle}}") of milestone {{milestoneId}}. Your working directory is `{{workingDirectory}}` — all file operations must use this path. All tasks are done. Your slice summary is the primary record of what was built — downstream agents (reassess-roadmap, future slice researchers) read it to understand what this slice delivered and what to watch out for. Use the **Slice Summary** and **UAT** output templates below. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during completion, without relaxing required verification or artifact rules. Write `{{sliceId}}-SUMMARY.md` (compress task summaries), write `{{sliceId}}-UAT.md`, and fill the `UAT Type` plus `Not Proven By This UAT` sections explicitly so the artifact states what class of acceptance it covers and what still remains unproven. Review task summaries for `key_decisions` and ensure any significant ones are in `.gsd/DECISIONS.md`. Mark the slice checkbox done in the roadmap, update milestone summary, Do not commit or merge manually — the system handles this after the unit completes.
+Complete slice {{sliceId}} ("{{sliceTitle}}") of milestone {{milestoneId}}. Your working directory is `{{workingDirectory}}` — all file operations must use this path. All tasks are done. Your slice summary is the primary record of what was built — downstream agents (reassess-roadmap, future slice researchers) read it to understand what this slice delivered and what to watch out for. Use the **Slice Summary** and **UAT** output templates below. {{skillActivation}} Write `{{sliceId}}-SUMMARY.md` (compress task summaries), write `{{sliceId}}-UAT.md`, and fill the `UAT Type` plus `Not Proven By This UAT` sections explicitly so the artifact states what class of acceptance it covers and what still remains unproven. Review task summaries for `key_decisions` and ensure any significant ones are in `.gsd/DECISIONS.md`. Mark the slice checkbox done in the roadmap, update milestone summary, Do not commit or merge manually — the system handles this after the unit completes.
 
 {{inlinedTemplates}}

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

@@ -1,3 +1,3 @@
-Execute the next task: {{taskId}} ("{{taskTitle}}") in slice {{sliceId}} of milestone {{milestoneId}}. Read the task plan (`{{taskId}}-PLAN.md`), load relevant summaries from prior tasks, and execute each step. Verify must-haves when done. If the task touches UI, browser flows, DOM behavior, or user-visible web state, exercise the real flow in the browser, prefer `browser_batch` for obvious sequences, prefer `browser_assert` for explicit pass/fail verification, use `browser_diff` when an action's effect is ambiguous, and use browser diagnostics when validating async or failure-prone UI. If you made an architectural, pattern, or library decision, append it to `.gsd/DECISIONS.md`. Use the **Task Summary** output template below. Write `{{taskId}}-SUMMARY.md`, mark it done, commit, and advance. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during execution, without relaxing required verification or artifact rules. If running long and not all steps are finished, stop implementing and prioritize writing a clean partial summary over attempting one more step — a recoverable handoff is more valuable than a half-finished step with no documentation. If verification fails, debug methodically: form a hypothesis and test that specific theory before changing anything, change one variable at a time, read entire functions not just the suspect line, distinguish observable facts from assumptions, and if 3+ fixes fail without progress stop and reassess your mental model — list what you know for certain, what you've ruled out, and form fresh hypotheses. Don't fix symptoms — understand why something fails before changing code.
+Execute the next task: {{taskId}} ("{{taskTitle}}") in slice {{sliceId}} of milestone {{milestoneId}}. Read the task plan (`{{taskId}}-PLAN.md`), load relevant summaries from prior tasks, and execute each step. Verify must-haves when done. If the task touches UI, browser flows, DOM behavior, or user-visible web state, exercise the real flow in the browser, prefer `browser_batch` for obvious sequences, prefer `browser_assert` for explicit pass/fail verification, use `browser_diff` when an action's effect is ambiguous, and use browser diagnostics when validating async or failure-prone UI. If you made an architectural, pattern, or library decision, append it to `.gsd/DECISIONS.md`. Use the **Task Summary** output template below. Write `{{taskId}}-SUMMARY.md`, mark it done, commit, and advance. {{skillActivation}} If running long and not all steps are finished, stop implementing and prioritize writing a clean partial summary over attempting one more step — a recoverable handoff is more valuable than a half-finished step with no documentation. If verification fails, debug methodically: form a hypothesis and test that specific theory before changing anything, change one variable at a time, read entire functions not just the suspect line, distinguish observable facts from assumptions, and if 3+ fixes fail without progress stop and reassess your mental model — list what you know for certain, what you've ruled out, and form fresh hypotheses. Don't fix symptoms — understand why something fails before changing code.
 
 {{inlinedTemplates}}

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

@@ -1,4 +1,4 @@
-Plan milestone {{milestoneId}} ("{{milestoneTitle}}"). Read `.gsd/DECISIONS.md` if it exists — respect existing decisions. Read `.gsd/REQUIREMENTS.md` if it exists and treat Active requirements as the capability contract. If `REQUIREMENTS.md` is missing, continue in legacy compatibility mode but explicitly note missing requirement coverage. Use the **Roadmap** output template below. Create `{{milestoneId}}-ROADMAP.md` in the milestone directory with slices, risk levels, dependencies, demo sentences, verification classes, milestone definition of done, requirement coverage, and a boundary map. Write success criteria as observable truths, not implementation tasks. If the milestone crosses multiple runtime boundaries, include an explicit final integration slice that proves the assembled system works end-to-end in a real environment. If planning produces structural decisions, append them to `.gsd/DECISIONS.md`. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during planning, without overriding required roadmap formatting.
+Plan milestone {{milestoneId}} ("{{milestoneTitle}}"). Read `.gsd/DECISIONS.md` if it exists — respect existing decisions. Read `.gsd/REQUIREMENTS.md` if it exists and treat Active requirements as the capability contract. If `REQUIREMENTS.md` is missing, continue in legacy compatibility mode but explicitly note missing requirement coverage. Use the **Roadmap** output template below. Create `{{milestoneId}}-ROADMAP.md` in the milestone directory with slices, risk levels, dependencies, demo sentences, verification classes, milestone definition of done, requirement coverage, and a boundary map. Write success criteria as observable truths, not implementation tasks. If the milestone crosses multiple runtime boundaries, include an explicit final integration slice that proves the assembled system works end-to-end in a real environment. If planning produces structural decisions, append them to `.gsd/DECISIONS.md`. {{skillActivation}}
 
 ## Requirement Rules
 

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

@@ -1,3 +1,3 @@
-Plan slice {{sliceId}} ("{{sliceTitle}}") of milestone {{milestoneId}}. Read `.gsd/DECISIONS.md` if it exists — respect existing decisions. Read `.gsd/REQUIREMENTS.md` if it exists — identify which Active requirements the roadmap says this slice owns or supports, and ensure the plan delivers them. Read the roadmap boundary map, any existing context/research files, and dependency summaries. Use the **Slice Plan** and **Task Plan** output templates below. Decompose into tasks with must-haves. Fill the `Proof Level` and `Integration Closure` sections truthfully so the plan says what class of proof this slice really delivers and what end-to-end wiring still remains. Write `{{sliceId}}-PLAN.md` and individual `T##-PLAN.md` files in the `tasks/` subdirectory. If planning produces structural decisions, append them to `.gsd/DECISIONS.md`. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during planning, without overriding required plan formatting. Before committing, self-audit the plan: every must-have maps to at least one task, every task has complete sections (steps, must-haves, verification, observability impact, inputs, and expected output), task ordering is consistent with no circular references, every pair of artifacts that must connect has an explicit wiring step, task scope targets 2–5 steps and 3–8 files (6–8 steps or 8–10 files — consider splitting; 10+ steps or 12+ files — must split), the plan honors locked decisions from context/research/decisions artifacts, the proof-level wording does not overclaim live integration if only fixture/contract proof is planned, every Active requirement this slice owns has at least one task with verification that proves it is met, and every task produces real user-facing progress — if the slice has a UI surface at least one task builds the real UI, if it has an API at least one task connects it to a real data source, and showing the completed result to a non-technical stakeholder would demonstrate real product progress rather than developer artifacts.
+Plan slice {{sliceId}} ("{{sliceTitle}}") of milestone {{milestoneId}}. Read `.gsd/DECISIONS.md` if it exists — respect existing decisions. Read `.gsd/REQUIREMENTS.md` if it exists — identify which Active requirements the roadmap says this slice owns or supports, and ensure the plan delivers them. Read the roadmap boundary map, any existing context/research files, and dependency summaries. Use the **Slice Plan** and **Task Plan** output templates below. Decompose into tasks with must-haves. Fill the `Proof Level` and `Integration Closure` sections truthfully so the plan says what class of proof this slice really delivers and what end-to-end wiring still remains. Write `{{sliceId}}-PLAN.md` and individual `T##-PLAN.md` files in the `tasks/` subdirectory. If planning produces structural decisions, append them to `.gsd/DECISIONS.md`. {{skillActivation}} Before committing, self-audit the plan: every must-have maps to at least one task, every task has complete sections (steps, must-haves, verification, observability impact, inputs, and expected output), task ordering is consistent with no circular references, every pair of artifacts that must connect has an explicit wiring step, task scope targets 2–5 steps and 3–8 files (6–8 steps or 8–10 files — consider splitting; 10+ steps or 12+ files — must split), the plan honors locked decisions from context/research/decisions artifacts, the proof-level wording does not overclaim live integration if only fixture/contract proof is planned, every Active requirement this slice owns has at least one task with verification that proves it is met, and every task produces real user-facing progress — if the slice has a UI surface at least one task builds the real UI, if it has an API at least one task connects it to a real data source, and showing the completed result to a non-technical stakeholder would demonstrate real product progress rather than developer artifacts.
 
 {{inlinedTemplates}}

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

@@ -1,4 +1,4 @@
-Research slice {{sliceId}} ("{{sliceTitle}}") of milestone {{milestoneId}}. Read `.gsd/DECISIONS.md` if it exists — respect existing decisions, don't contradict them. Read `.gsd/REQUIREMENTS.md` if it exists — identify which Active requirements this slice owns or supports and target research toward risks, unknowns, and constraints that could affect delivery of those requirements. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during research, without relaxing required verification or artifact rules. Explore the relevant code — use `rg`/`find` for targeted reads, or `scout` if the area is broad or unfamiliar. Check libraries with `resolve_library`/`get_library_docs` — skip this for libraries already used in the codebase. Use the **Research** output template below. Write `{{sliceId}}-RESEARCH.md` in the slice directory.
+Research slice {{sliceId}} ("{{sliceTitle}}") of milestone {{milestoneId}}. Read `.gsd/DECISIONS.md` if it exists — respect existing decisions, don't contradict them. Read `.gsd/REQUIREMENTS.md` if it exists — identify which Active requirements this slice owns or supports and target research toward risks, unknowns, and constraints that could affect delivery of those requirements. {{skillActivation}} Explore the relevant code — use `rg`/`find` for targeted reads, or `scout` if the area is broad or unfamiliar. Check libraries with `resolve_library`/`get_library_docs` — skip this for libraries already used in the codebase. Use the **Research** output template below. Write `{{sliceId}}-RESEARCH.md` in the slice directory.
 
 **You are the scout.** A planner agent reads your output in a fresh context to decompose this slice into tasks. Write for the planner — surface key files, where the work divides naturally, what to build first, and how to verify. If the research doc is vague, the planner re-explores code you already read. If it's precise, the planner decomposes immediately.
 

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. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during execution, without relaxing required verification or artifact rules.
+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}}

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

@@ -44,7 +44,7 @@ Narrate your decomposition reasoning — why you're grouping work this way, what
 
 Then:
 1. Use the **Roadmap** output template from the inlined context above
-2. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during planning, without overriding required roadmap formatting
+2. {{skillActivation}}
 3. Create the roadmap: decompose into demoable vertical slices — as many as the work genuinely needs, no more. A simple feature might be 1 slice. Don't decompose for decomposition's sake.
 4. Order by risk (high-risk first)
 5. Write `{{outputPath}}` with checkboxes, risk, depends, demo sentences, proof strategy, verification classes, milestone definition of done, **requirement coverage**, and a boundary map. Write success criteria as observable truths, not implementation tasks. If the milestone crosses multiple runtime boundaries, include an explicit final integration slice that proves the assembled system works end-to-end in a real environment

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

@@ -47,7 +47,7 @@ Then:
 1. Read the templates:
    - `~/.gsd/agent/extensions/gsd/templates/plan.md`
    - `~/.gsd/agent/extensions/gsd/templates/task-plan.md`
-2. **Load relevant skills.** Check the `GSD Skill Preferences` block in system context and the `<available_skills>` catalog in your system prompt. `read` any skill files relevant to this slice's technology stack before decomposing. When writing task plans, note which installed skills are relevant in the task description so executors know which to load.
+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 for this slice:
    - For non-trivial slices: plan actual test files with real assertions. Name the files.
    - For simple slices: executable commands or script assertions are fine.

package/dist/resources/extensions/gsd/prompts/reassess-roadmap.md

@@ -22,7 +22,7 @@ The following user thoughts were captured during execution and deferred to futur
 
 {{deferredCaptures}}
 
-If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during reassessment, without relaxing required verification or artifact rules.
+{{skillActivation}}
 
 Then assess whether the remaining roadmap still makes sense given what was just built.
 

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

@@ -21,7 +21,7 @@ Write for the roadmap planner. It needs to understand: what exists in the codeba
 A milestone adding a small feature to an established codebase needs targeted research — check the relevant code, confirm the approach, note constraints. A milestone introducing new technology, building a new system, or spanning multiple unfamiliar subsystems needs deep research — explore broadly, look up docs, investigate alternatives. Match your effort to the actual uncertainty, not the template's section count. Include only sections that have real content.
 
 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. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during research, without relaxing required verification or artifact rules
+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.
 4. Use `resolve_library` / `get_library_docs` for unfamiliar libraries — skip this for libraries already used in the codebase

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

@@ -42,7 +42,7 @@ An honest "this is straightforward, here's the pattern to follow" is more valuab
 
 Research what this slice needs. Narrate key findings and surprises as you go — what exists, what's missing, what constrains the approach.
 0. If `REQUIREMENTS.md` was preloaded above, identify which Active requirements this slice owns or supports. Research should target these requirements — surfacing risks, unknowns, and implementation constraints that could affect whether the slice actually delivers them.
-1. **Load relevant skills.** Check the `GSD Skill Preferences` block in system context and the `<available_skills>` catalog in your system prompt. `read` any skill files relevant to this slice's technology stack before exploring code. Reference specific rules from loaded skills in your findings where they inform the implementation approach.
+1. {{skillActivation}} Reference specific rules from loaded skills in your findings where they inform the implementation approach.
 2. **Skill Discovery ({{skillDiscoveryMode}}):**{{skillDiscoveryInstructions}}
 3. Explore relevant code for this slice's scope. For targeted exploration, use `rg`, `find`, and reads. For broad or unfamiliar subsystems, use `scout` to map the relevant area first.
 4. Use `resolve_library` / `get_library_docs` for unfamiliar libraries — skip this for libraries already used in the codebase

package/dist/resources/extensions/gsd/prompts/run-uat.md

@@ -10,7 +10,7 @@ All relevant context has been preloaded below. Start working immediately without
 
 {{inlinedContext}}
 
-If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during UAT execution, without relaxing required verification or artifact rules.
+{{skillActivation}}
 
 ---
 
@@ -25,6 +25,8 @@ You are the UAT runner. Execute every check defined in `{{uatPath}}` as deeply a
 ### Automation rules by mode
 
 - `artifact-driven` — verify with shell commands, scripts, file reads, and artifact structure checks.
+- `browser-executable` — use browser tools to navigate to the target URL and verify expected behavior. Capture screenshots as evidence. Record pass/fail with specific assertions.
+- `runtime-executable` — execute the specified command or script. Capture stdout/stderr as evidence. Record pass/fail based on exit code and output.
 - `live-runtime` — exercise the real runtime path. Start or connect to the app/service if needed, use browser/runtime/network checks, and verify observable behavior.
 - `mixed` — run all automatable artifact-driven and live-runtime checks. Separate any remaining human-only checks explicitly.
 - `human-experience` — automate setup, preconditions, screenshots, logs, and objective checks, but do **not** invent subjective PASS results. Mark taste-based, experiential, or purely human-judgment checks as `NEEDS-HUMAN` and use an overall verdict of `PARTIAL` unless every required check was objective and passed.