instar 1.3.608 → 1.3.610

package/package.json

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

package/upgrades/1.3.609.md

@@ -0,0 +1,24 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+WS5.2 Account Follow-Me, PR2 — the cross-machine enrollment **detection→consent surface** (Mechanism B re-mint). When the agent runs on more than one machine and a machine has no usable account for an operator subscription (a "depth-zero" machine), it now proactively detects that and surfaces ONE aggregated, phone-first consent ("authorize on the dashboard?") — and **enrolls nothing on its own**. Authorization remains the operator's PIN-gated mandate (issued on the target's own dashboard, per-server per OQ6); a peer can never enroll an account onto itself.
+
+Built on PR1's primitives: the request-never-self-authorize orchestrator, the depth-zero detector (R7-bounded), the per-machine depth adapter, the tolerant peer-views fetcher (reuses the `?scope=pool` fan-out, metadata-only — no token or config-home ever crosses), the cross-machine mandate bridge (R4a), and the composing service. Wired through `server.ts`/`AgentServer`/`RouteContext` and exposed at `POST /subscription-pool/follow-me/scan`. Ships DARK behind `multiMachine.accountFollowMe` (503 on the fleet, live on a development agent).
+
+## What to Tell Your User
+
+Still nothing to do yet — this is the next layer toward "log in once, it works on every machine," shipped off by default. With it, when one of your machines has no account, I'll notice and offer you a one-tap dashboard approval to enroll it (rather than ever doing it silently) — and no login token is copied between machines. The actual one-tap enrollment + safety checks land in the next PR.
+
+## Summary of New Capabilities
+
+Proactive cross-machine account-enrollment detection + consent (dark): the agent detects a machine with no usable account and surfaces ONE operator approval, enrolling nothing on its own. No user-facing surface is live in this release.
+
+## Evidence
+
+- 37 tests: 35 unit across 7 modules + 2 Tier-2 integration over the real HTTP pipeline (dark→503; enabled→detects a depth-zero peer→ONE consent, enrolls nothing); `tsc --noEmit` clean.
+- Side-effects review + mandatory independent second-pass security review (concurred) — verified no self-authorization path, no credential leak (peer fetch is metadata-only, configHome discarded), genuinely-inert fleet default, and no fail-open paths. Artifact: `upgrades/side-effects/ws52-account-follow-me-pr2.md`.
+- Spec: `docs/specs/ws52-account-follow-me-security.md` (converged, approved).

package/upgrades/1.3.610.md

@@ -0,0 +1,24 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+WS5.2 Account Follow-Me, §6.2 — the `locallyExecutable` account-selection gate. A new shared predicate `isLocallyExecutable(account)` (an account is executable on THIS machine iff it holds a real local `configHome` AND a valid login — active/warming) now gates account selection at its chokepoint: both `QuotaAwareScheduler.selectAccount()` (placement + swap-target selection) and `poolHeadroom()` (the quota throttle) filter on it, preserving the documented never-loop invariant `placeable ⟺ selectAccount(...) !== null`. A credential-less meta-only account replicated in from a peer (empty `configHome`) is now structurally unselectable — closing the force-mode "use an account I have metadata for but no credential" hole at SELECTION time. Adds `SubscriptionPool.locallyExecutable()` as the canonical machine-executable account set.
+
+This is a pure tightening: every real pool account already carries a non-empty `configHome` (required by `add()`), so among genuinely-held accounts the predicate is a no-op — it only ever excludes a credential-less peer projection. The structural guard that lets the later enrollment-execution PRs add accounts without any path ever selecting a peer's credential-less account.
+
+## What to Tell Your User
+
+Nothing to do — this is an internal selection-safety guard, shipped off by default as part of the multi-machine account-sharing groundwork. It guarantees this machine can only ever pick an account it actually holds a login for, never a peer's account it merely knows about. No user-facing surface in this release.
+
+## Summary of New Capabilities
+
+Internal: a `locallyExecutable` account-selection gate so a credential-less peer account projection can never be selected for execution, placement, or swap on this machine. Defense-in-depth groundwork for the WS5.2 enrollment-execution path. No user-facing surface.
+
+## Evidence
+
+- 9 unit tests (`tests/unit/account-follow-me-locally-executable.test.ts`): both boundary sides (executable active/warming + real configHome; non-executable empty/whitespace configHome, needs-reauth/disabled/rate-limited), selectAccount exclusion of a meta-only account, real-over-meta preference, no-regression for held accounts, and explicit never-loop-invariant agreement (`poolHeadroom.placeable ⟺ selectAccount !== null`) for meta-only and real cases. `tsc --noEmit` clean.
+- Side-effects review + mandatory independent second-pass security review (concurred): verified the never-loop invariant is preserved by the shared predicate, the change is a true no-op for current accounts, zero dangling references, no missed selection path, fail-closed (no fail-open). Artifact: `upgrades/side-effects/ws52-account-follow-me-locally-executable.md`.
+- Spec: `docs/specs/ws52-account-follow-me-security.md` §6.2 + §6.3a (converged, approved).

package/upgrades/side-effects/ws52-account-follow-me-locally-executable.md

@@ -0,0 +1,69 @@
+# Side-Effects Review — WS5.2 §6.2 `locallyExecutable` selection gate
+
+**Version / slug:** `ws52-account-follow-me-locally-executable`
+**Date:** `2026-06-17`
+**Author:** `Echo (instar-dev agent)`
+**Second-pass reviewer:** `pending (high-risk: account selection / credential boundary)`
+
+## Summary of the change
+
+WS5.2 §6.2. Adds a single shared predicate `isLocallyExecutable(account)` (exported from `src/core/SubscriptionPool.ts`) — an account is executable on THIS machine iff it carries a real local `configHome` AND a valid login (status `active`/`warming`). A meta-only account replicated in from a peer (credential-less, empty `configHome`) is NOT locally executable. The predicate is applied at the account-selection chokepoint in `src/core/QuotaAwareScheduler.ts` — in BOTH `selectAccount()` (the placement/swap selector, used by `ProactiveSwapMonitor` + `onQuotaPressure`/`SessionMigrator`) AND `poolHeadroom()` (the quota-throttle), which MUST share the exact eligibility predicate to preserve the documented never-loop invariant `placeable ⟺ selectAccount(...) !== null`. A `SubscriptionPool.locallyExecutable()` convenience method returns the filtered selectable set. Files: `SubscriptionPool.ts`, `QuotaAwareScheduler.ts`, plus `tests/unit/account-follow-me-locally-executable.test.ts`.
+
+## Decision-point inventory
+
+- `QuotaAwareScheduler.selectAccount()` eligibility filter — **modify** — tightened from status-only (`isEligibleStatus`) to `isLocallyExecutable` (status + non-empty configHome). A credential-less account is now unselectable.
+- `QuotaAwareScheduler.poolHeadroom()` eligibility filter — **modify** — tightened identically, preserving `placeable ⟺ selectAccount !== null`.
+- `SubscriptionPool.locallyExecutable()` — **add** — canonical read of the machine-executable account set.
+
+---
+
+## 1. Over-block
+
+**What legitimate inputs does this change reject that it shouldn't?**
+
+None. Every genuinely-held pool account carries a non-empty `configHome` (required by `SubscriptionPool.add()`, which trims and validates it), so among real accounts this predicate is a pure no-op — it returns exactly what `isEligibleStatus` returned before. It only ever excludes an account with an empty/whitespace `configHome`, which by construction has no local credential and therefore cannot spawn a session. There is no legitimate "selectable account with no configHome" today.
+
+## 2. Under-block
+
+**What failure modes does this still miss?**
+
+It gates SELECTION, not execution-time credential validity. An account that has a `configHome` and `active` status but whose on-disk token is stale/revoked still passes the predicate (the swap/refresh machinery + provider-side 401 handling owns that case — out of scope for §6.2). It also does not inspect token contents; a corrupted credential file at a valid `configHome` is caught downstream, not here. This is intentional: §6.2's job is "never select an account we hold no credential for," not "verify the credential works."
+
+## 3. Level-of-abstraction fit
+
+Correct layer. Account selection is exactly where "can this machine run this account?" must be decided — the predicate lives next to the `SubscriptionAccount` type (its canonical home) and is applied at the two selectors that gate placement. A higher layer (the router) does not select accounts (it routes SDK-vs-pool *path*, then the interactive pool runs whatever account the session was placed under); a lower layer (the credential store) does not know about selection. The shared-predicate design avoids the classic split-brain where two selectors drift.
+
+## 4. Signal vs authority compliance
+
+This is a **filter on a selection set**, not a brittle check with blocking authority over messages/actions. It is deterministic (a field-presence + status check), not heuristic — so it does not fall under the signal-vs-authority concern about brittle blocking logic. It cannot mis-fire on ambiguous input: `configHome` is either a non-empty string or not. It never blocks a user message or an outbound action; it only narrows which accounts a placement/swap may pick. Reference: `docs/signal-vs-authority.md` — a deterministic capability gate (can this machine physically execute this account) is authority appropriately exercised, not a brittle heuristic.
+
+## 5. Interactions
+
+The one real interaction is the **never-loop invariant** between `selectAccount` and `poolHeadroom`: the throttle's comment guarantees `placeable ⟺ selectAccount(...) !== null`. Tightening only one selector would break it (throttle says "go" while placement returns null → spin). Both are tightened with the SAME predicate, and a unit test asserts the two agree on a meta-only account. No other selector consumes these. `ProactiveSwapMonitor`/`SessionMigrator`/`onQuotaPressure` reach selection THROUGH `selectAccount`, so they inherit the gate for free. `PlacementExecutor` (cross-machine placement) does not select an account, so it is unaffected.
+
+## 6. External surfaces
+
+No new route, no new config, no user-facing surface. `SubscriptionPool.locallyExecutable()` is a new read method but no route exposes it in this change. Behavior visible to other agents/users is unchanged because the predicate is a no-op for all real accounts today (all have configHomes). It does not depend on timing or runtime conditions.
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+
+**Machine-local BY DESIGN.** This is the precise point of the change: a `configHome` is a per-machine credential location, so "locally executable" is inherently a per-machine question. The predicate deliberately treats a peer's account (which would arrive as a credential-less meta projection if/when a future scope=pool selection merges peer accounts into a local selection list) as NON-executable here. There is no replication or proxy-on-read surface — by design, each machine answers "which accounts can I run?" from its OWN configHome-bearing accounts. This is the structural guard that lets the later enrollment-execution PRs safely add accounts without any path ever selecting a peer's credential-less account.
+
+## 8. Rollback cost
+
+Trivial. Pure code change, no migration, no persisted state, no config. Revert is a single-commit back-out; because the predicate is a no-op for all current accounts, reverting changes nothing observable today. No agent state repair, no data migration.
+
+---
+
+## Second-pass review
+
+**Concur with the review.** Verified independently against the actual code, spec §6.2/§6.3a, build, and tests:
+
+1. **Never-loop invariant preserved** — `selectAccount` (`QuotaAwareScheduler.ts:103-108`) and `poolHeadroom` (`:141-143`) use the byte-identical eligibility predicate `isLocallyExecutable(a) && bindingUtilization(a.lastQuota) < soft`. `selectAccount`'s extra `a.id !== excludeId` is a pure narrowing on the swap path; the throttle calls `poolHeadroom` without an exclude, so `placeable ⟺ selectAccount(...) !== null` holds.
+2. **True no-op for current accounts** — `add()` (`SubscriptionPool.ts:308-309`) and `update()` (`:356-359`) both trim and reject empty `configHome`; no real account can have one. For real accounts `isLocallyExecutable` reduces to the old `active/warming` status check — exact behavioral parity.
+3. **Zero dangling `isEligibleStatus`** — grep across `src/` + `tests/` returns nothing; `tsc --noEmit` EXIT=0.
+4. **No missed selection path** — all `selectAccount`/`poolHeadroom` callers (`ProactiveSwapMonitor:226` swap-target, `server.ts:14343` spawn-resolver, `onQuotaPressure`, QuotaTracker throttle) route through the gated selectors. `AnthropicSubscriptionRouter` routes SDK-vs-pool *paths*, not accounts; `InteractivePoolIntelligenceProvider` runs sessions already spawned under a gated account; `mapCandidates` only enumerates running-session SOURCES; no `.list()[0]`-style ungated picks exist; `PlacementExecutor` doesn't select accounts.
+5. **Tests cover both boundary sides + invariant agreement** — 9/9 pass; explicit `poolHeadroom.placeable ⟺ selectAccount !== null` assertions for meta-only and real cases.
+6. **No fail-OPEN** — predicate is fail-closed (missing/non-string/empty `configHome` → false).
+
+Sound, well-tested pure tightening with the never-loop invariant correctly preserved.

package/upgrades/side-effects/ws52-account-follow-me-pr2.md

@@ -0,0 +1,59 @@
+# Side-Effects Review — WS5.2 Account Follow-Me, PR2 (Mechanism B enroll-drive)
+
+**Version / slug:** `ws52-account-follow-me-pr2`
+**Date:** `2026-06-17`
+**Author:** Echo (autonomous)
+**Second-pass reviewer:** REQUIRED (high-risk: credentials, mandate authorization, cross-machine mesh delivery) — to be appended.
+**Spec:** `docs/specs/ws52-account-follow-me-security.md` (converged 2026-06-13, approved)
+**Status:** READY — the detection→consent flow is built, production-wired, and tested (37 tests: 35 unit across 7 modules + 2 Tier-2 integration over the real HTTP pipeline; tsc clean). PR2 ships the detection/consent/offer surface; the email-gate-at-completion (S7) wiring + the router `locallyExecutable` gate are PR3 (selection-safety) <!-- tracked: CMT-1620 --> (the email-gate LOGIC is already built + unit-tested here; only its completion-flow wiring is PR3). Revocation is PR4 <!-- tracked: CMT-1620 -->.
+
+## Summary of the change
+
+PR2 builds Mechanism B (re-mint per machine) account enrollment — the "one approval per machine, ToS-safe" flow. Per OQ6 (resolved per the spec's lean + the 2-machine topology) the transport is **per-server operator-side selection**, not a new credential-adjacent mesh verb. PR2 ships the decision/orchestration logic (built, unit-tested) + the server-shell wiring (pending).
+
+Files added (all unit-tested, dark behind `multiMachine.accountFollowMe`):
+- `src/core/AccountFollowMeOrchestrator.ts` — §5.2 request-never-self-authorize: depth-zero → MandateGate.evaluate(`account-follow-me`) → deny/no-mandate ⇒ phone-first consent (never proceed/CLI); allow ⇒ proceed.
+- `src/core/AccountFollowMeEmailGate.ts` — §5.3/S7 email-validation-before-selectable (fail-closed; HIGH attention item on mismatch).
+- `src/core/AccountFollowMeDetector.ts` — depth-zero offer detection, R7-bounded (per-account max-follow cap, one-per-(account,target), in-flight dedup).
+- `src/coordination/AccountFollowMeMandateBridge.ts` — R4a cross-machine mandate package/accept via PR1's Ed25519 signMandateIssuance/verifyMandateIssuance.
+- `src/core/AccountFollowMeService.ts` — composes the above: `scanAndOffer()` (one aggregated consent, enrolls nothing) + `onMandateDelivered()` (verify → allow → enroll-drive instruction).
+- `src/core/accountFollowMeDepth.ts` — pure adapter: per-machine pool views → detector input (usable = locallyHeld + active/warming; meta-only ⇒ depth-zero).
+- `src/core/fetchPeerSubscriptionViews.ts` — extracts the `?scope=pool` fan-out into a tolerant, injectable peer-views fetcher (dark peers skipped, never throws).
+- `src/server/routes.ts` — `POST /subscription-pool/follow-me/scan` (dark→503; enabled→detect depth-zero peers→ONE aggregated consent attention item, enrolls nothing) + an optional `accountFollowMePeerViews` RouteContext field.
+- `src/server/AgentServer.ts` + `src/commands/server.ts` — thread + construct the real peer-views fetcher (listPoolMachines + fetchPeerSubscriptionViews, authToken).
+- `tests/integration/account-follow-me-scan-route.test.ts` — Tier-2 over the real HTTP pipeline (dark→503; enabled→detect+one-consent).
+- 37 tests total (35 unit across 7 modules + 2 Tier-2).
+
+## The eight side-effect questions (for the built decision logic)
+
+1. **Over-block** — The detector only offers to DEPTH-ZERO machines and caps per account; a machine that already serves is never offered, and the cap can suppress a legitimate offer past N machines (intended R7 bound, operator-tunable). No legitimate enrollment is silently lost — it's surfaced as consent or capped-by-policy.
+2. **Under-block** — PR2 logic does not itself perform the credential write (the server-shell does, pending); the at-rest residual / revocation (R10/R12) is PR4, tracked. The orchestrator denies by default, so the under-block risk (enrolling without authorization) is structurally closed at the decision layer.
+3. **Level-of-abstraction fit** — Decision logic is pure + injectable (no I/O), mirroring PR1's primitives; side effects (attention item, EnrollmentWizard drive, SubscriptionPool.add) are injected so the server-shell owns I/O. Correct layering.
+4. **Signal vs authority** — The orchestrator + bridge are AUTHORITIES (they gate a credential enrollment) but are NOT brittle: authorization delegates to the existing PIN-gated MandateGate + the R4a asymmetric signature, and every path FAILS CLOSED. No brittle check holds blocking authority; deny-by-default throughout.
+5. **Interactions** — Reuses PR1's CrossMachineMandate (no duplication) + the existing MandateGate (action-agnostic, no change needed) + the existing EnrollmentWizard/enroll routes (no fork). The `account-follow-me` action is a new string in the existing gate — no schema change.
+6. **External surfaces** — Dark on fleet. The consent surface is a phone-first dashboard deep-link, never a CLI instruction. The aggregated consent is ONE attention item (P17), never per-machine spam. No credential or token is in any surface the logic produces.
+7. **Multi-machine posture** — This IS the multi-machine feature. Mandate authority crosses via the R4a asymmetric signature (verified-operator binding); the credential is re-minted per machine (never replicated). Operator-rooted, not peer-quorum. Single-machine = no-op (no depth-zero peers).
+8. **Rollback cost** — Low. Dark behind `multiMachine.accountFollowMe`; revert the PR. No data migration (no live credential written by PR2's logic layer). The server-shell increment carries its own rollback once added.
+
+## Wired-surface notes (questions 2/6/8 for the shipped detection surface)
+
+- **Under-block (2):** the scan route only SURFACES consent (enrolls nothing); the credential write stays in the existing operator-driven enroll route. The email-gate (S7) validating a completed enrollment is PR3 <!-- tracked: CMT-1620 --> — until then a follow-me enrollment relies on the operator approving on the target's own dashboard (the existing, already-shipped enroll flow). No new credential path is opened by PR2.
+- **External surfaces (6):** the scan route fetches peers' PLAIN `/subscription-pool` (Bearer `config.authToken`, 4s timeout, dark-peer-tolerant) — same auth + tolerance posture as the existing `?scope=pool` / `/guards` fan-out. It surfaces ONE aggregated attention item (category `account-follow-me`), never per-machine spam. Dark on fleet (resolveDevAgentGate → 503).
+- **Rollback (8):** dark behind `multiMachine.accountFollowMe`; revert the PR. No data migration; no credential written by the detection surface. The `accountFollowMePeerViews` ctx field + server wiring are additive/optional.
+
+## Pending for PR3/PR4 (tracked)
+
+- PR3 <!-- tracked: CMT-1620 -->: wire the email-gate at enrollment completion (S7) + the router `locallyExecutable` gate (§6.2).
+- PR4 <!-- tracked: CMT-1620 -->: revocation (R12).
+
+## Second-pass review
+
+**Verdict: Concur with the review.** (Independent reviewer subagent, 2026-06-17; ran 35 unit + 2 integration tests green + `tsc --noEmit` clean.)
+
+Verified the four focus areas:
+- **(a) No self-authorization path** — `requestEnrollment` short-circuits to consent BEFORE the gate when no mandateId; only returns proceed on an explicit gate `allow`. `scanAndOffer` never passes a mandateId (structurally consent-only). `onMandateDelivered` requires the R4a asymmetric verify AND the real MandateGate (authorship/expiry/revocation/named-party/bounds). Deny-by-default holds.
+- **(b) No credential leak** — the peer fetch hits each peer's PLAIN `/subscription-pool` (no scope=pool recursion), projects only id/email/status, discards configHome; SubscriptionAccount structurally cannot carry a token; consent/attention surfaces are metadata-only.
+- **(c) Dark-default genuinely inert** — scan route 503s on the fleet via resolveDevAgentGate; integration test asserts it.
+- **(d) No fail-open bugs** — meta-only never counts usable; a dark peer can't make a held machine read depth-zero; email-gate + mandate-verify fail closed; the R7 cap is order-independent.
+
+Two non-blocking notes for the PR3+ author (NOT PR2 defects — PR2 never reaches these): the route wires `agentFp` to `ctx.config.projectName ?? 'self'`, which must match the named agent party once the real mandate-delivered flow lands in PR3; and the plain `/subscription-pool` route serializes `configHome` (a path, never a token; pre-existing, Bearer-gated) which the PR2 fetcher correctly discards.