instar 1.2.31 → 1.2.33

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.2.31",
+  "version": "1.2.33",
   "description": "Persistent autonomy infrastructure for AI agents",
   "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-05-22T18:31:32.419Z",
-  "instarVersion": "1.2.31",
+  "generatedAt": "2026-05-22T20:34:00.772Z",
+  "instarVersion": "1.2.33",
   "entryCount": 191,
   "entries": {
     "hook:session-start": {
@@ -392,7 +392,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:agents": {
@@ -400,7 +400,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:backups": {
@@ -408,7 +408,7 @@
       "type": "route-group",
       "domain": "operations",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:git": {
@@ -416,7 +416,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:memory": {
@@ -424,7 +424,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:semantic": {
@@ -432,7 +432,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:status": {
@@ -440,7 +440,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:capabilities": {
@@ -448,7 +448,7 @@
       "type": "route-group",
       "domain": "mapping",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:project-map": {
@@ -456,7 +456,7 @@
       "type": "route-group",
       "domain": "mapping",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:coherence": {
@@ -464,7 +464,7 @@
       "type": "route-group",
       "domain": "coherence",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:topic-bindings": {
@@ -472,7 +472,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:context": {
@@ -480,7 +480,7 @@
       "type": "route-group",
       "domain": "context",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:scope-coherence": {
@@ -488,7 +488,7 @@
       "type": "route-group",
       "domain": "coherence",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:canonical-state": {
@@ -496,7 +496,7 @@
       "type": "route-group",
       "domain": "state",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:ci": {
@@ -504,7 +504,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:sessions": {
@@ -512,7 +512,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:jobs": {
@@ -520,7 +520,7 @@
       "type": "route-group",
       "domain": "scheduling",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:skip-ledger": {
@@ -528,7 +528,7 @@
       "type": "route-group",
       "domain": "scheduling",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:telegram": {
@@ -536,7 +536,7 @@
       "type": "route-group",
       "domain": "communication",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:attention": {
@@ -544,7 +544,7 @@
       "type": "route-group",
       "domain": "communication",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:relationships": {
@@ -552,7 +552,7 @@
       "type": "route-group",
       "domain": "relationships",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:feedback": {
@@ -560,7 +560,7 @@
       "type": "route-group",
       "domain": "feedback",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:updates": {
@@ -568,7 +568,7 @@
       "type": "route-group",
       "domain": "updates",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:dispatches": {
@@ -576,7 +576,7 @@
       "type": "route-group",
       "domain": "dispatches",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:quota": {
@@ -584,7 +584,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:publishing": {
@@ -592,7 +592,7 @@
       "type": "route-group",
       "domain": "publishing",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:private-views": {
@@ -600,7 +600,7 @@
       "type": "route-group",
       "domain": "publishing",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:tunnel": {
@@ -608,7 +608,7 @@
       "type": "route-group",
       "domain": "networking",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:events": {
@@ -616,7 +616,7 @@
       "type": "route-group",
       "domain": "networking",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:evolution": {
@@ -624,7 +624,7 @@
       "type": "route-group",
       "domain": "evolution",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:watchdog": {
@@ -632,7 +632,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:topic-memory": {
@@ -640,7 +640,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:state-sync": {
@@ -648,7 +648,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:intent": {
@@ -656,7 +656,7 @@
       "type": "route-group",
       "domain": "intent",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:triage": {
@@ -664,7 +664,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:operations": {
@@ -672,7 +672,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:sentinel": {
@@ -680,7 +680,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:trust": {
@@ -688,7 +688,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:monitoring": {
@@ -696,7 +696,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:commitments": {
@@ -704,7 +704,7 @@
       "type": "route-group",
       "domain": "commitments",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:episodes": {
@@ -712,7 +712,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:messages": {
@@ -720,7 +720,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:system-reviews": {
@@ -728,7 +728,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "route-group:machine-mesh": {
@@ -744,7 +744,7 @@
       "type": "route-group",
       "domain": "security",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "41bcd0a33fc72e73398acb708c966936a63afad1c9430dae8b11a7c50a38dbac",
+      "contentHash": "8e2047a994d15f6e332d09d2e67d83c39f88541312674b50a4976d28d54e04b8",
       "since": "2025-01-01"
     },
     "cli:init": {
@@ -1440,7 +1440,7 @@
       "type": "subsystem",
       "domain": "server",
       "sourcePath": "src/server/AgentServer.ts",
-      "contentHash": "6e996e6ea45338ffe019e539eaa738af05d5ad9a1ca35c9d93a8ba198599f759",
+      "contentHash": "d8d019cc9691191bca75fabd916fa5a4400bb614abcd48b49afa4f650d533fdd",
       "since": "2025-01-01"
     },
     "subsystem:session-manager": {
@@ -1448,7 +1448,7 @@
       "type": "subsystem",
       "domain": "sessions",
       "sourcePath": "src/core/SessionManager.ts",
-      "contentHash": "c8a43e38d2707bf0f1e7f3bfc958b5f6f885a4cfc383cb99135100caad6fc901",
+      "contentHash": "7241736a08f63b09d8b1abda0965dadb37127c95aa6e4ac11bafee05661dbe9f",
       "since": "2025-01-01"
     },
     "subsystem:auto-updater": {

package/upgrades/1.2.29.md

@@ -52,3 +52,27 @@ Nothing is required from you. The graph builds quietly in the background through
 | Automatic entity extraction from session activity | Automatic — runs in every digest scan when SemanticMemory is enabled |
 | Cross-digest entity dedup | Automatic — same name + same type collapses to one entity |
 | Typed graph edges from intra-batch and cross-digest references | Automatic — emitted when target entity is in scope |
+
+---
+
+**feat(memory): periodic activity-digest scan — digest long-running sessions mid-flight.**
+
+The entity-extraction pipeline above only ran when a session reached `sessionComplete`. For a long-running Telegram topic that runs for hours or days, or never cleanly ends (compaction, machine restart, watchdog kill), that meant the activity was never digested mid-flight and the entities within it never reached SemanticMemory. The knowledge graph stayed sparse precisely for the longest, most context-rich topics — the exact shape this whole memory effort is meant to serve.
+
+This release wires the periodic `SessionActivitySentinel.scan()` (which already existed but was never scheduled) as an in-process timer. By default it runs every 30 minutes, digesting in-progress sessions that have accumulated new activity. Combined with the entity extraction above, the knowledge graph now grows throughout a long session, not only at its end.
+
+Details:
+
+1. New optional config `monitoring.episodicSentinel` with `enabled` (default true) and `scanIntervalMinutes` (default 30, floored at 5). Absent by default — existing agents get the 30-minute scan automatically.
+
+2. A new pure helper `resolveSentinelScanIntervalMs` computes the effective interval (default / floor / disabled), unit-tested independently of the server bootstrap.
+
+3. The scan timer is gated to the awake machine in a multi-machine setup (mirrors the scheduler gating), so standby machines don't double-digest. It `unref()`s so it never blocks process exit, and a failing scan is logged, never thrown.
+
+4. `scan()` itself is unchanged — it already enforces idempotency (hash-keyed digests), dormant-session skipping, and a minimum-activity threshold, so a 30-minute cadence is safe and idle sessions cost nothing.
+
+Tests: 6 new unit tests on the interval resolver (default, disabled, custom, floor-clamp). The 21 existing sentinel tests and 7 entity-extraction tests confirm scan() behaviour is unchanged.
+
+## What to Tell Your User (periodic scan)
+
+Your agent now keeps its memory current during long conversations, not just when they end. Every half hour it quietly reviews in-progress conversations that have new activity and files away the important facts. For a conversation that runs for days, this means the agent stays aware of decisions and facts from earlier in the same conversation instead of only catching up at the very end. It's on by default and costs nothing for idle conversations.

package/upgrades/1.2.32.md

@@ -0,0 +1,37 @@
+# Upgrade Guide — vNEXT
+
+<!-- bump: minor -->
+<!-- minor = new agent-facing capability without breaking changes -->
+
+## What Changed
+
+**feat(memory): periodic activity-digest scan — digest long-running sessions mid-flight.**
+
+The activity-digest entity-extraction pipeline (shipped just prior) only ran when a session reached `sessionComplete`. For a long-running Telegram topic that runs for hours or days, or never cleanly ends (compaction, machine restart, watchdog kill), that meant the activity was never digested mid-flight and the entities within it never reached SemanticMemory. The knowledge graph stayed sparse precisely for the longest, most context-rich topics — the exact shape this memory effort is meant to serve.
+
+This release wires the periodic `SessionActivitySentinel.scan()` (which already existed but was never scheduled) as an in-process timer. By default it runs every 30 minutes, digesting in-progress sessions that have accumulated new activity. Combined with the entity extraction, the knowledge graph now grows throughout a long session, not only at its end.
+
+Details:
+
+1. New optional config `monitoring.episodicSentinel` with `enabled` (default true) and `scanIntervalMinutes` (default 30, floored at 5). Absent by default — existing agents get the 30-minute scan automatically.
+
+2. A new pure helper `resolveSentinelScanIntervalMs` computes the effective interval (default / floor / disabled), unit-tested independently of the server bootstrap.
+
+3. The scan timer is gated to the awake machine in a multi-machine setup (mirrors the scheduler gating), so standby machines don't double-digest. It `unref()`s so it never blocks process exit, and a failing scan is logged, never thrown.
+
+4. `scan()` itself is unchanged — it already enforces idempotency (hash-keyed digests), dormant-session skipping, and a minimum-activity threshold, so a 30-minute cadence is safe and idle sessions cost nothing.
+
+## Evidence
+
+6 new unit tests on the interval resolver (`tests/unit/sentinel-scan-interval.test.ts`): default 30 minutes, null when disabled, custom interval, 5-minute floor-clamp (at 1/0/negative), exact-floor. The 21 existing `session-activity-sentinel.test.ts` tests and 7 `SessionActivitySentinel-entity-extraction.test.ts` tests still pass — confirming `scan()` behaviour is unchanged. The wiring is in-process `setInterval` following the established relay-prune / resume-heartbeat timer pattern; `tsc --noEmit` clean.
+
+## What to Tell Your User
+
+Your agent now keeps its memory current during long conversations, not just when they end. Every half hour it quietly reviews in-progress conversations that have new activity and files away the important facts. For a conversation that runs for days, this means the agent stays aware of decisions and facts from earlier in the same conversation instead of only catching up at the very end. It's on by default and costs nothing for idle conversations.
+
+## Summary of New Capabilities
+
+| Capability | How to Use |
+|-----------|-----------|
+| Periodic mid-session activity digestion | Automatic — every 30 min (configurable via `monitoring.episodicSentinel.scanIntervalMinutes`) |
+| Disable / retune the cadence | Set `monitoring.episodicSentinel.enabled` false, or `scanIntervalMinutes` (floored at 5) |

package/upgrades/1.2.33.md

@@ -0,0 +1,57 @@
+# Upgrade Guide — vNEXT
+
+<!-- bump: minor -->
+<!-- minor = new agent-facing capability (RateLimitSentinel — server-throttle survival) without breaking changes. Default-on; off-switch is one config flag. -->
+
+## What Changed
+
+**feat(monitoring): RateLimitSentinel — ride out Anthropic's server-side throttle instead of dropping the session.**
+
+Anthropic recently started surfacing a new Claude Code error: *"Server is temporarily limiting requests (not your usage limit) · Rate limited"* (and the related *"Repeated 529 Overloaded errors"*). This is a short-lived, shared-capacity throttle on Anthropic's side — **not** your account's usage cap. Claude Code already auto-retries it ~10 times with its own exponential backoff before it ever shows the message, so by the time you see it on screen, those built-in retries are exhausted and the session sits idle with no reply ever relayed to the user.
+
+Instar's prior behavior made this worse, not better. SessionManager's idle-error path fired a single *immediate* nudge the moment it saw an "API Error:" — which slams straight back into the live throttle, burns quota for nothing, and then goes silent until the zombie-killer reaps the session. There was no user-facing signal that the agent was throttled-but-alive.
+
+This release adds a dedicated **`RateLimitSentinel`** (same own-the-lifecycle shape as `CompactionSentinel`) that owns recovery end to end:
+
+1. **Detect** — a pure predicate (`src/monitoring/rateLimitDetection.ts`) distinguishes the server throttle from the user's plan/usage quota (PresenceProxy's domain — wait-for-reset, not retry) and from Claude's own in-progress retry spinner (the framework still owns it). Strings are taken from the user's live screenshot and the Claude Code error reference, not invented.
+2. **Notice immediately** — a fixed-template message tells the user they're throttled, backing off, and *not* dropped. No LLM call.
+3. **Back off BEFORE re-engaging** — escalating schedule (30s → 1m → 2m → 5m, last value repeats). This is the core quota-burn mitigation: we sit on top of Claude's already-exhausted retries instead of hammering.
+4. **Re-engage neutrally** — a plain "continue where you left off" nudge, *not* the compaction-resume payload (which would falsely tell the agent its memory was reset).
+5. **Verify** — JSONL size/mtime growth means Claude processed the nudge and the throttle cleared.
+6. **Check in** — periodic user updates at verify-fail transitions, minimum-spacing gated so it never spams.
+7. **Escalate** — after a capped attempts/window envelope (6 attempts or 30 min), a final "this is on Anthropic's side, status.claude.com has live notices, message me to retry" message.
+
+**Two signal triggers, one authority.** Per `feedback_signal_vs_authority`: both `SessionWatchdog` (periodic poll) and `SessionManager` (idle-error path) emit signals; the sentinel holds sole recovery authority and dedupes the two. SessionManager skips its single-nudge for the throttle case and hands ownership over — *without* consuming the nudge token, so a later generic API error still gets its one nudge.
+
+**Coexistence with the other recovery engines:**
+- **Zombie-kill veto** — `setActiveRecoveryChecker` now ORs both sentinels (the predicate is *edited*, not a second call — a second `setActiveRecoveryChecker` would silently drop the compaction veto). The reaper won't kill a session mid-throttle-recovery.
+- **Bidirectional deferral** — `RateLimitSentinel` and `CompactionSentinel` each defer to the other via `deferIf`, so the two never inject into one pane concurrently.
+- **PresenceProxy suppression** — while a throttle recovery owns a topic's session, PresenceProxy stays silent across *every* tier (including Tier 1), so the user hears one voice. It re-checks after a delay and resumes only if the agent is still silent post-recovery.
+
+**Opt-in retry-count raise.** A new `claudeCodeMaxRetries` config field, when set, injects `CLAUDE_CODE_MAX_RETRIES` at session spawn so Claude rides out transient throttle/overload longer before surfacing to the sentinel. Unset by default (Claude's default of 10 stands) so genuine outages aren't masked.
+
+Spec: `docs/specs/rate-limit-sentinel.md` (ELI16 overview up top, full technical spec below). The spec folded in an adversarial side-effects review (over/under-block, race conditions, quota-burn safety, signal-vs-authority, interactions with the other sentinels) before build.
+
+## What to Tell Your User
+
+Sometimes Anthropic's servers get briefly overloaded and slow everyone down for a minute or two. This is different from running out of your usage — it's a temporary "the servers are busy right now" speed bump on their end. Before this release, when that happened your agent could go quiet with no explanation, and the way it tried to recover actually wasted your usage hours by knocking on the door over and over.
+
+Now your agent handles it gracefully. The moment it hits one of these server slowdowns it sends you a quick note — *"heads up, Anthropic's servers are briefly throttling, I'm backing off, you haven't been dropped"* — then waits a bit, tries again, waits a little longer, tries again, and keeps you posted while it's stuck. When the servers free up, it picks right back up where it left off and tells you it's back. If it's still stuck after about half an hour, it lets you know it's an Anthropic-side issue and that you can just message it to retry.
+
+You don't have to do anything — it's on by default for every agent. If you ever want the old behavior back, it's a single config switch.
+
+## Summary of New Capabilities
+
+- **`RateLimitSentinel`** — new monitoring module that owns the full detect → notice → backoff → resume → verify → check-in → escalate lifecycle for Anthropic's server-side throttle.
+- **`GET /rate-limit/status`** — read-only observability route (Bearer-gated): active recoveries with `sessionName`, `status`, `attempts`, `nextBackoffMs`. Returns `{ enabled: false, active: [] }` (never 503) when the sentinel is absent.
+- **`monitoring.rateLimitSentinel` config** — `{ enabled: true }` by default; `enabled: false` restores pre-feature behavior. Backoff schedule, max attempts, window, verify window, check-in spacing, and dedupe window are all overridable.
+- **`claudeCodeMaxRetries` config** — opt-in `CLAUDE_CODE_MAX_RETRIES` raise at session spawn.
+- **Migration parity** — `rateLimitSentinel` default flows to existing agents automatically via the canonical `ConfigDefaults` registry applied by `PostUpdateMigrator` on update. No agent ships dead.
+
+## Evidence
+
+- **Tier 1 unit tests:** `tests/unit/RateLimitSentinel.test.ts` (14 tests) covers the lifecycle, dedupe across both triggers, escalation on attempt/window exhaustion, escalation when resume declines, check-in min-spacing, independent per-session recovery, and `listActive` shape. `tests/unit/rate-limit-detection.test.ts` (12 tests) covers throttle-vs-usage-limit-vs-retry-spinner discrimination with real fixture strings. All 26 passing.
+- **Tier 2 integration tests:** `tests/integration/rate-limit-status-routes.test.ts` (4 tests) — `GET /rate-limit/status` through the real `createRoutes` pipeline (active + disabled cases), plus wiring-integrity tests guarding the zombie-veto composition (EITHER sentinel owning a session holds the veto — the S1 regression where a second `setActiveRecoveryChecker` drops the compaction veto) and the bidirectional `deferIf`. All passing.
+- **Tier 3 E2E lifecycle:** `tests/e2e/rate-limit-sentinel-lifecycle.test.ts` (4 tests) boots the real `AgentServer` with the sentinel passed through exactly as `server.ts` wires it, and asserts `GET /rate-limit/status` returns **200 with `enabled: true`** — the "feature is alive" check that catches the case where `AgentServer`'s `?? null` plumbing drops the sentinel. Also verifies a reported throttle surfaces on the wire with the documented shape and that `isRecoveryActive` (the production zombie-veto predicate) tracks correctly. All passing.
+- **Type-check:** `npx tsc --noEmit` clean.
+- The full test suite must remain green before merge per the Zero-Failure Standard.

package/upgrades/side-effects/feat-periodic-sentinel-scan.md

@@ -0,0 +1,65 @@
+# Side-Effects Review — feat(memory): periodic SessionActivitySentinel scan
+
+**Branch:** `echo/phase-0b-periodic-scan`
+**Origin:** Phase 0b of the topic-intent-layer thread (Telegram 9976). Last foundation piece before Phase 1.
+
+## Summary
+
+Wires the periodic `SessionActivitySentinel.scan()` (every 30 min default) as a `setInterval` in `server.ts`, gated to the awake machine. Previously the sentinel only fired on `sessionComplete`, so long-running sessions never got mid-flight digestion and the Phase 0d entity extraction never ran for them.
+
+## Files touched
+
+- `src/core/types.ts` — added optional `MonitoringConfig.episodicSentinel` ({ enabled?, scanIntervalMinutes? }).
+- `src/monitoring/SessionActivitySentinel.ts` — added pure helper `resolveSentinelScanIntervalMs`.
+- `src/commands/server.ts` — wired the periodic scan interval after the sessionComplete handler; imports the new helper.
+- `tests/unit/sentinel-scan-interval.test.ts` — 6 tests on the resolver.
+- `docs/specs/periodic-sentinel-scan.md` + `.eli16.md` — spec + ELI16.
+- `upgrades/NEXT.md` — release note.
+
+## Over-block check
+
+The scan only runs when `resolveSentinelScanIntervalMs` returns non-null (enabled !== false) AND (no coordinator OR the machine is awake). It does NOT run on standby machines. It does NOT add an immediate startup scan (first fire is one interval out), so restart loops don't trigger repeated digestion. No new behaviour in the disabled path — `enabled: false` returns null and no interval is created.
+
+## Under-block check
+
+Could a long session still be missed? Only if: the periodic scan is disabled by config AND the session never reaches sessionComplete. That's an explicit operator opt-out, not a silent gap. The default (on, 30 min) covers the case the spec targets.
+
+scan() itself enforces dormant-skip and minimum-activity internally, so an idle session that the timer visits costs nothing — no over-digestion of quiet sessions.
+
+## Level-of-abstraction fit
+
+The interval policy (default, floor, disabled) is a pure function on the sentinel module — testable in isolation, no server bootstrap needed. The actual `setInterval` lives in server.ts next to the existing sessionComplete wire and the other periodic timers (relayPrune, resumeHeartbeat), matching the established in-process-timer pattern. The sentinel class is unchanged — it already had scan(); we just call it on a cadence.
+
+## Signal-vs-authority compliance
+
+Not a gate — this is a scheduler wire, not a filter. The closest principle is the awake-machine gating: the coordinator (authority on which machine is active) decides whether this machine scans. The timer defers to `coordinator.isAwake` rather than making its own liveness call.
+
+## Interactions
+
+- **sessionComplete synthesis**: unchanged. The periodic scan and the completion synthesis are independent; scan()'s idempotency (hash-keyed digests) means a periodic scan immediately before sessionComplete won't double-digest the same activity window.
+- **scan() idempotency / dormant-skip / min-activity**: relied upon, unchanged. These guards are what make a 30-min cadence safe.
+- **SemanticMemory entity extraction (Phase 0d)**: this scan is what drives it mid-session. The two compose: scan → digestUnit → materializeEntities. No new coupling; the periodic scan just calls the same digestActivity path the sessionComplete handler already used.
+- **Multi-machine coordinator**: awake-gating added; mirrors `config.scheduler.enabled && coordinator.isAwake`. Standby machines skip.
+- **Scheduler / jobs.json**: untouched. This is an in-process timer, not a cron job, so it doesn't interact with quota-tracked job scheduling. (Note: the LLM spend of periodic digestion is NOT currently quota-gated the way scheduled jobs are — see follow-up.)
+
+## Telemetry / observability
+
+- A `console.log` fires on startup naming the cadence ("periodic scan every 30min").
+- Each scan that creates digests logs the count.
+- Failures log via console.error, never throw.
+- `SemanticMemory.stats()` entity/edge growth is the downstream signal that the pipeline is working end-to-end.
+
+## Rollback
+
+Single-commit revert removes the interval, the config field, and the helper. Reverts to sessionComplete-only — the pre-change behaviour. No data/config migration (the field is optional and absent by default).
+
+## Cross-framework portability (v1.0+)
+
+Framework-agnostic: the scan reads tmux capture + Telegram JSONL and digests via `sharedIntelligence`. No INSTAR_FRAMEWORK branching. Same cadence on Claude and Codex.
+
+## Follow-ups (tracked, not orphaned)
+
+1. **Quota-awareness for periodic digestion LLM spend.** Scheduled jobs route through QuotaTracker; this in-process timer does not. On a quota-constrained agent, periodic digestion competes with foreground work for the same budget. A future enhancement could check `quotaTracker.canRunJob` before each scan. Lower priority — digestion uses the cheap `fast` tier and dormant-skip keeps volume low.
+2. **Live runtime verification.** The spec's acceptance includes a manual live check (set 5-min cadence, send messages, confirm a digest appears mid-session). Requires a live multi-message session; noted for the next live-agent session.
+
+Both tracked as initiatives, intentionally out of scope here.