instar 1.3.462 → 1.3.464

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.462",
+  "version": "1.3.464",
   "description": "Coherence infrastructure for self-evolving AI agents — on the Claude Code or Codex subscription you already have.",
   "type": "module",
   "main": "dist/index.js",

package/src/data/builtin-manifest.json

@@ -1,8 +1,8 @@
 {
   "$schema": "./builtin-manifest.schema.json",
   "schemaVersion": 1,
-  "generatedAt": "2026-06-10T03:41:06.411Z",
-  "instarVersion": "1.3.462",
+  "generatedAt": "2026-06-10T05:50:26.360Z",
+  "instarVersion": "1.3.464",
   "entryCount": 199,
   "entries": {
     "hook:session-start": {
@@ -418,7 +418,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:agents": {
@@ -426,7 +426,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:backups": {
@@ -434,7 +434,7 @@
       "type": "route-group",
       "domain": "operations",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:git": {
@@ -442,7 +442,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:memory": {
@@ -450,7 +450,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:semantic": {
@@ -458,7 +458,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:status": {
@@ -466,7 +466,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:capabilities": {
@@ -474,7 +474,7 @@
       "type": "route-group",
       "domain": "mapping",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:project-map": {
@@ -482,7 +482,7 @@
       "type": "route-group",
       "domain": "mapping",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:coherence": {
@@ -490,7 +490,7 @@
       "type": "route-group",
       "domain": "coherence",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:topic-bindings": {
@@ -498,7 +498,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:context": {
@@ -506,7 +506,7 @@
       "type": "route-group",
       "domain": "context",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:scope-coherence": {
@@ -514,7 +514,7 @@
       "type": "route-group",
       "domain": "coherence",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:canonical-state": {
@@ -522,7 +522,7 @@
       "type": "route-group",
       "domain": "state",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:ci": {
@@ -530,7 +530,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:sessions": {
@@ -538,7 +538,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:jobs": {
@@ -546,7 +546,7 @@
       "type": "route-group",
       "domain": "scheduling",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:skip-ledger": {
@@ -554,7 +554,7 @@
       "type": "route-group",
       "domain": "scheduling",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:telegram": {
@@ -562,7 +562,7 @@
       "type": "route-group",
       "domain": "communication",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:attention": {
@@ -570,7 +570,7 @@
       "type": "route-group",
       "domain": "communication",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:relationships": {
@@ -578,7 +578,7 @@
       "type": "route-group",
       "domain": "relationships",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:feedback": {
@@ -586,7 +586,7 @@
       "type": "route-group",
       "domain": "feedback",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:updates": {
@@ -594,7 +594,7 @@
       "type": "route-group",
       "domain": "updates",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:dispatches": {
@@ -602,7 +602,7 @@
       "type": "route-group",
       "domain": "dispatches",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:quota": {
@@ -610,7 +610,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:publishing": {
@@ -618,7 +618,7 @@
       "type": "route-group",
       "domain": "publishing",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:private-views": {
@@ -626,7 +626,7 @@
       "type": "route-group",
       "domain": "publishing",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:tunnel": {
@@ -634,7 +634,7 @@
       "type": "route-group",
       "domain": "networking",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:events": {
@@ -642,7 +642,7 @@
       "type": "route-group",
       "domain": "networking",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:evolution": {
@@ -650,7 +650,7 @@
       "type": "route-group",
       "domain": "evolution",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:watchdog": {
@@ -658,7 +658,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:topic-memory": {
@@ -666,7 +666,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:state-sync": {
@@ -674,7 +674,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:intent": {
@@ -682,7 +682,7 @@
       "type": "route-group",
       "domain": "intent",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:triage": {
@@ -690,7 +690,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:operations": {
@@ -698,7 +698,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:sentinel": {
@@ -706,7 +706,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:trust": {
@@ -714,7 +714,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:monitoring": {
@@ -722,7 +722,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:commitments": {
@@ -730,7 +730,7 @@
       "type": "route-group",
       "domain": "commitments",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:episodes": {
@@ -738,7 +738,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:messages": {
@@ -746,7 +746,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:system-reviews": {
@@ -754,7 +754,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "route-group:machine-mesh": {
@@ -770,7 +770,7 @@
       "type": "route-group",
       "domain": "security",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "1ed553bfb7805aff766d3d95e6e8f65778d535f804d86ba5b6b7916bc36f9068",
+      "contentHash": "f8368ea548abfd012ba860cd6c3de18b278029e88667be225795cf53e321d741",
       "since": "2025-01-01"
     },
     "cli:init": {
@@ -1506,7 +1506,7 @@
       "type": "subsystem",
       "domain": "server",
       "sourcePath": "src/server/AgentServer.ts",
-      "contentHash": "14cae0304a5a9d275cb282874387888f253a9253bec2e029c56c837ef294a3e4",
+      "contentHash": "c649846feae2eaef0c33a8ca902817fc84ff200eb306bbf4b2c37e26b8f91747",
       "since": "2025-01-01"
     },
     "subsystem:session-manager": {

package/upgrades/1.3.463.md

@@ -0,0 +1,27 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+The feedback-migration **cutover-readiness door** can now resolve its **integrity** leg. A new trigger — `POST /cutover-readiness/integrity-pass` — runs the REAL pre-click integrity pass and records the verdict to the canonical integrity path.
+
+Previously the door's formula (`ready = integrity.passed && parity.cleared && !parity.stale`) was unsatisfiable: the parity leg worked (#1007), but `recordIntegrityReport` had **zero callers** — nothing ever ran a real import and wrote the report, so `integrity.passed` could never become true and the door could never open. The import-dryrun route is deliberately walled off from the integrity path (its report can never green the gate), so it couldn't fill the gap either.
+
+The new pass: live read-only fetch → AS-IS import into a **persisted shadow** (`PersistedShadowImportTarget`, a throwaway JSONL copy — never canonical) → the full integrity gate over the readback → `recordIntegrityReport`. A passing report greens the leg; a failing one flips it closed (the door always reflects the latest real verdict). The heavy 145K-row pass runs OFF the event loop in a child process (`integrityPassRunner`) — the same event-loop-contention lesson that drove the parity fix (#948) — sharing `CutoverReadiness`'s single-flight guard and max-hold backstop.
+
+## What to Tell Your User
+
+Internal migration infrastructure — nothing to configure. This wires the last piece needed for the cutover-readiness door to go fully green ahead of the operator-gated cutover click. Building or deploying it does NOT green the door — that requires explicitly running the integrity pass, and the cutover flip itself remains the operator's manual click.
+
+## Summary of New Capabilities
+
+| Capability | How to use |
+|-----------|-----------|
+| Run the REAL pre-click integrity pass + record the canonical verdict | `POST /cutover-readiness/integrity-pass` (Bearer-gated; 409 when no `feedbackMigration.paritySource` is configured) |
+| Durable AS-IS import shadow for verification | `new PersistedShadowImportTarget(dir)` — JSONL-backed, dup-PK refusing, `dispose()`-able; never canonical |
+
+## Evidence
+
+Unit `tests/unit/cutover-readiness.test.ts` (28, incl. 7 new `runIntegrityPass`: greens-on-pass → door ready with parity / flips-closed-on-fail / no-record-on-abort / no-record-on-fetch-fail / unconfigured-refuse / single-flight-guard) + `tests/unit/feedback-factory/persisted-shadow-import-target.test.ts` (5 new). Integration `tests/integration/cutover-readiness-routes.test.ts` (14, incl. 4 new integrity-pass route). E2E `tests/e2e/cutover-readiness-lifecycle.test.ts` (5, incl. 1 new feature-alive on the real AgentServer init path). All green; `tsc --noEmit` clean. The integrity substance was independently proven over the live 145K-row corpus (0 issues). Earned from topic 12476 (feedback-process migration, Phase-2 / cutover-readiness integrity leg).

package/upgrades/1.3.464.md

@@ -0,0 +1,72 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Extends the **ActiveWorkSilenceSentinel** (the watchdog that notices when a
+session was working then went quiet) with two things:
+
+1. **Notices now go to the stalled session's OWN topic** — not the consolidated
+   lifeline feed. Previously a "this went quiet, want me to dig in?" escalation
+   landed in the shared system topic, where it was easy to miss and gave no
+   signal about *which* conversation stalled. Now it posts in that conversation's
+   own Telegram topic, falling back to the consolidated feed only if the topic
+   can't be resolved or delivery fails. (Operator ask, 2026-06-09.)
+
+2. **An opt-in auto-heal ladder** (`autoRecover`, DARK / off by default): when a
+   confirmed-silent session doesn't respond to the gentle nudge, instead of only
+   asking the operator, the sentinel can **respawn it fresh** (conversation
+   preserved via `--resume`) and report the outcome in that session's topic. The
+   respawn is loop-capped (`maxAutoRecoveries`, default 1): a session that stays
+   stuck after one respawn is asked-about once and then left alone — never
+   re-respawned in a loop. A failed respawn falls back to the old "ask the
+   operator" behavior.
+
+The respawn reuses the exact `refreshSession({fresh:true})` primitive the
+ContextWedgeSentinel already uses in production, so it is framework-agnostic and
+well-exercised.
+
+## What to Tell Your User
+
+When one of my work sessions goes quiet mid-task, two things are better now.
+First, the heads-up about it lands **in that conversation's own topic** instead
+of a shared system channel — so you can see exactly which thread stalled. Second,
+there's a new opt-in mode (⚗️ experimental, off by default) where I don't just
+tell you a session is stuck — I **automatically restart it** (keeping the
+conversation) and report back, only falling back to asking you if the restart
+itself doesn't work. It can only auto-restart a given stuck session once, so it
+can never get into a restart loop. It's off by default — just ask me to turn on
+auto-recovery for stalled sessions and I'll enable it for you.
+
+## Summary of New Capabilities
+
+| Capability | How to Use |
+|-----------|-----------|
+| Silence/recovery notices route to the stalled session's own topic | automatic — no config |
+| Opt-in auto-heal: respawn a confirmed-stuck session instead of only asking (⚗️ experimental, off by default) | `monitoring.activeWorkSilenceSentinel.autoRecover: true` |
+| Loop-cap on auto-respawn | `monitoring.activeWorkSilenceSentinel.maxAutoRecoveries` (default 1) |
+
+## Evidence
+
+Reproduction (live, 2026-06-09): a session that kicked off a long change went
+quiet for ~1 hour. The sentinel correctly detected the silence and escalated,
+but the escalation went to the consolidated lifeline topic — which had been
+deleted on the Telegram side — so the operator saw pure silence and couldn't
+tell a stalled session from a working one. The fix has two halves: the
+deleted-topic self-heal (shipped separately) and this change, which routes the
+notice to the session's own topic and (opt-in) recovers the session instead of
+only asking.
+
+After the change:
+- `tests/unit/monitoring/ActiveWorkSilenceSentinel.test.ts` — 6 new cases pin the
+  ladder: autoRecover OFF → ask, never respawn; ON + respawn succeeds → one
+  respawn, recovery notices, state cleared; ON + respawn fails → recovery-failed,
+  ask, state kept (loop-stopper); loop-cap → respawned at most once across
+  repeated ticks; recoverFn throws → recover-error surfaced + ask.
+- `tests/unit/monitoring/sentinelWiring.test.ts` — 5 new cases pin notice
+  routing (session topic on resolve; escalate fallback when unresolved or when
+  delivery fails) and recoverFn passthrough (present vs undefined-when-dark).
+- Existing silently-stopped unit/integration/e2e suites stay green. `tsc` +
+  repo lint clean.

package/upgrades/eli16/integrity-leg-shadow-import.md

@@ -0,0 +1,27 @@
+# ELI16 — Wire the cutover door's integrity check so it can actually go green
+
+## What this is
+
+The feedback-process migration (Dawn → Echo) ends with one irreversible step: an operator clicks "cut over," and from then on the new instance is canonical. To make that click safe, there's a **readiness door** that only reads green when two things are true: the live data still matches (parity), AND a real import of the curated data passes every integrity check (no corrupted clusters, no broken links, no schema surprises).
+
+The door's formula is literally `ready = integrity.passed && parity.cleared && !parity.stale`.
+
+## What already existed
+
+- The **parity** half works (verified live — a clusters-only pass clears in ~1s).
+- The integrity gate's *math* existed (`runIntegrityGate` — checksums, fingerprint-uniqueness, schema-equivalence, referential integrity) and was already proven clean over the live 145K-row corpus.
+- BUT the function that records a passing integrity report — `recordIntegrityReport` — had **zero callers**. Nothing in the running server ever ran a real import and wrote that report. So the integrity half could never turn green, which meant the door could never open. The migration was stuck one wire short of the finish line.
+
+## What's new
+
+A single new trigger: **`POST /cutover-readiness/integrity-pass`**. When called, it:
+1. Fetches the live curated corpus (read-only).
+2. Imports it AS-IS into a **persisted shadow** (a throwaway on-disk copy — never the canonical database).
+3. Runs the full integrity gate over what landed.
+4. Records the verdict to the canonical integrity path — a **passing** report turns the integrity leg green; a **failing** one keeps it shut (the door always reflects the latest real check).
+
+Because importing 145K rows would freeze the server's event loop, the heavy work runs in a **separate child process** (the same lesson that drove the parity fix). The shadow is a verification copy only — the real production import still happens *after* the operator clicks, on Dawn's side.
+
+## What you need to decide
+
+Nothing changes automatically. Building or merging this **cannot** make the door go green — that only happens when someone explicitly triggers the pass on the deployed server. The cutover click itself stays entirely the operator's. This change just makes "is everything up to the door green?" answerable from real evidence instead of an un-runnable gap.

package/upgrades/side-effects/autoheal-silence-ladder.md

@@ -0,0 +1,98 @@
+# Side-effects review — Auto-heal ladder (ActiveWorkSilenceSentinel)
+
+## Scope of change
+
+Extends the existing `ActiveWorkSilenceSentinel` (silent-freeze watchdog) with a
+dark-by-default auto-recovery ladder and routes its notices to the stalled
+session's own topic. Touched src files:
+
+- `src/monitoring/ActiveWorkSilenceSentinel.ts` — `SilenceStatus` gains
+  `recovering` / `recovery-failed`; `SilenceState.recoveryAttempts`; deps gain
+  optional `recoverFn`; config gains `autoRecover` (default false) +
+  `maxAutoRecoveries` (default 1); `escalate()` now branches to `runRecovery()`
+  when `autoRecover && recoverFn && recoveryAttempts < maxAutoRecoveries`; new
+  `runRecovery()` ladder (notify → respawn → notify outcome; emits
+  `recovering`/`recovered`/`recovery-failed`/`recover-error`).
+- `src/monitoring/sentinelWiring.ts` — `buildActiveWorkSilenceDeps` gains
+  optional `recoverFn`, `getTopicForSession`, `deliverToTopic`; `notifyFn` now
+  routes to the session's own topic, falling back to the consolidated `escalate`
+  path when the topic can't be resolved OR delivery returns false.
+- `src/commands/server.ts` — wires `recoverFn` (gated on `autoRecover`, via the
+  same `_sessionRefresh.refreshSession({fresh:true})` primitive ContextWedge
+  uses), `getTopicForSession` (telegram), `deliverToTopic` (POST
+  `/telegram/reply/:topicId`), and the new ladder event recorders.
+- `src/core/types.ts` — config type fields `autoRecover` + `maxAutoRecoveries`.
+- `src/config/ConfigDefaults.ts` — comment-only; `autoRecover` deliberately NOT
+  persisted (see Migration Parity below).
+- `src/monitoring/SentinelNotifier.ts` — adds `recovering` to `SentinelEventKind`
+  for the audit trail.
+
+## Blast radius
+
+The only behavioral path that DESTROYS state is `recoverFn` → fresh respawn.
+It is reachable ONLY when `monitoring.activeWorkSilenceSentinel.autoRecover ===
+true` (off by default) AND a session is confirmed silent past the threshold AND
+a nudge failed to advance output. The respawn uses `fresh:true`, preserving the
+conversation via `--resume` (same semantics ContextWedge already relies on in
+production). When `autoRecover` is off, the only behavior change from before is
+the notice ROUTING (see below) — no respawn ever occurs.
+
+## Notice-routing behavior change (applies even when autoRecover is OFF)
+
+Previously every silence escalation went through `notifier.escalate` →
+consolidated lifeline feed. Now `notifyFn` first tries the stalled session's own
+topic (`getTopicForSession` → `deliverToTopic`), and falls back to `escalate`
+only when the topic is unresolved or delivery fails. This is the operator's
+explicit ask ("messages should only go to the topic that's stalled").
+
+- **Tradeoff (flagged for the promotion review):** the per-session route posts
+  via `/telegram/reply/:topicId`, which does NOT pass through the consolidated
+  tone-gate / attention-topic anti-flood budget the `escalate` path uses. For a
+  fixed-template, low-frequency sentinel notice this is acceptable, and the
+  volume is intrinsically bounded (one detect + at most one recovery per stuck
+  session, and a stuck session is rare). The fallback path is still the
+  anti-flood-guarded `escalate`. If auto-heal is ever promoted to fire at higher
+  volume, revisit whether the per-session route needs its own rate cap.
+
+## Loop / runaway analysis
+
+- `maxAutoRecoveries` (default 1) caps respawns per session. The cap is enforced
+  twice: the `escalate()` guard (`recoveryAttempts < maxAutoRecoveries`) and the
+  fact that a failed recovery sets status `recovery-failed` WITHOUT clearing
+  state — so `tick()`'s `if (existing) continue` (already-tracked skip) prevents
+  re-detection. A session that stays stuck after one respawn is asked-about once
+  and then left alone, never re-respawned. Unit-tested explicitly
+  ("loop cap: respawned at most once").
+- A SUCCESSFUL recovery clears state so the freshly-respawned session is
+  monitored anew; the respawn resets its output clock so it won't immediately
+  re-trigger.
+
+## Framework generality
+
+`recoverFn` delegates to `_sessionRefresh.refreshSession`, which respawns
+whatever framework the session runs (claude-code / codex / others) — it does not
+assume Claude. No framework-specific branching is introduced. The notice text is
+plain-English and framework-neutral.
+
+## Migration parity
+
+No agent-installed file changes (no `.claude/settings.json` hooks, no hook
+scripts, no CLAUDE.md template section, no persisted config default). `autoRecover`
+is intentionally OMITTED from `ConfigDefaults` (mirroring
+`contextWedgeSentinel.autoRecovery`): `applyDefaults()` is add-missing-only, so
+persisting `false` now would freeze it and block a future default-on flip from
+reaching existing agents. The dark default lives as the runtime check in
+server.ts. New and existing agents get identical (off) behavior. Promotion to
+default-on = flip the runtime check + add the persisted default (documented in
+the ConfigDefaults comment).
+
+## Test coverage
+
+- `tests/unit/monitoring/ActiveWorkSilenceSentinel.test.ts` (+6): autoRecover
+  off → ask (no respawn); on + success → respawn once, notify, clear; on +
+  failure → recovery-failed, ask, keep state; loop-cap → at most one respawn;
+  recoverFn throws → recover-error + ask.
+- `tests/unit/monitoring/sentinelWiring.test.ts` (+5): notifyFn routes to the
+  session topic; falls back to escalate when topic unresolved; falls back when
+  delivery fails; recoverFn passthrough present-vs-undefined.
+- Existing unit/integration/e2e silently-stopped suites stay green.