instar 1.3.648 → 1.3.649

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.648",
+  "version": "1.3.649",
   "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-22T22:56:43.249Z",
-  "instarVersion": "1.3.648",
+  "generatedAt": "2026-06-23T04:36:48.669Z",
+  "instarVersion": "1.3.649",
   "entryCount": 202,
   "entries": {
     "hook:session-start": {
@@ -418,7 +418,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:agents": {
@@ -426,7 +426,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:backups": {
@@ -434,7 +434,7 @@
       "type": "route-group",
       "domain": "operations",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:git": {
@@ -442,7 +442,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:memory": {
@@ -450,7 +450,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:semantic": {
@@ -458,7 +458,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:status": {
@@ -466,7 +466,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:capabilities": {
@@ -474,7 +474,7 @@
       "type": "route-group",
       "domain": "mapping",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:project-map": {
@@ -482,7 +482,7 @@
       "type": "route-group",
       "domain": "mapping",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:coherence": {
@@ -490,7 +490,7 @@
       "type": "route-group",
       "domain": "coherence",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:topic-bindings": {
@@ -498,7 +498,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:context": {
@@ -506,7 +506,7 @@
       "type": "route-group",
       "domain": "context",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:scope-coherence": {
@@ -514,7 +514,7 @@
       "type": "route-group",
       "domain": "coherence",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:canonical-state": {
@@ -522,7 +522,7 @@
       "type": "route-group",
       "domain": "state",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:ci": {
@@ -530,7 +530,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:sessions": {
@@ -538,7 +538,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:jobs": {
@@ -546,7 +546,7 @@
       "type": "route-group",
       "domain": "scheduling",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:skip-ledger": {
@@ -554,7 +554,7 @@
       "type": "route-group",
       "domain": "scheduling",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:telegram": {
@@ -562,7 +562,7 @@
       "type": "route-group",
       "domain": "communication",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:attention": {
@@ -570,7 +570,7 @@
       "type": "route-group",
       "domain": "communication",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:relationships": {
@@ -578,7 +578,7 @@
       "type": "route-group",
       "domain": "relationships",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:feedback": {
@@ -586,7 +586,7 @@
       "type": "route-group",
       "domain": "feedback",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:updates": {
@@ -594,7 +594,7 @@
       "type": "route-group",
       "domain": "updates",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:dispatches": {
@@ -602,7 +602,7 @@
       "type": "route-group",
       "domain": "dispatches",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:quota": {
@@ -610,7 +610,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:publishing": {
@@ -618,7 +618,7 @@
       "type": "route-group",
       "domain": "publishing",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:private-views": {
@@ -626,7 +626,7 @@
       "type": "route-group",
       "domain": "publishing",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:tunnel": {
@@ -634,7 +634,7 @@
       "type": "route-group",
       "domain": "networking",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:events": {
@@ -642,7 +642,7 @@
       "type": "route-group",
       "domain": "networking",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:evolution": {
@@ -650,7 +650,7 @@
       "type": "route-group",
       "domain": "evolution",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:watchdog": {
@@ -658,7 +658,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:topic-memory": {
@@ -666,7 +666,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:state-sync": {
@@ -674,7 +674,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:intent": {
@@ -682,7 +682,7 @@
       "type": "route-group",
       "domain": "intent",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:triage": {
@@ -690,7 +690,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:operations": {
@@ -698,7 +698,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:sentinel": {
@@ -706,7 +706,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:trust": {
@@ -714,7 +714,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:monitoring": {
@@ -722,7 +722,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:commitments": {
@@ -730,7 +730,7 @@
       "type": "route-group",
       "domain": "commitments",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:episodes": {
@@ -738,7 +738,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:messages": {
@@ -746,7 +746,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:system-reviews": {
@@ -754,7 +754,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "route-group:machine-mesh": {
@@ -770,7 +770,7 @@
       "type": "route-group",
       "domain": "security",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "cb2f112cb6404ad51d59f815dbf5500ffcf7d4e262ce66f97679047829645d17",
+      "contentHash": "fba7ee802dbc21caf906ea9a2d63506294ac4425fcb68749ef258fcca82cbbab",
       "since": "2025-01-01"
     },
     "cli:init": {
@@ -1546,7 +1546,7 @@
       "type": "subsystem",
       "domain": "updates",
       "sourcePath": "src/core/AutoUpdater.ts",
-      "contentHash": "60802cc5aad744cad139c5f5c0b1e4b27468c0a27b38384804ed09a6aa4e081c",
+      "contentHash": "05e6333268bc74c2acb3b8af1f95d0bd59852f2d4c683826713305922947783d",
       "since": "2025-01-01"
     },
     "subsystem:auto-dispatcher": {
@@ -1586,7 +1586,7 @@
       "type": "subsystem",
       "domain": "monitoring",
       "sourcePath": "src/monitoring/DegradationReporter.ts",
-      "contentHash": "3895b7eb8c6d3caf4337014ad6aeda537ae5f2507fa22a2357609be319811326",
+      "contentHash": "b3707ae0af774b35ab55d97a370c5c80d5ca0ab4af245ed62bf2bc925a9a65ff",
       "since": "2025-01-01"
     },
     "subsystem:telegram-lifeline": {

package/upgrades/1.3.649.md

@@ -0,0 +1,30 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Three small, pre-existing dashboard issues, found while verifying the dashboard-freeze fix (#1253). None affect the dashboard connection.
+
+1. The dashboard polled the WhatsApp QR endpoint every 3s and never stopped when WhatsApp wasn't configured — the route answers 503, but the poll kept firing, piling ~20 console 503 errors/min into the browser for the whole session. It now stops the poll on the first 503.
+2. A parse-time script block attached a WebSocket "message" listener to `ws` before `connectWebSocket()` had assigned it, so `ws` was null and `ws.onmessage` threw "Cannot read properties of null (reading 'onmessage')" on every page load (and the paste-panel refresh it enabled never actually worked). Paste handling moved into the main `handleMessage` switch — no more error, and it now survives reconnects.
+3. The `/health` "Degraded" badge turned orange whenever any degradation event had ever been recorded, and those events never self-clear — so one transient/benign fallback pinned the badge red for the whole process lifetime even after recovery. `/health` now counts only degradations from the last 30 minutes (`DegradationReporter.getRecentEvents`); a persistent problem keeps re-reporting so it stays visible, a one-off ages out. An unparseable timestamp is kept (fail-safe). The full degradation log and the mark-reported path are unchanged, and on a Telegram agent the `status` field never gated restarts.
+
+## What to Tell Your User
+
+If your dashboard's health badge was stuck on "Degraded" even though everything looked fine, that's fixed — it now reflects current health and clears once a transient blip has passed (a real, ongoing problem still shows). You won't notice the other two fixes directly: they quietly remove browser-console noise and an on-load error. (A separate, deeper item — a "system review" panel showing days-old data because it never re-runs — is tracked separately.)
+
+## Summary of New Capabilities
+
+- `DegradationReporter.getRecentEvents(windowMs = 30min, now)` — a time-windowed view of degradation events. `/health` uses it for `status` + the reported count/summary, so the dashboard "Degraded" badge reflects CURRENT health rather than any-event-ever-recorded. The full append-only log (`getEvents`) and the mark-reported path are untouched.
+- Dashboard: the WhatsApp QR poll stops on a 503 (adapter absent) — removes ~20 console 503s/min of noise.
+- Dashboard: paste WebSocket events (`paste_delivered` / `paste_acknowledged`) are handled in the main message router — removes the on-load null-deref TypeError and makes the paste-panel refresh survive reconnects.
+
+## Evidence
+
+Observed live on this agent (Echo) while verifying #1253:
+
+1. **WhatsApp poll spam** — Before: with no WhatsApp adapter configured, the browser console accumulated repeated `GET /whatsapp/qr 503` errors at the 3s poll cadence (~20/min) for the whole session. After: the poll stops on the first 503 (`stopWaPolling()`), so the console stays clean.
+2. **On-load null deref** — Before: `Uncaught TypeError: Cannot read properties of null (reading 'onmessage')` fired at `dashboard:~9289` on every page load (the block ran at parse time, before `connectWebSocket()` assigned `ws`), and the paste-panel refresh it was meant to wire never ran. After: paste events are handled in `handleMessage`; the parse-time block is gone, so the load-time TypeError no longer occurs.
+3. **Stuck "Degraded" badge** — Before: `curl /health` on a healthy box returned `{"status":"degraded","degradations":2,...}` where both events were a benign `"Stop event allowed without authority ruling … fail-open"` recorded earlier in the boot — never cleared, pinning the badge red. After (unit-proven, `tests/unit/degradation-reporter.test.ts`): `getRecentEvents()` returns only events within the 30-min window, so once those benign events age out `status` returns to `ok`; a re-reported (persistent) degradation stays inside the window and keeps the badge red.

package/upgrades/eli16/autoupdate-strand-detector.md

@@ -0,0 +1,22 @@
+# ELI16 — Notice when an update silently fell off the truck
+
+## The problem in plain words
+
+Instar updates itself by installing the new version into a private folder (the "shadow install") and then restarting onto it. To avoid loops, it keeps a note: "I already applied version X." On each check, if that note matches the latest version, it shrugs and says "downloaded, just waiting for a restart."
+
+But that note is just a *memory* — it's not the same as *checking the folder*. And the version number the program reports for itself is read once when it starts up and then cached, so it never notices if the folder changes underneath it.
+
+So here's the failure: an update installs successfully (the folder now has the new version, the note says "applied X"). Then something knocks the folder back to the OLD version — for example, a crash-loop where two copies of the program fight, or a half-finished re-install. Now the note still says "I applied X," but X isn't actually in the folder anymore. The updater believes it's up to date, refuses to re-apply, and every time it checks it cheerfully reports "downloaded, waiting for a restart" — which is a lie. The agent is quietly stuck on the old version forever, and nobody can tell from the message.
+
+This really happened: an agent got stranded on the old version while its note insisted it had the new one. It only got unstuck when a human manually re-installed.
+
+## The fix
+
+Add a way to read the *live* version straight from the folder on disk (uncached), and use it. When the updater is about to print "downloaded, waiting for a restart," it now first checks the folder. If the folder doesn't actually have the version the note claims, it knows it's stranded — so instead of the misleading "waiting for a restart" it prints a loud warning and sends one honest heads-up: "an update was recorded as installed but isn't actually on disk — I'm stuck on the old version and won't auto-update until this is re-applied. Nothing's broken, but I won't pick up new versions until it's fixed."
+
+## What it does and doesn't do
+
+- It does: catch the stranded state immediately and tell a human (and the logs) the truth, with the exact versions involved and how to re-apply.
+- It doesn't (yet): automatically fix the strand by re-installing. That auto-repair is a deliberate follow-up, because re-installing on the critical update path can loop if the folder keeps getting knocked back, so it needs a careful retry limit and proper review. This change is the safe, observe-only first step: stop hiding the problem.
+
+Low risk: it's a new read plus a corrected message; it only triggers on the genuine strand (a normal "applied, waiting for restart" never reaches it), and it's covered by tests.

package/upgrades/eli16/dashboard-health-signal-polish.md

@@ -0,0 +1,26 @@
+# ELI16 — Three small dashboard annoyances, cleaned up
+
+## The problem in plain words
+
+While fixing the big "dashboard keeps saying Disconnected" bug, I noticed three smaller, pre-existing issues. None of them break the connection — they're noise and one misleading light — but they're the kind of papercut that makes a healthy system look unwell.
+
+**1. A button that never stopped knocking.** The dashboard checks "is WhatsApp set up?" every 3 seconds by pinging a WhatsApp address. If WhatsApp *isn't* set up (the normal case here), that address politely answers "not available" — but the dashboard kept asking anyway, forever. The result was about twenty error lines a minute piling up in the browser's hidden console. Harmless, but messy, and it buries real errors in the noise.
+
+**2. An error thrown on every page load.** Tucked at the very end of the dashboard's code was a line that tried to hook into the live connection to refresh a small "paste" panel. But it ran *too early* — before the connection actually existed — so it tried to use something that wasn't there yet and threw a "can't read a property of nothing" error each time the page loaded. Worse, because it ran at the wrong moment, the paste-refresh it was supposed to enable never actually worked.
+
+**3. A warning light stuck on.** At the top of the dashboard there's a little health badge: green "Healthy" or orange "Degraded". It turns orange if *anything* ever reported a hiccup. The catch: those hiccup reports are never erased. So one tiny, long-recovered blip would keep the badge orange for the entire time the server was running — telling you something's wrong when everything is actually fine.
+
+## The fix
+
+**1.** When the WhatsApp check gets the "not available" answer, stop checking. (If WhatsApp gets set up later, a page refresh starts it again.) The console noise is gone.
+
+**2.** Move the paste-refresh handling into the dashboard's normal message router — the place that's always listening once the connection is live. That removes the early-run error *and* makes the paste-refresh actually work, even after the connection drops and comes back.
+
+**3.** Make the health badge only count hiccups from the last 30 minutes. A real, ongoing problem keeps reporting itself, so it stays visible — but a one-off blip that recovered quietly ages out, and the badge goes back to green like it should. To be safe, a hiccup with a missing or garbled timestamp is always kept (better to show a maybe-stale warning than to hide a real one).
+
+## What it does and doesn't do
+
+- It does: silence the console spam, remove the on-load error (and revive the paste-refresh), and make the "Degraded" badge tell the truth about *current* health.
+- It doesn't: change anything about restarts (on this agent the badge doesn't control restarts — that's decided separately by whether the server process is actually alive), and it doesn't touch the full record of past hiccups — only the *summary badge* is time-windowed.
+
+Low risk: two of the three are small front-end guards in the dashboard page; the third is a contained, well-tested change to which hiccups the health summary counts. A separate, deeper issue — a different "system review" panel showing data from days ago because it never re-runs — is left for a follow-up, because re-running its checks on a schedule is a bigger, cost-bearing change.

package/upgrades/eli16/worktree-monitor-async-git.md

@@ -0,0 +1,24 @@
+# ELI16 — Make the worktree scan stop freezing the server
+
+## The problem in plain words
+
+Instar's server runs everything on a single thread — one line at a time, like a single cashier serving a queue. If any one task takes a long time, *everything else waits*: the dashboard's live connection, the message handlers, all of it.
+
+One of the background helpers, the **WorktreeMonitor**, periodically looks at all the git "worktrees" (separate working copies of the code) to spot abandoned work. To do that it shells out to `git worktree list` and a few other git commands. The way it called git was **synchronous** — meaning the single thread sat there and *waited* for git to finish before doing anything else.
+
+That's fine when there are a handful of worktrees. But on a machine where worktrees pile up (one agent had ~282 of them!), `git worktree list` takes a few *seconds*. And this scan ran on a 5-minute timer **and** every time a background job finished. So every few minutes the whole server froze for a second or two.
+
+## Why it showed up as "dashboard disconnected"
+
+On the local address you'd never notice — the dashboard's live connection just reconnects instantly. But when you reach the dashboard through the internet tunnel, a one- or two-second server freeze is enough to **drop the live connection and time out the data**. The result is the dashboard showing "Disconnected, 0 sessions, 0% memory" — even though the server is actually fine, it was just frozen for a moment.
+
+## The fix
+
+Make the git calls **asynchronous**. Instead of the single thread sitting and waiting for git, it kicks off the git command and goes back to serving everyone else; when git finishes, it picks the result back up. Same scans, same schedule, same results — but the server stays responsive the whole time, so the dashboard's live connection never drops.
+
+## What changed and what didn't
+
+- Changed: the worktree scan's git calls no longer block the server thread.
+- Unchanged: it still scans on the same 5-minute timer and after each job, still reports the same things, and the `/hooks/worktrees` endpoint returns the exact same data. The git calls keep their old behavior of returning whatever output they produced even if git exits with an error.
+
+It's a small, low-risk change covered by the existing tests (all green), and it's the permanent replacement for a quick hotpatch that had temporarily disabled the scans to stop the freezing.

package/upgrades/side-effects/autoupdate-strand-detector.md

@@ -0,0 +1,36 @@
+# Side-Effects Review — Auto-update version-strand detector
+
+**Version / slug:** `autoupdate-strand-detector`
+**Date:** `2026-06-23`
+**Author:** Echo (autonomous)
+**Tier:** 1 (observe-only diagnostic — no change to update behavior, no new config, no decision points)
+**Second-pass reviewer:** not-required (Tier 1; the new method + a corrected log/notify branch, covered by unit tests)
+
+## Summary of the change
+
+The AutoUpdater has a loop-breaker (`if lastAppliedVersion === latestVersion`) that, on every tick, assumes the recorded-applied version is genuinely installed in the shadow and prints a benign "downloaded, waiting for a restart" message. But `getInstalledVersion()` caches the version the running process booted with — it does NOT reflect the LIVE shadow on disk.
+
+If the shadow REVERTS after a successful apply (e.g., crash-loop collateral, or a partial re-install) while `lastAppliedVersion` still records the new version, the agent is **stranded**: the updater believes it is current, the loop-breaker never re-applies, and the misleading "waiting for a restart" message hides a permanent stuck state. This actually happened (an agent stranded on the old version while `lastAppliedVersion` claimed the new one).
+
+## The change
+
+- `src/core/UpdateChecker.ts` — new `getShadowInstalledVersion(): string | null`, an **uncached** read of `{stateDir}/shadow-install/node_modules/instar/package.json`. Distinct from `getInstalledVersion()` (which caches the running-process version).
+- `src/core/AutoUpdater.ts` — in the loop-breaker, read the live shadow-disk version; if it differs from `lastAppliedVersion` (the shadow doesn't actually have what the record claims), emit a distinct loud STRAND warning + a one-time honest notification ("an update was recorded as installed but isn't on disk — I'm stuck until it's re-applied") instead of the benign "awaiting restart" message.
+- `tests/unit/UpdateChecker.test.ts` — 4 tests for `getShadowInstalledVersion` (reads the disk version, reflects a reverted version uncached, returns null when absent / version-less).
+
+## Side effects & risk
+
+- **Observe-only.** Update behavior is unchanged: the strand path still `return`s (no auto re-apply — a bounded auto-heal is a deliberate follow-up). The change only corrects the diagnosis and the one-time notification text.
+- **No false positives on the benign case.** A genuine "applied, awaiting restart" has shadow-disk === lastAppliedVersion → `updateAvailable` is false → the tick returns before the loop-breaker. Reaching the loop-breaker with shadow-disk ≠ lastAppliedVersion is the strand.
+- **Fail-safe reads.** `getShadowInstalledVersion()` returns null on any read error; a null shadow version never trips the strand branch (it falls through to the existing benign messages).
+- **Risk:** low. New diagnostic method + a corrected branch, both covered by unit tests; AutoUpdater's existing 29 tests stay green.
+
+## Verification
+
+- `tsc --noEmit`: 0 errors.
+- `tests/unit/UpdateChecker.test.ts`: 17/17 (incl. 4 new).
+- `tests/unit/AutoUpdater.test.ts` + `tests/unit/auto-updater-failures.test.ts`: 29/29.
+
+## Rollout
+
+No flag, no migration. Strictly additive diagnostic — surfaces a previously-silent stuck state. The bounded auto-re-apply self-heal (which would also FIX the strand, not just surface it) is a tracked Tier-2 follow-up (it mutates the critical update path and warrants spec-converge review).

package/upgrades/side-effects/dashboard-health-signal-polish.md

@@ -0,0 +1,59 @@
+# Side-Effects Review — Dashboard health-signal polish (3 pre-existing fixes)
+
+**Version / slug:** `dashboard-health-signal-polish`
+**Date:** `2026-06-23`
+**Author:** Echo (autonomous)
+**Tier:** 1 (three contained, low-risk fixes — two client-side dashboard guards + one health-status windowing on an endpoint whose `status` field does not gate restarts on this agent)
+**Second-pass reviewer:** not-required (Tier 1; small contained fixes, the server-side change covered by new unit tests)
+
+## Summary of the change
+
+Three minor, pre-existing dashboard issues found while verifying the dashboard-freeze fix (#1253). None affect the dashboard connection; all are noise/cosmetic.
+
+1. **WhatsApp QR poll spam.** `pollWaQr()` polls `/whatsapp/qr` every 3s. When WhatsApp isn't configured the route returns 503, but the poll loop was never stopped — so the browser console accumulated ~20 503s/min for the whole session. Fix: call `stopWaPolling()` on the 503 (adapter absent).
+2. **Null-deref TypeError on load.** A parse-time block attached a `'message'` listener to `ws`, guarded by `if (typeof ws !== 'undefined')`. `ws` is a declared `let` that is **null** at parse time (`connectWebSocket()` runs later in a `.then()`), and `typeof null === 'object' !== 'undefined'`, so the guard passed and `ws.onmessage` threw `Cannot read properties of null (reading 'onmessage')` on every load. The block was the only place paste WebSocket events refreshed the drop-zone — so the feature was also effectively dead. Fix: fold `paste_delivered` / `paste_acknowledged` into the main `handleMessage` switch (where it survives reconnects) and remove the broken parse-time block.
+3. **Stale "Degraded" badge.** The vital-signs badge renders `/health`'s `status`, which is `degraded` whenever `DegradationReporter.getEvents().length > 0`. Degradation events are append-only and never self-clear, so a single transient/benign fallback pins the badge red for the entire process lifetime even after recovery. Fix: `/health` now uses a new `DegradationReporter.getRecentEvents()` (30-min window) for status + the reported count/summary — a persistent problem keeps re-reporting so it stays visible; a one-off ages out.
+
+## The change
+
+- `dashboard/index.html` — (1) `stopWaPolling()` on 503; (2) paste cases added to `handleMessage`, broken parse-time block removed.
+- `src/monitoring/DegradationReporter.ts` — new `getRecentEvents(windowMs = HEALTH_WINDOW_MS, now = Date.now())` + `static HEALTH_WINDOW_MS = 30min`. Filters by event `timestamp`; an unparseable timestamp is KEPT (fail-safe: surface, never hide). `getEvents()` (full log) is unchanged.
+- `src/server/routes.ts` — `/health` calls `getRecentEvents()` instead of `getEvents()` for the `degradations` list that feeds `status` + `degradations` count + `degradationSummary`.
+- `tests/unit/degradation-reporter.test.ts` — 3 new tests (recent kept / old aged out / unparseable kept).
+
+## Side effects & risk
+
+- **`/health` status semantics.** `status` flips back to `ok` once degradations age past 30 min without recurring. Reviewed consumers: the **Telegram lifeline** derives `serverHealthy` from the supervisor's process status, NOT from `/health.status`, so this never affects restart behavior on a Telegram agent (Echo). `SlackLifeline` keys on `status === 'ok'` only to detect the unhealthy→healthy *recovery* transition (a log/notify), not to trigger restarts. The change makes status MORE truthful (reflects current health), and is the safe direction (a real, recurring problem keeps re-reporting and stays visible).
+- **The full degradation log is untouched.** `getEvents()`, `getUnreportedEvents()`, mark-reported, and persistence all still see every event — only the /health *status view* is windowed.
+- **Client-side fixes are isolated** to the dashboard static asset; no server behavior changes; the dashboard isn't in the typecheck/test suite, so both were syntax-checked with `node --check`.
+- **Risk:** low. No new config, no new route, no migration (the dashboard asset + core source ship with the package on update). Reversible (revert the three edits).
+
+## 6b. Operator-surface quality (Operator-Surface Quality standard)
+
+This change touches `dashboard/index.html`. It alters **background behavior**, not layout or primary actions — so it adds no new operator-facing controls or content. Against the four criteria:
+
+1. **Leads with the primary action?** Unchanged — the dashboard still leads with the session list + vital-signs strip. No new primary action is introduced; nothing is moved, collapsed, or pushed below the fold.
+2. **Zero raw internals as primary content?** Yes — the change adds NO displayed content. It REMOVES noise (the WhatsApp console 503 spam) and an on-load TypeError, and makes the existing plain-language health badge ("Healthy" / uptime vs "Degraded") accurate. No JSON/UUID/fingerprint/hash is shown.
+3. **Destructive actions de-emphasized?** N/A — no destructive control is added or touched.
+4. **Plain language + phone width?** Yes — the only user-visible behavioral change is the top-of-dashboard badge now correctly reads "Healthy" when the box is healthy (it was stuck on "Degraded"). Plain wording, same layout, same width — no new elements, so no phone-width regression.
+
+(The dashboard's pre-existing raw-input field — the PIN/token unlock — already carries the co-located `operator-surface-power-user` marker and is untouched here.)
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+
+**machine-local BY DESIGN.** The vital-signs badge reads THIS machine's `/health`; each machine's `DegradationReporter` and health state are local, per-machine observability (a degradation on machine A is machine A's concern). The dashboard already exposes pool-wide state through separate `?scope=pool` surfaces (sessions, guards, attention, …), which this change does not touch. The WhatsApp poll and the paste WS handler are pure client-side, per-browser-tab.
+
+- **User-facing notices?** None emitted — no one-voice gating concern.
+- **Durable state strand on topic transfer?** No durable state added; nothing strands.
+- **Generated URLs?** None.
+
+## Verification
+
+- `tsc --noEmit`: 0 errors.
+- `tests/unit/degradation-reporter.test.ts`: 20/20 (incl. 3 new windowing tests).
+- `tests/unit/{routes-degradations-mark-reported,degradation-never-silent,degradation-reporter-reentrancy-wedge}.test.ts`: 14/14 (no regression on the mark-reported / never-silent paths).
+- `dashboard/index.html` embedded script: `node --check` passes.
+
+## Rollout
+
+No flag, no migration. Three additive fixes that surface previously-hidden console errors and make the health badge truthful. The genuinely-stale `systemReview` *panel* (last ran 2026-06-20, never re-runs) is a SEPARATE, more-involved concern (re-running 16 probes on a cadence is cost-bearing) — explicitly NOT bundled here; tracked for follow-up.