gsd-pi 2.72.0-dev.de4c4b3 → 2.73.0

package/src/resources/extensions/gsd/prompts/discuss.md

@@ -49,31 +49,132 @@ This happens ONCE, before the first round. The goal: your first questions should
 
 For subsequent rounds, continue investigating between rounds — check docs, search, or scout as needed to make each round's questions smarter. But the first-round investigation is mandatory and explicit. Distribute searches across turns rather than clustering them in one turn.
 
-## Question Rounds
+## Layered Question Rounds
 
-Ask **1–3 questions per round**. Keep each round tightly focused on one or two of the depth checklist dimensions — do not try to cover all six in one round.
+Questions are organized into four layers. Each layer targets a specific depth dimension. At each layer: ask 1-3 open questions per round, investigate between rounds as needed, and gate before advancing.
 
-**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.**
+**Default to open questions.** Use `ask_user_questions` only when there are 2-3 genuinely distinct paths with clear tradeoffs (e.g., "REST vs GraphQL" or "Postgres vs SQLite"). For nuanced design questions, ask in plain text and let the user explain.
 
-**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.
+**If `{{structuredQuestionsAvailable}}` is `true`:** use `ask_user_questions` for binary/ternary choices. 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.**
 
-After each answer set, investigate further if any answer opens a new unknown, then ask 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.
 
-### Round cadence
+**Incremental persistence:** After every 2 question rounds (across any layer), silently save a `{{milestoneId}}-CONTEXT-DRAFT.md` using `gsd_summary_save` with `artifact_type: "CONTEXT-DRAFT"` and `milestone_id: "{{milestoneId}}"`. This protects confirmed work against session crashes. Do NOT mention this save to the user.
 
-After each round of answers, decide whether you already have enough depth to write strong output.
+### Identify Work Type
 
-- **Incremental persistence:** After every 2 question rounds, silently save a `{{milestoneId}}-CONTEXT-DRAFT.md` using `gsd_summary_save` with `artifact_type: "CONTEXT-DRAFT"` and `milestone_id: "{{milestoneId}}"`. This protects confirmed work against session crashes. Do NOT mention this save to the user.
-- If not ready, continue to the next round immediately. Do **not** ask a meta "ready to wrap up?" question after every round.
-- **Depth-matching rule:** Simple, well-defined work needs fewer rounds — maybe 1–2. Large, ambiguous visions need more — maybe 4+. Do not pad rounds to hit a number. Stop when the Depth Enforcement checklist below is fully satisfied.
-- Do not count the reflection step as a question round. Rounds start after reflection is confirmed.
-- When you genuinely believe the depth checklist is satisfied, move to the Depth Verification step below. Do not ask a separate "ready to wrap up?" gate — the depth verification IS the gate.
+Before starting Layer 1, identify the primary work type and state it:
+
+"Based on your description and the codebase, this is primarily **[work type]** work."
+
+Work types include: API/backend, UI/frontend, CLI/developer tool, data pipeline, ML/AI, infrastructure/platform, refactoring/migration, or a combination. The user can correct this. The classification shapes which questions deserve deep exploration at each layer.
+
+### Layer 1 — Scope
+
+Resolve what's in and what's out. Ask about:
+- Feature boundaries — what exactly ships in this milestone vs later
+- Ambiguities in the user's description — anything you're unsure about, ask
+- Dependencies — what does this work depend on, what depends on it
+- Priority — if scope needs trimming, what matters most
+
+Adapt depth to work type:
+- **CLI work:** Focus on user mental model, command grammar, what existing commands do
+- **Refactoring:** Focus on what changes vs what must stay identical
+
+**Depth-matching:** Simple, well-defined scope may need 1 round. Ambiguous or large scope may need 3-4 rounds. Don't pad rounds to hit a number.
+
+#### Layer 1 Gate
+
+Summarize scope decisions in the user's own terminology:
+- What's included, what's excluded, what's deferred
+- Key boundaries and constraints
+
+Then ask: **"Does this capture the scope? Adjust anything before we move on."**
+
+If the user adjusts, reflect the updated understanding and ask again. Do not advance until the user explicitly confirms. If the user says "looks good, let's move faster" at any gate, respect that and advance.
+
+---
+
+### Layer 2 — Architecture
+
+Resolve how it's built. Ask about:
+- Per-slice technical decisions — what approach for each major piece
+- Inter-slice contracts — how do the pieces connect
+- Library/framework choices — with evidence from investigation, not assumptions
+- Integration with existing code — what patterns to follow, what to change
+
+Adapt depth to work type:
+- **API work:** Contracts, versioning, backwards compatibility, auth boundaries
+- **UI work:** Component boundaries, state management, data flow
+- **Infrastructure:** Deployment topology, failure domains, rollback
+
+Between rounds, use your available web search tools to research technologies from the Codebase Brief. Search for "[technology] [version] best practices [current year]" and "[technology] [version] known issues". Present findings alongside your questions.
+
+#### Layer 2 Gate
+
+Summarize architecture decisions, each with:
+- The decision and rationale
+- Evidence source (codebase patterns, library docs, web research)
+- Alternatives considered
+
+Then ask: **"Does this capture the architecture? Adjust anything before we move on."**
+
+Same gate rules: reflect adjustments, wait for confirmation.
+
+---
+
+### Layer 3 — Error States
+
+Resolve what happens when things fail. Present this layer with an option:
+
+"We can go deep on error handling and failure modes, or I can apply sensible defaults based on the architecture decisions above. Which do you prefer?"
+
+If the user chooses defaults, summarize what the defaults are and gate. If the user chooses to go deep, ask about:
+- Failure modes for each major component
+- Error propagation between layers (API → frontend, service → database)
+- Timeout, retry, and circuit-breaker strategies
+- What the user sees when something fails
+
+Adapt depth to work type:
+- **API work:** Rate limiting, timeout cascades, partial failure, status codes
+- **UI work:** Loading states, optimistic updates, offline behavior, error boundaries
+- **Data pipelines:** Data corruption, checkpoint recovery, idempotency
+
+#### Layer 3 Gate
+
+Summarize error handling strategy. Then ask: **"Does this capture how errors should be handled? Adjust anything before we move on."**
+
+---
+
+### Layer 4 — Quality Bar
+
+Resolve what "done" means concretely. Ask about:
+- Per-slice acceptance criteria — specific enough for automated verification
+- Test strategy — what types of tests, what coverage expectations
+- Definition of done — what must be true before the milestone ships
+- Non-functional requirements — performance, accessibility, security if relevant
+
+Adapt depth to work type:
+- **CLI work:** Shell compatibility, error message clarity, exit code semantics
+- **Refactoring:** Behavioral equivalence tests, not just code coverage
+- **UI work:** Visual regression criteria, responsive breakpoints
+
+#### Layer 4 Gate
+
+Summarize quality bar: acceptance criteria, test strategy, definition of done. Then ask: **"Does this capture the quality bar? Adjust anything before we move on to requirements and roadmap?"**
+
+---
+
+### Layer cadence
+
+- Do not count the reflection step as a question round. Rounds start at Layer 1 after reflection is confirmed.
+- When all four layer gates have been confirmed (or skipped by the user), move to the Depth Verification step below. Do not ask a separate "ready to wrap up?" gate — the depth verification confirms the full picture.
 
 ## Questioning Philosophy
 
 You are a thinking partner, not an interviewer.
 
-**Turn-taking contract (non-bypassable).** Never fabricate, simulate, or role-play user responses. Never generate fake transcript markers like `[User]`, `[Human]`, or `User:` to invent input. Ask one question round (1-3 questions) per turn, then stop and wait for the user's actual response before continuing. If you use `ask_user_questions`, call it at most once per turn and treat its returned response as the only valid structured user input for that round.
+**Turn-taking contract (non-bypassable).** Never fabricate, simulate, or role-play user responses. Never generate fake transcript markers like `[User]`, `[Human]`, or `User:` to invent input. 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) per turn, then stop and wait for the user's actual response before continuing. If you use `ask_user_questions`, call it at most once per turn and treat its returned response as the only valid structured user input for that round.
 
 **Start open, follow energy.** Let the user's enthusiasm guide where you dig deeper. If they light up about a particular aspect, explore it. If they're vague about something, that's where you probe.
 
@@ -225,6 +326,14 @@ Once the user is satisfied, in a single pass:
 **Depth-Preservation Guidance for context.md:**
 When writing context.md, preserve the user's exact terminology, emphasis, and specific framing from the discussion. Do not paraphrase user nuance into generic summaries. If the user said "craft feel," write "craft feel" — not "high-quality user experience." If they emphasized a specific constraint or negative requirement, carry that emphasis through verbatim. The context file is downstream agents' only window into this conversation — flattening specifics into generics loses the signal that shaped every decision.
 
+**Structured sections from discussion layers:**
+When writing CONTEXT.md, include structured sections that map to the discussion layers:
+- **Scope** — what's in, what's out, what's deferred (from Layer 1 gate summary)
+- **Architectural Decisions** — each with rationale, evidence source, alternatives considered (from Layer 2 gate summary)
+- **Error Handling Strategy** — failure modes, propagation, user-facing error behavior (from Layer 3 gate summary)
+- **Acceptance Criteria** — per-slice criteria specific enough for the planner to use directly (from Layer 4 gate summary)
+These sections are in addition to whatever other context the discussion surfaced.
+
 4. Write `{{contextPath}}` — use the **Context** output template below. Preserve key risks, unknowns, existing codebase constraints, integration points, and relevant requirements surfaced during discussion.
 5. Call `gsd_plan_milestone` to create the roadmap. Decompose into demoable vertical slices with risk, depends, demo sentences, proof strategy, verification classes, milestone definition of done, requirement coverage, and a boundary map. 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. Use the **Roadmap** output template below to structure the tool call parameters.
 6. For each architectural or pattern decision made during discussion, call `gsd_decision_save` — the tool auto-assigns IDs and regenerates `.gsd/DECISIONS.md` automatically.

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

@@ -35,7 +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. 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 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/src/resources/extensions/gsd/state.ts

@@ -57,6 +57,7 @@ import {
   insertMilestone,
   insertSlice,
   insertTask,
+  updateSliceStatus,
   updateTaskStatus,
   getPendingGateCountForTurn,
   type MilestoneRow,
@@ -358,6 +359,25 @@ function reconcileDiskToDb(basePath: string): MilestoneRow[] {
         depends: s.depends, demo: s.demo,
       });
     }
+
+    // Reconcile stale *existing* slice rows (#3599): a slice row may exist in
+    // the DB with status "pending" even though disk artifacts (SUMMARY) prove
+    // completion — the same class of desync that task-level reconciliation
+    // (further below) already handles.  Without this, the dependency resolver
+    // builds doneSliceIds from stale DB rows and downstream slices stay blocked
+    // forever with "No slice eligible".
+    for (const dbSlice of dbSlices) {
+      if (isStatusDone(dbSlice.status)) continue;
+      const summaryPath = resolveSliceFile(basePath, mid, dbSlice.id, "SUMMARY");
+      if (summaryPath) {
+        try {
+          updateSliceStatus(mid, dbSlice.id, "complete");
+          logWarning("reconcile", `slice ${mid}/${dbSlice.id} status reconciled from "${dbSlice.status}" to "complete" (#3599)`, { mid, sid: dbSlice.id });
+        } catch (e) {
+          logError("reconcile", `failed to update slice ${dbSlice.id}`, { sid: dbSlice.id, error: (e as Error).message });
+        }
+      }
+    }
   }
   return allMilestones;
 }

package/src/resources/extensions/gsd/tests/auto-paused-ui-cleanup.test.ts

@@ -0,0 +1,27 @@
+import { test } from "node:test";
+import assert from "node:assert/strict";
+import { readFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const autoSource = readFileSync(join(__dirname, "..", "auto.ts"), "utf-8");
+
+test("#3370: cleanupAfterLoopExit preserves paused auto badge after provider pause", () => {
+  const cleanupIdx = autoSource.indexOf("function cleanupAfterLoopExit");
+  assert.ok(cleanupIdx > -1, "auto.ts should define cleanupAfterLoopExit");
+
+  const dispatchIdx = autoSource.indexOf("export async function dispatchHookUnit", cleanupIdx);
+  assert.ok(dispatchIdx > cleanupIdx, "cleanupAfterLoopExit body should be bounded by the next export");
+
+  const cleanupBody = autoSource.slice(cleanupIdx, dispatchIdx);
+  const pausedGuardIdx = cleanupBody.indexOf("if (!s.paused) {");
+  const clearStatusIdx = cleanupBody.indexOf('ctx.ui.setStatus("gsd-auto", undefined);');
+
+  assert.ok(pausedGuardIdx > -1, "loop-exit cleanup must guard UI clearing when auto is paused");
+  assert.ok(clearStatusIdx > pausedGuardIdx, "status clearing must live behind the paused guard");
+  assert.ok(
+    autoSource.includes('ctx?.ui.setStatus("gsd-auto", "paused");'),
+    "pauseAuto must still set the paused badge for transient provider pauses",
+  );
+});

package/src/resources/extensions/gsd/tests/block-db-writes.test.ts

@@ -0,0 +1,63 @@
+/**
+ * Regression test for #3674 — block direct writes to gsd.db
+ *
+ * When gsd_complete_task was unavailable, agents fell back to shell-based
+ * sqlite3 writes, corrupting the WAL-backed database. The fix extends
+ * write-intercept to block file writes and bash commands targeting gsd.db.
+ */
+
+import { describe, test } from 'node:test';
+import assert from 'node:assert/strict';
+import { isBlockedStateFile, isBashWriteToStateFile } from '../write-intercept.ts';
+
+describe('isBlockedStateFile blocks gsd.db paths (#3674)', () => {
+  test('blocks .gsd/gsd.db', () => {
+    assert.ok(isBlockedStateFile('/project/.gsd/gsd.db'));
+  });
+
+  test('blocks .gsd/gsd.db-wal', () => {
+    assert.ok(isBlockedStateFile('/project/.gsd/gsd.db-wal'));
+  });
+
+  test('blocks .gsd/gsd.db-shm', () => {
+    assert.ok(isBlockedStateFile('/project/.gsd/gsd.db-shm'));
+  });
+
+  test('blocks resolved symlink path under .gsd/projects/', () => {
+    assert.ok(isBlockedStateFile('/home/user/.gsd/projects/myproj/gsd.db'));
+  });
+
+  test('still blocks STATE.md', () => {
+    assert.ok(isBlockedStateFile('/project/.gsd/STATE.md'));
+  });
+
+  test('does not block other .gsd files', () => {
+    assert.ok(!isBlockedStateFile('/project/.gsd/DECISIONS.md'));
+  });
+});
+
+describe('isBashWriteToStateFile blocks DB shell commands (#3674)', () => {
+  test('blocks sqlite3 targeting gsd.db', () => {
+    assert.ok(isBashWriteToStateFile('sqlite3 .gsd/gsd.db "INSERT INTO ..."'));
+  });
+
+  test('blocks better-sqlite3 targeting gsd.db', () => {
+    assert.ok(isBashWriteToStateFile('node -e "require(\'better-sqlite3\')(\'.gsd/gsd.db\')"'));
+  });
+
+  test('blocks shell redirect to gsd.db', () => {
+    assert.ok(isBashWriteToStateFile('echo data > .gsd/gsd.db'));
+  });
+
+  test('blocks cp to gsd.db', () => {
+    assert.ok(isBashWriteToStateFile('cp backup.db .gsd/gsd.db'));
+  });
+
+  test('blocks mv to gsd.db', () => {
+    assert.ok(isBashWriteToStateFile('mv temp.db .gsd/gsd.db'));
+  });
+
+  test('does not block reading gsd.db with cat', () => {
+    assert.ok(!isBashWriteToStateFile('cat .gsd/gsd.db'));
+  });
+});

package/src/resources/extensions/gsd/tests/definition-io.test.ts

@@ -0,0 +1,57 @@
+/**
+ * definition-io.ts — unit tests for readFrozenDefinition.
+ */
+
+import { describe, test, beforeEach, afterEach } from "node:test";
+import assert from "node:assert/strict";
+import { mkdtempSync, mkdirSync, writeFileSync, rmSync, realpathSync } from "node:fs";
+import { join } from "node:path";
+import { tmpdir } from "node:os";
+
+import { readFrozenDefinition } from "../definition-io.ts";
+
+function createTmpDir(): string {
+  return realpathSync(mkdtempSync(join(tmpdir(), "gsd-defio-test-")));
+}
+
+describe("readFrozenDefinition", () => {
+  let runDir: string;
+
+  beforeEach(() => {
+    runDir = createTmpDir();
+  });
+
+  afterEach(() => {
+    rmSync(runDir, { recursive: true, force: true });
+  });
+
+  test("parses a valid DEFINITION.yaml", () => {
+    const yaml = [
+      "version: 1",
+      "name: test-workflow",
+      "description: A test workflow",
+      "steps:",
+      "  - id: step-1",
+      "    prompt: do the thing",
+    ].join("\n");
+    writeFileSync(join(runDir, "DEFINITION.yaml"), yaml, "utf-8");
+
+    const def = readFrozenDefinition(runDir);
+    assert.equal(def.version, 1);
+    assert.equal(def.name, "test-workflow");
+    assert.equal(def.description, "A test workflow");
+    assert.equal(def.steps.length, 1);
+    assert.equal(def.steps[0].id, "step-1");
+  });
+
+  test("throws when DEFINITION.yaml is missing", () => {
+    assert.throws(() => readFrozenDefinition(runDir), {
+      code: "ENOENT",
+    });
+  });
+
+  test("throws on malformed YAML", () => {
+    writeFileSync(join(runDir, "DEFINITION.yaml"), ": : : not valid yaml [", "utf-8");
+    assert.throws(() => readFrozenDefinition(runDir));
+  });
+});

package/src/resources/extensions/gsd/tests/dispatch-guard.test.ts

@@ -172,6 +172,32 @@ test("dispatch guard ignores positionally-earlier reverse dependents for zero-de
   );
 });
 
+test("dispatch guard treats zero-dependency slices as independent when a milestone uses explicit deps (#3998)", (t) => {
+  const repo = setupRepo();
+  t.after(() => teardownRepo(repo));
+
+  mkdirSync(join(repo, ".gsd", "milestones", "M022"), { recursive: true });
+
+  insertMilestone({ id: "M022", title: "Mixed dependency milestone" });
+  insertSlice({ id: "S02", milestoneId: "M022", title: "Core A", status: "complete", depends: [], sequence: 2 });
+  insertSlice({ id: "S03", milestoneId: "M022", title: "Core B", status: "complete", depends: [], sequence: 3 });
+  insertSlice({ id: "S05", milestoneId: "M022", title: "Blocked integration", status: "pending", depends: ["S02", "S03", "S07"], sequence: 5 });
+  insertSlice({ id: "S06", milestoneId: "M022", title: "Independent zero-dep slice", status: "pending", depends: [], sequence: 6 });
+  insertSlice({ id: "S07", milestoneId: "M022", title: "Late prerequisite", status: "pending", depends: ["S02"], sequence: 7 });
+
+  writeFileSync(join(repo, ".gsd", "milestones", "M022", "M022-ROADMAP.md"), "# M022\n");
+
+  assert.equal(
+    getPriorSliceCompletionBlocker(repo, "main", "execute-task", "M022/S06/T02"),
+    null,
+  );
+
+  assert.equal(
+    getPriorSliceCompletionBlocker(repo, "main", "execute-task", "M022/S05/T01"),
+    "Cannot dispatch execute-task M022/S05/T01: dependency slice M022/S07 is not complete.",
+  );
+});
+
 test("dispatch guard allows slice with all declared dependencies complete", (t) => {
   const repo = setupRepo();
   t.after(() => teardownRepo(repo));

package/src/resources/extensions/gsd/tests/doctor-heal-fixable-warnings.test.ts

@@ -0,0 +1,14 @@
+import test from "node:test";
+import assert from "node:assert/strict";
+import { isDoctorHealActionable } from "../commands-handlers.js";
+
+test("doctor heal actionable filter keeps fixable warnings and errors", () => {
+  assert.equal(isDoctorHealActionable({ fixable: true, severity: "warning" }), true);
+  assert.equal(isDoctorHealActionable({ fixable: true, severity: "error" }), true);
+});
+
+test("doctor heal actionable filter excludes info and non-fixable issues", () => {
+  assert.equal(isDoctorHealActionable({ fixable: true, severity: "info" }), false);
+  assert.equal(isDoctorHealActionable({ fixable: false, severity: "warning" }), false);
+  assert.equal(isDoctorHealActionable({ fixable: false, severity: "error" }), false);
+});

package/src/resources/extensions/gsd/tests/false-degraded-mode-warning.test.ts

@@ -0,0 +1,104 @@
+/**
+ * false-degraded-mode-warning.test.ts — Regression tests for #3922.
+ *
+ * Before this fix, deriveState() logged a "DB unavailable — degraded mode"
+ * warning even when the DB simply hadn't been opened yet (e.g. during
+ * before_agent_start context injection). The fix introduces wasDbOpenAttempted()
+ * to distinguish "not yet initialized" from "genuinely unavailable."
+ *
+ * Two aspects:
+ * 1. gsd-db: wasDbOpenAttempted() tracks whether openDatabase() was ever called.
+ * 2. state: the degraded-mode warning is gated behind wasDbOpenAttempted().
+ */
+
+import { describe, test } from "node:test";
+import assert from "node:assert/strict";
+import { readFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+import {
+  openDatabase,
+  closeDatabase,
+  isDbAvailable,
+  wasDbOpenAttempted,
+} from "../gsd-db.ts";
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const stateSource = readFileSync(join(__dirname, "..", "state.ts"), "utf-8");
+
+// ═══════════════════════════════════════════════════════════════════════════
+// 1. gsd-db: wasDbOpenAttempted flag
+// ═══════════════════════════════════════════════════════════════════════════
+
+describe("wasDbOpenAttempted (#3922)", () => {
+
+  test("wasDbOpenAttempted returns true after openDatabase is called", () => {
+    // By this point in the test suite, openDatabase may or may not have been
+    // called by other tests. So we call it explicitly and verify it returns true.
+    openDatabase(":memory:");
+    assert.strictEqual(wasDbOpenAttempted(), true,
+      "wasDbOpenAttempted should be true after openDatabase call");
+    closeDatabase();
+  });
+
+  test("openDatabase sets the flag even if it fails on invalid path", () => {
+    // openDatabase with an unreachable path may fail, but the flag should
+    // still be set because the attempt was made.
+    try { openDatabase("/nonexistent/path/that/will/fail.db"); } catch { /* expected */ }
+    assert.strictEqual(wasDbOpenAttempted(), true,
+      "wasDbOpenAttempted should be true even after a failed open attempt");
+  });
+});
+
+// ═══════════════════════════════════════════════════════════════════════════
+// 2. state.ts: degraded-mode warning is gated behind wasDbOpenAttempted
+// ═══════════════════════════════════════════════════════════════════════════
+
+describe("degraded-mode warning guard (#3922)", () => {
+
+  test("state.ts imports wasDbOpenAttempted from gsd-db", () => {
+    assert.ok(
+      stateSource.includes("wasDbOpenAttempted"),
+      "state.ts must import wasDbOpenAttempted to gate the degraded-mode warning",
+    );
+  });
+
+  test("degraded-mode warning is inside a wasDbOpenAttempted() guard", () => {
+    // Find the degraded-mode warning string
+    const warningStr = 'DB unavailable — using filesystem state derivation (degraded mode)';
+    const warningIdx = stateSource.indexOf(warningStr);
+    assert.ok(warningIdx > 0, "degraded-mode warning string must exist in state.ts");
+
+    // The wasDbOpenAttempted() check must appear BEFORE the warning,
+    // within the same else-branch (i.e. within a reasonable distance).
+    // Look backwards from the warning for the guard.
+    const searchWindow = stateSource.slice(Math.max(0, warningIdx - 300), warningIdx);
+    assert.ok(
+      searchWindow.includes("wasDbOpenAttempted()"),
+      "wasDbOpenAttempted() guard must appear shortly before the degraded-mode warning " +
+      "to prevent false warnings when DB has not been initialized yet",
+    );
+  });
+
+  test("warning is NOT emitted unconditionally in the else branch", () => {
+    // The old code had `logWarning(...)` directly in the else branch.
+    // The fix wraps it in `if (wasDbOpenAttempted())`.
+    // Verify the logWarning call is inside a conditional, not bare.
+    const lines = stateSource.split("\n");
+    for (let i = 0; i < lines.length; i++) {
+      if (lines[i]!.includes("DB unavailable") && lines[i]!.includes("degraded mode")) {
+        // This line has the warning. Check that the preceding non-empty line
+        // contains an if-condition (wasDbOpenAttempted), not a bare else.
+        let prev = i - 1;
+        while (prev >= 0 && lines[prev]!.trim() === "") prev--;
+        const prevLine = lines[prev]!.trim();
+        assert.ok(
+          prevLine.includes("wasDbOpenAttempted"),
+          `Line ${i + 1} emits degraded-mode warning — preceding line ${prev + 1} must ` +
+          `contain wasDbOpenAttempted guard, but found: "${prevLine}"`,
+        );
+        break;
+      }
+    }
+  });
+});