@yemi33/minions 0.1.2372 → 0.1.2374

package/dashboard/js/settings.js

@@ -1132,6 +1132,7 @@ async function saveSettings() {
       liveCheckoutAutoStash: !!document.getElementById('set-liveCheckoutAutoStash')?.checked,
       liveCheckoutAutoReset: !!document.getElementById('set-liveCheckoutAutoReset')?.checked,
       liveCheckoutAutoBaseRepair: !!document.getElementById('set-liveCheckoutAutoBaseRepair')?.checked,
+      liveCheckoutAutoFreshen: !!document.getElementById('set-liveCheckoutAutoFreshen')?.checked,
       orphanHolderScanTimeoutMs: document.getElementById('set-orphanHolderScanTimeoutMs')?.value,
       statusProbeKillTimeoutMs: document.getElementById('set-statusProbeKillTimeoutMs')?.value,
       adoPollEnabled: document.getElementById('set-adoPollEnabled').checked,

package/dashboard.js

@@ -7854,23 +7854,35 @@ const server = http.createServer(async (req, res) => {
       return jsonReply(res, 200, _plansCache);
     }
     const fsp = fs.promises;
-    const dirs = [
-      { dir: PLANS_DIR, archived: false },
-      { dir: path.join(PLANS_DIR, 'archive'), archived: true },
-      { dir: PRD_DIR, archived: false },
-      { dir: path.join(PRD_DIR, 'archive'), archived: true },
-    ];
-    // Load central work items from the SQL-backed store to check for completed
-    // plan-to-prd conversions.
-    const centralWi = require('./engine/work-items-store').readWorkItemsForScope('central');
+    // W-mrffmjaf002f08f0 — PRD JSON is SQL-authoritative (engine/prd-store.js);
+    // no PRD JSON file is guaranteed to exist on disk post SQL-only cutover
+    // (migration 018), so PRD plan cards AND conversion state are read from
+    // prdStore.listPrdRows() below, not fs.readdir(PRD_DIR). This is also what
+    // fixes the underlying bug: a completed SQL PRD's source_plan must mark
+    // its Markdown draft "converted" even once the plan-to-prd work item that
+    // produced it has aged out of central work-item retention.
+    const prdRows = prdStore.listPrdRows();
     const completedPrdFiles = new Set(
-      centralWi.filter(w => w.type === WORK_TYPE.PLAN_TO_PRD && DONE_STATUSES.has(w.status) && w.planFile)
-        .map(w => w.planFile)
+      prdRows.filter(r => r.plan && r.plan.source_plan).map(r => r.plan.source_plan)
     );
+    // Defense-in-depth union with the legacy central-WI signal, in case a
+    // conversion work item completed but its PRD row somehow lacks
+    // source_plan; SQL PRD rows above remain the primary, canonical source.
+    const centralWi = require('./engine/work-items-store').readWorkItemsForScope('central');
+    for (const w of centralWi) {
+      if (w.type === WORK_TYPE.PLAN_TO_PRD && DONE_STATUSES.has(w.status) && w.planFile) {
+        completedPrdFiles.add(w.planFile);
+      }
+    }
+
     const plans = [];
-    for (const { dir, archived } of dirs) {
-      const allFiles = (await fsp.readdir(dir).catch(() => []))
-        .filter(f => f.endsWith('.json') || f.endsWith('.md'));
+
+    // --- Markdown source plans (plans/*.md + plans/archive/*.md, file-backed) ---
+    for (const { dir, archived } of [
+      { dir: PLANS_DIR, archived: false },
+      { dir: path.join(PLANS_DIR, 'archive'), archived: true },
+    ]) {
+      const allFiles = (await fsp.readdir(dir).catch(() => [])).filter(f => f.endsWith('.md'));
       const dirResults = await Promise.all(allFiles.map(async f => {
         const filePath = path.join(dir, f);
         const [content, stat] = await Promise.all([
@@ -7878,107 +7890,110 @@ const server = http.createServer(async (req, res) => {
           fsp.stat(filePath).catch(() => null),
         ]);
         const updatedAt = stat ? new Date(stat.mtimeMs).toISOString() : '';
-        const isJson = f.endsWith('.json');
-        if (isJson) {
-          try {
-            const plan = JSON.parse(content);
-            const status = plan.status || (plan.requires_approval && !plan.approvedAt ? 'awaiting-approval' : 'active');
-            // W-mqacrzis0003df4a Bug 2 — fresh staleness from plans/*.md mtime.
-            // plan.planStale lags by an engine tick; stat the source plan here
-            // so the Plans tab does not silently mirror a stale-but-cached false.
-            let freshStale = false;
-            if (!archived && plan.source_plan) {
-              try {
-                const sourceMtime = Math.floor(fs.statSync(path.join(PLANS_DIR, plan.source_plan)).mtimeMs);
-                const recorded = plan.sourcePlanModifiedAt ? new Date(plan.sourcePlanModifiedAt).getTime() : null;
-                if (recorded && sourceMtime > recorded) freshStale = true;
-              } catch { /* source plan may have been deleted/renamed */ }
-            }
-            // P-e8d49105 — _projects rollup feeds the plan-card multi-badge
-            // path in dashboard/js/render-plans.js. For PRD JSONs, walk
-            // missing_features[].project (order-preserving dedup) and fall
-            // back to plan.project for items that omit it. Single-project
-            // plans collapse to a single-element array, identical to today's
-            // single `p.project` badge.
-            const _projects = [];
-            const _seen = new Set();
-            for (const it of (plan.missing_features || [])) {
-              const proj = (it && it.project) || plan.project || '';
-              if (proj && !_seen.has(proj)) { _seen.add(proj); _projects.push(proj); }
-            }
-            if (_projects.length === 0 && plan.project) _projects.push(plan.project);
-            // P-66b1faec — _perProjectProgress feeds the per-project status
-            // pills in the plan card meta line (dashboard/js/render-plans.js
-            // renderPlanCard). Group missing_features by item.project (with
-            // fallback to plan.project) and count `status === 'done'` per
-            // bucket. Keys are first-seen order so the rendered pill row is
-            // stable. Always emitted on PRD JSON records (possibly empty);
-            // MD drafts omit it since they carry no item-level statuses.
-            const _perProjectProgress = {};
-            for (const it of (plan.missing_features || [])) {
-              const proj = (it && it.project) || plan.project || '';
-              if (!proj) continue;
-              if (!_perProjectProgress[proj]) _perProjectProgress[proj] = { complete: 0, total: 0 };
-              _perProjectProgress[proj].total += 1;
-              if (it && it.status === 'done') _perProjectProgress[proj].complete += 1;
-            }
-            return {
-              file: f, format: 'prd', archived,
-              project: plan.project || '',
-              _projects,
-              _perProjectProgress,
-              summary: plan.plan_summary || '',
-              status,
-              branchStrategy: plan.branch_strategy || 'parallel',
-              featureBranch: plan.feature_branch || '',
-              itemCount: (plan.missing_features || []).length,
-              generatedBy: plan.generated_by || '',
-              generatedAt: plan.generated_at || '',
-              completedAt: plan.completedAt || '',
-              updatedAt,
-              requiresApproval: plan.requires_approval || false,
-              revisionFeedback: plan.revision_feedback || null,
-              sourcePlan: plan.source_plan || null,
-              archiveReady: plan._archiveReady || false,
-              archiveReadyAt: plan._archiveReadyAt || null,
-              planStale: freshStale || plan.planStale || false,
-            };
-          } catch { return null; /* JSON parse fallback */ }
-        } else {
-          const titleMatch = content.match(/^#\s+(?:Plan:\s*)?(.+)/m);
-          const projectMatch = content.match(/\*\*Project:\*\*\s*(.+)/m);
-          const authorMatch = content.match(/\*\*Author:\*\*\s*(.+)/m);
-          const dateMatch = content.match(/\*\*Date:\*\*\s*(.+)/m);
-          const versionMatch = f.match(/-v(\d+)/);
-          // P-e8d49105 — for MD drafts, the cross-repo marker / **Projects:**
-          // line is the source of truth (parsed by shared.extractPlanTargetProjects).
-          // If neither is present, fall back to the singular **Project:** header
-          // so single-project drafts render the same badge as today.
-          const declaredProject = projectMatch ? projectMatch[1].trim() : '';
-          const targetProjects = shared.extractPlanTargetProjects(content);
-          const _projects = targetProjects.length > 0
-            ? targetProjects
-            : (declaredProject ? [declaredProject] : []);
-          return {
-            file: f, format: 'draft', archived,
-            project: declaredProject,
-            _projects,
-            summary: titleMatch ? titleMatch[1].trim() : f.replace('.md', ''),
-            status: archived ? 'completed' : completedPrdFiles.has(f) ? 'converted' : 'draft',
-            branchStrategy: '',
-            featureBranch: '',
-            itemCount: (content.match(/^\d+\.\s+\*\*/gm) || []).length,
-            generatedBy: authorMatch ? authorMatch[1].trim() : '',
-            generatedAt: dateMatch ? dateMatch[1].trim() : '',
-            updatedAt,
-            requiresApproval: false,
-            revisionFeedback: null,
-            version: versionMatch ? parseInt(versionMatch[1]) : null,
-          };
-        }
+        const titleMatch = content.match(/^#\s+(?:Plan:\s*)?(.+)/m);
+        const projectMatch = content.match(/\*\*Project:\*\*\s*(.+)/m);
+        const authorMatch = content.match(/\*\*Author:\*\*\s*(.+)/m);
+        const dateMatch = content.match(/\*\*Date:\*\*\s*(.+)/m);
+        const versionMatch = f.match(/-v(\d+)/);
+        // P-e8d49105 — for MD drafts, the cross-repo marker / **Projects:**
+        // line is the source of truth (parsed by shared.extractPlanTargetProjects).
+        // If neither is present, fall back to the singular **Project:** header
+        // so single-project drafts render the same badge as today.
+        const declaredProject = projectMatch ? projectMatch[1].trim() : '';
+        const targetProjects = shared.extractPlanTargetProjects(content);
+        const _projects = targetProjects.length > 0
+          ? targetProjects
+          : (declaredProject ? [declaredProject] : []);
+        return {
+          file: f, format: 'draft', archived,
+          project: declaredProject,
+          _projects,
+          summary: titleMatch ? titleMatch[1].trim() : f.replace('.md', ''),
+          status: archived ? 'completed' : completedPrdFiles.has(f) ? 'converted' : 'draft',
+          branchStrategy: '',
+          featureBranch: '',
+          itemCount: (content.match(/^\d+\.\s+\*\*/gm) || []).length,
+          generatedBy: authorMatch ? authorMatch[1].trim() : '',
+          generatedAt: dateMatch ? dateMatch[1].trim() : '',
+          updatedAt,
+          requiresApproval: false,
+          revisionFeedback: null,
+          version: versionMatch ? parseInt(versionMatch[1]) : null,
+        };
       }));
       for (const r of dirResults) if (r) plans.push(r);
     }
+
+    // --- PRD JSON records (prd/*.json + prd/archive/*.json, SQL-backed) ---
+    for (const row of prdRows) {
+      const plan = row.plan;
+      if (!plan || typeof plan !== 'object') continue;
+      const archived = !!row.archived;
+      const f = row.filename;
+      const updatedAt = row.updatedAt ? new Date(row.updatedAt).toISOString() : '';
+      const status = plan.status || (plan.requires_approval && !plan.approvedAt ? 'awaiting-approval' : 'active');
+      // W-mqacrzis0003df4a Bug 2 — fresh staleness from plans/*.md mtime.
+      // plan.planStale lags by an engine tick; stat the source plan here
+      // so the Plans tab does not silently mirror a stale-but-cached false.
+      let freshStale = false;
+      if (!archived && plan.source_plan) {
+        try {
+          const sourceMtime = Math.floor(fs.statSync(path.join(PLANS_DIR, plan.source_plan)).mtimeMs);
+          const recorded = plan.sourcePlanModifiedAt ? new Date(plan.sourcePlanModifiedAt).getTime() : null;
+          if (recorded && sourceMtime > recorded) freshStale = true;
+        } catch { /* source plan may have been deleted/renamed */ }
+      }
+      // P-e8d49105 — _projects rollup feeds the plan-card multi-badge
+      // path in dashboard/js/render-plans.js. For PRD JSONs, walk
+      // missing_features[].project (order-preserving dedup) and fall
+      // back to plan.project for items that omit it. Single-project
+      // plans collapse to a single-element array, identical to today's
+      // single `p.project` badge.
+      const _projects = [];
+      const _seen = new Set();
+      for (const it of (plan.missing_features || [])) {
+        const proj = (it && it.project) || plan.project || '';
+        if (proj && !_seen.has(proj)) { _seen.add(proj); _projects.push(proj); }
+      }
+      if (_projects.length === 0 && plan.project) _projects.push(plan.project);
+      // P-66b1faec — _perProjectProgress feeds the per-project status
+      // pills in the plan card meta line (dashboard/js/render-plans.js
+      // renderPlanCard). Group missing_features by item.project (with
+      // fallback to plan.project) and count `status === 'done'` per
+      // bucket. Keys are first-seen order so the rendered pill row is
+      // stable. Always emitted on PRD JSON records (possibly empty);
+      // MD drafts omit it since they carry no item-level statuses.
+      const _perProjectProgress = {};
+      for (const it of (plan.missing_features || [])) {
+        const proj = (it && it.project) || plan.project || '';
+        if (!proj) continue;
+        if (!_perProjectProgress[proj]) _perProjectProgress[proj] = { complete: 0, total: 0 };
+        _perProjectProgress[proj].total += 1;
+        if (it && it.status === 'done') _perProjectProgress[proj].complete += 1;
+      }
+      plans.push({
+        file: f, format: 'prd', archived,
+        project: plan.project || '',
+        _projects,
+        _perProjectProgress,
+        summary: plan.plan_summary || '',
+        status,
+        branchStrategy: plan.branch_strategy || 'parallel',
+        featureBranch: plan.feature_branch || '',
+        itemCount: (plan.missing_features || []).length,
+        generatedBy: plan.generated_by || '',
+        generatedAt: plan.generated_at || '',
+        completedAt: plan.completedAt || '',
+        updatedAt,
+        requiresApproval: plan.requires_approval || false,
+        revisionFeedback: plan.revision_feedback || null,
+        sourcePlan: plan.source_plan || null,
+        archiveReady: plan._archiveReady || false,
+        archiveReadyAt: plan._archiveReadyAt || null,
+        planStale: freshStale || plan.planStale || false,
+      });
+    }
+
     plans.sort((a, b) => (b.generatedAt || '').localeCompare(a.generatedAt || ''));
     _plansCache = plans;
     _plansCacheTs = Date.now();

package/docs/design-inbox-entries-schema.md

@@ -0,0 +1,106 @@
+# inbox_entries Table Schema
+
+## Overview
+The `inbox_entries` table is the persistent store for operator and agent inbox messages within the Minions orchestration engine. It provides a time-ordered, unread-tracking message queue decoupled from the runtime work-item/dispatch lifecycle.
+
+## Schema Specification
+
+### Column Definitions
+
+| Column | Type | Constraints | Purpose |
+|--------|------|-----------|---------|
+| `id` | TEXT | PRIMARY KEY | Unique message identifier; generated as `<recipient>-<timestamp>-<sender>-<seq>` format |
+| `recipient_session_id` | TEXT | NOT NULL | Session ID of the inbox owner (operator or agent); routes messages to specific actor |
+| `sender_id` | TEXT | NOT NULL | Identifier of the message originator; structured as `<agent-id>` or `'system'` or `'operator'` |
+| `sender_name` | TEXT | NOT NULL | Human-readable sender name for UI display; persisted at write-time for offline/archived reference |
+| `sender_type` | TEXT | NOT NULL | Enum: `'agent'`, `'system'`, `'operator'`; constrains allowed sender_id values |
+| `interaction_id` | TEXT | NOT NULL | Group ID linking related messages (e.g., work-item dispatch feedback, PR review batch); enables threading and deduplication |
+| `sequence` | INTEGER | NOT NULL, DEFAULT 0 | Per-interaction message counter; disambiguates bursts and enables ordering within same millisecond |
+| `summary` | TEXT | NOT NULL | Title/subject line; used for list views and user scanning; always present even if content is truncated |
+| `content` | TEXT | NOT NULL | Full message body; may contain Markdown, code blocks, or structured JSON sidecars (not yet parsed at table level) |
+| `unread` | INTEGER | NOT NULL, DEFAULT 1 | Boolean flag (0/1); toggled by reader, cleared on archive/delete; enables fast unread-count queries |
+| `sent_at` | INTEGER | NOT NULL | Unix timestamp (milliseconds) of message creation; primary sort key for time-ordered display |
+| `read_at` | INTEGER | Nullable | Unix timestamp (milliseconds) when recipient first read the message; null until marked read |
+| `notified_at` | INTEGER | Nullable | Unix timestamp (milliseconds) of last notification event sent to operator; null if no notification dispatched |
+
+### Constraints & Relationships
+
+- **PK constraint:** `id` is globally unique across all inboxes; collision risk is negligible given the composite structure (recipient + timestamp + sender + seq).
+- **FK (soft):** `recipient_session_id` does NOT enforce a referential constraint to `sessions` table (sessions may be archived). Queries SHOULD handle missing recipients gracefully.
+- **FK (soft):** `sender_id` is informational only; no validation that the sender exists in the `config.agents` or active sessions. Invalid senders are logged but do not block writes.
+- **No composite index on (recipient_session_id, sent_at):** See Performance section.
+
+## Architectural Rationale
+
+### Design Decisions
+
+1. **Separate inbox table vs. inline dispatch/work-item attachments.**
+   - Inboxes can outlive their source work items (e.g., a feedback message remains useful after the WI is done).
+   - Decoupling allows independent inbox lifecycle (archive, export, cleanup) without cascading work-item deletes.
+   - Supports rich async consolidation (team notes, KB articles) that don't belong to any single WI.
+
+2. **`unread` flag instead of soft-delete or status enum.**
+   - Fast count queries for badge (`SELECT COUNT(*) WHERE recipient_session_id = ? AND unread = 1`).
+   - Unread state is mutable; allows mark-as-read UX without data loss.
+   - Simplifies archive/export (no tombstone filtering needed).
+
+3. **`sender_type` as an explicit column.**
+   - Allows schema validation (e.g., "agent" senders must have valid IDs; "system" is always valid).
+   - Enables filtered views ("show only agent messages" or "system alerts only") without string parsing.
+
+4. **`interaction_id` for grouping.**
+   - Enables undo/redo on related messages (e.g., canceling all build-failure notifications from one dispatch).
+   - Supports consolidation: multiple small notifications can be collapsed into one summary message.
+
+5. **Persistent `sender_name` at write-time.**
+   - Operator may rename agents or disable them; storing the name ensures historical accuracy.
+   - UI doesn't need to perform runtime lookups on archived inboxes.
+
+6. **Unix timestamps (milliseconds) instead of ISO strings.**
+   - Enables range queries (`sent_at BETWEEN ? AND ?`) without parsing.
+   - Smaller column footprint; easier to sort.
+   - Downside: not human-readable; UI must convert to locale strings.
+
+### Entity Relationships
+
+- **inbox_entries ← dispatch WI feedback:** A failed dispatch may create multiple inbox entries (error summary, retry recommendation, logs snippet). Threaded via `interaction_id`.
+- **inbox_entries ← PR reviews:** Humans and auto-review agents post comments; summarized as inbox alerts to project owners via `interaction_id` per-PR.
+- **inbox_entries ← consolidation:** `engine/consolidation.js` reads inbox entries to extract `agent:` frontmatter and route findings into per-agent knowledge files.
+
+## Performance Considerations
+
+### Indexing Strategy
+
+**Current indexes (recommended):**
+- `idx_recipient_sent` on `(recipient_session_id, sent_at DESC)` — enables efficient "unread count" and "latest N messages" queries without table scans.
+- `idx_interaction` on `(interaction_id)` — enables grouping/dedup queries (e.g., "was this interaction already notified?").
+- PK `id` is implicit index.
+
+**Query patterns:**
+- **Unread count per session:** `SELECT COUNT(*) WHERE recipient_session_id = ? AND unread = 1` → must scan `idx_recipient_sent` to avoid full table.
+- **Latest messages:** `SELECT * WHERE recipient_session_id = ? ORDER BY sent_at DESC LIMIT 20` → seeks on `idx_recipient_sent` DESC.
+- **Thread view:** `SELECT * WHERE interaction_id = ? ORDER BY sent_at` → seeks on `idx_interaction`, then sorts in application or via secondary index.
+- **Cleanup:** `DELETE WHERE sent_at < ? AND unread = 0` → full table scan (acceptable; cleanup is infrequent, low-priority background task).
+
+**Missing indexes (future optimization):**
+- `idx_sender_id` — if queries like "messages from this agent" are common, consider adding.
+- `idx_unread` — if badge ("N unread") is a hot query, consider combining with recipient (`idx_recipient_unread` on `(recipient_session_id, unread)`).
+
+### Size Estimates & Cleanup
+
+- **Row size:** ~500–2000 bytes (summary + content; content can be verbose with logs/code snippets).
+- **Growth:** ~5–50 entries/day (depends on agent activity and verbose flagging).
+- **Retention:** No automatic cleanup; operators may archive/export and manually delete aged entries. Engine does NOT auto-prune.
+- **Recommended**: Implement a dashboard setting to soft-delete entries older than N days (default 30) with an undo/export option.
+
+## Migration & Backward Compatibility
+
+- **Migration 018 or later** creates `inbox_entries` as part of SQL state cutover. Legacy `inbox/` Markdown files are NOT imported; operators must re-send or manually recreate critical messages.
+- **No schema versioning needed** for now; table is immutable-append-only (reads/writes only).
+
+## Related Code
+
+- **Writes:** `engine/inbox-store.js` (primary mutator; uses `getDb()` and `emitStateEvent`).
+- **Reads:** `engine/queries.js#getInboxForSession()`, dashboard `/api/inbox`, `engine/consolidation.js`.
+- **UI:** `dashboard/pages/inbox.html`, `dashboard/js/inbox.js`.
+

package/docs/live-checkout-mode.md

@@ -153,6 +153,33 @@ A count `> 0` returns `{ ok:false, reason:'stale-main', mainRef, ahead, localMai
 
 `spawnAgent` completes the dispatch non-retryably with the dedicated **`FAILURE_CLASS.LIVE_CHECKOUT_STALE_BASE`** (`'live-checkout-stale-base'`; in `dispatch.js`'s `neverRetry` set) plus a `live-checkout-stale-base-<wi-id>` inbox alert and a `_pendingReason: 'live_checkout_stale_base'` stamp — instead of `LIVE_CHECKOUT_FAILED` (retryable) retry-storming an identical structural failure to `maxRetries`. The engine **never** resets, cleans, or rebases the operator's local `mainRef` — surfacing it as a refusal keeps history rewrites in the operator's hands, consistent with the dirty and mid-operation refusals. The alert's recovery guidance offers two paths: salvage the extra commits onto their own branch then `git reset --hard origin/<mainRef>`, or discard them with the same reset — either leaves `mainRef` matching `origin/<mainRef>` so the next dispatch forks off a clean base.
 
+#### 6b. Opt-in auto-freshen (`liveCheckoutAutoFreshen`, W-mrdlcud2000e630e)
+
+The STALE-BASE GUARD (§6) only counts the **local-ahead** side: local `mainRef` merely being **behind** `origin/<mainRef>` (ahead == 0, behind > 0) is silently allowed to fork off a stale-but-safe base. Issue #226 is the reason the engine never auto-fetches live checkouts — preserving operator control over history rewrites. **Auto-freshen** is the narrow, opt-in exception that lets a live (or hybrid liveValidation) dispatch work off the freshest safe base without ever risking a history rewrite or data loss.
+
+Enabling **`liveCheckoutAutoFreshen`** (per-project `project.liveCheckoutAutoFreshen` > fleet-wide `engine.liveCheckoutAutoFreshen` > **`false`**, resolved by `shared.resolveLiveCheckoutAutoFreshen`) makes `prepareLiveCheckout` — **before** the STALE-BASE GUARD, as `_maybeAutoFreshenLocalMain` — fast-forward the local base when, and **only** when, **all** of these hold:
+
+- the tree is **clean** (the Guarantee 2 dirty-tree bail already ran — auto-freshen is never attempted on a dirty tree, and the mid-operation preflight of Guarantee 5 has already refused any in-progress op);
+- HEAD is on `mainRef` (the branch it is about to fork off);
+- this is **not** an `allowNonMainBase` dispatch (PR-targeted fixes / shared-branch continuations are exempt — same skip condition as §6/§7);
+- local `mainRef` has **ZERO** commits ahead of `origin/<mainRef>` — i.e. **not** the stale-base-with-unpushed-commits case; that path stays UNTOUCHED and still hits §6's refusal;
+- local `mainRef` **is** behind `origin/<mainRef>` (behind > 0).
+
+When they hold it runs the **one sanctioned live-mode fetch** — `git fetch origin <mainRef>` — then a **fast-forward-only** update, `git merge --ff-only refs/remotes/origin/<mainRef>` (HEAD is on `mainRef`, so this advances the checked-out base). A `--ff-only` update can never rewrite history or drop local commits (there are none ahead), so the no-data-loss guarantee is preserved even though issue #226's blanket no-fetch rule is relaxed for this one case.
+
+- **Fails open.** Any fetch/network/auth failure, an uncomputable divergence, or an unexpected `--ff-only` refusal (e.g. a race committed onto local `mainRef`) returns **without mutating**, so the dispatch proceeds to the existing stale-base check exactly as if auto-freshen were off. A freshen-step hiccup never hard-fails the dispatch.
+- **Low-noise audit.** On a successful freshen it logs an `info` line and writes a `live-checkout-autofreshen-<wi-id>` inbox note recording the before/after local `mainRef` SHA — **only** when a freshen actually happened (never on every dispatch), so it does not alert-spam.
+- **Uniform across live and hybrid.** Hybrid mode reuses the same live-checkout preflight for its `liveValidation` dispatch path, so the flag applies to both without extra wiring.
+- **Scope-narrow.** The ahead>0 STALE-BASE GUARD refusal is deliberately **unchanged**; auto-freshen only adds a safe fast-forward for the ahead==0/behind>0 case. Default **OFF** — a human opts individual projects in.
+
+Enable it fleet-wide via **Settings → "Live-checkout auto-freshen (fleet-wide)"**, or in `config.json`:
+
+```jsonc
+{ "engine": { "liveCheckoutAutoFreshen": true } }        // fleet-wide
+// or per-project (wins over fleet-wide):
+{ "projects": [ { "name": "office", "checkoutMode": "live", "liveCheckoutAutoFreshen": true } ] }
+```
+
 
 ### 7. Refuse on stale non-main base when forking a new branch (W-mr3lunnq000o9f41)
 

package/docs/runtime-adapters.md

@@ -82,10 +82,113 @@ real behavioral split appears between adapters.
 | `resumeBookkeepingTurn` | ✓ | — | — | Claude CLI injects a synthetic "Continue from where you left off." meta turn on `--resume`; CC prompts must tell the model not to treat it as user intent. |
 | `streamConsumer` | ✓ | ✓ | ✓ | Adapter implements `createStreamConsumer(ctx)` — required by `engine/llm.js` accumulator. |
 | `imageInput` | ✓ | ✓ | ✗ | Runtime accepts `images: [{mimeType, dataBase64}]` and delivers them to the CLI. Claude: Anthropic Messages base64 content-block envelope via `--input-format stream-json`. Copilot: base64 payloads materialized to tmp files and passed as `--attachment <path>` (W-mqv7324u0021db5d). When false, `_resolveImageOpts` returns a typed `model-unavailable` error. |
+| `acpWorkerPool` | ✗ | ✓ | ✗ | Runtime supports `<bin> --acp` (Agent Client Protocol), so it can be routed through a persistent worker pool instead of cold-spawning a fresh CLI process per turn/dispatch. Two independent consumers gate on this flag: `engine/cc-worker-pool.js` (CC/doc-chat tabs, `resolveCcUseWorkerPool`) and `engine/agent-worker-pool.js` (fleet agent dispatch, `resolveAgentUseWorkerPool`). Both resolvers hard-return `false` whenever this flag isn't `true` on the resolved runtime, regardless of any operator override, so a future non-ACP runtime can never be silently pooled. See [ACP Worker Pool](#acp-worker-pool-fleet-agent-dispatch) below. |
 
 When a behavior is genuinely uniform across all current adapters, it still gets
 a flag if a future runtime might disagree — flags are cheap.
 
+## ACP Worker Pool (Fleet Agent Dispatch)
+
+Copilot's `acpWorkerPool` capability backs **two** independent opt-in pools that
+avoid cold-spawning a fresh `copilot` CLI process for every turn/dispatch. Both
+share the same spawn + JSON-RPC transport (`engine/acp-transport.js`) but have
+different ownership models:
+
+| Pool | Module | Ownership model | Config | Default |
+|------|--------|------------------|--------|---------|
+| CC / doc-chat | `engine/cc-worker-pool.js` | 1 worker permanently owned per CC tab, kept warm for the tab's lifetime | `engine.ccUseWorkerPool` | `true` (Copilot CC) — see [docs/command-center.md](./command-center.md) |
+| Fleet agent dispatch | `engine/agent-worker-pool.js` | 1 worker leased to exactly one **active** dispatch at a time, returned to a shared free set on release — not owned for the dispatch's whole life | `engine.agentUseWorkerPool` + `engine.agentAcpPoolSize` | `false` (opt-in) |
+
+This section covers the fleet agent pool (P-9b3d5f61 / P-1d8f0b93 / P-4c6e8a72).
+
+### Config keys
+
+| Key | Resolver | Chain | Default |
+|-----|----------|-------|---------|
+| `engine.agentUseWorkerPool` | `shared.resolveAgentUseWorkerPool(engine, runtime)` | 1. Hard `false` unless `runtime.capabilities.acpWorkerPool === true` (Copilot only). 2. `engine.agentUseWorkerPool` explicit `true`/`false` override. 3. `ENGINE_DEFAULTS.agentUseWorkerPool`. | `false` |
+| `engine.agentAcpPoolSize` | `shared.resolveAgentAcpPoolSize(engine)` | 1. `engine.agentAcpPoolSize` (positive number, else ignored). 2. `engine.maxConcurrent` (fleet dispatch concurrency cap). 3. `ENGINE_DEFAULTS.maxConcurrent`. | `ENGINE_DEFAULTS.maxConcurrent` (currently `5`) |
+
+`agentUseWorkerPool` is deliberately **opt-in** (`false` by default), unlike
+`ccUseWorkerPool`'s default-`true` — the fleet dispatch path has a much larger
+MCP-auth-popup / isolation surface than the single CC singleton, so it stays
+off until proven safe in a given operator's environment. `agentAcpPoolSize`
+defaults to the same cap the engine would already use for cold-spawn
+concurrency (`maxConcurrent`), so enabling the pool never queues more
+concurrent dispatches than the fleet would have run anyway — it only changes
+*how* those dispatches get a CLI process, not how many run at once.
+
+### How dispatches route through the pool
+
+When `resolveAgentUseWorkerPool` resolves `true`, `engine.js#spawnAgent` skips
+`node engine/spawn-agent.js` and instead calls `engine/agent-worker-pool.js#acquireWorker`,
+wrapping the lease in `engine/pooled-agent-process.js#PooledAgentProcess` — a
+child_process-shaped facade (`.pid`, `.stdout`/`.stderr`, `.kill()`,
+`'close'`/`'error'`) so the rest of `spawnAgent`'s downstream code (stdout/stderr
+handlers, PID-file writing, live-output.log, timeout/steering cancel-vs-kill,
+restart-reattach) runs unmodified regardless of whether `proc` is a real OS
+process or a pooled lease. Assignment strategy, in order:
+
+1. A **free** worker whose MCP-server set already matches wins first — reused
+   via a fresh `session/new`, no respawn.
+2. Otherwise another free worker is **evicted** (closed) and a replacement is
+   spawned fresh with the requested MCP servers/cwd (MCP servers are resolved
+   at `copilot --acp` process boot, so a changed server set requires a full
+   respawn, not just a new session).
+3. Otherwise, if the pool has room (fewer than `agentAcpPoolSize` workers
+   allocated across free + busy + in-flight-spawn), a brand-new worker spawns.
+4. Otherwise the request queues FIFO until a `release()` or worker crash frees
+   a slot.
+
+Dispatch records persist `item.pooled = true` on disk (`dispatch.json`), not
+just the in-memory `activeProcesses._pooled` flag (which is wiped on engine
+restart) — the on-disk flag is what tells the restart-reattach path
+(`engine/cli.js`) that a live worker PID is a pooled lease, not a resumable
+cold-spawned child process.
+
+### Isolation tradeoff — read this before enabling `agentUseWorkerPool`
+
+**Enabling the pool bounds the MCP-auth-popup / cross-dispatch isolation risk
+by pool size — it does not eliminate it.** Cold-spawn gives every dispatch its
+own fresh OS process and its own `COPILOT_HOME`; the pool instead keeps up to
+`agentAcpPoolSize` `copilot --acp` processes warm and reuses them across
+dispatches whenever the MCP-server set matches. Concretely:
+
+- A worker process — and anything an MCP server inside it authenticated,
+  cached, or leaked into process memory during a prior dispatch — can be
+  handed to a **different** dispatch/work item next, as long as the MCP-server
+  set is unchanged. There is no per-dispatch process boundary the way
+  cold-spawn provides.
+- The blast radius of a compromised or misbehaving MCP server is capped at
+  `agentAcpPoolSize` concurrently-warm workers, not the whole fleet — but it is
+  **not zero**. A larger pool size widens the number of dispatches that could
+  share exposure to the same warm worker over its lifetime; a smaller pool
+  size narrows it at the cost of more evictions/respawns (and therefore more
+  MCP-auth prompts) when the requested MCP-server set changes between
+  dispatches.
+- This mirrors the same tradeoff `engine.ccUseWorkerPool` already accepts for
+  CC tabs (see [docs/command-center.md](./command-center.md)), which is why
+  `agentUseWorkerPool` defaults `false`: the fleet dispatch surface has more,
+  and more varied, work items than a single CC session, so the exposure window
+  per warm worker is larger and the default stays conservative until an
+  operator has evaluated the tradeoff for their own MCP-server set.
+
+Operators enabling `engine.agentUseWorkerPool` should choose `agentAcpPoolSize`
+deliberately: a pool size of `1` gives the strongest isolation (still weaker
+than cold-spawn, since consecutive dispatches on that single worker still
+share process state) at the cost of maximum serialization/respawns; a larger
+pool size trades some isolation for parallelism and fewer respawns.
+
+### See Also (ACP pool)
+
+- `engine/agent-worker-pool.js` — pool mechanics, assignment strategy, JSDoc header.
+- `engine/pooled-agent-process.js` — the child_process-shaped facade and its
+  documented output-translation scope limits (no tool-call/model-announcement
+  event synthesis — a deliberate parity gap, not an oversight).
+- `test/unit/agent-worker-pool.test.js`, `test/integration/agent-pool-dispatch.test.js`,
+  `test/unit/pooled-cold-parity-matrix.test.js`, `test/unit/pooled-cancel-vs-kill.test.js`,
+  `test/unit/pooled-dispatch-restart-reattach.test.js` — pool mechanics, end-to-end
+  flow, cold/pooled parity matrix, cancel-vs-kill, and restart-reattach coverage.
+
 ## CC vs Agent Runtime Independence
 
 Command Center (CC) / doc-chat and the agent fleet are two **independent**