gsd-pi 2.37.1-dev.d3ace49 → 2.38.0-dev.63ad7e5

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

@@ -33,19 +33,16 @@ Ask **1–3 questions per round**. Keep each question focused on one of:
 
 After the user answers, investigate further if any answer opens a new unknown, then ask the next round.
 
-### Check-in after each round
+### Round cadence
 
-After each round of answers, ask:
+After each round of answers, decide whether you already have enough depth to write a strong context file.
 
-> "I think I have a solid picture of this milestone. Ready to wrap up and write the context file, or is there more to cover?"
-
-**If `{{structuredQuestionsAvailable}}` is `true`:** use `ask_user_questions` with options:
-- "Wrap up — write the context file" *(recommended after ~2–3 rounds)*
-- "Keep going — more to discuss"
-
-**If `{{structuredQuestionsAvailable}}` is `false`:** ask in plain text.
-
-If the user wants to keep going, keep asking. Stop when they say wrap up.
+- If not, investigate any newly-opened unknowns and continue to the next round immediately. Do **not** ask a meta "ready to wrap up?" question after every round.
+- Use a single wrap-up prompt only when you genuinely believe the depth checklist is satisfied or the user signals they want to stop.
+- **If `{{structuredQuestionsAvailable}}` is `true` and you need that wrap-up prompt:** use `ask_user_questions` with options:
+  - "Write the context file" *(recommended when depth is satisfied)*
+  - "One more pass"
+- **If `{{structuredQuestionsAvailable}}` is `false`:** ask in plain text only once you believe you are ready to write.
 
 ---
 
@@ -55,7 +52,7 @@ If the user wants to keep going, keep asking. Stop when they say wrap up.
 
 **Challenge vagueness, make abstract concrete.** When the user says something abstract ("it should be smart" / "good UX"), push for specifics.
 
-**Questions must be about the experience, not the implementation.** Never ask "what auth provider?" — ask "when someone logs in, what should that feel like?" Implementation is your job. Understanding what they want to experience is the discussion's job.
+**Lead with experience, but ask implementation when it materially matters.** Default questions should target the experience and outcome. But when implementation choices materially change scope, proof, compliance, integration, deployment, or irreversible architecture, ask them directly instead of forcing a fake UX phrasing.
 
 **Position-first framing.** Have opinions. "I'd lean toward X because Y — does that match your thinking?" is better than "what do you think about X vs Y?"
 
@@ -95,6 +92,8 @@ Before moving to the wrap-up gate, verify you have covered:
 
 If they clarify, absorb the correction and re-verify.
 
+The depth verification is the only required confirmation gate. Do not add a second "ready to proceed?" gate after it.
+
 ---
 
 ## Output

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

@@ -1,6 +1,6 @@
 You are interviewing the user to surface behavioural, UX, and usage grey areas for slice **{{sliceId}}: {{sliceTitle}}** of milestone **{{milestoneId}}**.
 
-Your goal is **not** to settle tech stack, naming conventions, or architecture — that happens during research and planning. Your goal is to produce a context file that captures the human decisions: what this slice should feel like, how it should behave, what edge cases matter, where scope begins and ends, and what the user cares about that won't be obvious from the roadmap entry alone.
+Your goal is **not** to center the discussion on tech stack trivia, naming conventions, or speculative architecture. Your goal is to produce a context file that captures the human decisions: what this slice should feel like, how it should behave, what edge cases matter, where scope begins and ends, and what the user cares about that won't be obvious from the roadmap entry alone. If a technical choice materially changes scope, proof, or integration behavior, ask it directly and capture it.
 
 {{inlinedContext}}
 
@@ -27,17 +27,15 @@ Ask **1–3 questions per round** using `ask_user_questions`. Keep each question
 
 After the user answers, investigate further if any answer opens a new unknown, then ask the next round.
 
-### Check-in after each round
+### Round cadence
 
-After each round of answers, use `ask_user_questions` to ask:
+After each round of answers, decide whether you already have enough signal to write the slice context cleanly.
 
-> "I think I have a solid picture of this slice. Ready to wrap up and write the context file, or is there more to cover?"
-
-Options:
-- "Wrap up — write the context file" *(recommended after ~2–3 rounds)*
-- "Keep going — more to discuss"
-
-If the user wants to keep going, keep asking. Stop when they say wrap up.
+- If not, investigate any new unknowns and continue to the next round immediately. Do **not** ask a meta "ready to wrap up?" question after every round.
+- Ask a single wrap-up question only when you genuinely believe the slice is well understood or the user signals they want to stop.
+- When you do ask it, use `ask_user_questions` with:
+  - "Write the context file" *(recommended when the slice is well understood)*
+  - "One more pass"
 
 ---
 

package/src/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}}, then pick up from where you left off. Delete the continue file after reading it. 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. 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.

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

@@ -36,15 +36,11 @@ Don't go deep — just enough that your next question reflects what's actually t
 - How the new work relates to existing milestones — overlap, dependencies, prerequisites
 - If `.gsd/REQUIREMENTS.md` exists: which unmet Active or Deferred requirements this queued work advances
 
-**Then use ask_user_questions** to dig into gray areas — architecture choices, scope boundaries, tech preferences, what's in vs out. 1-3 questions per round.
+**Then use ask_user_questions** to dig into gray areas — scope boundaries, proof expectations, integration choices, tech preferences when they materially matter, and what's in vs out. 1-3 questions per round.
 
 If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during discuss/planning work, but do not let it override the required discuss flow or artifact requirements.
 
-**Self-regulate:** After about 10-15 questions total (3-5 rounds), or when you feel you have a solid understanding, include a question like:
-"I think I have a good picture. Ready to queue this, or are there more things to discuss?"
-with options: "Ready to queue (Recommended)", "I have more to discuss"
-
-If the user wants to keep going, keep asking. If they're ready, proceed.
+**Self-regulate:** Do **not** ask a meta "ready to queue?" question after every round. Keep going until you have enough depth to write the context well, then use a single wrap-up prompt if needed. If the user clearly keeps adding detail instead of objecting, treat that as permission to continue.
 
 ## Existing Milestone Awareness
 
@@ -88,7 +84,7 @@ For EACH milestone you are about to write context for, investigate the codebase
 1. **Read the actual code** — for every file or module you reference in "Existing Codebase / Prior Art", read enough to confirm your assumptions about what exists, what it does, and what it doesn't do. Do not guess from memory or training data.
 2. **Check for stale assumptions** — the codebase may have changed since the user's spec was written. Verify: do the APIs you reference still exist? Have modules been refactored? Has upstream merged features that change the landscape?
 3. **Identify phantom capabilities** — for every capability you list as "existing," confirm it actually works as described. Look for: functions that exist but are never called, fields that are set but never read, features that are piped but never connected.
-4. **Note what you found** — include verified findings in the context file's "Existing Codebase / Prior Art" section with "verified against v{version}" annotations.
+4. **Note what you found** — include verified findings in the context file's "Existing Codebase / Prior Art" section with annotations like "verified against current codebase state" or an actual concrete version/commit only if you truly have one.
 
 ### Step 2: Per-Milestone Depth Verification
 
@@ -103,7 +99,7 @@ This triggers the per-milestone write-gate. The question should present:
 - Key technical assumptions you verified (or couldn't verify)
 - Any risks or unknowns the investigation surfaced
 
-The user confirms or corrects before you write. One depth verification per milestone — not one for all milestones combined.
+The user confirms or corrects before you write. One depth verification per milestone — not one for all milestones combined. This is the required write-gate; do not add extra "ready to proceed?" prompts around it once you have enough signal.
 
 **If you skip this step, the system will block the CONTEXT.md write and return an error telling you to complete verification first.**
 

package/src/resources/extensions/gsd/prompts/reactive-execute.md

@@ -8,7 +8,7 @@
 
 You are executing **multiple tasks in parallel** for this slice. The task graph below shows which tasks are ready for simultaneous execution based on their input/output dependencies.
 
-**Critical rule:** Use the `subagent` tool in **parallel mode** to dispatch all ready tasks simultaneously. Each subagent gets a self-contained execute-task prompt. After all subagents return, verify each task's outputs and write summaries.
+**Critical rule:** Use the `subagent` tool in **parallel mode** to dispatch all ready tasks simultaneously. Each subagent gets a full `execute-task` prompt and is responsible for its own implementation, verification, task summary, and checkbox updates. The parent batch agent orchestrates, verifies, and records failures only when a dispatched task failed before it could leave its own summary behind.
 
 ## Task Dependency Graph
 
@@ -24,15 +24,18 @@ You are executing **multiple tasks in parallel** for this slice. The task graph
 
 1. **Dispatch all ready tasks** using `subagent` in parallel mode. Each subagent prompt is provided below.
 2. **Wait for all subagents** to complete.
-3. **Verify each task's outputs** — check that expected files were created/modified and that verification commands pass.
-4. **Write task summaries** for each completed task using the task-summary template.
-5. **Mark completed tasks** as done in the slice plan (checkbox `[x]`).
-6. **Commit** all changes with a clear message covering the parallel batch.
+3. **Verify each dispatched task's outputs** — check that expected files were created/modified, that verification commands pass where applicable, and that each task wrote its own `T##-SUMMARY.md`.
+4. **Do not rewrite successful task summaries or duplicate checkbox edits.** Treat a subagent-written summary as authoritative for that task.
+5. **If a failed task produced no summary, write a recovery summary for that task** with `blocker_discovered: true`, clear failure details, and leave the task unchecked so replan/retry has an authoritative record.
+6. **Preserve successful sibling tasks exactly as they landed.** Do not roll back good work because another parallel task failed.
+7. **Do NOT create a batch commit.** The surrounding unit lifecycle owns commits; this parent batch agent should not invent a second commit layer.
+8. **Report the batch outcome** — which tasks succeeded, which failed, and any output collisions or dependency surprises.
 
 If any subagent fails:
-- Write a summary for the failed task with `blocker_discovered: true`
-- Continue marking the successful tasks as done
-- The orchestrator will handle re-dispatch on the next iteration
+- Keep successful task summaries and checkbox updates as-is
+- Write a failure summary only when the failed task did not leave one behind
+- Do not silently discard or overwrite another task's outputs
+- The orchestrator will handle re-dispatch or replanning on the next iteration
 
 ## Subagent Prompts
 

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

@@ -18,32 +18,47 @@ If a `GSD Skill Preferences` block is present in system context, use it to decid
 
 **UAT file:** `{{uatPath}}`
 **Result file to write:** `{{uatResultPath}}`
+**Detected UAT mode:** `{{uatType}}`
 
-You are the test runner. Execute every check defined in `{{uatPath}}` directly:
+You are the UAT runner. Execute every check defined in `{{uatPath}}` as deeply as this mode truthfully allows. Do not collapse live or subjective checks into cheap artifact checks just to get a PASS.
+
+### Automation rules by mode
+
+- `artifact-driven` — verify with shell commands, scripts, file reads, and artifact structure checks.
+- `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.
+
+### Evidence tools
+
+Choose the lightest tool that proves the check honestly:
 
 - Run shell commands with `bash`
 - Run `grep` / `rg` checks against files
-- Run `node` / script invocations
+- Run `node` / other script invocations
 - Read files and verify their contents
 - Check that expected artifacts exist and have correct structure
+- For live/runtime/UI checks, exercise the real flow in the browser when applicable and inspect runtime/network/console state
+- When a check cannot be honestly automated, gather the best objective evidence you can and mark it `NEEDS-HUMAN`
 
 For each check, record:
 - The check description (from the UAT file)
+- The evidence mode used: `artifact`, `runtime`, or `human-follow-up`
 - The command or action taken
 - The actual result observed
-- PASS or FAIL verdict
+- `PASS`, `FAIL`, or `NEEDS-HUMAN`
 
 After running all checks, compute the **overall verdict**:
-- `PASS` — all checks passed
+- `PASS` — all required checks passed and no human-only checks remain
 - `FAIL` — one or more checks failed
-- `PARTIAL` — some checks passed, some failed or were skipped
+- `PARTIAL` — some checks passed, but one or more checks were skipped, inconclusive, or still require human judgment
 
 Write `{{uatResultPath}}` with:
 
 ```markdown
 ---
 sliceId: {{sliceId}}
-uatType: artifact-driven
+uatType: {{uatType}}
 verdict: PASS | FAIL | PARTIAL
 date: <ISO 8601 timestamp>
 ---
@@ -52,9 +67,9 @@ date: <ISO 8601 timestamp>
 
 ## Checks
 
-| Check | Result | Notes |
-|-------|--------|-------|
-| <check description> | PASS / FAIL | <observed output or reason> |
+| Check | Mode | Result | Notes |
+|-------|------|--------|-------|
+| <check description> | artifact / runtime / human-follow-up | PASS / FAIL / NEEDS-HUMAN | <observed output, evidence, or reason> |
 
 ## Overall Verdict
 
@@ -62,7 +77,7 @@ date: <ISO 8601 timestamp>
 
 ## Notes
 
-<any additional context, errors encountered, or follow-up items>
+<any additional context, errors encountered, screenshots/logs gathered, or manual follow-up still required>
 ```
 
 ---

package/src/resources/extensions/gsd/prompts/workflow-start.md

@@ -14,7 +14,7 @@ You are executing a **{{templateName}}** workflow (template: `{{templateId}}`).
 
 ## Workflow Definition
 
-Follow the workflow defined below. Execute each phase in order, completing one before moving to the next. At each phase gate, confirm with the user before proceeding.
+Follow the workflow defined below. Execute each phase in order, completing one before moving to the next. For low and medium complexity workflows, keep moving by default — pause only at true decision gates (user must choose between materially different directions, outward-facing actions need approval, or the workflow explicitly requires a human checkpoint). For high complexity workflows, confirm at phase transitions unless the workflow explicitly marks a gate as skip-safe.
 
 {{workflowContent}}
 
@@ -24,5 +24,5 @@ Follow the workflow defined below. Execute each phase in order, completing one b
 2. **Artifact discipline.** If an artifact directory is specified, write all planning/summary documents there.
 3. **Atomic commits.** Commit working code after each meaningful change. Use conventional commit format: `<type>(<scope>): <description>`.
 4. **Verify before shipping.** Run the project's test suite and build before marking the workflow complete.
-5. **Gate between phases.** After each phase, summarize what was done and ask the user to confirm before moving to the next phase.
+5. **Decision gates, not ceremony.** After each phase, summarize what changed. For low/medium complexity, ask for confirmation only when the next phase depends on a real user choice or external approval. For high complexity, confirm before proceeding to each new phase.
 6. **Stay focused.** This is a {{complexity}}-complexity workflow. Match your ceremony level to the task — don't over-engineer or under-deliver.

package/src/resources/extensions/gsd/repo-identity.ts

@@ -12,6 +12,8 @@ import { existsSync, lstatSync, mkdirSync, readFileSync, realpathSync, rmSync, s
 import { homedir } from "node:os";
 import { join, resolve } from "node:path";
 
+const gsdHome = process.env.GSD_HOME || join(homedir(), ".gsd");
+
 // ─── Repo Identity ──────────────────────────────────────────────────────────
 
 /**
@@ -90,14 +92,31 @@ function resolveGitRoot(basePath: string): string {
   }
 }
 
+/**
+ * Validate a GSD_PROJECT_ID value.
+ *
+ * Must contain only alphanumeric characters, hyphens, and underscores.
+ * Call this once at startup so the user gets immediate feedback on bad values.
+ */
+export function validateProjectId(id: string): boolean {
+  return /^[a-zA-Z0-9_-]+$/.test(id);
+}
+
 /**
  * Compute a stable identity for a repository.
  *
- * SHA-256 of `${remoteUrl}\n${resolvedRoot}`, truncated to 12 hex chars.
- * Deterministic: same repo always produces the same hash regardless of
- * which worktree the caller is inside.
+ * If `GSD_PROJECT_ID` is set, returns it directly (validation is expected
+ * to have already happened at startup via `validateProjectId`).
+ *
+ * Otherwise returns SHA-256 of `${remoteUrl}\n${resolvedRoot}`, truncated
+ * to 12 hex chars. Deterministic: same repo always produces the same hash
+ * regardless of which worktree the caller is inside.
  */
 export function repoIdentity(basePath: string): string {
+  const projectId = process.env.GSD_PROJECT_ID;
+  if (projectId) {
+    return projectId;
+  }
   const remoteUrl = getRemoteUrl(basePath);
   const root = resolveGitRoot(basePath);
   const input = `${remoteUrl}\n${root}`;
@@ -113,7 +132,7 @@ export function repoIdentity(basePath: string): string {
  * otherwise `~/.gsd/projects/<hash>`.
  */
 export function externalGsdRoot(basePath: string): string {
-  const base = process.env.GSD_STATE_DIR || join(homedir(), ".gsd");
+  const base = process.env.GSD_STATE_DIR || gsdHome;
   return join(base, "projects", repoIdentity(basePath));
 }
 

package/src/resources/extensions/gsd/resource-version.ts

@@ -11,6 +11,8 @@ import { join } from "node:path";
 import { homedir } from "node:os";
 import { resolveProjectRoot } from "./worktree.js";
 
+const gsdHome = process.env.GSD_HOME || join(homedir(), ".gsd");
+
 // ─── Resource Staleness ───────────────────────────────────────────────────
 
 /**
@@ -23,7 +25,7 @@ function isManifestWithVersion(data: unknown): data is { gsdVersion: string } {
 }
 
 export function readResourceVersion(): string | null {
-  const agentDir = process.env.GSD_CODING_AGENT_DIR || join(homedir(), ".gsd", "agent");
+  const agentDir = process.env.GSD_CODING_AGENT_DIR || join(gsdHome, "agent");
   const manifestPath = join(agentDir, "managed-resources.json");
   const manifest = loadJsonFileOrNull(manifestPath, isManifestWithVersion);
   return manifest?.gsdVersion ?? null;

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

@@ -31,7 +31,7 @@ import {
   gsdRoot,
 } from './paths.js';
 
-import { milestoneIdSort, findMilestoneIds } from './guided-flow.js';
+import { milestoneIdSort, findMilestoneIds } from './milestone-ids.js';
 import { nativeBatchParseGsdFiles, type BatchParsedFile } from './native-parser-bridge.js';
 
 import { join, resolve } from 'path';

package/src/resources/extensions/gsd/tests/agent-end-retry.test.ts

@@ -1,9 +1,9 @@
 /**
- * agent-end-retry.test.ts — Regression checks for the post-#1419 agent_end model.
+ * agent-end-retry.test.ts — Regression checks for the agent_end model.
  *
- * The old recursive handleAgentEnd retry path is gone. The loop now keeps
- * pendingResolve + pendingAgentEndQueue on AutoSession, and handleAgentEnd is
- * only a thin compatibility wrapper around resolveAgentEnd().
+ * The per-unit one-shot resolve function lives at module level in auto-loop.ts
+ * (_currentResolve). handleAgentEnd is a thin compatibility wrapper around
+ * resolveAgentEnd().
  */
 
 import test from "node:test";
@@ -14,40 +14,43 @@ import { fileURLToPath } from "node:url";
 
 const __dirname = dirname(fileURLToPath(import.meta.url));
 const AUTO_TS_PATH = join(__dirname, "..", "auto.ts");
+const AUTO_LOOP_TS_PATH = join(__dirname, "..", "auto-loop.ts");
 const SESSION_TS_PATH = join(__dirname, "..", "auto", "session.ts");
 
 function getAutoTsSource(): string {
   return readFileSync(AUTO_TS_PATH, "utf-8");
 }
 
+function getAutoLoopTsSource(): string {
+  return readFileSync(AUTO_LOOP_TS_PATH, "utf-8");
+}
+
 function getSessionTsSource(): string {
   return readFileSync(SESSION_TS_PATH, "utf-8");
 }
 
-test("AutoSession declares pending agent_end queue state", () => {
-  const source = getSessionTsSource();
+test("auto-loop.ts declares _currentResolve for per-unit one-shot promises", () => {
+  const source = getAutoLoopTsSource();
   assert.ok(
-    source.includes("pendingResolve"),
-    "AutoSession must declare pendingResolve for the in-flight unit promise",
+    source.includes("_currentResolve"),
+    "auto-loop.ts must declare _currentResolve for the per-unit resolve function",
   );
   assert.ok(
-    source.includes("pendingAgentEndQueue"),
-    "AutoSession must declare pendingAgentEndQueue for between-iteration agent_end events",
+    source.includes("_sessionSwitchInFlight"),
+    "auto-loop.ts must declare _sessionSwitchInFlight guard",
   );
 });
 
-test("AutoSession reset clears pending agent_end queue state", () => {
+test("AutoSession no longer holds promise state (moved to auto-loop.ts module scope)", () => {
   const source = getSessionTsSource();
-  const resetIdx = source.indexOf("reset(): void");
-  assert.ok(resetIdx > -1, "AutoSession must have a reset() method");
-  const resetBlock = source.slice(resetIdx, resetIdx + 4000);
+  // Properties should NOT exist as class fields
   assert.ok(
-    resetBlock.includes("this.pendingResolve = null"),
-    "reset() must clear pendingResolve",
+    !source.includes("pendingResolve:"),
+    "AutoSession must not declare pendingResolve (moved to auto-loop.ts)",
   );
   assert.ok(
-    resetBlock.includes("this.pendingAgentEndQueue = []"),
-    "reset() must clear pendingAgentEndQueue",
+    !source.includes("pendingAgentEndQueue:"),
+    "AutoSession must not declare pendingAgentEndQueue (removed — events are dropped)",
   );
 });
 

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

@@ -37,9 +37,6 @@ function makeMockSession(opts?: {
   const session = {
     active: true,
     verbose: false,
-    sessionSwitchInFlight: false,
-    pendingResolve: null,
-    pendingAgentEndQueue: [],
     cmdCtx: {
       newSession: () => {
         opts?.onNewSessionStart?.(session);
@@ -96,7 +93,6 @@ test("resolveAgentEnd resolves a pending runUnit promise", async () => {
   const ctx = makeMockCtx();
   const pi = makeMockPi();
   const s = makeMockSession();
-  _setActiveSession(s);
   const event = makeEvent();
 
   // Start runUnit — it will create the promise and send a message,
@@ -122,25 +118,21 @@ test("resolveAgentEnd resolves a pending runUnit promise", async () => {
   assert.deepEqual(result.event, event);
 });
 
-test("resolveAgentEnd queues event when no promise is pending", () => {
+test("resolveAgentEnd drops event when no promise is pending", () => {
   _resetPendingResolve();
-  const s = makeMockSession();
-  _setActiveSession(s);
 
-  // Should not throw — queues the event for the next runUnit
+  // Should not throw — event is dropped (logged as warning)
   assert.doesNotThrow(() => {
     resolveAgentEnd(makeEvent());
   });
-  assert.equal(s.pendingAgentEndQueue.length, 1, "event should be queued");
 });
 
-test("double resolveAgentEnd only resolves once (second is queued)", async () => {
+test("double resolveAgentEnd only resolves once (second is dropped)", async () => {
   _resetPendingResolve();
 
   const ctx = makeMockCtx();
   const pi = makeMockPi();
   const s = makeMockSession();
-  _setActiveSession(s);
   const event1 = makeEvent([{ id: 1 }]);
   const event2 = makeEvent([{ id: 2 }]);
 
@@ -151,15 +143,10 @@ test("double resolveAgentEnd only resolves once (second is queued)", async () =>
   // First resolve — should work
   resolveAgentEnd(event1);
 
-  // Second resolve — should be queued (no pending promise)
+  // Second resolve — should be dropped (no pending resolver)
   assert.doesNotThrow(() => {
     resolveAgentEnd(event2);
   });
-  assert.equal(
-    s.pendingAgentEndQueue.length,
-    1,
-    "second event should be queued",
-  );
 
   const result = await resultPromise;
   assert.equal(result.status, "completed");
@@ -211,29 +198,25 @@ test("runUnit returns cancelled when s.active is false before sendMessage", asyn
   assert.equal(pi.calls.length, 0);
 });
 
-test("runUnit only arms pendingResolve after newSession completes", async () => {
+test("runUnit only arms resolve after newSession completes", async () => {
   _resetPendingResolve();
 
   let sawSwitchFlag = false;
-  let sawPendingResolve: unknown = "unset";
 
   const ctx = makeMockCtx();
   const pi = makeMockPi();
   const s = makeMockSession({
     newSessionDelayMs: 20,
-    onNewSessionStart: (session) => {
-      sawSwitchFlag = session.sessionSwitchInFlight;
-      sawPendingResolve = session.pendingResolve;
+    onNewSessionStart: () => {
+      sawSwitchFlag = isSessionSwitchInFlight();
     },
   });
-  _setActiveSession(s);
 
   const resultPromise = runUnit(ctx, pi, s, "task", "T01", "prompt", undefined);
 
   await new Promise((r) => setTimeout(r, 30));
 
   assert.equal(sawSwitchFlag, true, "session switch guard should be active during newSession");
-  assert.equal(sawPendingResolve, null, "pendingResolve should not be armed before newSession completes");
   assert.equal(isSessionSwitchInFlight(), false, "session switch guard should clear after newSession settles");
 
   resolveAgentEnd(makeEvent());
@@ -275,24 +258,23 @@ test("auto-loop.ts contains a while keyword", () => {
   );
 });
 
-test("auto-loop.ts one-shot pattern: pendingResolve is nulled before calling resolver", () => {
+test("auto-loop.ts one-shot pattern: _currentResolve is nulled before calling resolver", () => {
   const src = readFileSync(
     resolve(import.meta.dirname, "..", "auto-loop.ts"),
     "utf-8",
   );
   // The one-shot pattern requires: save ref, null the variable, then call
-  // Look for the pattern: s.pendingResolve = null appearing before r(
   const resolveBlock = src.slice(
     src.indexOf("export function resolveAgentEnd"),
     src.indexOf("export function resolveAgentEnd") + 600,
   );
-  const nullIdx = resolveBlock.indexOf("pendingResolve = null");
+  const nullIdx = resolveBlock.indexOf("_currentResolve = null");
   const callIdx = resolveBlock.indexOf("r({");
-  assert.ok(nullIdx > 0, "should null pendingResolve in resolveAgentEnd");
+  assert.ok(nullIdx > 0, "should null _currentResolve in resolveAgentEnd");
   assert.ok(callIdx > 0, "should call resolver in resolveAgentEnd");
   assert.ok(
     nullIdx < callIdx,
-    "pendingResolve should be nulled before calling the resolver (one-shot)",
+    "_currentResolve should be nulled before calling the resolver (one-shot)",
   );
 });
 
@@ -462,8 +444,6 @@ function makeLoopSession(overrides?: Partial<Record<string, unknown>>) {
     pendingQuickTasks: [],
     sidecarQueue: [],
     autoModeStartModel: null,
-    pendingResolve: null,
-    pendingAgentEndQueue: [],
     unitDispatchCount: new Map<string, number>(),
     unitLifetimeDispatches: new Map<string, number>(),
     unitRecoveryCount: new Map<string, number>(),