instar 1.3.461 → 1.3.463

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.461",
+  "version": "1.3.463",
   "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:19:26.946Z",
-  "instarVersion": "1.3.461",
+  "generatedAt": "2026-06-10T04:04:50.737Z",
+  "instarVersion": "1.3.463",
   "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.462.md

@@ -0,0 +1,83 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Makes the SentinelNotifier's consolidated-escalation delivery **self-heal a deleted lifeline/system topic instead of silently swallowing the error**. Both `sendConsolidated` closures in `server.ts` (the sentinel-notify path and the stop-notify path) did `try { telegram.sendToTopic(lifelineTopicId, text) } catch { return false }`. When the lifeline/system topic is deleted on the Telegram side, every send returns `400: message thread not found`, and the bare `catch` black-holed it — so stall/stop escalations the system generated never reached the user, with zero log trace. New shared helper `sendConsolidatedWithSelfHeal` (`src/monitoring/sentinelConsolidatedSend.ts`): sends to the lifeline topic; on failure it (1) logs the real error (de-swallow) and (2) calls the adapter's existing `ensureLifelineTopic()` — which recreates a deleted topic and persists the new id — then retries the send once. Both call sites now use it. No behavior change on the happy path (a working topic sends and returns immediately, never touching `ensureLifelineTopic`).
+
+## What to Tell Your User
+
+If your "Lifeline"/system topic ever gets deleted, the alerts the system tries to send you there (a session went quiet, a session stopped) used to vanish without a trace — you'd just get silence. Now those alerts heal themselves: the system recreates the topic and delivers the alert, and any delivery failure is logged instead of disappearing. (This is the foundation under the broader "tell me when a session stalls, in that session's own topic, and auto-recover it" work.)
+
+## Summary of New Capabilities
+
+| Capability | How to Use |
+|-----------|-----------|
+| Sentinel/stop escalations self-heal a deleted lifeline topic + never swallow the send error | automatic — no config |
+
+## Evidence
+
+Reproduction (live, 2026-06-09): the configured lifeline topic (`lifelineTopicId: 2`, "Lifeline") had been deleted on Telegram. `logs/sentinel-events.jsonl` showed the active-silence sentinel correctly detecting stalled sessions and emitting `escalated` ("session went quiet ~16 min ago, want me to dig in?") — immediately followed by `notify-error: sendConsolidated returned false`, **41 times in one day**. A direct probe (`POST /telegram/reply/2`) returned exactly `400: Bad Request: message thread not found`, confirming the dead topic. The user received pure silence, so a stalled session was indistinguishable from a working one.
+
+After the fix: `tests/unit/sentinel-consolidated-send.test.ts` (7 cases) pins the happy path (no ensureLifelineTopic call), the dead-topic self-heal (recreate id 2→new, retry, deliver), the no-topic-configured path, and all three failure modes (ensure returns null / ensure throws / retry fails) — each returning false WITH a logged reason, never a silent swallow. tsc + repo lint clean. (The 15 unrelated A2ARedeliverySentinel / SessionActivitySentinel local failures are pre-existing on main, not introduced here.)
+
+## The problem
+
+The operator couldn't tell whether a session had stalled or was just working —
+because for almost an hour it heard nothing. Here's what was actually happening
+under the hood, and it's worse than "the agent didn't notice."
+
+The agent's stall-detector **did** notice. It saw a session go quiet, gave it a
+nudge, and tried to send the operator a message: "this session went quiet ~16
+minutes ago, want me to dig in?" That message goes to a dedicated "Lifeline"
+system topic in Telegram.
+
+But that Lifeline topic had been **deleted** on the Telegram side, while the
+config still pointed at it. So every send came back with `message thread not
+found` — and the code did `catch { return false }`, i.e. it threw the error in
+the trash and moved on. **41 times in one day** the system had something
+important to tell the operator and it silently failed to send. The operator got
+pure silence, which looks exactly like "nothing's wrong."
+
+So the real bug wasn't a missing alert — it was a generated alert dying on the
+way out the door, invisibly.
+
+## What already exists
+
+The Telegram adapter already has a method, `ensureLifelineTopic()`, that knows
+how to **recreate** a deleted Lifeline topic and remember the new one. The alert
+path just never called it — and worse, it hid the failure instead of reacting to
+it.
+
+## What's new
+
+One small, shared helper that both alert paths now use. When it tries to send an
+alert and the send fails, it:
+
+1. **Logs the real error** instead of swallowing it — so a delivery failure can
+   never again be invisible.
+2. **Heals the topic** — calls `ensureLifelineTopic()` to recreate the deleted
+   topic, then retries the send once.
+
+If the topic is fine, nothing changes — it sends and returns immediately. Only on
+a failure does the heal-and-retry kick in.
+
+## The safeguards in plain terms
+
+- **No silent failures, ever.** Every send failure is now logged with the real
+  reason, so the next time something can't be delivered, it's diagnosable in
+  seconds instead of invisible for hours.
+- **Self-healing, not just louder.** A deleted system topic now repairs itself
+  and the alert still gets through.
+- **Zero change on the happy path.** A working topic behaves exactly as before —
+  the heal logic only runs when a send actually fails.
+- **Bounded.** It retries once, never loops.
+
+## What you need to decide
+
+Nothing — it ships as a normal patch with safe behavior. This is the foundation
+under the bigger piece you asked for (stall alerts that land in the *stalled
+session's own topic*, and auto-recovering the session, not just alerting): step
+one was making sure these alerts can't silently disappear in the first place.

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/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/integrity-leg-shadow-import.md

@@ -0,0 +1,35 @@
+# Side-effects review — cutover integrity-pass wiring
+
+## The change
+
+Wires the previously-unwired integrity leg of the cutover-readiness door. New surface:
+- `POST /cutover-readiness/integrity-pass` (routes.ts) → `CutoverReadiness.runIntegrityPass()`.
+- `runIntegrityImport` dep + closure (AgentServer) spawns `integrityPassRunner` as a child `node` process.
+- `PersistedShadowImportTarget` — a durable JSONL-backed `ImportTarget`.
+- Extended route budget (middleware) + capability-index entry.
+
+## Blast radius — what this can and cannot touch
+
+- **It cannot mutate canonical data.** The import target is a throwaway on-disk shadow dir (`stateDir/state/cutover-integrity-shadow`), `dispose()`d after each pass. There is NO Portal/Prisma write path here. Read side is `GET /api/instar/read` only (read-only token).
+- **It cannot accidentally green the irreversible cutover door.** The door greens only when `recordIntegrityReport` is called with a passing report, which happens ONLY on an explicit `POST /cutover-readiness/integrity-pass`. Shipping/merging/deploying this route does nothing until that trigger fires. The cutover flip itself remains the operator's manual click — there is still no fire-cutover route.
+- **A failing pass is safe + honest.** A failing integrity report is recorded too (door reads closed) so the door reflects the LATEST real verdict, never a stale green. A pre-import abort (fingerprint collision → null report) records nothing and leaves prior state. A failed fetch records nothing (absence of evidence).
+
+## Concurrency + resource safety
+
+- Shares `CutoverReadiness`'s single-flight `liveFetchInFlight` guard with parity-pass + import-dryrun — only one live source fetch at a time (the #948 lock-pileup guard). A concurrent integrity-pass is refused 409.
+- The 145K-row fetch+import runs OFF the server event loop in a child process (the in-process import-dryrun budget-fails at 720s; #948). The child's internal fetch budget (600s) sits under `CutoverReadiness`'s 12-min max-hold backstop, which releases the lock if the child ever hangs; the child also carries an 11-min execFile wall-clock cap. Worst case is an orphaned child + a released lock, never a wedged server.
+- Memory: `--max-old-space-size=4096` on the child; the shadow is JSONL on disk, not held in RAM beyond the readback.
+
+## Failure modes considered
+
+- Child exits non-zero with a valid failing verdict on stdout → parsed + recorded (door flips closed), not treated as a crash. Only a no-verdict crash (exit 2 / killed) throws → 409, nothing recorded.
+- No paritySource configured → `runIntegrityImport` is null → 409 "no import source configured" (verified by the e2e feature-alive test on the real AgentServer init path).
+- Stale/torn integrity report on disk → `integrityStatus()` reads deny-safe (not passed).
+
+## Migration parity
+
+No agent-installed file changes (no settings/hooks/CLAUDE.md template/config-default changes), so no `PostUpdateMigrator` entry is required. The route ships in server code and reaches existing agents on their normal server update. The new capability-index entry surfaces it to agents (Agent Awareness Standard).
+
+## Tests
+
+Unit (PersistedShadowImportTarget + runIntegrityPass both-sides-of-boundary), integration (route greens-on-pass / flips-on-fail / 409-fetch-fail / 503-unavailable), e2e (route alive on real AgentServer init path). All green; tsc clean.