npm - claude-code-session-manager - Versions diffs - 0.33.0 → 0.34.0 - Mend

claude-code-session-manager 0.33.0 → 0.34.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (41) hide show

package/README.md +5 -1
package/dist/assets/{TiptapBody-DHzFmRr2.js → TiptapBody-DWeWI8gw.js} +51 -51
package/dist/assets/index-C2m4dco8.css +32 -0
package/dist/assets/index-CFT773vM.js +3491 -0
package/dist/index.html +2 -2
package/package.json +1 -1
package/plugins/session-manager-dev/skills/discover-features/SKILL.md +95 -0
package/plugins/session-manager-dev/skills/optimize-kpi/SKILL.md +9 -9
package/plugins/session-manager-dev/skills/process-feedback/SKILL.md +77 -62
package/plugins/session-manager-dev/skills/project-status/SKILL.md +13 -0
package/src/main/__tests__/chat-queue.test.cjs +65 -0
package/src/main/__tests__/chat-stop-signal.test.cjs +52 -0
package/src/main/__tests__/exchanges.test.cjs +177 -0
package/src/main/__tests__/files-reject-credentials.test.cjs +40 -0
package/src/main/__tests__/kg-augment.test.cjs +195 -0
package/src/main/__tests__/memoryAggregate.test.cjs +70 -0
package/src/main/agentMemory.cjs +0 -21
package/src/main/chatRunner.cjs +393 -0
package/src/main/exchanges.cjs +125 -0
package/src/main/files.cjs +20 -8
package/src/main/historyAggregator.cjs +0 -162
package/src/main/index.cjs +76 -57
package/src/main/ipcSchemas.cjs +70 -30
package/src/main/lib/kgExchangePairing.cjs +75 -0
package/src/main/lib/reaperHelpers.cjs +7 -1
package/src/main/lib/summarize.cjs +114 -0
package/src/main/memoryAggregate.cjs +250 -0
package/src/main/pluginInstall.cjs +4 -2
package/src/main/scheduler.cjs +66 -20
package/src/main/supervisor.cjs +16 -0
package/src/main/transcripts.cjs +22 -2
package/src/main/usage.cjs +58 -11
package/src/main/voiceHotkey.cjs +0 -2
package/src/main/webRemote.cjs +11 -78
package/src/preload/api.d.ts +131 -125
package/src/preload/index.cjs +45 -29
package/dist/assets/index-AKeGl-VM.css +0 -32
package/dist/assets/index-Bwwbc2mS.js +0 -3535
package/src/main/kg.cjs +0 -792
package/src/main/lib/kgLite.cjs +0 -195
package/src/main/lib/kgPrune.cjs +0 -87

package/dist/index.html CHANGED Viewed

@@ -7,10 +7,10 @@
     <link rel="preconnect" href="https://fonts.googleapis.com">
     <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
     <link href="https://fonts.googleapis.com/css2?family=Newsreader:ital,opsz,wght@0,6..72,400;0,6..72,500;0,6..72,600;0,6..72,700;1,6..72,400&family=Geist:wght@300;400;500;600;700&family=IBM+Plex+Mono:wght@400;500;600&display=swap" rel="stylesheet">
-    <script type="module" crossorigin src="./assets/index-Bwwbc2mS.js"></script>
+    <script type="module" crossorigin src="./assets/index-CFT773vM.js"></script>
     <link rel="modulepreload" crossorigin href="./assets/monaco-editor-BW5C4Iv1.js">
     <link rel="stylesheet" crossorigin href="./assets/monaco-editor-BTnBOi8r.css">
-    <link rel="stylesheet" crossorigin href="./assets/index-AKeGl-VM.css">
+    <link rel="stylesheet" crossorigin href="./assets/index-C2m4dco8.css">
   </head>
   <body class="bg-bg text-fg font-sans antialiased">
     <div id="root"></div>

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "claude-code-session-manager",
-  "version": "0.33.0",
+  "version": "0.34.0",
   "description": "Local cockpit for the Claude Code CLI — multi-tab terminal, full config surface, scheduler, voice dictation, and live observability.",
   "type": "module",
   "main": "src/main/index.cjs",

package/plugins/session-manager-dev/skills/discover-features/SKILL.md ADDED Viewed

@@ -0,0 +1,95 @@
+---
+name: discover-features
+description: >-
+  Propose and prototype NEW features for the current project. Reads the project's issues, PRs,
+  `main`, and md/docs to learn its objectives, then runs THREE independent discovery sessions
+  (each may also web-search for ideas) that every one proposes 5 high-level feature ideas best
+  fitting the project's goals — 15 total. Synthesises and ranks them, picks the top 3, and runs a
+  high-quality `/develop` build for each. Delivers a deployed URL per feature plus a validation
+  checklist so the human can try them — and NEVER opens a PR or a GitHub issue from a proposed
+  feature (the human validates first, then decides). Use when the user says "/discover-features",
+  "propose features", "discover feature opportunities", "what should we build next", "prototype
+  some new features for me to try". Keywords: discover, propose, feature, opportunity, ideation,
+  prototype, what's next, roadmap.
+---
+# /discover-features — propose → prototype → hand over URLs (no PRs)
+**Role:** the *generative* counterpart to `/find-opportunity`. `/find-opportunity` triages the
+*existing* backlog to pick the next issue to resolve; `/discover-features` *invents* net-new
+features the backlog doesn't contain yet, prototypes the best ones, and hands the human running
+URLs to validate. It is for "what should we build next?", not "which open issue next?".
+**Hard rules (do not violate):**
+- **Never open a PR or a GitHub issue** from a proposed feature. The deliverable is a *running,
+  validatable prototype on a branch* + a URL + a validation checklist — the human decides what
+  (if anything) becomes a PR. (See the `solve-dont-open-issues` principle.)
+- **No fabricated data.** Prototypes run on the project's real data layer / real queries. If a
+  feature needs data that doesn't exist, it shows an honest empty state — never seeded fakes.
+- **Don't touch `main`.** Build on a fresh branch (or worktrees) off the latest `main`.
+- **Respect the conflict-skip sense** (from `/find-opportunity`): don't prototype something an
+  open PR is already building.
+## Phase 0 — Ground in the project's objectives
+Before ideating, learn what the project is *for* (so ideas fit, not just dazzle):
+```bash
+gh issue list --state open --limit 100 --json number,title,labels
+gh pr list   --state all  --limit 60  --json number,title,headRefName,state
+ls docs/ README.md AGENTS.md CLAUDE.md 2>/dev/null
+```
+Read the design docs / README / AGENTS for the mission, the north-star, the explicit
+non-goals/constraints, and the data model. Extract a short **objectives + constraints** brief —
+this is the anchor every discovery session and the ranking use.
+## Phase 1 — THREE independent discovery sessions (fan-out)
+Spawn **3 independent agents in parallel**. Each gets the objectives brief and is told to think
+differently from the others (assign distinct stances, e.g. *user-value first* / *data-leverage
+first* / *differentiation-&-novelty first*). Each agent:
+- Re-reads the issues / PRs / `main` / docs itself (independent grounding, not just your brief).
+- **May web-search** for ideas — comparable products, domain best-practice, what peer
+  civic/▢-tech projects ship — and bring back what genuinely fits.
+- Returns **exactly 5 high-level feature ideas**, each with: one-line pitch; which project
+  objective it advances; the data/infra it leans on (must already exist or be honestly stubbable);
+  rough surface (new route/page is preferred so it's independently deployable + validatable); a
+  novelty/effort/impact read. Be creative — no artificial limits.
+15 ideas total. Keep each agent blind to the others (diversity > consensus).
+## Phase 2 — Synthesise & rank → top 3
+Merge the 15. De-dupe near-identicals (keep the sharpest framing). Drop anything that: an open PR
+already builds, needs data the project doesn't have, or is a multi-week epic that can't reach a
+*validatable* prototype in one build. Rank the survivors by **objective-fit × user-value ×
+prototype-feasibility**. Pick the **top 3**. State *why* each won and what you dropped (no silent
+cuts). Prefer 3 that are independently deployable (separate routes) so the human can validate each
+in isolation.
+## Phase 3 — High-quality build of each top-3 feature
+For each of the 3, run a `/develop` `quality: high`-style build (deep-check → plan → implement →
+tests → self-validate). Build all three on **one branch** (or worktrees) so a single running app
+serves all three. Wire each as its own route/page where possible. Real data via real queries;
+honest empty states. Typecheck + the project's tests must pass before you call a feature done.
+## Phase 4 — Deploy locally & hand over (NO PR)
+Launch the project's dev server (or preview) so the features are reachable. Deliver, per feature:
+- **The URL** it's live at (e.g. `http://localhost:<port>/<route>`).
+- **What it does** in two lines + which objective it serves.
+- **A validation checklist** — concrete things for the human to click/observe to judge it
+  ("filter to sector X, confirm the sparkline matches the table total", "open on mobile width",
+  "try an entity with no data → honest empty state").
+- Note any assumptions or stubs.
+End with: the branch name (un-pushed), the 3 URLs, and "say which to keep → I'll turn those into
+PRs." **Do not push or PR anything yourself.**
+## Notes
+- This skill is token-intensive by design (3 discovery sessions + 3 builds). Run it when the user
+  has explicitly asked for a feature-ideation+prototype round, typically as an overnight batch.
+- If the dev server can only serve one branch at a time, that's fine — all three features share
+  the one branch and one server; give three routes/URLs on it.
+- Keep ideas anchored to the project's actual objectives — a brilliant idea that fights the
+  mission is noise. Creativity in service of the goal, not despite it.

package/plugins/session-manager-dev/skills/optimize-kpi/SKILL.md CHANGED Viewed

@@ -4,7 +4,7 @@ description: >-
   Project-agnostic North-Star-KPI optimization cycle. Reads the current project's
   declared North-Star KPI from its CLAUDE.md, measures it, audits real
   consumption/usage telemetry + operational logs, grades the prior iteration's
-  filed lever, then fans out 3 INDEPENDENT recommender agents (Opus 4.8, max
+  filed lever, then fans out 3 INDEPENDENT recommender agents (Fable 5, max
   thinking) that each diagnose the gap and propose the single
   highest-leverage improvement — every recommendation grounded in usage + logs,
   not the scorecard alone; one consolidator agent merges them into ONE feedback
@@ -14,7 +14,7 @@ description: >-
   "optimize the KPI", "improve our north-star metric", or runs the daily KPI
   optimization loop. Keywords: optimize, KPI, north-star, metric, coverage,
   recommenders, consolidate, feedback, scheduler, attribution.
-model: opus
+model: fable
 ---
 # /optimize-kpi — measure → grade last lever → 3 recommenders → consolidate → file → scheduler
@@ -158,12 +158,12 @@ the point; do not coordinate them. (Default panel = 3; you may scale to 4–5 wh
 the gap is large and token budget allows, or drop to 2 for a tiny gap — note the
 choice.)
-- **Model:** `opus` (Opus 4.8) with **failover to `sonnet`** — launch each agent
-  with `model: opus`; if an agent dies on a model/availability error, re-spawn
-  that one with `model: sonnet`. A **mixed panel** (some opus, some sonnet) is
-  fine — don't block waiting for a uniform fleet. (Fable is not GA and only
-  causes availability failures — do not use it.) Instruct each to think at
-  **maximum depth** before answering.
+- **Model:** `fable` (Fable 5) with **failover to `opus`, then `sonnet`** — launch
+  each agent with `model: fable`; if an agent dies on a model/availability error,
+  re-spawn that one with `model: opus`, and `sonnet` only if opus is also
+  unavailable. A **mixed panel** (some fable, some opus/sonnet) is fine — don't
+  block waiting for a uniform fleet. Instruct each to think at **maximum depth**
+  before answering.
 - **Prompt (identical for all 3, vary only an angle hint):** give each the KPI
   statement, the definition doc path, the Step-1 scorecard block, the **Step-1b
   usage+log evidence block**, the **Step-2 prior-lever grade + in-flight/cooldown
@@ -197,7 +197,7 @@ choice.)
 ## Step 4 — Consolidate into ONE recommendation + a ranked backlog (single agent)
-Spawn **one** consolidator agent (same `opus`→`sonnet` failover, max thinking).
+Spawn **one** consolidator agent (same `fable`→`opus`→`sonnet` failover, max thinking).
 Give it the 3 temp files **and** the Step-2 in-flight/cooldown set. It must:
 - Read all three, dedupe overlapping ideas, and **score** the distinct proposals

package/plugins/session-manager-dev/skills/process-feedback/SKILL.md CHANGED Viewed

@@ -3,10 +3,10 @@ name: process-feedback
 description: >-
   Process the current project's inbound feedback folder end-to-end: read every
   open item, evaluate it against real code, and for work that belongs to this
-  project queue it as scheduled PRDs via /develop (never implement inline) —
-  then track those PRDs to completion, archive the item as processed, and fold
-  lessons back into the folder's README so future feedback (written by other
-  agents/projects) gets better. Use whenever the user says "/process-feedback",
+  project queue it as scheduled PRDs via /develop (never implement inline),
+  archive the item as processed **the moment it is queued** (the scheduler owns
+  execution from there), and fold lessons back into the folder's README so
+  future feedback (written by other agents/projects) gets better. Use whenever the user says "/process-feedback",
   "review the feedback folder", "work through the feedback", "any open
   feedback?", or drops new files into feedback/. Keywords: feedback, intake,
   external-feedback, cross-project requests, process feedback, triage feedback.
@@ -30,9 +30,24 @@ conventions — read it first; the steps below are the process.
 **Core principle:** this skill *triages and dispatches*; it does not implement.
 Anything that requires writing code for this project is decomposed and queued as
 scheduled PRDs through **`/develop`**, which runs them headlessly on the
-session-manager scheduler. process-feedback then watches those PRDs to
-completion and does the bookkeeping. Implementing feedback inline — bypassing
-the scheduler — is the one thing this skill must not do.
+session-manager scheduler. **process-feedback is done the moment every item is
+dispositioned — queued as a PRD, declined, or forwarded — and archived; the
+scheduler owns execution from there on.** It does NOT hold items in the inbox
+waiting for PRDs to land, and it does NOT babysit the scheduler. Implementing
+feedback inline — bypassing the scheduler — is the one thing this skill must not
+do.
+**Definition of done (resilience contract):** the actionable inbox is empty.
+Every open item has been turned into a scheduler PRD (or declined / forwarded
+with a reason), given a `## RESOLUTION`, and moved to `processed/`. Archival
+happens at **disposition time, not delivery time** — once an item is a queued
+PRD, its job is done and the file is archived immediately. The README
+status-log **row** (🛠) is the durable execution tracker that lives on after the
+file is archived; it is reconciled 🛠→✅ (and failures flagged) by
+`/project-status`'s scheduler-PRD audit, cross-referencing the queue — never by
+process-feedback blocking on it. A pass that leaves a queued item sitting in the
+inbox "until its PRD lands" is the non-resilient bug this contract exists to
+prevent.
 ## Steps
@@ -50,14 +65,16 @@ so the empty case must cost almost nothing:
   an agent loop.
 - Only when at least one **open** item exists do you continue — an open item
   means *someone cares about this project*, so it's worth the full pass (and,
-  per step 7, leaving the README better for next time).
+  per step 6, leaving the README better for next time).
 ### 1. Read the intake
-- Read `feedback/README.md` (conventions + the status log), then every file
-  whose status is open/🆕. Skip files already ✅/archived. Items already 🛠
-  (queued — see step 4) are in flight: don't re-queue them, just re-check their
-  PRD status (step 5).
+- Read `feedback/README.md` (conventions + the status log), then every open/🆕
+  file still in the inbox. Under this contract a **🛠 (queued) item has already
+  been archived to `processed/`** at disposition time — so anything still sitting
+  in the inbox is genuinely un-dispositioned and needs a pass. You will not find
+  🛠 items in the inbox to "re-check"; their execution is tracked by the
+  status-log row + `/project-status`'s scheduler audit, not by the folder.
 - If the folder doesn't exist, say so and stop — don't invent one.
 ### 2. Evaluate before queueing
@@ -102,55 +119,45 @@ work — the implementation **commit + deploy**. That means process-feedback doe
 Record the emitted PRD filenames/ids — you need them for steps 4–6.
-### 4. Interim bookkeeping — commit the triage now
-Two cases:
-- **Closed-without-code** items (declines, upstream forwards): append a full
-  `## RESOLUTION` (what was declined and why / what was forwarded where, with the
-  upstream file id), flip the README row to ✅, and `git mv` the file to
-  `feedback/processed/` — these are done.
-- **Queued** items (sent to `/develop`): append a `## RESOLUTION (in progress)`
-  recording the queued PRD filenames/ids and that execution is pending the
-  scheduler. Flip the README row to **🛠 queued** (add 🛠 to the log's legend if
-  absent) — **not** ✅. Leave the file in `feedback/` until the PRDs land. Do not
-  fabricate verification for code that hasn't run yet.
-Commit only this feedback bookkeeping + any upstream filings (message references
-the feedback file id, e.g. `chore(feedback): triage + queue 2026-06-10-01`).
+### 4. Disposition + archive every item now — this is the definition of done
+Every open item gets a disposition, a `## RESOLUTION`, and a `git mv` to
+`feedback/processed/` **in this pass** — archival is at disposition time, not
+delivery time. Do NOT leave a queued item in the inbox "until its PRD lands":
+that is the drift this contract forbids. By disposition:
+- **Queued (Ours, do it):** append `## RESOLUTION` naming the emitted PRD
+  filename(s)/id(s) and stating execution is now the scheduler's job. Set the
+  README status-log row to **🛠 queued (PRD NN)** (add 🛠 to the legend if
+  absent). `git mv` the file (and any `-REPLY`) to `processed/` **now**. The 🛠
+  row — not the file's location — is what tracks execution; do not fabricate
+  verification for code that hasn't run yet, just record the handoff.
+- **Declined (Ours, decline):** append `## RESOLUTION` with the reason (contract
+  / boundary conflict), flip the row to ✅, `git mv` to `processed/`.
+- **Forwarded (Theirs):** append `## RESOLUTION` naming the upstream filing
+  (`/my-feedback to <project>` id), flip the row to ✅ (closed here — the ask now
+  lives in their intake), `git mv` to `processed/`.
+After this step the actionable inbox is **empty** — only genuinely un-dispositioned
+items (still being triaged) may remain, and only within this same pass. Commit the
+feedback bookkeeping + any upstream filings in one clean commit (message
+references the file id, e.g. `chore(feedback): triage + queue 2026-06-10-01`).
 Only commit a clean, green tree; if unrelated in-flight work is mixed into the
 working tree, stop and tell the user instead of committing around it.
-### 5. Track to completion — delegate to /develop Phase 2
-The queued PRDs run headlessly and can take a while. **Do not re-implement the
-monitor here** — `/develop` Phase 2 already owns it (the 30-min scheduler watch,
-the escalate-on-stuck/`needs_review`/timeout logic, and the live verification
-against each PRD's acceptance criteria). When you call `/develop` in step 3, that
-tracking runs as part of it.
-Your only job in this step is to consume its outcome per queued item:
-- **`/develop` escalated a PRD** (failed / stuck / needs attention) — relay it to
-  the user with its specifics; leave the feedback item at 🛠 (still in flight)
-  until it's resolved or re-queued. Don't archive a broken item as done.
-- **`/develop` reported all of an item's PRDs landed + verified** — proceed to
-  step 6 to finalize that item's bookkeeping.
-### 6. Finalize the archive (when an item's PRDs land + verify)
-Once `/develop` Phase 2 reports an item's PRDs merged and verified against the AC:
+### 5. Hand off to the scheduler — do NOT babysit
-- Append the final `## RESOLUTION`: what changed, the PRD/commit refs, what was
-  declined/forwarded, and how `/develop` verified it (cite its gate result —
-  don't re-run the verification it already did).
-- Flip the README row **🛠 → ✅** (keep the row — the log is the durable index).
-- `git mv` the file to `feedback/processed/` (create the dir if needed). Closed
-  items live there as the durable record; only files entered in error are ever
-  deleted.
-- Commit the bookkeeping.
+Execution is the scheduler's job from here. **Do not run an interactive watch
+loop, and do not block the pass on PRDs landing** — `/develop` already queued
+them with the engineering standards inline, the scheduler runs them at its
+cadence, and **`/project-status` owns the ongoing audit**: its scheduler-PRD
+check cross-references `queue.json` to reconcile each 🛠 status-log row → ✅ when
+its PRD lands (the file is already archived), and surfaces any `failed` /
+`needs_review` / stuck Burrow PRD. If a PRD later fails, the requester re-files or
+the status audit escalates it — the feedback pass does not stay open waiting for
+that. If the user wants live progress, point them at the SchedulePanel.
-### 7. Self-improve the intake (always do this)
+### 6. Self-improve the intake (always do this)
 Update the folder's `README.md` guidance section based on what this round
 taught you:
@@ -172,12 +179,20 @@ This step is the point of the skill: every processing pass should make the
 - **Never implement feedback inline.** Code that belongs to this project goes
   through `/develop` → the scheduler. The only commits process-feedback makes
   itself are feedback bookkeeping and upstream filings.
-- **Never mark a queued item ✅ or move it to `processed/` before its PRDs land
-  and verify.** Queued ≠ done; 🛠 is the honest interim state. An item archived
-  as resolved must point to merged, verified work.
+- **Archive at disposition time, not delivery time.** The moment an item is
+  queued as a PRD (or declined / forwarded), give it a RESOLUTION and `git mv` it
+  to `processed/` — do NOT leave it in the inbox waiting for the PRD to land. A
+  queued item is archived with a **🛠** status-log row (not ✅); the row is the
+  durable execution tracker and is reconciled 🛠→✅ by `/project-status` from the
+  scheduler queue. Leaving dispositioned items in the inbox "until they verify"
+  is the non-resilient behavior this contract exists to kill.
+- **The status-log row is honest about state even after archival.** 🛠 = "PRD
+  queued, scheduler owns it, not yet landed"; ✅ = "landed/verified (or
+  declined/forwarded)". Never fabricate a ✅ for code that hasn't run — archive at
+  🛠 and let the status audit flip it.
 - Never delete feedback files to "clear" the folder — archive them.
 - Service boundaries outrank feedback asks: an item that requests a boundary
   violation gets a documented decline + an upstream filing, not compliance.
-- Report honestly in the RESOLUTION: PRDs that failed or stalled, asks left
-  open, deps on other teams. An archived item with open external deps should say
-  what unblocks it.
+- Report honestly in the RESOLUTION: which PRD id owns the work, what was
+  declined/forwarded and why, deps on other teams. An archived item with open
+  external deps should say what unblocks it.

package/plugins/session-manager-dev/skills/project-status/SKILL.md CHANGED Viewed

@@ -141,6 +141,19 @@ pending feedback (cross-project asks others filed to us, plus the prior cycle's
 `/my-feedback`, decline-with-reason. Don't generate new levers on top of an
 unprocessed backlog. (If the inbox is empty, say so and move on.)
+**Reconcile queued feedback — this audit owns it, because `/process-feedback`
+hands off at queue time.** Under the resilience contract, `/process-feedback` is
+done the moment an item is queued as a PRD and archived to `processed/` — it does
+NOT wait for the PRD to land. So the ongoing tracking is **this skill's job**: as
+part of the chores/scheduler audit, cross-reference the feedback status-log
+against `queue.json` and (a) flip any **🛠** row whose PRD now shows `completed`
+to **✅** with the landing evidence, and (b) surface any `failed` / `needs_review`
+/ stuck Burrow PRD behind a still-🛠 row as a finding to route. The file is
+already in `processed/`; only the row's status is reconciled here. A `-local` may
+supply the exact cross-reference command (grep 🛠 rows → look up their PRD id in
+the queue); if it doesn't, do it inline. Never expect `/process-feedback` to have
+delivery-gated the archive — that's the anti-pattern this split removes.
 Then route **this audit's own findings**, by ownership:
 1. **A finding that belongs to another project** (an upstream/downstream service

package/src/main/__tests__/chat-queue.test.cjs ADDED Viewed

@@ -0,0 +1,65 @@
+/**
+ * chat-queue.test.cjs — unit tests for the chatRunner serial run queue (v0.34).
+ * Asserts the "one loop at a time" guarantee: runs execute serially in FIFO
+ * order, and a queued (not-yet-started) run can be cancelled without running.
+ *
+ * Run: timeout 120 node --test src/main/__tests__/chat-queue.test.cjs
+ */
+'use strict';
+// Force the default cap (1) regardless of the developer's shell env.
+delete process.env.SM_CHAT_CONCURRENCY;
+const { test } = require('node:test');
+const assert = require('node:assert/strict');
+const cr = require('../chatRunner.cjs');
+const tick = () => new Promise((r) => setImmediate(r));
+const job = (id) => ({ tabId: id, sessionId: id, prompt: 'x', cwd: '/', resume: false });
+test('runs execute one at a time in FIFO order', async () => {
+  const order = [];
+  let active = 0;
+  let maxActive = 0;
+  // Stub the spawn: each run resolves on the next tick, so the queue must
+  // advance via the pump's finally hook for B and C to ever run.
+  cr.__setExecutor((j) => {
+    active += 1;
+    maxActive = Math.max(maxActive, active);
+    order.push(j.tabId);
+    return new Promise((res) => setImmediate(() => { active -= 1; res(); }));
+  });
+  cr.run(job('A'));
+  cr.run(job('B'));
+  cr.run(job('C'));
+  // Drain the queue (each run takes one tick; allow generous headroom).
+  for (let i = 0; i < 12 && order.length < 3; i++) await tick();
+  await tick();
+  assert.equal(maxActive, 1, 'never more than one run active at once');
+  assert.deepEqual(order, ['A', 'B', 'C'], 'runs execute in FIFO order');
+  cr.__setExecutor(null); // restore real executor
+});
+test('cancelling a queued run drops it without executing', async () => {
+  const order = [];
+  cr.__setExecutor((j) => {
+    order.push(j.tabId);
+    return new Promise((res) => setImmediate(res));
+  });
+  // X takes the only lane; Y queues behind it. Cancel Y before the lane frees.
+  cr.run(job('X'));
+  cr.run(job('Y'));
+  cr.cancel('Y'); // Y is still in the waiting list — drop it
+  for (let i = 0; i < 8; i++) await tick();
+  assert.deepEqual(order, ['X'], 'only X ran; Y was cancelled while queued');
+  cr.__setExecutor(null);
+});

package/src/main/__tests__/chat-stop-signal.test.cjs ADDED Viewed

@@ -0,0 +1,52 @@
+/**
+ * chat-stop-signal.test.cjs — unit tests for chatRunner.parseStopSignal, the
+ * single source of truth for the terminal-chat stop-signal protocol (PRD 318).
+ *
+ * Run: timeout 120 node --test src/main/__tests__/chat-stop-signal.test.cjs
+ */
+'use strict';
+const { test } = require('node:test');
+const assert = require('node:assert/strict');
+const { parseStopSignal, STOP_SENTINEL } = require('../chatRunner.cjs');
+test('sentinel present with valid JSON → questions array', () => {
+  const text =
+    'I did some work but need to know which target.\n' +
+    `${STOP_SENTINEL}\n` +
+    '{"questions":["Which environment?","Overwrite existing config?"]}';
+  const out = parseStopSignal(text);
+  assert.deepEqual(out, {
+    questions: ['Which environment?', 'Overwrite existing config?'],
+  });
+});
+test('sentinel absent → null (run is complete)', () => {
+  const text = 'All done. I created the file and the tests pass.';
+  assert.equal(parseStopSignal(text), null);
+});
+test('sentinel present but malformed JSON → null (treated as complete, no crash)', () => {
+  const text = `Here is a summary.\n${STOP_SENTINEL}\n{questions: [oops not json}`;
+  assert.equal(parseStopSignal(text), null);
+});
+test('sentinel present but JSON lacks questions array → null', () => {
+  const text = `${STOP_SENTINEL}\n{"foo":"bar"}`;
+  assert.equal(parseStopSignal(text), null);
+});
+test('non-string input → null (no crash)', () => {
+  assert.equal(parseStopSignal(undefined), null);
+  assert.equal(parseStopSignal(null), null);
+  assert.equal(parseStopSignal(42), null);
+});
+test('only the LAST sentinel occurrence is parsed', () => {
+  const text =
+    `${STOP_SENTINEL}\n{"questions":["stale earlier block"]}\n` +
+    'then the agent kept working...\n' +
+    `${STOP_SENTINEL}\n{"questions":["the real question"]}`;
+  assert.deepEqual(parseStopSignal(text), { questions: ['the real question'] });
+});