instar 1.3.259 → 1.3.261

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.259",
+  "version": "1.3.261",
   "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-05T00:47:15.893Z",
-  "instarVersion": "1.3.259",
+  "generatedAt": "2026-06-05T01:20:58.426Z",
+  "instarVersion": "1.3.261",
   "entryCount": 198,
   "entries": {
     "hook:session-start": {
@@ -418,7 +418,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:agents": {
@@ -426,7 +426,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:backups": {
@@ -434,7 +434,7 @@
       "type": "route-group",
       "domain": "operations",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:git": {
@@ -442,7 +442,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:memory": {
@@ -450,7 +450,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:semantic": {
@@ -458,7 +458,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:status": {
@@ -466,7 +466,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:capabilities": {
@@ -474,7 +474,7 @@
       "type": "route-group",
       "domain": "mapping",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:project-map": {
@@ -482,7 +482,7 @@
       "type": "route-group",
       "domain": "mapping",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:coherence": {
@@ -490,7 +490,7 @@
       "type": "route-group",
       "domain": "coherence",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:topic-bindings": {
@@ -498,7 +498,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:context": {
@@ -506,7 +506,7 @@
       "type": "route-group",
       "domain": "context",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:scope-coherence": {
@@ -514,7 +514,7 @@
       "type": "route-group",
       "domain": "coherence",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:canonical-state": {
@@ -522,7 +522,7 @@
       "type": "route-group",
       "domain": "state",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:ci": {
@@ -530,7 +530,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:sessions": {
@@ -538,7 +538,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:jobs": {
@@ -546,7 +546,7 @@
       "type": "route-group",
       "domain": "scheduling",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:skip-ledger": {
@@ -554,7 +554,7 @@
       "type": "route-group",
       "domain": "scheduling",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:telegram": {
@@ -562,7 +562,7 @@
       "type": "route-group",
       "domain": "communication",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:attention": {
@@ -570,7 +570,7 @@
       "type": "route-group",
       "domain": "communication",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:relationships": {
@@ -578,7 +578,7 @@
       "type": "route-group",
       "domain": "relationships",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:feedback": {
@@ -586,7 +586,7 @@
       "type": "route-group",
       "domain": "feedback",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:updates": {
@@ -594,7 +594,7 @@
       "type": "route-group",
       "domain": "updates",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:dispatches": {
@@ -602,7 +602,7 @@
       "type": "route-group",
       "domain": "dispatches",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:quota": {
@@ -610,7 +610,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:publishing": {
@@ -618,7 +618,7 @@
       "type": "route-group",
       "domain": "publishing",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:private-views": {
@@ -626,7 +626,7 @@
       "type": "route-group",
       "domain": "publishing",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:tunnel": {
@@ -634,7 +634,7 @@
       "type": "route-group",
       "domain": "networking",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:events": {
@@ -642,7 +642,7 @@
       "type": "route-group",
       "domain": "networking",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:evolution": {
@@ -650,7 +650,7 @@
       "type": "route-group",
       "domain": "evolution",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:watchdog": {
@@ -658,7 +658,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:topic-memory": {
@@ -666,7 +666,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:state-sync": {
@@ -674,7 +674,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:intent": {
@@ -682,7 +682,7 @@
       "type": "route-group",
       "domain": "intent",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:triage": {
@@ -690,7 +690,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:operations": {
@@ -698,7 +698,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:sentinel": {
@@ -706,7 +706,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:trust": {
@@ -714,7 +714,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:monitoring": {
@@ -722,7 +722,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:commitments": {
@@ -730,7 +730,7 @@
       "type": "route-group",
       "domain": "commitments",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:episodes": {
@@ -738,7 +738,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:messages": {
@@ -746,7 +746,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:system-reviews": {
@@ -754,7 +754,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "route-group:machine-mesh": {
@@ -770,7 +770,7 @@
       "type": "route-group",
       "domain": "security",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "a4d156e36b2b832f6a7d6abf612472e7f1fcf67f8ea73fc6a84599ee4232eaef",
+      "contentHash": "d2718318046b6de40e16b114e4dc579ca5518ff687f2c1999ed1bc07fc1c816c",
       "since": "2025-01-01"
     },
     "cli:init": {

package/src/scaffold/templates.ts

@@ -419,6 +419,8 @@ This routes feedback to the Instar maintainers automatically. Valid types: \`bug
 - Also: when a session is autonomously shut down, you get a "your session was shut down — <reason>" notice (recovery-bounces and your own operator kills stay silent). Turn the notice off with \`{"monitoring": {"reapNotify": {"enabled": false}}}\`.
 - 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.
 
+**🩺 Agent Health lane (calm self-health notices)** — Routine notices about MY OWN internal state (a session that looks stuck, a peer I can't reach) land in ONE calm, named "🩺 Agent Health" Telegram topic — never topic-after-topic. Each is normal-priority (not a user-critical alert), names the topic in plain language (e.g. "the 'EXO 3.0' session", never \`topic-19077\`), ends with a next step you can just reply to, and same-session re-escalations are de-duped so the lane stays quiet. Ships **default-on, no config** (it's a delivery-shaper in code — it never gates or drops anything; every notice is still in the attention store). Tune via \`messaging[].config.agentHealthLane\` = \`{ "enabled": true, "topicName": "🩺 Agent Health", "dedupWindowMs": 1800000 }\` (set \`enabled:false\` for the old per-item-topic behavior). Proactive: user asks "what's this Agent Health topic?" / "why are my stale-session notices grouped?" → explain the calm lane (the StaleSessionBackstop now routes its "looks stuck" heads-up here at normal priority instead of spawning a topic each time).
+
 **Applying config & hook changes to running sessions** — A running session keeps the config it was *spawned* with. Claude Code loads \`.claude/settings.json\` (hooks, model) **once, at session start** — so a config change (default model, a disabled feature) or a newly-added hook does NOT reach an already-running session. It only takes effect on the next session, OR when you restart the existing one. (This is why a UserPromptSubmit hook added mid-session never fires for that live session — the session was launched before the hook existed.)
 - Restart ONE session (preserves the conversation via \`claude --resume\`): \`curl -X POST -H "Authorization: Bearer $AUTH" http://localhost:${port}/sessions/refresh -H 'Content-Type: application/json' -d '{"sessionName":"<tmux-name>","reason":"config change"}'\`
 - Restart EVERY running Telegram-bound session in one call (staggered, each conversation preserved): \`curl -X POST -H "Authorization: Bearer $AUTH" http://localhost:${port}/sessions/restart-all -H 'Content-Type: application/json' -d '{"reason":"applied new default model"}'\` → \`{ scheduled: [...], count, skipped }\`. Pass \`{"excludeSession":"<tmux-name>"}\` to keep the calling session alive. Non-Telegram-bound (Slack/iMessage/headless) sessions are skipped.

package/upgrades/1.3.260.md

@@ -0,0 +1,72 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: minor -->
+
+## What Changed
+
+Added a CI gate (`.github/workflows/eli16-pr-gate.yml` + the pure check
+`scripts/eli16-pr-description-check.mjs`) that requires every PR's DESCRIPTION to carry a
+plain-English ELI16 overview, and FAILS the PR when it is missing. Per Justin's standard
+(2026-06-05): the PR description is what a reviewer reads and approves on the link, and the PRs "had
+different formats." The ELI16 *file* (docs/specs/<slug>.eli16.md) is unchanged and still enforced at
+commit time; this closes the PR-body half. Re-runs on `edited` (self-clears on a description fix);
+exempts bot authors + the automated release-cut PR.
+
+Self-health notices now land in ONE calm "🩺 Agent Health" topic instead of spawning
+a new Telegram topic per event. Previously the StaleSessionBackstop raised a HIGH
+"Session topic-N is stale but unkillable" attention item every stall episode, and
+because HIGH bypasses the topic-flood guard, each spawned its own forum topic — a wall
+of cryptic, unnamed, non-actionable threads (one agent had 54 of 116 topics that were
+this kind of auto-generated noise).
+
+The fix is a delivery-shaper in the messaging layer: an attention item may now opt into
+`lane:'agent-health'`. Lane items route into a single, persistently-named lane topic
+from the very first item, never spawn their own topic (even if mis-tagged HIGH), and
+same-session re-escalations are suppression-deduped within a window. The StaleSessionBackstop
+now emits into that lane at NORMAL priority with a topic-name-resolved, reply-able
+message ("Heads-up on the 'EXO 3.0' session … reply 'check EXO 3.0' …" instead of
+"Session topic-19077 is stale but unkillable"). Nothing is gated or dropped — every
+notice is still in the attention store.
+
+## What to Tell Your User
+
+Your agent's routine self-health heads-ups — like "a session looks stuck" — now collect
+in one calm, named "Agent Health" topic instead of creating a fresh topic every time.
+Each one names the session in plain language, ends with a next step you can just reply
+to, and repeats are bundled so the topic stays quiet. It is on by default and never
+blocks anything. If you'd rather have the old one-topic-per-notice behavior, you can turn
+the lane off in your config.
+
+## Summary of New Capabilities
+
+- A calm "🩺 Agent Health" lane: self-health attention items (opt-in via the lane field)
+  route into one named topic, never topic-after-topic.
+- Suppression-dedup: the same session re-escalating within the dedup window is recorded
+  but not re-posted, so the lane stays quiet.
+- Named, actionable notices: the StaleSessionBackstop heads-up resolves the human topic
+  name and ends with a reply-able next step, at NORMAL priority.
+- Tunable via messaging config (enabled / topicName / maxTrackedKeys / dedupWindowMs);
+  default-on, set enabled to false for the prior behavior.
+
+## Evidence
+
+- The decision is a PURE function (`checkPrDescriptionEli16`) with 10 unit tests covering both
+  sides (has-overview → pass; missing / too-short / next-heading-boundary / comment-stripped → fail)
+  and every exemption (bot, release-cut, title-mentions-release non-exemption, null inputs).
+- `node --check scripts/eli16-pr-description-check.mjs` clean. New additive workflow — cannot affect
+  existing checks/builds/releases; a failing PR is visible + self-clears on a description edit.
+- This PR's own description carries an ELI16 overview (dogfoods the gate). scripts + workflow + test
+  only, no `src/` (internal-only lane).
+
+- Unit (tests/unit/stale-session-backstop.test.ts): the escalation is lane-routed,
+  NORMAL, keyed per-session, names the topic (never topic-N), and carries a reply CTA.
+- Integration (tests/integration/agent-health-lane.test.ts): a real TelegramAdapter
+  routes N self-health notices into exactly ONE lane topic, sends HIGH ones to the lane
+  too, suppression-dedups same-key re-escalations (intro + one line, rest audited), and
+  leaves non-lane items untouched.
+- E2E (tests/e2e/agent-health-lane-route.test.ts): over real HTTP, POST /attention
+  carries lane+healthKey through and lane items bypass the per-topic tone-gate (still
+  delivered even when the gate would block), while non-lane items still run the gate.
+- 95 related tests green (incl. the flood-guard + tone-gate suites); tsc clean;
+  pre-push-gate clean.

package/upgrades/1.3.261.md

@@ -0,0 +1,45 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: minor -->
+
+## What Changed
+
+The stale-session watchdog no longer cries wolf on healthy long-running sessions. Two
+detection-accuracy fixes in StaleSessionBackstop:
+
+1. Operator-protected sessions (the reaper's protectedSessions) are never flagged as
+   stale — they're deliberately kept alive, so escalating them was a false alarm.
+2. Conversational/autonomous sessions get a far more forgiving no-progress window
+   (conversationalEscalateMinutes, default 180 min) than run-to-completion jobs (which
+   keep the strict 30-min window). A long autonomous session that legitimately idles
+   between turns or waits on a multi-minute tool call no longer trips the 30-minute
+   "looks stuck" threshold.
+
+This is the detection half of the Notification UX Coherence work; PR1 shipped the calm
+"🩺 Agent Health" lane (the delivery half). The fake-work guards (transcript tail-hash +
+cpu-seconds delta) are unchanged — genuine wedges are still caught; the backstop is still
+signal-only and never auto-kills.
+
+## What to Tell Your User
+
+Your agent will stop pinging you that a long-running session "looks stuck" when it's
+actually just working through a slow step or waiting between turns. Sessions you've
+marked as protected are never flagged at all, and ordinary long conversations get a much
+more patient window before the agent mentions anything. Genuinely-stuck work is still
+caught — just without the false alarms.
+
+## Summary of New Capabilities
+
+- StaleSessionBackstop exempts operator-protected sessions from stale escalation.
+- New monitoring.staleBackstop.conversationalEscalateMinutes (default 180): a forgiving
+  no-progress window for conversational/autonomous sessions, separate from the strict job
+  window (unverifiableEscalateMinutes, 30). Clamped to never be more aggressive than the
+  job window.
+
+## Evidence
+
+- Unit (tests/unit/stale-session-backstop.test.ts): a protected session is never
+  escalated even well past the window; the threshold split — a healthy long conversational
+  session at 35 min does NOT escalate while a wedged job at 35 min DOES.
+- 82 standards + backstop tests green; tsc clean; pre-push-gate clean.

package/upgrades/side-effects/notification-ux-coherence.md

@@ -0,0 +1,59 @@
+# Side-Effects Review — Notification UX Coherence (PR1: the calm Agent-Health lane)
+
+## What changed (mechanically)
+
+A new opt-in routing lane in the messaging layer. An attention item may now carry
+`lane:'agent-health'` (+ optional `healthKey`). When set, `createAttentionItem`
+routes it into ONE persistently-named "🩺 Agent Health" forum topic BEFORE (and
+bypassing) the topic-flood guard, suppression-dedups same-`healthKey` re-escalations
+within a window, and never spawns a per-item topic. `StaleSessionBackstop` now emits
+its "looks stuck" escalation into that lane at `NORMAL` (was `HIGH`), with a
+topic-name-resolved, next-step-bearing, reply-able message. The `/attention` route
+carries `lane`/`healthKey` through and lets lane items skip the per-topic outbound
+tone-gate.
+
+## Blast radius / who is affected
+
+- **Items WITHOUT `lane`**: byte-for-byte unchanged — same guard, same topics, same
+  tone-gate. The only caller that sets the lane today is `StaleSessionBackstop`.
+- **The flood guard**: untouched logic; lane items simply never reach it.
+- **The tone-gate**: still runs for every non-lane item; lane items bypass it because
+  they don't spawn a per-item topic and are named+CTA-bearing by construction.
+
+## Failure modes considered
+
+- **Telegram unavailable**: `routeToAgentHealthLane` returns null on topic-create
+  failure; the item is still recorded in the attention store (never dropped). Best-
+  effort send is `@silent-fallback-ok` (a transient send failure must not crash the
+  attention path) — consistent with the existing flood-notice path.
+- **Lane topic deleted out from under us**: the cached `agentHealthTopicId` is cleared
+  on send failure so it's recreated next time (same pattern as `floodNoticeByBucket`).
+- **Concurrent first-escalations**: a single in-flight creation promise
+  (`agentHealthPending`) prevents a double-create race (covered by integration test).
+- **Unbounded memory**: the dedup ring is hard-capped at `maxTrackedKeys` (default 256),
+  oldest-evicted.
+- **A genuinely-stuck session now NORMAL not HIGH**: it still surfaces (in the calm lane
+  + the attention store + the dashboard); it is no longer a per-topic interrupt. The
+  global "tmux control plane unreachable" item stays HIGH. PR2 will reduce the
+  false-positive RATE; PR1 only changes delivery.
+
+## What this does NOT do (explicit non-goals)
+
+- Does NOT gate, block, drop, delay, or rewrite any message — pure delivery-shaper.
+- Does NOT change the StaleSessionBackstop's detection logic (PR2).
+- Does NOT touch the "went quiet" / "can't reach…routing" SentinelNotifier paths
+  (tracked as fast-follow; they were the older floods).
+
+## Reversibility
+
+`messaging[].config.agentHealthLane.enabled:false` restores the prior per-item-topic
+behavior for self-health items. No schema migration, no data migration, no on-disk
+format change. Additive type fields only.
+
+## Tests
+
+Unit (StaleSessionBackstop: lane/healthKey/NORMAL/named-title/next-step + name
+resolution), integration (real TelegramAdapter: N notices → 1 topic, HIGH→lane,
+suppression-dedup + audit, non-lane unaffected), E2E (HTTP /attention: lane+healthKey
+passthrough, tone-gate bypass for lane, no regression for non-lane). 95 related tests
+green; tsc clean.

package/upgrades/side-effects/stalebackstop-accuracy.md

@@ -0,0 +1,52 @@
+# Side-Effects Review — StaleBackstop detection accuracy (PR2 / D5)
+
+## What changed (mechanically)
+
+`StaleSessionBackstop` no longer cries wolf on healthy long-running sessions:
+1. **Protected sessions are never escalated.** New `isProtectedSession?(session)` dep
+   (wired in server.ts to the reaper's `getProtectedSessions()`, matched by tmux name
+   or session name). A protected session — one the operator deliberately keeps alive —
+   skips BOTH escalation paths (no-progress and long-indeterminate).
+2. **Conversational/autonomous sessions get a forgiving window.** New
+   `conversationalEscalateMinutes` option (default 180, clamped to ≥ the job window).
+   The no-progress threshold is now `session.jobSlug ? unverifiableEscalateMinutes (30)
+   : max(conversationalEscalateMinutes, unverifiableEscalateMinutes)`. A job runs to
+   completion (strict 30-min window); a conversational/autonomous session legitimately
+   idles between turns and while waiting on multi-minute tool calls, so it gets 180.
+
+## Blast radius
+
+- The fake-work guards (`hasForwardProgress`: tail-hash + cpu-seconds delta) are
+  UNTOUCHED — wedge detection is unchanged; this only widens the no-progress WINDOW for
+  conversational sessions and exempts protected ones.
+- A genuinely-wedged JOB still escalates at 30 min (unchanged).
+- A genuinely-wedged conversational session still escalates — just at 180 min, not 30.
+  Combined with PR1's calm lane, even that is a single calm heads-up, not topic-spam.
+- Config additive + defaulted; absent config → defaults apply (180 / protected-from-reaper).
+
+## Failure modes considered
+
+- **conversationalEscalateMinutes mis-set below the job window**: clamped up via
+  `max(...)` at the decision site, so it can never be MORE aggressive than the job window.
+- **isProtectedSession absent** (older wiring / tests): optional-chained → no session
+  treated as protected (prior behavior), never throws.
+- **Protected list by name vs id**: matched against both `tmuxSession` and `name`.
+
+## Non-goals
+
+- Does NOT change delivery (that's PR1's lane).
+- Does NOT auto-kill anything (the backstop remains signal-only).
+
+## Reversibility
+
+`monitoring.staleBackstop.conversationalEscalateMinutes: 30` restores the old uniform
+window; protection follows the existing `protectedSessions` list. Additive only.
+
+## Tests
+
+Unit (stale-session-backstop.test.ts): protected session never escalates; the
+conversational-vs-job threshold split (a healthy long conversational session at 35 min
+does NOT escalate while a wedged job DOES). Existing mechanism tests pinned to the 30-min
+window via `conversationalEscalateMinutes: M`. 82 standards + backstop tests green; tsc
+clean. (Also: bumped the no-silent-fallbacks baseline 458→459 for PR1's lane fallback, and
+tracked main's untacked `/secrets/sync-status` migrator section — both per Zero-Failure.)