instar 1.3.615 → 1.3.617

package/package.json

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

package/upgrades/1.3.616.md

@@ -0,0 +1,34 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+WS5.2 R7a — the per-account spend ceiling, lease-sliced and owned by the fenced single-writer, so multiple machines sharing one operator account can never collectively over-spend its quota (bounded by sum-of-leases, never N×ceiling — even under partition and across a lease-holder failover). New module `src/core/AccountFollowMeSpendSlice.ts` (pure/injectable): `SliceIssuer` (holder-side; refuses unless it holds the live fenced lease; delegates the sum-of-leases ceiling to the durable PR1 grant-ledger; epoch-stamps every slice), `SliceRenewalControl` (requester-side rate-cap + exponential backoff + per-(account,machine) coalescing + a P19 breaker that fails a machine closed to its OWN account when the holder is slow/partitioned — so the renewal RPC rate is O(per-account-cap), not O(N)), and `decideAccountUse` (the pure selection-time check — a borrowed account is used ONLY for a live, current-epoch, unexpired, positive-remaining slice; every uncertainty falls back to the machine's own account). A new operator-mandate-gated `slice-renew` mesh verb (its own deny-by-default RBAC case). The `AnthropicSubscriptionRouter` gains an optional consult hook (subscription-path only). Config knobs under `multiMachine.accountFollowMe.spendSlice`. Dark behind `multiMachine.accountFollowMe`.
+
+**Scope (honest):** this delivers the spend-ceiling MECHANISM + the consultation; the router currently surfaces the decision to observability. The pool's account selection actually choosing own-vs-borrowed based on it is the enforcement integration that requires the (not-yet-live) borrowed-account-in-pool concept — so the consultation is inert today by construction (nothing is borrowed yet), leaving no reachable over-spend path unguarded. The enforcement wiring lands with that selection layer.
+
+WS5.2 — one-dashboard cross-machine mandate delivery. Closes a real UX gap: authorizing an account-follow-me enrollment on another machine used to require a PIN-gated mandate issued on THAT machine's own dashboard (per-machine friction). Now the operator's SINGLE dashboard does it: a new PIN-gated `POST /mandate/issue-for-machine` issues the mandate locally and, for a remote target, packages it with the operator machine's Ed25519 signature (the already-approved ws52 R4a bridge) and delivers it over a new `account-follow-me-mandate-deliver` mesh verb. The target authenticates the mesh sender (existing Ed25519 envelope verification → the registered operator-machine identity), R4a-verifies the mandate's issuance signature against that registered key (a name in the payload is never trusted — Know Your Principal), checks the exact bounds (account-follow-me / this machine / re-mint), and persists it to a new `DeliveredMandateStore`. The enroll-start route then consults the delivered mandate (re-verifying the signature at point-of-use) when the local gate has none — both paths fail-closed. The core MandateGate authorship model is untouched. Dark behind `multiMachine.accountFollowMe`.
+
+## What to Tell Your User
+
+Nothing to do — this ships off by default. It's the safety cap that lets several of your machines share one subscription account without them collectively blowing past that account's quota: each machine gets a metered slice of the account's allowance from one coordinating machine, and if it can't reach that coordinator it quietly uses its own account instead of overspending the shared one.
+
+You now manage everything from your ONE dashboard — no more "open the other machine's dashboard." When you approve a machine to use one of your accounts, you do it once on your single dashboard with your PIN; your approval is cryptographically signed and delivered to that machine, which verifies it really came from you before acting. You never touch the other machine. (Off by default while the broader account-sharing feature is dark.)
+
+## Summary of New Capabilities
+
+Cross-machine per-account spend ceiling (dark): lease-sliced sub-budgets issued by the fenced single-writer, bounded by sum-of-leases under partition + failover, with an operator-mandate-gated renewal mesh verb and fail-closed-to-own-account on every uncertainty. No user-facing surface is live in this release.
+
+One-dashboard cross-machine mandate authorization (dark): issue + deliver an account-follow-me mandate to any of your machines from your single dashboard; the target verifies it via the R4a operator signature and honors it only for its exact bounds. New PIN-gated `POST /mandate/issue-for-machine` + the `account-follow-me-mandate-deliver` mesh verb. No user-facing surface is live until `multiMachine.accountFollowMe` is enabled.
+
+## Evidence
+
+- 59+ tests across `account-followme-spend-slice` (fenced issuance, non-holder refusal, sum-of-leases/Nth-VM refusal, failover re-derivation with no double-allocation, coalescing, rate-cap+backoff, refusal-vs-failure breaker distinction, breaker open/cooldown/reset, all `decideAccountUse` branches), `MeshRpc` (slice-renew deny-by-default RBAC: unwired/rogue/mandated), and `anthropic-subscription-router` (unwired byte-identical, consult on subscription paths only). `tsc --noEmit` clean. Dark-gate lint golden-map updated for the new config block (24/24).
+- Side-effects review + mandatory independent second-pass security review (concurred on all 7 audit points: sum-of-leases bound, failover no-double-allocation, fail-closed-to-own everywhere, deny-by-default RBAC, O(per-account-cap) control plane, dark-by-default, no fail-open).
+- Spec: `docs/specs/ws52-account-follow-me-security.md` R7a/R7/S5 (converged, approved).
+
+- 122 tests across 11 files (delivery store + accept/trust path: valid R4a → stored+honored; bad signature / untrusted key / issuer≠sender / wrong-target / wrong-mechanism / non-follow-me → refused & nothing persisted; mesh-verb RBAC deny-by-default; issue-for-machine PIN-gated + dark→503 + honest 502 on delivery failure + local-target unchanged; enroll-start honoring a delivered+verified mandate vs 403 without one; dashboard routing). `tsc --noEmit` clean.
+- Side-effects review + mandatory independent second-pass security review (concurred on all 8 points: trust anchor = authenticated sender never payload, R4a load-bearing fail-closed, exact-bounds double-gated no-replay, enroll-start additive fail-closed with point-of-use re-verify, PIN-gated issuance / no self-issue, deny-by-default mesh RBAC, dark-by-default, no fail-open).
+- Spec: `docs/specs/ws52-account-follow-me-security.md` R4a/R1/R6a (converged, approved) — wires the spec's R4a cross-machine mandate bridge.

package/upgrades/1.3.617.md

@@ -0,0 +1,22 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Fixed a server restart loop that could hit an agent on an overloaded machine. The supervisor's CPU-starvation guard — which is supposed to NOT restart an alive-but-slow server while the box is oversubscribed — judged load at a single instant. On a machine whose 1-minute load average oscillates around the starvation threshold, a momentary dip below the line tricked the guard into restarting a server that had been starved the whole time; the restart's heavy boot deepened the overload and the cycle repeated every ~11–15 minutes (2026-06-17 incident, topic 12476). `ServerSupervisor.deferRestartForCpuStarvation()` now judges **sustained** load — it samples the load ratio on each unresponsive health-check tick, keeps the last ~60 seconds of readings, and treats the box as starved if it was starved at any point in that window. A single dip can no longer authorize a restart. The recent-load window is dropped the moment the server recovers, so stale readings can't over-defer a later, unrelated episode. The genuinely-dead-process path (instant restart), the idle-machine-hung path (fast restart), and the ~5-minute hard-cap backstop are all unchanged.
+
+## What to Tell Your User
+
+If your agent felt laggy or kept "auto-restarting" on a busy machine — replies arriving late, messages queueing, the dashboard briefly 502-ing every ~10–15 minutes — that was this loop. Your agent now rides out short load spikes instead of bouncing itself, so it stays responsive under load. Nothing for you to do; it applies automatically on update. (Separately: if a machine is *chronically* overloaded, the real cure is reducing how much is running on it — this fix stops the self-inflicted restart loop, not the underlying load.)
+
+## Summary of New Capabilities
+
+No new user-facing capability — this is a reliability fix to the existing server supervisor. The supervisor's CPU-starvation restart guard now uses a sustained (windowed) load signal instead of an instantaneous one.
+
+## Evidence
+
+- `src/lifeline/ServerSupervisor.ts` — `deferRestartForCpuStarvation()` rewritten to use a windowed-max load signal over `loadSampleWindow` (6 samples ≈ 60s); window cleared on failure-streak reset; deferral log line now reports the sustained ratio.
+- `tests/unit/supervisor-cpu-starvation-defer.test.ts` — updated the test that encoded the old instantaneous behavior (it expected a restart after a single dip — the bug); added cases: a momentary dip does NOT restart a sustainedly-starved server (the 2026-06-17 loop), sustained easing eventually restarts (defer is not permanent), and the window is dropped on streak reset (no stale over-defer).
+- All 4 supervisor-related unit suites green: 40 tests passed (10 in the starvation-defer file). `tsc --noEmit` clean.

package/upgrades/side-effects/supervisor-sustained-starvation-fix.md

@@ -0,0 +1,81 @@
+# Side-Effects Review — Supervisor sustained-CPU-starvation restart guard
+
+**Version / slug:** `supervisor-sustained-starvation-fix`
+**Date:** `2026-06-17`
+**Author:** `Echo (instar-dev agent)`
+**Second-pass reviewer:** `(see Phase 5 section below — required: restart/recovery path)`
+
+## Summary of the change
+
+`ServerSupervisor.deferRestartForCpuStarvation()` decided whether to hold off restarting an alive-but-unresponsive server based on the **instantaneous** CPU load ratio (`loadRatioProvider() > maxLoadRatio`). On an oversubscribed box the 1-minute load average oscillates around the threshold, so a single sample dipping below it authorized a restart of a server that had been CPU-starved the whole time — and the restart's heavy boot deepened the starvation, producing a ~11–15-minute restart loop (2026-06-17 incident, topic 12476). The fix records the load ratio on each unresponsive tick into a small fixed window (`loadSampleWindow = 6`, ~60s) and treats the box as starved if the **windowed max** exceeds the threshold. The window is cleared when the failure streak resets (server recovered), so stale high readings can't over-defer a later episode. Files: `src/lifeline/ServerSupervisor.ts` (the guard + 4 new fields + the deferral log line now reports the sustained ratio), `tests/unit/supervisor-cpu-starvation-defer.test.ts` (updated the test that encoded the old instantaneous behavior; added dip-protection, sustained-easing, and window-reset cases).
+
+## Decision-point inventory
+
+- `ServerSupervisor.deferRestartForCpuStarvation()` — **modify** — the starvation SIGNAL feeding the restart authority is changed from instantaneous to a sustained windowed-max reading. No new authority added; the existing restart decision (and its hard cap) is unchanged in structure.
+
+---
+
+## 1. Over-block
+
+**What legitimate inputs does this change reject that it shouldn't?**
+
+Mapped to this domain, "over-block" = deferring a restart that genuinely should happen. The change makes deferral *more* likely (it holds off restarting while recent load was high). The bounded risk: a server that is genuinely hung (frozen event loop) AND happens to be on a box that was busy in the last ~60s will wait up to the full window (~60s) longer before the windowed max falls — and in the worst case waits for the ~5-minute hard cap, which is unchanged and still force-restarts. So the maximum added delay before a truly-hung server restarts is bounded by the existing hard cap; the change never *prevents* a restart, only delays it under recent-high-load — which is the intended, safe direction.
+
+## 2. Under-block
+
+**What failure modes does this still miss?**
+
+A box that is chronically starved for longer than the ~5-minute hard cap will still force-restart at the cap, which on a sustainedly-overloaded machine is itself unhelpful (restarting never cures starvation). This fix addresses the dominant observed failure (the sub-cap dip-triggered restarts at "10 checks") but does NOT change the hard-cap behavior. Making the hard cap escalate-instead-of-restart under sustained starvation is a genuine follow-up. <!-- tracked: topic-12476 --> The real cure for chronic starvation is reducing machine load (surfaced to the operator separately).
+
+## 3. Level-of-abstraction fit
+
+**Is this at the right layer?**
+
+Yes. The supervisor is the correct owner of the server-restart decision (process lifecycle). The starvation check is a *detector signal* feeding that authority; this change improves the signal's quality (smoothing out single-sample noise) rather than adding a new authority. It reuses the existing injectable `loadRatioProvider` / `cpuStarvation` primitive — no re-implementation of load reading.
+
+## 4. Signal vs authority compliance
+
+**Does this hold blocking authority with brittle logic, or produce a signal that feeds a smart gate?** (`docs/signal-vs-authority.md`)
+
+Compliant. The brittle part (reading load) is a detector; this change makes that detector *less* brittle by replacing an instantaneous reading with a sustained windowed one. The restart authority (the supervisor's deterministic lifecycle policy — appropriate for this tightly-constrained domain) is unchanged. No new brittle blocker is introduced; the existing one is smoothed.
+
+## 5. Interactions
+
+**Does it shadow another check, get shadowed, double-fire, race?**
+
+- It interacts only with `evaluateUnhealthyServer()`, which calls it once per unresponsive tick. No new timers, no concurrency. The window is single-threaded supervisor state.
+- The hard-cap early-return is preserved and runs *after* the sample is recorded, so the window stays accurate for logging.
+- The window-reset detection keys on `consecutiveFailures` not strictly increasing (it strictly increases within a streak; a new episode restarts at the threshold) — verified against all reset sites; deferral is only consulted at/above threshold, so the `<=` reset test is correct.
+- SleepWakeDetector uses the same `cpuStarvation` ratio but keeps its own state — no shared mutable state touched.
+
+## 6. External surfaces
+
+**Anything visible to other agents/users/systems? Timing/state dependencies?**
+
+Only the supervisor's own log line changes wording (now reports the sustained ratio + window). No API, no message, no cross-agent surface. Behavior is purely local process-lifecycle. The only timing dependency is the existing 10s health-check cadence, which the window is sized against (6 samples ≈ 60s).
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+
+**Machine-local BY DESIGN.** The supervisor watches the server on its OWN machine; CPU starvation and restart decisions are inherently per-machine. There is no cross-machine state to replicate and nothing to proxy on read — each machine's supervisor independently judges its own load. No one-voice/transfer/URL concerns (no user-facing notice, no durable shared state, no generated link).
+
+## 8. Rollback cost
+
+**If wrong in production, what's the back-out?**
+
+Low. Single-file logic change behind the existing injectable provider. Back-out = revert the commit (a hot-fix patch release). No data migration, no state repair — the supervisor holds only in-memory transient state (the load window), which resets on the next boot. Worst-case failure mode of the fix itself (over-deferral) is bounded by the unchanged ~5-minute hard cap.
+
+---
+
+## Phase 5 — Second-pass review (required: restart/recovery path)
+
+**Reviewer:** independent reviewer subagent (general-purpose), 2026-06-17.
+
+**Verdict: Concur with the review.**
+
+Independent audit findings:
+- **Windowing correctness:** the counter strictly increases within a streak because `consecutiveFailures++` precedes every `evaluateUnhealthyServer()` call (both failure callsites), so the `<=` reset-detection correctly distinguishes a continuing streak (no clear) from a new episode (clear); it cannot false-clear mid-streak.
+- **Empty-array / -Infinity:** safe — a sample is pushed unconditionally before every `Math.max(...)`, even right after a reset-to-`[]`.
+- **Safety valves all preserved:** dead process restarts instantly (early return before the guard); hung server on an idle box restarts promptly (window fills with low samples → max < threshold); the ~5-min hard cap still force-restarts.
+- **Signal vs authority:** compliant — improves a detector signal (instantaneous → sustained windowed-max), no new brittle authority.
+- **Direction:** only ever makes restart *less* aggressive; max added delay for a truly-hung-on-recently-busy box is bounded by the unchanged hard cap.
+- **Test quality:** the new tests genuinely fail against the old instantaneous code (the dip-sample and first-eased-tick cases).

package/upgrades/side-effects/ws52-account-follow-me-r7a-spend-slice.md

@@ -0,0 +1,70 @@
+# Side-Effects Review — WS5.2 R7a: lease-sliced per-account spend ceiling
+
+**Version / slug:** `ws52-account-follow-me-r7a-spend-slice`
+**Date:** `2026-06-17`
+**Author:** `Echo (instar-dev agent)`
+**Second-pass reviewer:** `pending (HIGHEST-risk: cross-machine money/quota ceiling under partition + a new operator-mandate-gated mesh verb)`
+
+## Summary of the change
+
+WS5.2 R7a. A per-account spend ceiling, lease-sliced, owned by the fenced single-writer (the `FencedLease` holder), so N machines sharing one operator account can never collectively over-spend its quota — bounded by sum-of-leases, never N×ceiling, even under partition and across lease-holder failover. New module `src/core/AccountFollowMeSpendSlice.ts` (pure/injectable): `SliceIssuer` (holder-side — refuses `not-lease-holder`, stamps the current lease epoch, delegates the sum-of-leases ceiling to the existing durable `AccountFollowMeGrantLedger`); `SliceRenewalControl` (requester-side rate-cap + exponential backoff + per-(account,machine) coalescing + P19 breaker → fail-closed-to-own-account on a slow/partitioned holder); `decideAccountUse` (pure selection-time consultation — borrowed account used ONLY for a live, current-epoch, unexpired, remaining>0 slice; every uncertainty → own account). A new operator-mandate-gated `slice-renew` mesh verb in `MeshRpc.ts` (its own deny-by-default `checkCommandRBAC` case via an injected `authorizeSliceRenew` seam). `AnthropicSubscriptionRouter` gains optional `consultSlice`/`onSliceConsult` hooks invoked only on the subscription-pool selection path (no-op when unwired). Config knobs under `multiMachine.accountFollowMe.spendSlice`. Dark behind `multiMachine.accountFollowMe`; default behavior byte-identical when the hook is unwired/off.
+
+## Decision-point inventory
+
+- `slice-renew` mesh verb RBAC — **add** — deny-by-default; only the operator-mandate-authorized requester (via `authorizeSliceRenew`) may request a slice; absent seam → deny.
+- `SliceIssuer.issueForRenew` — **add** — only the live `FencedLease` holder issues; ceiling enforced by the durable ledger; epoch-stamped.
+- `decideAccountUse` — **add** — selection-time: borrowed vs own account; fail-closed-to-own on every uncertainty.
+- `SliceRenewalControl` — **add** — the control-plane bound (rate-cap/coalesce/breaker) → O(per-account-cap) renewal RPCs.
+
+---
+
+## 1. Over-block
+
+The conservative direction is intentional: when a slice is unknown/stale/expired/exhausted, or the holder is slow/partitioned, a machine "over-blocks" by falling back to its OWN account rather than using the borrowed one. This is the REQUIRED safe direction (never overspend a borrowed money/quota credential). It cannot wrongly deny the machine's own account (fallback is always available). No legitimate over-block of a healthy borrowed slice (a live current-epoch slice with budget is used).
+
+## 2. Under-block
+
+The ceiling is enforced at slice ISSUANCE (the ledger refuses `outstanding + amount > ceiling`) and at selection (a machine without budget falls back). It does NOT meter per-call token spend WITHIN a slice — a slice is a pre-allocated sub-budget; intra-slice accounting is the slice's granularity (by design — the spec's lease-slice model). A compromised holder could in principle over-issue, but the holder is the fenced single-writer (the same trust root as who-is-awake) and the ledger still caps the durable sum; a non-holder cannot issue at all.
+
+## 3. Level-of-abstraction fit
+
+Correct layers: issuance authority on the FencedLease holder (the existing single-writer), durable accounting in the existing GrantLedger (reused, not rebuilt), the renewal control-plane as a pure injectable state machine, the consultation as a pure function the router calls. The mesh verb sits in MeshRpc with the other commands. No logic duplicated; the ledger's sum-of-leases + epoch-fencing is reused as-is.
+
+## 4. Signal vs authority compliance
+
+The authority here (issue a spend slice) is held by the fenced single-writer + gated by the operator mandate (deny-by-default) — appropriate, not a brittle heuristic. The consultation (`decideAccountUse`) is a deterministic pure function (field checks on a slice), fail-closed. The breaker is a signal (consecutive transport failures → open) that only ever makes a machine MORE conservative (fall back to own account). No brittle blocking authority over user actions. Reference `docs/signal-vs-authority.md`: operator-mandate + fenced-single-writer authority, deny-by-default, is correctly-placed.
+
+## 5. Interactions
+
+Reuses `AccountFollowMeGrantLedger` (PR1) for the durable sum-of-leases bound + epoch-fenced consume — failover re-derivation is "for free" because `SliceIssuer` holds no in-memory slice state (reads the durable store live; a new holder over the same store sees the committed set). The `not-lease-holder` guard prevents a stale ex-holder from issuing during a handoff. The breaker distinguishes grant REFUSALS (`would-exceed-ceiling` — the holder answered; back off but don't trip) from transport FAILURES (trip the breaker) — so a healthy-but-full account doesn't open the breaker. The router hook runs only on the subscription path (never sdk-credit), so it can't perturb SDK routing.
+
+## 6. External surfaces
+
+One new mesh verb (`slice-renew`), deny-by-default, dark behind the flag. New config block (`spendSlice`, additive, defaulted). No new HTTP route. When `multiMachine.accountFollowMe` is off (or the router hook unwired — the default), behavior is byte-identical: the consult hook is never invoked. Other agents see the new verb only if they're mandated peers in a follow-me pool.
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+
+This IS a multi-machine coherence mechanism by construction. The single source of truth is the fenced-lease holder + the durable grant-ledger; slices are epoch-stamped so a failover voids stale-epoch slices and the new holder re-derives the outstanding set from the durable store before issuing — the sum-of-leases bound holds across the handoff with no double-allocation. Under partition, a VM that can't reach the holder fails closed to its own account (bounded, never unbounded overshoot). The renewal control plane is O(per-account-cap), not O(N), so it can't storm the holder. A single-machine agent is a no-op (no peers, the flag is off).
+
+## 8. Rollback cost
+
+Low. Entirely dark behind `multiMachine.accountFollowMe` + the unwired router hook → no live effect by default. New module + additive config + one mesh verb. Revert is a single-commit back-out; no migration, no persisted-schema change (the slice records live in the existing grant-ledger store, which already shipped in PR1).
+
+---
+
+## Scope note (honest, not a hidden deferral)
+
+R7a delivers the spend-ceiling MECHANISM end-to-end: the fenced-single-writer slice issuer (ledger-backed sum-of-leases ceiling + epoch-fenced failover re-derivation), the requester-side renewal control plane (rate-cap + coalescing + P19 breaker → O(per-account-cap)), the operator-mandate-gated `slice-renew` mesh verb, the pure `decideAccountUse` consultation (fail-closed-to-own on every uncertainty), AND the router hook that invokes it. The router currently SURFACES the decision to observability (`onSliceConsult`); the pool's account-selection actually CHOOSING own-vs-borrowed based on that decision is the enforcement integration that belongs to — and requires — the borrowed-account-in-pool concept, which is not yet live (enrollment adds accounts as normal local accounts; nothing is marked `isBorrowedAccount` yet). So the consultation is inert today by construction (every account → `own`), meaning there is NO reachable over-spend path that this layer leaves unguarded. This is the correct decomposition for a dark mechanism, not a deferral of reachable behavior; the enforcement wiring lands with the borrowed-account selection layer.
+
+## Second-pass review
+
+**Concur with the review** (security substance) — the independent reviewer verified all 7 points directly:
+1. **Sum-of-leases bound holds** — `SliceIssuer.issueForRenew` delegates to the ledger's `issue()` (re-reads outstanding from the durable store, refuses `outstanding + amount > ceiling`); `SliceIssuer` holds ZERO in-memory accounting state; the `GrantStore` is synchronous so no interleave past the ceiling (structural invariant: keep the store synchronous). `outstandingFor` conservatively over-counts (safe direction).
+2. **Failover / no double-allocation** — `holdsLease()` blocks a stale ex-holder; the new holder re-derives from the same durable store; epoch-stamped slices are void on stale epoch. Tested.
+3. **Fail-closed-to-own on every uncertainty** — `decideAccountUse` returns `own` for flag-off / not-borrowed / no-slice / stale-epoch / expired / `!(remaining>0)` (0, negative, NaN). `borrowed` only via a live current-epoch unexpired positive-remaining slice.
+4. **slice-renew RBAC deny-by-default** — own `checkCommandRBAC` case; `authorizeSliceRenew?.(...) ?? false` → absent seam OR false → 403; not the any-peer read class.
+5. **Control plane O(per-account-cap)** — coalescing + rate-cap + exponential backoff + P19 breaker on transport `failed` only; grant `refused` (would-exceed-ceiling) backs off but does NOT trip the breaker.
+6. **Dark by default / byte-identical when off** — `consultSlice` no-ops when unwired; subscription-path only, never sdk-credit. (Observe-only in this layer — see Scope note above.)
+7. **No fail-open** — no catch/`||true`/default-allow; every positive outcome follows explicit guards.
+
+The reviewer's one CONCERN was the dark-gate lint golden-map line shift from the new `spendSlice` config block — **FIXED**: the 7 shifted entries updated to the attributor's values (924/949/978/1147/1269/1314/1339); `lint-dev-agent-dark-gate.test.ts` now 24/24 green. tsc EXIT=0; the 3 R7a suites 59 passed.