instar 1.3.562 → 1.3.564

package/src/data/builtin-manifest.json

@@ -1,8 +1,8 @@
 {
   "$schema": "./builtin-manifest.schema.json",
   "schemaVersion": 1,
-  "generatedAt": "2026-06-14T11:06:11.902Z",
-  "instarVersion": "1.3.562",
+  "generatedAt": "2026-06-14T17:47:52.563Z",
+  "instarVersion": "1.3.564",
   "entryCount": 201,
   "entries": {
     "hook:session-start": {
@@ -11,7 +11,7 @@
       "domain": "identity",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/session-start.sh",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:dangerous-command-guard": {
@@ -20,7 +20,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/dangerous-command-guard.sh",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:grounding-before-messaging": {
@@ -29,7 +29,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/grounding-before-messaging.sh",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:compaction-recovery": {
@@ -38,7 +38,7 @@
       "domain": "identity",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/compaction-recovery.sh",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:external-operation-gate": {
@@ -47,7 +47,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/external-operation-gate.js",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:deferral-detector": {
@@ -56,7 +56,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/deferral-detector.js",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:self-stop-guard": {
@@ -65,7 +65,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/self-stop-guard.js",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:post-action-reflection": {
@@ -74,7 +74,7 @@
       "domain": "evolution",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/post-action-reflection.js",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:external-communication-guard": {
@@ -83,7 +83,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/external-communication-guard.js",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:scope-coherence-collector": {
@@ -92,7 +92,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/scope-coherence-collector.js",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:scope-coherence-checkpoint": {
@@ -101,7 +101,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/scope-coherence-checkpoint.js",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:free-text-guard": {
@@ -110,7 +110,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/free-text-guard.sh",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:claim-intercept": {
@@ -119,7 +119,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/claim-intercept.js",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:claim-intercept-response": {
@@ -128,7 +128,7 @@
       "domain": "coherence",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/claim-intercept-response.js",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:stop-gate-router": {
@@ -137,7 +137,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/stop-gate-router.js",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "hook:auto-approve-permissions": {
@@ -146,7 +146,7 @@
       "domain": "safety",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
       "installedPath": ".instar/hooks/instar/auto-approve-permissions.js",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "job:health-check": {
@@ -1554,7 +1554,7 @@
       "type": "subsystem",
       "domain": "updates",
       "sourcePath": "src/core/PostUpdateMigrator.ts",
-      "contentHash": "e0ddbc39521447ae1bfecddfc98b2bd579400889d5fac37cf7df7d380e6a2fb7",
+      "contentHash": "67ee569178f3390f9f87fc675416d9d85b1eaf58a1291a8b0ee90b37c67af7b8",
       "since": "2025-01-01"
     },
     "subsystem:scheduler": {

package/src/scaffold/templates.ts

@@ -420,6 +420,7 @@ This routes feedback to the Instar maintainers automatically. Valid types: \`bug
 - Read it: \`curl -H "Authorization: Bearer $AUTH" "http://localhost:${port}/sessions/reap-log?limit=50"\` → \`{ entries: [{ ts, type:'reaped'|'skipped'|'notify', session, reason, disposition, origin, skipped?, machine?, midWork?, workEvidence?, noticeId?, topicId?, outcome? }] }\`. Read-only. \`type:'notify'\` rows are reap-NOTICE delivery outcomes (append-only pairs: \`enqueued\` → \`sent\`/\`send-failed-escalated\`/\`no-topic\`/\`enqueue-failed\`; latest record per noticeId wins) — "did the user get told?" is auditable. \`midWork:true\` on a reaped row means the kill interrupted evidenced work.
 - Notices are PER-TOPIC and durable: every topic that lost a session gets one plain-English notice in THAT topic (bursts coalesce per topic; the lifeline gets unbound sessions + a cross-topic index), delivered through a durable store + always-on drain that retries with backoff. Rollback levers: \`{"monitoring": {"reapNotify": {"perTopic": false}}}\` (legacy single-buffer), \`{"drainEnabled": false}\` (legacy direct send), \`{"enabled": false}\` (no notices). Recovery-bounces and your own operator kills stay silent.
 - **Mid-work resume queue** (ships observe-only/dry-run by default): a session reaped MID-WORK (strong work evidence at kill time) is queued for ordered automatic revival once the machine recovers — at most one resume per minute, only after sustained calm + quota headroom. \`GET /sessions/resume-queue\` shows entries, paused/breaker state, and lastTickAt; \`POST /sessions/resume-queue/:id/cancel\` · \`/:id/requeue\` (gave-up entries only) · \`/resume\` (unpause) · \`/drain\` (manual single step). Emergency stops pause the queue; an explicit per-topic stop cancels that topic's entries. Jobs only auto-resume when their definition sets \`resumeOnReap: true\`.
+- **A stale emergency-stop pause self-heals**: an emergency-stop pauses the WHOLE revival queue, and that pause used to never lift — silently stranding later, unrelated active-run revivals (the 2026-06-14 4-hour-silent-strand). Now: while the queue is paused with sessions waiting, you get ONE plain-English heads-up that revival is paused (Layer 1, always on); and if the pause is a stale emergency/sentinel stop AND an active autonomous run has since been recycled and queued well after the stop, the queue auto-resumes itself (Layer 2, on by default — \`monitoring.resumeQueue.autoResumeStalePause: false\` to disable; \`staleEmergencyPauseAutoResumeMin\` tunes the window, default 60). Any topic you actually stopped stays blocked by its per-topic operator-stop record even after the queue resumes, and a deliberate \`autonomous stop-all\` halt is NEVER auto-cleared. Proactive: user asks "why did my session restart by itself after a stop?" / "why is revival paused?" → GET /sessions/resume-queue (paused state) and the resume-queue audit log, then explain in plain words.
 - Proactive: user asks "where did my session go?" / "why did X disappear?" / "did something get killed?" → GET /sessions/reap-log and explain the most recent reaped/skipped entries for that session. User asks "did my interrupted work come back?" / "is a restart queued?" → GET /sessions/resume-queue and report the entry's status in plain words.
 - **Build-Session Yield Safety** (ACT-839; ships dev-enabled, dark on the fleet, per the Maturation Path standard): a session reaped while its WORKTREE holds uncommitted work (a build that died "standing by for tests") is resume-eligible on that alone — the killer collects a bounded, fail-open dirty-check pre-kill and tags \`uncommitted-worktree-work\`. On revival the continuation prompt leads with a commit-first directive, and a durable beacon-enabled commitment (\`GET /commitments\`) re-surfaces the obligation if the revived session stalls. An explicit operator/user kill is NEVER auto-revived on a dirty worktree alone. The die-again case is caught by the OrphanedWorkSentinel (\`GET /orphaned-work\`). Proactive: user asks "why did my build come back / why am I being told to commit?" → it was revived because its worktree had unsaved work; commit it or deliberately discard it.
 

package/upgrades/1.3.563.md

@@ -0,0 +1,32 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Fixed a boot-ordering bug that meant the **Durable Inbound Message Queue** (`multiMachine.sessionPool.inboundQueue`) could NEVER construct its engine, regardless of config. In `startServer()`, the queue-engine construction gate read the module-level `_sessionPoolStage()` getter while it was still its initial stub (`() => 'dark'`) — the real liveConfig-reading implementation is only assigned ~350 lines further down the same synchronous boot flow. So the gate's `_sessionPoolStage() !== 'dark'` test was always false at construction time, the engine never built, and `GET /pool/queue` answered 503 forever even with the feature enabled and a non-dark session-pool stage. The feature ships dark/dry-run by default, so the fleet never hit this; it only bites the first agent to enable it for real.
+
+The fix resolves the stage INLINE at the construction site, reading the same `multiMachine.sessionPool` config (liveConfig override over the static block) via a new shared pure helper `resolveSessionPoolStage(cfg)` in `src/core/inboundQueueConfig.ts`, instead of consulting the not-yet-wired ref. The live `_sessionPoolStage` getter is refactored to call the same helper, so the two stage readers can never drift apart again (that drift was the root cause). No new capability, config key, HTTP route, or authority — purely a correction to WHEN an existing decision is read.
+
+audience: agent-only
+maturity: stable
+
+A no-deferrals audit of all five `_sessionPoolStage()` call sites confirmed exactly one genuinely-premature boot-time read (the construction gate). The three runtime-handler reads (`wireTelegramRouting` x2, the `onAccepted` forwarded-message callback) are correct as-is: they execute per-message AFTER boot and close over the ref, so they see the wired implementation when invoked.
+
+## What to Tell Your User
+
+Nothing to announce proactively — the inbound queue ships disabled by default, so for any agent that hasn't deliberately turned it on, nothing changes. If asked: the crash-proof holding area for messages that arrive while a conversation is mid-move between machines had a startup bug that kept it from ever turning on; it now starts correctly when enabled. For a developer agent running it live, the queue's status page now returns real data instead of "not available." Every error path still fails toward off (no queue), which is identical to the shipped default.
+
+## Summary of New Capabilities
+
+No new capability — a latent behavior-correctness fix restoring intended behavior.
+
+| Change | Effect |
+|--------|--------|
+| Inbound-queue construction gate reads stage inline | The queue engine constructs when `inboundQueue.enabled=true` + a non-dark `sessionPool` stage (was: never) |
+| `resolveSessionPoolStage(cfg)` shared helper | Single source of truth for the pool stage; boot gate + live getter can no longer drift |
+
+## Evidence
+
+Behavior-correctness fix; reproduced by code-read on `JKHeadley/main` and pinned by a fails-before/passes-after structural regression guard. `tests/unit/inbound-queue-boot-order.test.ts` (5) asserts the construction gate no longer calls the stub getter, resolves inline before gating, routes both readers through the shared helper, and leaves the stub declaration intact (4 of 5 assertions fail against pre-fix `server.ts`; all 5 pass against the fix). `tests/unit/resolve-session-pool-stage.test.ts` (5) covers both sides of the stage-resolution boundary (enabled+stage→stage; disabled/missing→dark). The existing `tests/integration/inbound-queue-route.test.ts` and `tests/e2e/inbound-queue-lifecycle.test.ts` already prove a constructed engine serves a real 200 on `/pool/queue`. `npx tsc --noEmit` clean; full lint + dark-gate (24/24, line-map unchanged) + no-silent-fallbacks (baseline 474 unchanged) + feature-delivery-completeness + route-completeness green.

package/upgrades/1.3.564.md

@@ -0,0 +1,40 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Fixed a latent bug where a **stale emergency-stop could silently strand the resume queue forever**. A MessageSentinel emergency-stop is topic-scoped in intent (it kills/clears/cancels only the topic the "stop" message arrived in — verified against the `routes.ts` handler), but it ALSO sets a **global** `resumeQueue.pause()` with no expiry and no re-arm. Nothing ever lifted that pause, so a stale emergency stop on one topic permanently disabled the revival net for *every other* topic. On 2026-06-14 an emergency stop from the previous day left the net off for ~18h; when an unrelated autonomous run was later recycled at its age cap, the resume-idle fix correctly queued it for revival — but a paused queue admits and never drains, so the run sat dead for ~4h until the operator messaged. This is the concrete cause behind the recurring "why do my sessions keep dying?" feeling.
+
+`ResumeQueueDrainer.tick()` now runs two layers where the silent strand happened (both inert on a dry-run/observe-only queue, so the fleet default is unchanged):
+
+- **Layer 1 (signal-only):** when the queue is paused with waiting work, raise ONE deduped `paused-waiting` aggregated attention notice — keyed on `(pausedAt | waitingCount)` so a new pause OR a growing backlog re-alerts, but a steady pause doesn't drip every tick. This alone makes the strand never silent again.
+- **Layer 2 (bounded behavior change, on by default when the queue is live):** auto-resume a **stale** emergency/sentinel pause when an active-autonomous-run entry (`AGE_LIMIT_ACTIVE_RUN_REASON`) was queued **strictly more than** `staleEmergencyPauseAutoResumeMin` (default 60) minutes after the pause began, then fall through to normal draining. Every revived candidate still passes all deterministic reality gates AND the per-topic `operatorStopSince` validation — so a genuinely-stopped topic stays blocked. A FRESH "kill everything" is never auto-undone (the staleness window protects it), and a deliberate `autonomous stop-all` halt is NEVER auto-cleared.
+
+`ResumeQueue.pause()` gains a deliberate-halt **upgrade**: a later non-auto-resumable reason (`autonomous stop-all`) overrides an existing auto-resumable emergency pause (the reverse never downgrades), so an operator's explicit halt issued during a stale pause is honored. The auto-resume predicate lives in ONE centralized, mechanically-enforced helper `isAutoResumableEmergencyPauseReason()` (a callsite-scan unit test pins every `ResumeQueue.pause()` reason's verdict, so a future rewording can't silently change behavior).
+
+audience: agent-only
+maturity: stable
+
+Spec converged through `/spec-converge` (6 rounds; real cross-model review via codex-cli:gpt-5.5 + gemini-cli:gemini-2.5-pro). Future hardening (a structured `pauseKind` enum; broadening the trigger; original-context age) is tracked as evolution-action ACT-904, not deferred-and-forgotten.
+
+## What to Tell Your User
+
+Nothing to announce proactively — the revival safety net ships in watch-only mode for most agents, so unless it was deliberately turned on, behavior is unchanged. If asked "why did my session restart by itself after a stop?" or "why is revival paused?": an emergency stop pauses the whole revival queue, and that pause used to never turn back off — silently stranding later, unrelated work. Now the agent tells you when revival is paused with work still waiting, and a stale emergency pause heals itself once a fresh active run has been recycled and queued well after the stop. Anything you actually stopped stays stopped — the per-topic stop record keeps blocking its revival even after the queue turns back on. If you'd rather the auto-heal stay off, just ask me to turn it off.
+
+## Summary of New Capabilities
+
+A behavior-correctness fix (a permanent silent strand becomes a visible, self-healing one), plus two code-defaulted config knobs.
+
+| Change | Effect |
+|--------|--------|
+| Layer 1 paused-waiting notice | A paused queue with waiting sessions raises ONE deduped attention notice instead of staying silent (re-alerts on a growing backlog) |
+| Layer 2 stale-pause auto-resume | A stale emergency/sentinel pause auto-resumes when an active-run revival was queued > `staleEmergencyPauseAutoResumeMin` (60) min after the pause; per-topic `operatorStopSince` still guards genuinely-stopped topics |
+| `pause()` deliberate-halt upgrade | A later `autonomous stop-all` overrides an in-flight auto-resumable emergency pause (never the reverse) |
+| `isAutoResumableEmergencyPauseReason()` | One centralized, callsite-scan-tested predicate for which pause reasons are auto-resumable |
+| `monitoring.resumeQueue.staleEmergencyPauseAutoResumeMin` (60) / `autoResumeStalePause` (true) | Code-defaulted knobs; `autoResumeStalePause:false` disables Layer 2 (Layer 1 always on) |
+
+## Evidence
+
+Behavior-correctness fix proven from a real 2026-06-14 forensic chain (`logs/reap-log.jsonl`, `logs/resume-queue.jsonl`). All three test tiers green: `tests/unit/resume-queue-drainer.test.ts` (+20: Layer-1 once-per-episode + growing-backlog re-alert, dry-run silence, stale auto-resume happy path, exactly-at/just-over/malformed-timestamp boundaries, fresh-pause/stop-all/plain-mid-work negatives, `autoResumeStalePause:false`, post-resume `operatorStopSince` guard intact, both pause-overlap orderings, the closed-world predicate + mechanical `ResumeQueue.pause(` callsite scan); the suite fails for the right reason before the fix); `tests/integration/resume-queue-routes.test.ts` (+1: `GET /sessions/resume-queue` shows `paused:false` after a drainer auto-resume); `tests/e2e/reap-notify-resume-queue-lifecycle.test.ts` (+1: full lifecycle — emergency-stop pauses → active-run admitted later → drainer auto-resumes → entry `respawned`, the feature-is-alive assertion). `npx tsc --noEmit` clean; full lint + dark-gate green. Config keys are code-defaulted (not in ConfigDefaults — preserves the fleet flip), so no `migrateConfig` change is needed; CLAUDE.md awareness ships via the template + a dedicated idempotent `PostUpdateMigrator` block (so existing agents learn the self-heal too). Side-effects review: `upgrades/side-effects/resume-queue-stale-emergency-pause.md`.

package/upgrades/side-effects/inbound-queue-boot-order-fix.md

@@ -0,0 +1,72 @@
+# Side-Effects Review — Inbound-Queue Boot-Order Fix
+
+**Tier:** 1 (latent behavior-correctness fix restoring intended behavior — no new capability, no new config key, no new route, no new authority). **Parent principle:** Structure > Willpower / feature-is-alive — a feature that can never construct is a broken feature; this restores the intended construction path and pins it with a regression guard.
+**Files:** src/commands/server.ts, src/core/inboundQueueConfig.ts, tests/unit/resolve-session-pool-stage.test.ts (new), tests/unit/inbound-queue-boot-order.test.ts (new)
+
+## The bug
+
+The Durable Inbound Message Queue (`multiMachine.sessionPool.inboundQueue`, spec `docs/specs/durable-inbound-message-queue.md`) NEVER constructed its engine, regardless of correct config, because of a boot-ordering bug in `src/commands/server.ts`:
+
+- `let _sessionPoolStage: () => string = () => 'dark';` — a module-level stub initialized to always return `'dark'`.
+- The inbound-queue engine construction is gated `if (qcfg.enabled && _sessionPoolStage() !== 'dark') { … _inboundQueue = new QueueDrainLoop(…) … }`, running SYNCHRONOUSLY in the mesh boot block (`if (meshIdMgr && meshSelfId)`) inside `startServer()`.
+- The ONLY reassignment of `_sessionPoolStage` to the real (liveConfig-reading) impl executes ~350 lines BELOW that construction site, also synchronously, in the same block.
+
+At construction time the stub is still in force → `_sessionPoolStage()` returns `'dark'` → `'dark' !== 'dark'` is false → the engine never constructs. The same gate guards the `else if (_sweptInboundStore)` cleanup branch. Net: the feature has been inert since it shipped (it ships dark/dry-run by default, so nobody on the fleet hit it). `/pool/queue` returns 503 forever even with `inboundQueue.enabled=true` + a non-dark stage.
+
+## The no-deferrals audit — every `_sessionPoolStage()` call site
+
+Grepped ALL uses of `_sessionPoolStage` in `src/commands/server.ts`. Verdict for each:
+
+| Line (main) | Context | Runs synchronously at boot before the ~16045 reassignment? | Verdict |
+|---|---|---|---|
+| ~443 | `let _sessionPoolStage = () => 'dark'` | n/a (the stub declaration) | the bug SOURCE — left in place by design (runtime handlers legitimately close over it) |
+| ~1992 | inside `wireTelegramRouting` (the per-message inbound dispatch handler) | NO — invoked per-message at runtime, after boot; closes over the ref and sees the wired impl | FINE — not fixed |
+| ~2000 | inside `wireTelegramRouting` (same handler) | NO — same as above | FINE — not fixed |
+| ~14434 | inside the `onAccepted` callback (fires when a forwarded mesh message arrives) | NO — runtime mesh-message handler; closes over the ref | FINE — not fixed |
+| ~15694 | the inbound-queue engine CONSTRUCTION gate | **YES** — synchronous boot read, BEFORE the ~16045 reassignment | **BUGGY — FIXED** |
+| ~16045 | the `_sessionPoolStage = () => {…}` reassignment to the real impl | n/a (the assignment itself; everything after it sees the wired impl) | FINE — refactored to use the shared helper |
+
+Exactly ONE genuinely-premature boot-time read (15694). No sibling premature read left unfixed. The three runtime-handler reads (1992/2000/14434) are correct as-is — they execute only after boot, by which time the ref is wired; the `session-pool-activation-wiring.test.ts` structural test continues to assert those handlers use `_sessionPoolStage()`, and it stays green.
+
+## What changed
+
+1. **`src/core/inboundQueueConfig.ts`** — added a pure helper `resolveSessionPoolStage(cfg)` that returns the configured `stage` only when the pool is BOTH `enabled` AND carries a `stage`, else `'dark'`. This becomes the single source of truth for the stage decision, eliminating the hand-duplicated logic that let the two readers drift. No config types, defaults, or invariants changed.
+2. **`src/commands/server.ts` (construction site, ~15694):** the gate now computes the stage INLINE — `const _sessionPoolStageNow = (() => { try { const live = liveConfig.get('multiMachine.sessionPool', fallback); return iqcMod.resolveSessionPoolStage(live); } catch { return 'dark'; } })();` — mirroring the ~16045 impl exactly (liveConfig override over the static config block), then gates on `qcfg.enabled && _sessionPoolStageNow !== 'dark'`. It no longer consults the not-yet-wired `_sessionPoolStage()` ref.
+3. **`src/commands/server.ts` (the real getter, ~16045):** refactored to call the same `resolveSessionPoolStage` helper (dynamic-imported at that site, matching the file's existing dynamic-import pattern) instead of its own inline copy of the logic. Behavior identical; now DRY with the boot gate.
+4. **Tests (new):** `tests/unit/resolve-session-pool-stage.test.ts` (5) proves the resolution logic on both sides of the decision boundary; `tests/unit/inbound-queue-boot-order.test.ts` (5) is the structural regression guard — it asserts the construction gate no longer reads the stub, resolves inline before gating, routes both readers through the shared helper, and leaves the stub declaration intact.
+
+## Blast radius (activation, explicit)
+
+- **Fleet = no-op.** The inbound queue ships `enabled: false` (and `dryRun: true` even when enabled) by default. No fleet agent's behavior changes: with the queue disabled, `qcfg.enabled` is false and the gate short-circuits before the stage is even consulted.
+- **Any agent with `inboundQueue.enabled=true` AND `sessionPool` stage `!== 'dark'`** will now CONSTRUCT the queue engine where before it silently did not. `/pool/queue` flips from 503 to 200. For **Echo** this is the intended **no-dark-on-dev activation** — the dev agent enabling the feature live is the first real exercise of the construction path, which is exactly the path this fixes.
+- **Multi-machine posture:** machine-local construction only. This is a behavior-correctness fix — it changes WHEN an existing local decision is read, not any cross-machine protocol, route, or mesh verb. A single-machine agent that hasn't enabled the queue is wholly unaffected.
+- **No new authority surface.** The construction still requires the full existing gate chain (enabled + non-dark stage + the six config-seam invariants validated by `validateInboundQueueInvariants` + dry-run handling). Nothing about WHAT the queue is allowed to do changed.
+
+## Risk + mitigation
+
+- **Risk:** the inline read disagrees with the live getter (the same drift class that caused the bug). **Mitigation:** both now call the single `resolveSessionPoolStage` helper — there is no second copy of the logic to drift. Pinned by `inbound-queue-boot-order.test.ts` (asserts ≥2 helper callsites) + `resolve-session-pool-stage.test.ts`.
+- **Risk:** a config-read throw at the inline site crashes boot or builds a half-configured queue. **Mitigation:** the inline resolution is try/caught and fails to `'dark'` (the safe, queue-OFF direction = the shipped default), carrying an in-brace `@silent-fallback-ok` justification. Verified against `tests/unit/no-silent-fallbacks.test.ts` (baseline unchanged at 474).
+- **Risk:** the fix accidentally activates the queue on the fleet. **Mitigation:** the `qcfg.enabled` half of the gate is untouched and still defaults false; the fix only corrects the stage half. Fleet default behavior is byte-identical.
+
+## Migration parity
+
+- No agent-installed files changed: no `.claude/settings.json` hooks, no `.instar/config.json` defaults, no CLAUDE.md template section, no hook scripts, no built-in skills. `resolveSessionPoolStage` is a pure code helper consumed only by `server.ts`. No `PostUpdateMigrator` change is needed — existing agents pick up the corrected construction path the moment their server runs the new code.
+
+## Dark-gate line-map
+
+- UNCHANGED. The change touches `src/core/inboundQueueConfig.ts` (a new pure function, no `enabled:` literal) and `src/commands/server.ts` (no `ConfigDefaults.ts` edit). The dark-gate attributor reads `src/core/ConfigDefaults.ts` only and matches `enabled:` lines; no such line shifted. Verified: `tests/unit/lint-dev-agent-dark-gate.test.ts` → 24/24 green, unchanged.
+
+## Rollback
+
+- Revert the two source edits (the inline resolution at the construction site + the helper call at the getter) and delete the helper + the two new test files. The queue reverts to never-constructing (the prior broken-but-inert state). Because the feature ships dark, the revert is a strict no-op on the fleet. No data migration, no durable-state change.
+
+## Tests
+
+- `tests/unit/resolve-session-pool-stage.test.ts` (5) — the stage-resolution logic: enabled+stage→stage; enabled+missing-stage→dark; disabled→dark; empty/null/undefined→dark; non-string stage coerced.
+- `tests/unit/inbound-queue-boot-order.test.ts` (5) — the structural regression guard: the construction gate does not call the stub getter; resolves inline; resolution precedes the gate; both readers use the shared helper; the stub declaration is intact. Fails-before/passes-after verified (4 of 5 assertions fail against pre-fix `server.ts`; all 5 pass against the fix).
+- Existing coverage already proves feature-alive: `tests/integration/inbound-queue-route.test.ts` (engine present → 200, absent → 503) and `tests/e2e/inbound-queue-lifecycle.test.ts` (boot-sweep → construct → drain → /pool/queue 200).
+- Green locally: `npx tsc --noEmit` clean; the two new suites + `session-pool-activation-wiring` + `inbound-queue-route` + `inbound-queue-config` + `no-silent-fallbacks` + `feature-delivery-completeness` + `route-completeness` + `lint-dev-agent-dark-gate` (159 tests) all pass.
+
+## Agent awareness
+
+- No CLAUDE.md change. The inbound queue is already documented in the agent template ("Durable Inbound Message Queue + Hold-for-Stability"); this fix restores the documented behavior rather than adding a capability, so no `generateClaudeMd`/`migrateClaudeMd` change is required (feature-delivery-completeness green — no new tracked section). <!-- tracked: inbound-queue-boot-order-fix -->

package/upgrades/side-effects/resume-queue-stale-emergency-pause.md

@@ -0,0 +1,212 @@
+# Side-Effects Review — Resume queue: stale emergency-stop pause auto-recovery
+
+**Version / slug:** `resume-queue-stale-emergency-pause`
+**Date:** `2026-06-14`
+**Author:** `Echo (instar-dev agent)`
+**Second-pass reviewer:** `cross-model (codex-cli:gpt-5.5, gemini-cli:gemini-2.5-pro) via /spec-converge — 6 rounds`
+
+## Summary of the change
+
+A paused resume queue used to early-return `{blocked:'paused'}` at the top of
+`ResumeQueueDrainer.tick()`, silently stranding every waiting revival for the life of
+the pause. A MessageSentinel emergency-stop (topic-scoped in its real intent) sets a
+GLOBAL pause that never lifts, so a stale emergency stop on one topic permanently
+disabled the revival net for all topics (the 2026-06-14 4-hour-silent-strand
+incident). This change replaces that early-return with two layers, both at the same
+chokepoint and both inert on a dry-run queue: **Layer 1** (signal-only) raises ONE
+deduped `paused-waiting` aggregated attention notice when the queue is paused with
+waiting work; **Layer 2** (bounded behavior change, on by default) auto-resumes a
+STALE emergency/sentinel pause when an `AGE_LIMIT_ACTIVE_RUN_REASON` entry was queued
+strictly more than `staleEmergencyPauseAutoResumeMin` (default 60) minutes after the
+pause began, then falls through to normal draining. Files touched:
+`src/monitoring/ResumeQueueDrainer.ts` (the two layers + 2 config keys),
+`src/core/WorkEvidence.ts` (new `isAutoResumableEmergencyPauseReason` predicate),
+`src/monitoring/ResumeQueue.ts` (`pause()` now upgrades an auto-resumable pause when a
+deliberate halt arrives), `src/commands/server.ts` (thread the 2 code-defaulted keys),
+`src/core/types.ts` (2 optional config keys), `src/scaffold/templates.ts` +
+`src/core/PostUpdateMigrator.ts` (Agent Awareness), and the 3 test tiers.
+
+## Decision-point inventory
+
+- `ResumeQueueDrainer.tick()` paused-queue branch — **modify** — was an
+  unconditional early-return; now runs Layer 1 (signal) + Layer 2 (a bounded
+  authority change that REMOVES a stale over-broad block).
+- `ResumeQueue.pause()` overlap semantics — **modify** — first-writer-wins gains a
+  deliberate-halt UPGRADE (a non-auto-resumable reason overrides an existing
+  auto-resumable pause; never the reverse).
+- `isAutoResumableEmergencyPauseReason()` — **add** — the centralized closed-world
+  predicate that decides which pause reasons are auto-resumable.
+
+## 1. Over-block
+
+No new block/allow surface is ADDED. Layer 2 strictly REMOVES a block (a stale global
+pause). The only way this could "over-block" is by FAILING to auto-resume when it
+should — which is the safe direction (the queue stays paused, exactly today's
+behavior, and Layer 1 keeps alerting). Concrete safe-side cases that intentionally do
+NOT auto-resume: a fresh emergency pause (active-run queued < threshold after
+pausedAt), a deliberate `autonomous stop-all` pause, a plain mid-work entry (reason ≠
+`AGE_LIMIT_ACTIVE_RUN_REASON`), a malformed `pausedAt`/`queuedAt`, `autoResumeStalePause:false`,
+or a dry-run queue. All keep the pause — none wrongly clear it.
+
+## 2. Under-block
+
+Layer 2 could in principle clear a pause the operator wanted kept. Mitigations: (a)
+the staleness window (default 60 min) means a fresh "kill everything" is never
+auto-undone; (b) only the strongest re-engagement signal
+(`AGE_LIMIT_ACTIVE_RUN_REASON`, queued AFTER the stop) triggers it; (c) **every topic
+the operator actually stopped stays blocked by the per-topic `operatorStopSince`
+validation in `validateReality` even after the queue auto-resumes** — verified by a
+unit test (`operatorStopSince:() => true` still yields `invalidated:operator-stop`
+post auto-resume); (d) a deliberate `autonomous stop-all` is never auto-cleared and
+now UPGRADES an in-flight emergency pause so a later deliberate halt wins. The known
+accepted residual (gemini r2/r5): an autonomous run that was contextually old but only
+age-reaped after the stop satisfies the predicate — accepted because the per-topic
+guard still blocks a genuinely-stopped topic, and the entry queued-after-stop
+genuinely reflects a run left running through the stop window.
+
+## 3. Level-of-abstraction fit
+
+Correct layer. Layer 1 is a low-cost SIGNAL feeding the EXISTING aggregated attention
+surface (`raiseAggregated` → the single `resume-queue:aggregate` P17 item) — it does
+not run parallel to a smarter gate, it reuses the one that exists. Layer 2 is a
+deterministic predicate over durable queue state at the drainer chokepoint where the
+strand happens; it does not re-implement any existing primitive, and it explicitly
+DEFERS the real per-topic safety decision to the already-existing finer-grained
+`operatorStopSince` gate rather than duplicating it. The pause-reason classification
+lives in one centralized, tested predicate rather than being re-derived per callsite.
+
+## 4. Signal vs authority compliance
+
+**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
+
+- [x] No — Layer 1 produces a signal consumed by the existing aggregated attention gate.
+- [x] Yes — but the logic NARROWS authority toward a finer-grained gate that already
+  exists. Layer 2 REMOVES an over-broad, stale, blunt block (the global pause) only
+  when a precise deterministic staleness predicate holds; it does not ADD a new
+  brittle blocker, and every revived candidate still passes ALL deterministic reality
+  gates AND the per-topic `operatorStopSince` validation. The substring reason match
+  is anchored to a closed, internally-generated set of pause reasons, centralized in
+  one tested predicate, with a mechanical `src/`-callsite-scan test pinning every
+  current reason's verdict so a future reason can't silently change behavior; a
+  non-match resolves to the SAFE side (pause stays). Per signal-vs-authority, the
+  change is strictly additive to safety on the stopped topic and removes a
+  false-negative-on-revival for unrelated topics.
+
+## 5. Interactions
+
+- **Shadowing:** the new branch runs in place of the old `if (queue.isPaused()) return`
+  early-return — it can either keep the pause (same as before) or fall through to the
+  rest of `tick()` (which runs all the existing calm/quota/reality gates unchanged). No
+  existing check is shadowed; the fall-through ADDS the gates rather than skipping them.
+- **Double-fire:** Layer 1 dedupes on `(pausedAt | waitingCount)` so it cannot drip
+  every tick; the existing `raiseResumeAggregated` in server.ts collapses all kinds
+  into one rolling item. No double-notice.
+- **Races:** `pause()`/`unpause()` are synchronous mutations on the single-writer,
+  lockfile-guarded, in-memory-authoritative queue; the drainer's `ticking` re-entrancy
+  guard prevents overlapping ticks. `unpause()` correctly accumulates `frozenMs` into
+  each waiting entry's TTL clock (uses the existing lever, not a raw flag).
+- **Feedback loops:** the auto-resume → spawn → (if it re-reaps) re-enqueue path is
+  already bounded by the resurrection cap in `ResumeQueue.considerEnqueue`. A topic
+  that keeps getting reaped-and-revived still hits `maxResurrections` and gives up
+  loudly — Layer 2 does not bypass that cap.
+
+## 6. External surfaces
+
+- **Other agents on the same machine:** none — per-machine queue.
+- **Install base:** the two config keys are code-defaulted (absent from
+  ConfigDefaults). Existing agents pick up the new drainer behavior on update+restart.
+- **External systems:** none. No Telegram/Slack/GitHub/Cloudflare call added beyond
+  the existing attention surface (Layer 1 reuses it).
+- **Persistent state:** `unpause()` mutates the existing `state/resume-queue.json`
+  pause fields and a new `pause-upgraded`/`auto-resumed-stale-pause`/`paused-waiting`
+  audit event in `logs/resume-queue.jsonl`. No schema field added to entries or
+  persisted state. The Layer-1 dedupe marker is in-memory only.
+- **Timing:** the staleness comparison uses the queue's single injected clock; strict
+  `>`; malformed timestamps fail safe.
+- **Operator surface (Mobile-Complete):** no NEW operator-facing action. The existing
+  `POST /sessions/resume-queue/resume` lever (dashboard/phone-reachable) is unchanged;
+  Layer 1 points the operator at "ask me to resume it, or resume it from the dashboard"
+  (no raw API in the user-facing body).
+
+## 6b. Operator-surface quality (Operator-Surface Quality standard)
+
+No operator surface — not applicable. This change touches no dashboard renderer/markup
+file, no approval page, and no grant/revoke/secret-drop form. (The CLAUDE.md template
++ migrator edits are agent-awareness text, not an operator UI.)
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+
+**Machine-local BY DESIGN.** The resume queue is one-queue-per-machine: a
+single-writer lockfile (`state/resume-queue.lock`, pid + hostname + heartbeat), a
+host-local state dir, and a hard invariant that a foreign-host lock is refused (never
+probed/reclaimed). Pause/unpause state lives in that per-machine
+`state/resume-queue.json`. Both layers are pure additions to the per-machine drainer
+tick: Layer 1 routes through the existing per-machine `resume-queue:aggregate`
+attention item (no new cross-machine surface, no generated URL); Layer 2's `unpause()`
+mutates only the local queue and acts only on locally-queued entries. No timestamp
+crosses a machine boundary (`pausedAt`/`queuedAt` are always same-process-stamped). A
+topic transfer already closes the source session and the queue does not follow a moved
+topic, so there is no strand-on-transfer concern. Emits a user-facing notice (Layer 1)
+— it routes through the per-machine attention surface and is deduped per pause episode,
+so no one-voice violation; holds durable state (the per-machine pause record, which
+does not strand on transfer because the queue is machine-local); generates no URLs.
+
+## 8. Rollback cost
+
+- **Hot-fix release:** pure code change — revert the PR and ship as the next patch.
+- **Data migration:** none. No persisted entry/state schema field added. Existing
+  `state/resume-queue.json` files are read/written exactly as before (the new audit
+  events are append-only log rows).
+- **Agent state repair:** none. `monitoring.resumeQueue.autoResumeStalePause: false`
+  disables Layer 2 instantly (read live at tick time, no restart needed for the read —
+  though a config change requires a session/server restart to load). Reverting restores
+  the prior permanent-pause behavior exactly.
+- **User visibility:** no regression during a rollback window. The worst case after a
+  rollback is the return of the original bug (a stale pause can strand again) — but
+  Layer 1's alert and Layer 2's behavior are independent, and Layer 1 carries no
+  behavioral risk.
+
+## Migration parity
+
+- **Config defaults:** `staleEmergencyPauseAutoResumeMin` (60) and
+  `autoResumeStalePause` (true) are CODE-defaulted in `ResumeQueueDrainerConfig` /
+  `DEFAULT_RESUME_DRAINER_CONFIG` and threaded from `monitoring.resumeQueue.*` in
+  server.ts via `?? default` — deliberately NOT frozen into ConfigDefaults (preserving
+  the fleet flip, consistent with the other resumeQueue.* keys). **No `migrateConfig()`
+  change needed** — existing agents pick up the new behavior on update+restart with the
+  code defaults.
+- **CLAUDE.md template:** added a bullet to `generateClaudeMd()` (new agents via init)
+  AND a dedicated idempotent `PostUpdateMigrator` block sniffed on the unique phrase
+  `autoResumeStalePause` (existing agents, even those that already have the resume-queue
+  section — the parent block's `/sessions/resume-queue` sniff would otherwise skip
+  them). Both are content-sniffed and safe to run repeatedly.
+- **No hook/skill changes.**
+
+## Conclusion
+
+The review (6 spec-converge rounds with two real cross-model reviewers) hardened the
+change substantially: the topic-scoped emergency-stop premise went from asserted to
+code-cited; `pause()` gained a deliberate-halt upgrade so a later `stop-all` is honored
+over an in-flight emergency pause; the substring match was centralized and mechanically
+enforced by a callsite-scan test; Layer-1 dedupe became count-aware; clock/boundary
+discipline and the per-topic-guard dependency were made explicit and test-backed. The
+change is strictly additive to safety on a genuinely-stopped topic and removes a
+false-negative-on-revival for unrelated topics. All three test tiers are green (unit
+51, integration 9, e2e 8). Clear to ship.
+
+## Second-pass review (if required)
+
+**Reviewer:** cross-model external pass (codex-cli:gpt-5.5 + gemini-cli:gemini-2.5-pro), 6 rounds
+**Independent read of the artifact: concur**
+
+The external reviewers converged to MINOR ISSUES with no architectural objection; the
+final round (codex r6) produced zero new material findings. Every prior-round finding
+is resolved in the spec/code or recorded as an accepted tradeoff / Future item
+(`pauseKind` enum), with the lone fresh round-5 finding (pause-upgrade) implemented.
+
+## Evidence pointers
+
+- Spec: `docs/specs/resume-queue-stale-emergency-pause.md` (frontmatter
+  `review-convergence`, `cross-model-review: codex-cli:gpt-5.5`, `approved: true`).
+- Convergence report: `docs/specs/reports/resume-queue-stale-emergency-pause-convergence.md`.
+- Tests: `tests/unit/resume-queue-drainer.test.ts` (51), `tests/integration/resume-queue-routes.test.ts` (9), `tests/e2e/reap-notify-resume-queue-lifecycle.test.ts` (8).