instar 1.3.648 → 1.3.650

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.648",
+  "version": "1.3.650",
   "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-23T05:05:15.576Z",
+  "instarVersion": "1.3.650",
   "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/1.3.650.md

@@ -0,0 +1,21 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+The built-in "system review" (a batch of ~16 local self-checks surfaced in `/health` and rendered as the dashboard health panel) runs on a 6-hour timer — but it only ever ran when that timer fired, never on boot. Each restart resets the 6-hour timer, so on an agent that restarts more often than every 6 hours (updates, recovery bounces), the review never runs again after the first time, and the health panel freezes on a days-old snapshot. `SystemReviewer.start()` now also runs one review shortly after boot (default 30s delay, in the background, behind a default-on `reviewOnStart` flag), gated by a freshness guard so a restart loop doesn't pile up reviews (skipped if a review ran in the last hour; an unparseable timestamp errs toward running it).
+
+## What to Tell Your User
+
+If your dashboard's health panel showed a scary days-old "critical" status even though everything was fine, that's fixed — the panel now refreshes within about 30 seconds of every startup, so it reflects current health instead of an old snapshot. There's nothing to do; it's on by default. If you'd ever prefer it only refresh on its slower six-hour cycle, just ask me and I'll switch it.
+
+## Summary of New Capabilities
+
+- `SystemReviewer` runs one review shortly after `start()` (in addition to the `scheduleMs` interval), so the health panel stays current on agents that restart more often than the interval.
+- New `monitoring.systemReview` config: `reviewOnStart` (default true), `initialReviewDelayMs` (default 30s), `initialReviewStaleAfterMs` (default 1h — skip the on-boot review if the last one is younger than this).
+
+## Evidence
+
+Observed live on Echo: `curl /health` returned `systemReview` with `lastReview.timestamp = "2026-06-20T11:51:54.985Z"` and `status: "critical", passed: 11, failed: 5` — days stale, from a past incident, while the box was healthy (uptime ~1–2h, no current failures). Root cause confirmed by reading `start()`: it set the `scheduleMs` (6h) interval but ran no review on boot, and the probe sources contain no LLM/network calls (so an on-boot review is cheap). After: 4 new unit tests prove `start()` runs a review after the delay when the last review is absent or >1h old, and skips it when the last review is <1h old.

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/systemreview-onboot-refresh.md

@@ -0,0 +1,24 @@
+# ELI16 — The health panel that was stuck showing days-old news
+
+## The problem in plain words
+
+Instar runs a built-in "system review" — a batch of ~16 quick self-checks (is the scheduler alive, is messaging working, etc.) — and shows the result as a health summary. It's meant to run on a repeating timer so the summary stays current.
+
+The timer is set to every 6 hours. But here's the bug: the review only ever ran *when the 6-hour timer went off* — it never ran *when the agent started up*. And this agent restarts pretty often (every update, every recovery bounce, restarts a few hours apart). Each restart resets the 6-hour timer back to zero. So if the agent restarts more often than every 6 hours, the timer never actually reaches 6 hours — and the review never runs again after the very first time.
+
+The result: the health panel got frozen on whatever it last said. On this agent it was stuck showing a scary "critical — only 11 of 16 checks passing" from days ago (during a past incident), long after everything had recovered. Anyone looking at the dashboard would think the agent was on fire when it was perfectly healthy.
+
+## The fix
+
+Run one review shortly after the agent boots, in addition to the 6-hour timer. Now every startup refreshes the panel within about 30 seconds, so it always reflects the *current* state regardless of how often the agent restarts.
+
+Two safeguards keep it sensible:
+- **It waits ~30 seconds and runs in the background**, so it never slows down startup.
+- **It skips if the panel is already fresh** (a review ran in the last hour). That way, if the agent is in a rapid restart loop, it won't pile up a review on every single boot — just one per hour at most. (If the timestamp is somehow unreadable, it errs on the side of running the review — better a fresh check than a stale one.)
+
+## What it does and doesn't do
+
+- It does: keep the health panel honest by refreshing it on every boot, so it shows current health instead of a days-old snapshot.
+- It doesn't: change what the checks are or how the 6-hour cadence works, and it doesn't add any cost worth worrying about — the checks are all local (no AI calls, no network), so running one extra on boot is cheap.
+
+There's an off-switch (`reviewOnStart: false`) for anyone who wants only the 6-hour cadence, and it's on by default because a health panel showing days-old "critical" status is a real, misleading bug. Low risk: it's an additive background timer with a freshness guard, covered by tests.

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).