gsd-pi 2.79.0-dev.ece5fd8ba → 2.80.0-dev.710c06e97

package/src/resources/extensions/gsd/prompts/triage-captures.md

@@ -2,7 +2,7 @@ You are triaging user-captured thoughts during a GSD session.
 
 ## UNIT: Triage Captures
 
-The user captured thoughts during execution using `/gsd capture`. Your job is to classify each capture, present your proposals, get user confirmation, and update CAPTURES.md with the final classifications.
+The user captured thoughts with `/gsd capture`. Classify each capture, present proposals, get needed confirmation, and update CAPTURES.md with final classifications.
 
 ## Pending Captures
 
@@ -18,24 +18,24 @@ The user captured thoughts during execution using `/gsd capture`. Your job is to
 
 ## Classification Criteria
 
-For each capture, classify it as one of:
+Classify each capture as one of:
 
-- **stop**: User directive to halt auto-mode immediately. Use when the user says "stop", "halt", "abort", "don't continue", "pause", or otherwise wants execution to cease. Auto-mode will pause after the current unit completes. Examples: "stop running", "halt execution", "don't continue".
-- **backtrack**: User directive to abandon the current milestone and return to a previous one. The user believes earlier milestones missed critical features or need rework. Include the target milestone ID (e.g., M003) in the Resolution field. Auto-mode will pause and write a regression marker. Examples: "restart from M003", "go back to milestone 3", "M004 and M005 failed, restart from M003".
-- **quick-task**: Small, self-contained, no downstream impact. Can be done in minutes without modifying the plan. Examples: fix a typo, add a missing import, tweak a config value.
-- **inject**: Belongs in the current slice but wasn't planned. Needs a new task added to the slice plan. Examples: add error handling to a module being built, add a missing test case for current work.
-- **defer**: Belongs in a future slice or milestone. Not urgent for current work. Examples: performance optimization, feature that depends on unbuilt infrastructure, nice-to-have enhancement.
-- **replan**: Changes the shape of remaining work in the current slice. Existing incomplete tasks may need rewriting. Examples: "the approach is wrong, we need to use X instead of Y", discovering a fundamental constraint.
-- **note**: Informational only. No action needed right now. Good context for future reference. Examples: "remember that the API has a rate limit", observations about code quality.
+- **stop**: Halt/pause auto-mode immediately after the current unit. Examples: "stop", "halt", "abort", "don't continue".
+- **backtrack**: Abandon current milestone and return to an earlier one. Include target milestone ID (e.g., M003) in Resolution. Auto-mode pauses and writes a regression marker.
+- **quick-task**: Small, self-contained, no downstream impact; minutes of work without plan changes.
+- **inject**: Belongs in current slice but was not planned; needs a new task.
+- **defer**: Belongs in a future slice/milestone; not urgent for current work.
+- **replan**: Changes remaining work shape in the current slice; incomplete tasks may need rewriting.
+- **note**: Informational only; useful future context with no immediate action.
 
 ## Decision Guidelines
 
-- **ALWAYS classify as stop** when the user explicitly says "stop", "halt", "abort", or "don't continue". Never shoe-horn a stop directive into "replan" or "note".
-- **ALWAYS classify as backtrack** when the user references returning to a previous milestone, restarting from an earlier point, or abandoning current milestone work. Include the target milestone ID in the Resolution field (e.g., "Backtrack to M003").
+- **ALWAYS classify as stop** when the user says "stop", "halt", "abort", or "don't continue". Never shoe-horn stop into "replan" or "note".
+- **ALWAYS classify as backtrack** when the user references returning to a previous milestone, restarting earlier, or abandoning current milestone work. Include target milestone ID in Resolution (e.g., "Backtrack to M003").
 - Prefer **quick-task** when the work is clearly small and self-contained.
 - Prefer **inject** over **replan** when only a new task is needed, not rewriting existing ones.
 - Prefer **defer** over **inject** when the work doesn't belong in the current slice's scope.
-- Use **replan** only when remaining incomplete tasks in the *current slice* need to change — not for cross-milestone issues.
+- Use **replan** only when remaining incomplete tasks in the *current slice* need to change, not for cross-milestone issues.
 - Use **note** for observations that don't require action.
 - When unsure between quick-task and inject, consider: will this take more than 10 minutes? If yes, inject.
 
@@ -49,8 +49,8 @@ For each capture, classify it as one of:
    - Your rationale
    - If applicable, which files would be affected
    
-   For captures classified as **note** or **defer**, auto-confirm without asking — these are low-impact.
-   For captures classified as **stop** or **backtrack**, auto-confirm without asking — these are urgent user directives that must be honored immediately.
+   Auto-confirm **note** and **defer** because they are low-impact.
+   Auto-confirm **stop** and **backtrack** because they are urgent user directives.
    For captures classified as **quick-task**, **inject**, or **replan**, ask the user to confirm or choose a different classification. **Non-bypassable:** If `ask_user_questions` fails, errors, or the user does not respond, you MUST re-ask — never auto-confirm these classifications without explicit user approval.
 
 3. **Update** `.gsd/CAPTURES.md` — for each capture, update its section with the confirmed classification:
@@ -61,7 +61,7 @@ For each capture, classify it as one of:
    - Add `**Resolved:** <current ISO timestamp>`
    - Add `**Milestone:** <current milestone ID>` (e.g., `**Milestone:** M003`)
 
-4. **Summarize** what was triaged: how many captures, what classifications were assigned, and what actions are pending (e.g., "2 quick-tasks ready for execution, 1 deferred to S03").
+4. **Summarize** count, assigned classifications, and pending actions (e.g., "2 quick-tasks ready, 1 deferred to S03").
 
 **Important:** Do NOT execute any resolutions. Only classify and update CAPTURES.md. Resolution execution happens separately (in auto-mode dispatch or manually by the user).
 

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

@@ -1,20 +1,20 @@
-# Milestone Validation — Parallel Review
+# Milestone Validation - Parallel Review
 
-You are the validation orchestrator for **{{milestoneId}} — {{milestoneTitle}}**.
+You are the validation orchestrator for **{{milestoneId}} - {{milestoneTitle}}**.
 
 ## Working Directory
 
-Your working directory is `{{workingDirectory}}`. All file reads, writes, and shell commands MUST operate relative to this directory. Do NOT `cd` to any other directory.
+Work in `{{workingDirectory}}`. All reads, writes, and shell commands MUST stay relative to it. Do NOT `cd` elsewhere.
 
 ## Mission
 
-Dispatch 3 independent parallel reviewers, then synthesize their findings into the final VALIDATION verdict.
+Dispatch 3 independent parallel reviewers, then synthesize the final VALIDATION verdict.
 
-This is remediation round {{remediationRound}}. If this is round 0, this is the first validation pass. If > 0, prior validation found issues and remediation slices were added and executed — verify those remediation slices resolved the issues.
+Remediation round: {{remediationRound}}. Round 0 is the first pass; later rounds must verify remediation slices resolved prior findings.
 
 ## Context
 
-All relevant context has been preloaded below — the roadmap, all slice summaries, assessment results, requirements, decisions, and project context are inlined. Start working immediately without re-reading these files.
+Roadmap, slice summaries, assessments, requirements, decisions, and project context are inlined. Start immediately.
 
 {{inlinedContext}}
 
@@ -22,29 +22,29 @@ All relevant context has been preloaded below — the roadmap, all slice summari
 
 ## Execution Protocol
 
-### Step 1 — Dispatch Parallel Reviewers
+### Step 1 - Dispatch Parallel Reviewers
 
 Call `subagent` with `tasks: [...]` containing ALL THREE reviewers simultaneously:
 
-**Reviewer A — Requirements Coverage**
-Prompt: "Review milestone {{milestoneId}} requirements coverage. Working directory: {{workingDirectory}}. Read `.gsd/{{milestoneId}}/REQUIREMENTS.md` (or equivalent requirements file). For each requirement, check the slice SUMMARY files in `.gsd/{{milestoneId}}/` to determine if it is: COVERED (clearly demonstrated), PARTIAL (mentioned but not fully demonstrated), or MISSING (no evidence). Output a markdown table with columns: Requirement | Status | Evidence. End with a one-line verdict: PASS if all covered, NEEDS-ATTENTION if partials exist, FAIL if any missing."
+**Reviewer A - Requirements Coverage**
+Prompt: "Review milestone {{milestoneId}} requirements coverage. Working directory: {{workingDirectory}}. Read `.gsd/{{milestoneId}}/REQUIREMENTS.md` or equivalent. For each requirement, check slice SUMMARY files in `.gsd/{{milestoneId}}/` and mark COVERED, PARTIAL, or MISSING. Output table: Requirement | Status | Evidence. End with one-line verdict: PASS if all covered, NEEDS-ATTENTION if partials exist, FAIL if any missing."
 
-**Reviewer B — Cross-Slice Integration**
-Prompt: "Review milestone {{milestoneId}} cross-slice integration. Working directory: {{workingDirectory}}. Read `{{roadmapPath}}` and find the boundary map (produces/consumes contracts). For each boundary, 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 B - Cross-Slice Integration**
+Prompt: "Review milestone {{milestoneId}} cross-slice integration. Working directory: {{workingDirectory}}. Read `{{roadmapPath}}` and find the boundary map (produces/consumes contracts). For each boundary, confirm producer SUMMARY produced the artifact and consumer SUMMARY consumed it. Output table: Boundary | Producer Summary | Consumer Summary | Status. End with one-line verdict: PASS if all boundaries honored, NEEDS-ATTENTION if any gaps."
 
-**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. 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."
+**Reviewer C - Assessment & Acceptance Criteria**
+Prompt: "Review milestone {{milestoneId}} assessment evidence and acceptance criteria. Working directory: {{workingDirectory}}. Read `.gsd/{{milestoneId}}/CONTEXT.md` for criteria. Check slice ASSESSMENT files. Verify each criterion maps to a passing assessment or clear SUMMARY evidence. Then review inlined milestone verification classes. For each non-empty planned class, output 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 sections `Acceptance Criteria` with checklist `[ ] Criterion | Evidence`, and `Verification Classes` with the table. End with one-line verdict: PASS if all criteria and classes are covered, NEEDS-ATTENTION if gaps exist."
 
-### Step 2 — Synthesize Findings
+### Step 2 - Synthesize Findings
 
-After all reviewers complete, aggregate their verdicts:
-- If ALL reviewers say PASS → overall verdict: `pass`
-- If any reviewer says NEEDS-ATTENTION → overall verdict: `needs-attention`
-- If any reviewer says FAIL → overall verdict: `needs-remediation`
+Aggregate reviewer verdicts:
+- ALL PASS -> `pass`
+- Any NEEDS-ATTENTION -> `needs-attention`
+- Any FAIL -> `needs-remediation`
 
-### Step 3 — Persist Validation
+### Step 3 - Persist Validation
 
-Prepare the validation content you will pass to `gsd_validate_milestone`. Do **not** manually write `{{validationPath}}` — the DB-backed tool is the canonical write path and renders the validation file for you.
+Prepare validation content for `gsd_validate_milestone`. Do **not** manually write `{{validationPath}}` - the DB-backed tool is the canonical write path and renders the file.
 
 ```markdown
 ---
@@ -65,7 +65,7 @@ reviewers: 3
 <paste Reviewer C output>
 
 ## Synthesis
-<2-3 sentences summarizing overall findings and verdict rationale>
+<2-3 sentence verdict rationale>
 
 ## Remediation Plan
 <if verdict is not pass: specific actions required>
@@ -74,14 +74,14 @@ 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.
+**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` for milestone and slice state. Data is already inlined or available via `gsd_*` tools. Direct DB access risks WAL corruption and bypasses validation.
 
 If verdict is `needs-remediation`:
-- Use `gsd_reassess_roadmap` to add the remediation slices instead of editing `{{roadmapPath}}` manually
+- Use `gsd_reassess_roadmap` to add remediation slices instead of editing `{{roadmapPath}}` manually.
 - Those slices will be planned and executed before validation re-runs
 
 **You MUST call `gsd_validate_milestone` before finishing. Do not manually write `{{validationPath}}`.**
 
-**File system safety:** When scanning milestone directories for evidence, use `ls` or `find` to list directory contents first — never pass a directory path (e.g. `tasks/`, `slices/`) directly to the `read` tool. The `read` tool only accepts file paths, not directories.
+**File system safety:** When scanning milestone directories, use `ls` or `find` first. Never pass a directory path such as `tasks/` or `slices/` directly to `read`; it only accepts files.
 
 When done, say: "Milestone {{milestoneId}} validation complete — verdict: <verdict>."

package/src/resources/extensions/gsd/prompts/worktree-merge.md

@@ -1,16 +1,16 @@
-You are merging changes from worktree **{{worktreeName}}** (branch `{{worktreeBranch}}`) into target branch `{{mainBranch}}`.
+You are merging worktree **{{worktreeName}}** (branch `{{worktreeBranch}}`) into target branch `{{mainBranch}}`.
 
 ## Working Directory
 
-Your current working directory has been set to the **main project tree** at `{{mainTreePath}}`. You are on the `{{mainBranch}}` branch. All git and file commands run from here.
+Your CWD is the **main project tree** at `{{mainTreePath}}` on `{{mainBranch}}`. Run all git and file commands here.
 
-- **Main tree (CWD):** `{{mainTreePath}}` — this is where you run `git merge`, read main-branch files, and commit
-- **Worktree directory:** `{{worktreePath}}` — the worktree's working copy; read files here to inspect worktree versions before merging
+- **Main tree (CWD):** `{{mainTreePath}}` — run `git merge`, read main files, commit.
+- **Worktree directory:** `{{worktreePath}}` — inspect worktree versions before merging.
 - **Worktree branch:** `{{worktreeBranch}}`
 
 ## Context
 
-The worktree was created as a parallel workspace. It may contain code changes, new milestones, updated roadmaps, new plans, research, decisions, or other artifacts that need to be merged into the target branch.
+The worktree may contain code, milestones, roadmaps, plans, research, decisions, requirements, or other artifacts to merge.
 
 ### Commit History (worktree)
 
@@ -43,50 +43,50 @@ The worktree was created as a parallel workspace. It may contain code changes, n
 
 ## Your Task
 
-Analyze the changes and guide the merge. Follow these steps exactly:
+Analyze and guide the merge exactly:
 
 ### Step 1: Categorize Changes
 
-Classify each changed file:
+Classify each changed file.
 
 **Code changes:**
-- **New source files** — new modules, components, utilities, tests
-- **Modified source files** — changes to existing code
+- **New source files** — modules, components, utilities, tests.
+- **Modified source files** — existing code changes.
 - **Config changes** — package.json, tsconfig, build config, etc.
-- **Deleted files** — removed source or config files
+- **Deleted files** — removed source/config.
 
 **GSD artifact changes:**
-- **New milestones** — entirely new M###/ directories with roadmaps
-- **New slices/tasks** — new planning artifacts within existing milestones
-- **Updated roadmaps** — modifications to existing M###-ROADMAP.md files
-- **Updated plans** — modifications to existing slice or task plans
-- **Research/context** — new or updated RESEARCH.md, CONTEXT.md files
+- **New milestones** — new M###/ directories with roadmaps.
+- **New slices/tasks** — planning artifacts inside existing milestones.
+- **Updated roadmaps** — changed M###-ROADMAP.md files.
+- **Updated plans** — changed slice/task plans.
+- **Research/context** — new or updated RESEARCH.md, CONTEXT.md.
 - **Decisions** — changes to DECISIONS.md
 - **Requirements** — changes to REQUIREMENTS.md
 - **Other** — anything else
 
 ### Step 2: Conflict Assessment
 
-For each **modified** file, check whether the main branch version has also changed since the worktree branched off. Flag any files where both branches have diverged — these need manual reconciliation.
+For each **modified** file, check whether main also changed since the worktree branched. Flag diverged files for manual reconciliation.
 
 To compare versions:
-- **Main-branch version:** read the file at its normal path (your CWD is the main tree)
-- **Worktree version:** read the file at `{{worktreePath}}/<relative-path>`
-- Use `git merge-base {{mainBranch}} {{worktreeBranch}}` to find the common ancestor if needed
+- **Main version:** read normal path from CWD.
+- **Worktree version:** read `{{worktreePath}}/<relative-path>`.
+- Use `git merge-base {{mainBranch}} {{worktreeBranch}}` if needed.
 
 Classify each modified file:
-- **Clean merges** — main hasn't changed, worktree changes can apply directly
-- **Conflicts** — both branches changed the same file; needs reconciliation
-- **Stale changes** — worktree modified a file that main has since replaced or removed
+- **Clean merges** — main unchanged; apply worktree changes directly.
+- **Conflicts** — both changed same file; reconcile.
+- **Stale changes** — main replaced/removed a file the worktree modified.
 
 ### Step 3: Merge Strategy
 
-Present a merge plan to the user:
+Present a merge plan:
 
-1. For **clean merges**: list files that will merge without conflict
-2. For **conflicts**: show both versions side-by-side and propose a reconciled version
-3. For **new files**: confirm they should be added to the main branch
-4. For **removed files**: confirm the removals are intentional
+1. **Clean merges:** files expected to merge without conflict.
+2. **Conflicts:** show both versions side-by-side and propose reconciliation.
+3. **New files:** confirm they should be added.
+4. **Removed files:** confirm removals are intentional.
 
 Ask the user to confirm the merge plan before proceeding.
 
@@ -97,17 +97,17 @@ Ask the user to confirm the merge plan before proceeding.
 Once the user has explicitly confirmed, run all commands from `{{mainTreePath}}` (your CWD):
 
 1. Ensure you are on the target branch: `git checkout {{mainBranch}}`
-2. If there are conflicts requiring manual reconciliation, apply the reconciled versions first
+2. If conflicts require manual reconciliation, apply reconciled versions first
 3. Run `git merge --squash {{worktreeBranch}}` to bring in all changes
-4. Review the staged changes — if any reconciled files need adjustment, apply them now
+4. Review staged changes; adjust reconciled files if needed
 5. Commit with message: `merge(worktree/{{worktreeName}}): <summary of what was merged>`
 6. Report what was merged
 
 ### Step 5: Cleanup Prompt
 
 After a successful merge, ask the user whether to:
-- **Remove the worktree** — delete the worktree directory and the `{{worktreeBranch}}` branch
-- **Keep the worktree** — leave it for continued parallel work
+- **Remove the worktree** — delete the worktree directory and `{{worktreeBranch}}`.
+- **Keep the worktree** — leave it for continued parallel work.
 
 If the user chooses to remove it, run these commands from `{{mainTreePath}}`:
 ```
@@ -119,7 +119,7 @@ git branch -D {{worktreeBranch}}
 
 ## Important
 
-- Never silently discard changes from either branch
-- When in doubt about a conflict, show both versions and ask the user
-- Preserve all GSD artifact formatting conventions (frontmatter, section structure, checkbox states)
-- If the worktree introduced new milestone IDs that conflict with main, flag this immediately
+- Never silently discard changes from either branch.
+- When in doubt, show both versions and ask.
+- Preserve GSD artifact formatting: frontmatter, sections, checkbox states.
+- If new milestone IDs conflict with main, flag immediately.

package/src/resources/extensions/gsd/state.ts

@@ -1,3 +1,5 @@
+// Project/App: GSD-2
+// File Purpose: Runtime state derivation from GSD workflow database and legacy files.
 // GSD Extension — State Derivation
 // DB-authoritative runtime derivation with explicit legacy filesystem fallback.
 // Pure TypeScript, zero Pi dependencies.
@@ -46,6 +48,7 @@ import { logWarning } from './workflow-logger.js';
 import { extractVerdict } from './verdict-parser.js';
 import { detectPendingEscalation } from './escalation.js';
 import { isTerminalMilestoneSummaryContent } from './milestone-summary-classifier.js';
+import { incrementLegacyTelemetry } from './legacy-telemetry.js';
 
 import {
   isDbAvailable,
@@ -59,10 +62,9 @@ import {
   getRequirementCounts,
   getLatestAssessmentByScope,
   getPendingGateCountForTurn,
-  type MilestoneRow,
-  type SliceRow,
-  type TaskRow,
 } from './gsd-db.js';
+import type { MilestoneRow } from './db-milestone-artifact-rows.js';
+import type { SliceRow, TaskRow } from './db-task-slice-rows.js';
 
 /**
  * A "ghost" milestone directory contains only META.json (and no substantive
@@ -331,6 +333,7 @@ export async function deriveState(
     }
     result = await _deriveStateImpl(basePath, opts);
     _telemetry.markdownDeriveCount++;
+    incrementLegacyTelemetry("legacy.markdownFallbackUsed");
   } else {
     if (wasDbOpenAttempted()) {
       logWarning("state", "DB unavailable — refusing implicit markdown state derivation");

package/src/resources/extensions/gsd/tests/auto-abort-pause-regression.test.ts

@@ -0,0 +1,38 @@
+import test from "node:test";
+import assert from "node:assert/strict";
+
+import { _buildAbortedPauseContext, isUserInitiatedAbortMessage } from "../bootstrap/agent-end-recovery.js";
+import { _buildCancelledUnitStopReason } from "../auto/phases.js";
+
+test("aborted agent_end maps errorMessage into structured aborted pause context", () => {
+  const withMessage = _buildAbortedPauseContext({ errorMessage: "provider aborted request" });
+  assert.deepEqual(withMessage, {
+    message: "provider aborted request",
+    category: "aborted",
+    isTransient: true,
+  });
+
+  const withoutMessage = _buildAbortedPauseContext({});
+  assert.deepEqual(withoutMessage, {
+    message: "Operation aborted",
+    category: "aborted",
+    isTransient: true,
+  });
+});
+
+test("cancelled non-session failures are labeled as unit aborts (not session-creation failures)", () => {
+  const cancelled = _buildCancelledUnitStopReason("execute-task", "M001-S001-T001", {
+    category: "aborted",
+    message: "tool invocation cancelled",
+  });
+
+  assert.match(cancelled.notifyMessage, /aborted after dispatch/);
+  assert.equal(cancelled.stopReason, "Unit aborted: tool invocation cancelled");
+  assert.equal(cancelled.loopReason, "unit-aborted");
+});
+
+test("provider user-abort errors are recognized as cancellations, not provider outages", () => {
+  assert.equal(isUserInitiatedAbortMessage("Claude Code process aborted by user"), true);
+  assert.equal(isUserInitiatedAbortMessage("Request aborted by user"), true);
+  assert.equal(isUserInitiatedAbortMessage("HTTP 503 Service Unavailable"), false);
+});

package/src/resources/extensions/gsd/tests/auto-dashboard.test.ts

@@ -13,6 +13,9 @@ import {
   formatWidgetTokens,
   estimateTimeRemaining,
   extractUatSliceId,
+  updateProgressWidget,
+  getRoadmapSlicesSync,
+  clearSliceProgressCache,
   getWidgetMode,
   cycleWidgetMode,
   _resetWidgetModeForTests,
@@ -20,7 +23,16 @@ import {
   _refreshLastCommitForTests,
   _getLastCommitForTests,
   _getLastCommitFetchedAtForTests,
+  formatRuntimeHealthSignal,
+  shouldRenderRoadmapProgress,
 } from "../auto-dashboard.ts";
+import {
+  openDatabase,
+  closeDatabase,
+  insertMilestone,
+  insertSlice,
+  insertTask,
+} from "../gsd-db.ts";
 
 const autoSource = readFileSync(join(process.cwd(), "src", "resources", "extensions", "gsd", "auto.ts"), "utf-8");
 const dashboardSource = readFileSync(join(process.cwd(), "src", "resources", "extensions", "gsd", "auto-dashboard.ts"), "utf-8");
@@ -183,6 +195,37 @@ test("formatWidgetTokens formats millions with M", () => {
   assert.equal(formatWidgetTokens(25_000_000), "25M");
 });
 
+test("formatRuntimeHealthSignal surfaces idle recovery instead of generic progress", () => {
+  const signal = formatRuntimeHealthSignal({
+    version: 1,
+    unitType: "research-milestone",
+    unitId: "M001",
+    startedAt: 1_000,
+    updatedAt: 600_000,
+    phase: "recovered",
+    wrapupWarningSent: false,
+    continueHereFired: false,
+    timeoutAt: null,
+    lastProgressAt: 1_000,
+    progressCount: 1,
+    lastProgressKind: "idle-recovery-retry",
+    recoveryAttempts: 1,
+    lastRecoveryReason: "idle",
+  }, 600_000);
+
+  assert.deepEqual(signal, {
+    level: "yellow",
+    summary: "Recovering",
+    detail: "retry 1 after idle stall",
+  });
+});
+
+test("shouldRenderRoadmapProgress hides pre-roadmap zero-slice progress", () => {
+  assert.equal(shouldRenderRoadmapProgress(null), false);
+  assert.equal(shouldRenderRoadmapProgress({ done: 0, total: 0, activeSliceTasks: null } as any), false);
+  assert.equal(shouldRenderRoadmapProgress({ done: 0, total: 1, activeSliceTasks: null } as any), true);
+});
+
 // ─── estimateTimeRemaining ──────────────────────────────────────────────
 
 test("estimateTimeRemaining returns null when no ledger data", () => {
@@ -220,6 +263,61 @@ test("auto progress widget renders RTK savings under the footer stats line", ()
   assert.match(dashboardSource, /lines\.push\(rightAlign\("", theme\.fg\("dim", cachedRtkLabel\), width\)\);/);
 });
 
+test("updateProgressWidget refreshes slice progress cache immediately", (t) => {
+  const dir = makeTempDir("progress-cache");
+  mkdirSync(join(dir, ".gsd"), { recursive: true });
+
+  t.after(() => {
+    closeDatabase();
+    clearSliceProgressCache();
+    cleanup(dir);
+  });
+
+  openDatabase(join(dir, ".gsd", "gsd.db"));
+  insertMilestone({ id: "M001", title: "Milestone", status: "active" });
+  insertSlice({ milestoneId: "M001", id: "S01", title: "Done", status: "complete", sequence: 1 });
+  insertSlice({ milestoneId: "M001", id: "S02", title: "Active", status: "pending", sequence: 2 });
+  insertSlice({ milestoneId: "M001", id: "S03", title: "Pending", status: "pending", sequence: 3 });
+  insertTask({ milestoneId: "M001", sliceId: "S02", id: "T01", title: "Task", status: "complete" });
+
+  clearSliceProgressCache();
+  updateProgressWidget(
+    {
+      hasUI: true,
+      ui: { setWidget() {} },
+    } as any,
+    "complete-slice",
+    "M001/S02",
+    {
+      phase: "summarizing",
+      activeMilestone: { id: "M001", title: "Milestone" },
+      activeSlice: { id: "S02", title: "Active" },
+      activeTask: null,
+    } as any,
+    {
+      getAutoStartTime: () => 0,
+      isStepMode: () => false,
+      getCmdCtx: () => null,
+      getBasePath: () => dir,
+      isVerbose: () => false,
+      isSessionSwitching: () => false,
+      getCurrentDispatchedModelId: () => null,
+    },
+  );
+
+  const progress = getRoadmapSlicesSync();
+  assert.ok(progress, "progress cache should be populated immediately after updateProgressWidget");
+  assert.deepEqual({
+    done: progress.done,
+    total: progress.total,
+    activeSliceTasks: progress.activeSliceTasks,
+  }, {
+    done: 1,
+    total: 3,
+    activeSliceTasks: { done: 1, total: 1 },
+  });
+});
+
 test("last commit refresh backs off cleanly when base path is not a git repo", (t) => {
   const dir = makeTempDir("non-git");
   mkdirSync(dir, { recursive: true });

package/src/resources/extensions/gsd/tests/auto-loop.test.ts

@@ -879,6 +879,123 @@ test("autoLoop passes structured session-lock failure details to the handler", a
   );
 });
 
+// Regression for #5308: the iteration prelude must dequeue sidecar items
+// (popping the queue and emitting the `sidecar-dequeue` journal event) BEFORE
+// validateSessionLock + break-on-invalid. Inverting that order silently drops
+// queued sidecar work on lock-loss. Covers first-iteration and mid-session.
+test("autoLoop dequeues sidecar item before session-lock break (first iteration, #5308)", async () => {
+  _resetPendingResolve();
+
+  const ctx = makeMockCtx();
+  ctx.ui.setStatus = () => {};
+  const pi = makeMockPi();
+  const s = makeLoopSession();
+  s.sidecarQueue.push({
+    kind: "hook" as const,
+    unitType: "hook/review",
+    unitId: "M001/S01/T01/review",
+    prompt: "review the code",
+  });
+
+  const journalEvents: string[] = [];
+  const deps = makeMockDeps({
+    validateSessionLock: () =>
+      ({
+        valid: false,
+        failureReason: "compromised",
+        expectedPid: process.pid,
+      }) as SessionLockStatus,
+    handleLostSessionLock: () => {
+      deps.callLog.push("handleLostSessionLock");
+    },
+    emitJournalEvent: (entry) => {
+      journalEvents.push(entry.eventType);
+    },
+  });
+
+  await autoLoop(ctx, pi, s, deps);
+
+  assert.equal(
+    s.sidecarQueue.length,
+    0,
+    "sidecar item must be popped on lock-loss iteration (pre-#5308 ordering)",
+  );
+  assert.ok(
+    journalEvents.includes("sidecar-dequeue"),
+    "sidecar-dequeue journal event must be emitted before session-lock break",
+  );
+  assert.ok(
+    deps.callLog.includes("handleLostSessionLock"),
+    "session lock handler must still fire after sidecar dequeue",
+  );
+  assert.ok(!deps.callLog.includes("deriveState"), "lock loss should stop before deriving state");
+});
+
+test("autoLoop dequeues sidecar item before session-lock break (mid-session, #5308)", async () => {
+  _resetPendingResolve();
+
+  const ctx = makeMockCtx();
+  ctx.ui.setStatus = () => {};
+  const pi = makeMockPi();
+  const s = makeLoopSession();
+
+  const journalEvents: string[] = [];
+  let lockCheckCount = 0;
+  const deps = makeMockDeps({
+    // First iteration: lock valid; second iteration: lock invalidates.
+    validateSessionLock: () => {
+      lockCheckCount += 1;
+      if (lockCheckCount === 1) {
+        return { valid: true } as SessionLockStatus;
+      }
+      return {
+        valid: false,
+        failureReason: "compromised",
+        expectedPid: process.pid,
+      } as SessionLockStatus;
+    },
+    handleLostSessionLock: () => {
+      deps.callLog.push("handleLostSessionLock");
+    },
+    emitJournalEvent: (entry) => {
+      journalEvents.push(entry.eventType);
+    },
+    // Enqueue a sidecar item at the end of iteration 1, so iteration 2 begins
+    // with a non-empty queue and an invalid lock.
+    postUnitPostVerification: async () => {
+      deps.callLog.push("postUnitPostVerification");
+      s.sidecarQueue.push({
+        kind: "hook" as const,
+        unitType: "hook/review",
+        unitId: "M001/S01/T01/review",
+        prompt: "review the code",
+      });
+      return "continue" as const;
+    },
+  });
+
+  const loopPromise = autoLoop(ctx, pi, s, deps);
+  // Allow the loop to reach runUnit's await on iteration 1.
+  await new Promise((r) => setTimeout(r, 50));
+  resolveAgentEnd(makeEvent());
+  await loopPromise;
+
+  assert.ok(lockCheckCount >= 2, "lock validator must run on iteration 2");
+  assert.equal(
+    s.sidecarQueue.length,
+    0,
+    "queued sidecar item must be popped on the lock-loss iteration",
+  );
+  assert.ok(
+    journalEvents.includes("sidecar-dequeue"),
+    "sidecar-dequeue journal event must be emitted before session-lock break",
+  );
+  assert.ok(
+    deps.callLog.includes("handleLostSessionLock"),
+    "lock-loss handler must still fire on iteration 2",
+  );
+});
+
 test("autoLoop exits on terminal blocked state", async (t) => {
   _resetPendingResolve();