instar 1.3.598 → 1.3.600

package/package.json

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

package/upgrades/1.3.599.md

@@ -0,0 +1,21 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Closes the bug the gold-standard live-test caught: multi-machine placement assigned a Slack channel to a machine connected to a DIFFERENT Slack workspace, so the channel "owned" by that machine black-holed (the user got a "working…" standby, never a reply). Placement now knows which channels each machine's adapters can actually reach (`MachineCapacity.servesChannels`, adapter-derived on the heartbeat) and refuses to own a Slack channel on a machine not connected to its workspace — three-valued (`yes`/`no`/`unknown`), `yes` ranked over `unknown` (fail-open on a missing/old signal), all-`no` → `queued` + an honest "no machine serves this" attention surface (never a black-hole pick). Mirrors CMT-1570 (which made placement quota-aware). Ships behind the existing multi-machine path; single-machine = no-op; inert until the Slack inbound threads the channel scope (telegram is shared, so it's deliberately not threaded).
+
+## What to Tell Your User
+
+Nothing user-facing yet — it ships behind the multi-machine path and is the fix for the cross-machine bug the live-test caught (a Slack channel served on the wrong machine). The payoff lands when the multi-machine flags are flipped on.
+
+## Summary of New Capabilities
+
+Internal: placement avoids a machine that can't reach a channel's platform/workspace (mirrors the quota-awareness fix). No new routes or flags; rides the existing multi-machine heartbeat.
+
+## Evidence
+
+- `tests/unit/machineServesChannel.test.ts` (8), `tests/unit/PlacementExecutor.test.ts` (+8 serve-filter), `tests/unit/SessionRouter.test.ts` (+3 incl. the behavioral proof that a Slack channel places on the machine serving its workspace, not the cheaper non-serving one — the bug fixed — and the failover wiring-integrity test). 71 relevant tests green; tsc clean.
+- Spec converged 6 iterations (5 cross-model codex/gpt-5.5 + lessons-aware + decision-completeness), ~33 findings; second-pass implementation review concurs.

package/upgrades/1.3.600.md

@@ -0,0 +1,44 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+The (already-built, dark) multi-machine transfer CAPSTONE harness is now RUNNABLE behind
+a dev-gated route. `POST /live-test/multi-machine-capstone` moves the seat FIRST (local
+`/pool/transfer`), demands the honest `seatMoved` signal (records a `200 capstone:'aborted'`
+on a non-move — never a misleading PASS), then drives the §7.5 risk-category matrix through
+the REAL user surfaces and records a signed PASS/FAIL artifact (PASS only where the reply
+came FROM the target machine). `GET /live-test/artifacts` lists the recorded artifacts.
+A surface whose demo credential is absent is reported in `blockedSurfaces` and fails loudly
+via the driver — never a fabricated reply. Ships DARK (`monitoring.liveTestRunner.enabled`
+omitted → `resolveDevAgentGate`: live on dev, 503 on the fleet). Driven by the converged +
+approved `live-user-channel-proof-standard` (§6 / §7.5).
+
+## What to Tell Your User
+
+Nothing user-facing yet — this is an experimental, developer-only self-test that ships
+turned off on the fleet. It exists so the agent can prove a multi-machine conversation
+move works end-to-end through the real channels (Telegram and Slack) before you ever have
+to test it — the first application of the Live-User-Channel Proof standard. The payoff is
+invisible reliability: features get caught failing in a live self-test instead of by you
+on first use.
+
+## Summary of New Capabilities
+
+Internal / developer-only: a gated endpoint that runs the gold-standard live-test harness
+over the cross-machine conversation move (it moves the seat first, asserts the reply comes
+from the target machine, and records a signed pass/fail report), plus a read-only endpoint
+to list those reports. No fleet-facing surface; off by default.
+
+## Evidence
+
+- `tests/unit/multiMachineCapstoneMatrix.test.ts` (8) — the §7.5 matrix builder.
+- `tests/unit/LiveTestRunner-capstone.test.ts` (3) — seat-move-first + reply-from-target.
+- `tests/integration/live-test-capstone-route.test.ts` (7) — route 200/400/aborted/auth +
+  seatMoved:true→artifact / seatMoved:false→no artifact.
+- `tests/e2e/live-test-capstone-alive.test.ts` (4) — feature-alive on the REAL AgentServer
+  init path: wired→200, dark→503, Bearer-required, shared-store wiring-integrity.
+- `tsc --noEmit` clean. Ratchets green: no-silent-fallbacks, CapabilityIndex,
+  feature-delivery-completeness, docs-coverage (all class floors met).

package/upgrades/side-effects/live-test-capstone-runner-route.md

@@ -0,0 +1,89 @@
+# Side-Effects Review — Live-Test Capstone Runner Route
+
+**Change:** Make the (already-built, dark) multi-machine transfer CAPSTONE harness RUNNABLE.
+Adds `POST /live-test/multi-machine-capstone` + `GET /live-test/artifacts`, the
+`liveTestRunnerCtx` wiring (a `LiveTestRunnerWiring` factory on `AgentServer`), the
+`multiMachineCapstoneMatrix` builder, and registers `liveTestRunner` in the dev-gated
+feature registry. DEV-GATED + DARK (`monitoring.liveTestRunner.enabled` omitted from
+ConfigDefaults → `resolveDevAgentGate`: live on a dev agent, dark on the fleet → routes
+503). Driven by the converged + approved `docs/specs/live-user-channel-proof-standard.md`
+(§6 / §7.5).
+
+**Files:** `src/commands/server.ts` (ctx factory), `src/server/AgentServer.ts`
+(`LiveTestRunnerWiring` type + ctor wiring), `src/server/routes.ts` (the two routes),
+`src/core/multiMachineCapstoneMatrix.ts` (the §7.5 matrix builder),
+`src/core/devGatedFeatures.ts` (registration). Tests: unit (matrix + runner-capstone),
+integration (route 200/503/400/aborted/auth), e2e (feature-alive on the real AgentServer
+init path).
+
+## 1. Over-block — legitimate inputs wrongly rejected?
+The route rejects only missing `targetMachine`/`telegramTopicId` (400). A surface whose
+demo credential is absent is **not** rejected — it is recorded in `blockedSurfaces` and
+its scenarios surface as a loud driver-error FAIL via `RealChannelDriver`'s "no real
+sender configured" throw. No legitimate run is silently dropped: a non-moving seat is a
+recorded `200 capstone:'aborted'` (the honesty contract), never a 400/500.
+
+## 2. Under-block — failure modes still missed?
+- A demo SENDER that is mis-configured (wrong token) fails at send time → the scenario
+  records a driver-error FAIL (honest), not a fabricated PASS. Acceptable.
+- The Slack production path uses `SlackApiClient(demoSlackUserToken)` (a Bearer xoxp
+  token). Reality: the available SageMind-Live-Test creds are an `xoxc` web-client token
+  + `d` cookie, not xoxp — so with today's creds the Slack surface reports
+  `credential-unavailable` (blocked, HONEST) rather than running. The Telegram surface is
+  the capstone's reply-from-target channel. **Tracked follow-up (CMT-1568):** an
+  xoxc+cookie Slack drive variant to actually run the Slack channel-parity scenario.
+  `<!-- tracked: CMT-1568 -->`
+- The responder-machine resolver keys every surface on `telegramTopicId` (there is no
+  live Slack-channel→topic resolver) — documented inline as a GUESS; only affects the
+  optional Slack scenario. `<!-- tracked: CMT-1568 -->`
+
+## 3. Level-of-abstraction fit
+Correct layer: the route composes existing, separately-tested primitives
+(`RealChannelDriver`, `TelegramLiveSender`/`SlackLiveSender`, `LiveTestHarness`,
+`LiveTestRunner`, `PlacementResponderReader`, `DemoChannelRegistry`) and the shared
+`LiveTestArtifactStore` (the SAME store `LiveTestGate` reads, so a run's artifact is
+exactly the artifact the gate later verifies). No business logic is re-implemented in the
+route — it is composition + request validation + the seat-move-first orchestration the
+standard mandates.
+
+## 4. Signal vs authority compliance
+The route holds **no blocking authority over agent behavior**. It runs a test harness and
+records a signed artifact. The only authority-adjacent component (`LiveTestGate`, which
+computes a completion veto) is unchanged by this PR and remains dry-run. The route is a
+pure producer of an observable artifact — Signal, not Authority. (`docs/signal-vs-authority.md`.)
+
+## 5. Interactions
+- Shares the `LiveTestArtifactStore` instance with `LiveTestGate` by construction (server.ts
+  threads the SAME store into both) — verified by the e2e wiring-integrity test (d).
+- The seat-move calls the LOCAL `/pool/transfer` (production) — same route the operator
+  uses; it is read through the honest `seatMoved` signal (the #1188 fix), never assumed.
+- `transferForRequest` / `driverForRequest` are TEST-ONLY injection seams (undefined in
+  production); they let the e2e exercise the real AgentServer route with no live pool/network.
+- No double-fire / no shadowing: the routes are new prefixes; CapabilityIndex +
+  feature-delivery-completeness ratchets pass.
+
+## 6. External surfaces
+When RUN on a dev agent it posts a real demo message into a real (throwaway) channel and
+moves a real seat — but it is DEV-GATED + DARK, requires explicit demo creds, and every
+scenario is `safe`-volatility. On the fleet the routes 503 (no external effect). The run
+is operator-gated in practice (demo-sender provisioning + a live destination machine).
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+**Machine-local BY DESIGN.** The artifact store + the route are per-machine: the capstone
+is RUN from one machine (the test driver) and asserts the reply was served FROM the target
+machine via `PlacementResponderReader` (GET /pool/placement). The cross-machine fact being
+PROVEN is the responder identity; the runner itself does not replicate state. Recorded
+artifacts are local observability (like the live-test gate's). No generated URLs; no
+user-facing notice (dark infra) → no one-voice concern.
+
+## 8. Rollback cost
+Trivial. Dark by default (503 on fleet). Back-out = omit/disable
+`monitoring.liveTestRunner.enabled` (already the fleet default) or revert the PR — no data
+migration, no agent-state repair. The shared store is additive (read-only to the gate).
+
+## Second-pass review
+**Not required.** The change adds a test-harness RUN route with no block/allow authority
+over agent behavior, no session-lifecycle mutation, and no gate/sentinel/watchdog decision
+logic. It interacts with `LiveTestGate` only by sharing an artifact store (read path
+unchanged). The seat-move uses the existing honest `/pool/transfer` contract. Risk is
+bounded by the dev-gate + dark default + safe-only scenarios.

package/upgrades/side-effects/placement-platform-workspace-aware.md

@@ -0,0 +1,43 @@
+# Side-Effects Review — platform/workspace-aware placement (CMT-1568)
+
+**Slug:** placement-platform-workspace-aware
+**Spec:** docs/specs/placement-platform-workspace-aware.md (converged 6 iterations + approved)
+**Files:** src/core/machineServesChannel.ts (+test), src/core/PlacementExecutor.ts (+test), src/core/types.ts, src/core/PeerPresencePuller.ts, src/core/MachinePoolRegistry.ts, src/messaging/slack/SlackAdapter.ts, src/commands/server.ts, src/core/SessionRouter.ts (+test)
+**Posture:** ships behind the EXISTING multi-machine path. Single-machine = no-op (lone machine serves its own channels / fail-open). The filter is a strict no-op until a caller threads `req.channel` (only the Slack inbound does) — so the change is inert everywhere else.
+
+## What it is
+Closes the live-test-caught bug: placement assigned a Slack channel to a machine connected to a DIFFERENT workspace → black-hole. Adds `MachineCapacity.servesChannels` (adapter-DERIVED reachability), a three-valued (`yes`/`no`/`unknown`) `machineServesChannel` filter in `PlacementExecutor.decide()`, and threads the channel scope from the Slack inbound through the router into placement.
+
+## Phase 1 — Principle check (signal vs authority)
+The `yes`/`unknown` narrowing is a pure SIGNAL fed into the existing `PlacementExecutor` authority (same posture as CMT-1570's quota signal) — it never blocks a message. The one deterministic refusal (all-`no` → `queued`/`no-machine-serves-channel`) is a STRUCTURAL VALIDATOR per docs/signal-vs-authority.md: it rests on the enumerable objective fact "zero connected machines reach this workspace," not a judgment — and it reuses the EXISTING `queued`/null unsatisfiable outcome (no new blocking authority, no new return variant). Compliant.
+
+## Phase 4 — Side-effects answers
+1. **Over-block** — could a machine that CAN serve be dropped? Only on a PRESENT-and-fresh `no`. Absent/legacy signal = `unknown` = eligible (fail-open). `yes` is ranked ABOVE `unknown` so a missing signal never strands a known-reachable machine. Worst over-block: a brief stale `no` between a workspace reconnect and the next heartbeat → that machine is skipped for one window (recovered next beat). Bounded.
+2. **Under-block** — workspace-membership ≠ channel-permission (private-channel/bot-membership/Slack-Connect). Accepted as a first-stage filter (the spec's reachability-not-authority scope); the failed-post-feedback follow-up unifies it with the false-`yes` case. The wrong-workspace STRUCTURAL black-hole (the actual bug) IS closed.
+3. **Level-of-abstraction fit** — correct: mirrors CMT-1570 exactly (a capability signal on the capacity heartbeat + a parallel `decide()` filter). No new layer.
+4. **Signal vs authority** — see Phase 1. Compliant.
+5. **Interactions** — the filter runs AFTER the quota gate, BEFORE the ordering loop; it narrows `candidates` (and `eligible`, so a hard-pin to a `no` machine → the existing `hard-pin-unavailable`/`hard-pin-unsatisfiable` path). It does not shadow the quota gate (orthogonal signal) or the capability (`capOk`) gate. The all-`no` `queued` outcome flows into the EXISTING SessionRouter `decision.outcome === 'queued'` handler (raiseAttention + queueMessage) — no new consumer code; the dedup/wording refinement of that attention is a tracked follow-up (the generic attention already surfaces it, never a black-hole).
+6. **External surfaces** — the producer reports `servesChannels` on the capacity heartbeat (other machines read it — same surface as quotaState). The Slack inbound now threads the channel scope. **KEY DECISION: telegram is NOT threaded** — telegram is a SHARED chat (every machine reports the same chatId → the filter is a no-op for telegram), so only the Slack inbound sets `req.channel`. This sidesteps the telegram-chatId-secret-resolution complication AND the "present-servesChannels-without-a-telegram-block reads as `no`" trap (telegram channels never consult the filter). The producer still reports telegram when its chatId is a concrete value, for completeness.
+7. **Multi-machine posture** — REPLICATED: `servesChannels` rides the existing capacity-heartbeat path (PeerPresencePuller allow-list + recordHeartbeat + both PeerCapacity types; MachinePoolRegistry obs type + forward), exactly like quotaState. Single-machine = no-op. This is the whole point — it makes "follow the user across machines" correct for per-machine-scoped Slack workspaces.
+8. **Rollback cost** — low: revert the commit. The filter is fail-open + inert without `req.channel`; `servesChannels` is an optional heartbeat field (older peers omit it → `unknown`). No migration, no durable-state change.
+
+## Spec-implementation reconciliations (documented build-time refinements of the approved spec)
+- **all-`no` returns `queued` (not "local-ingress machine"):** the real `decide()` contract ALREADY returns `queued`/null for unsatisfiable cases (`no-capable-machine`, `hard-pin-unavailable`); the pure `decide()` has no "ingress machine" concept. So all-`no` reuses `queued`/`no-machine-serves-channel` — contract-consistent, surfaced via the existing queued→attention path. Spec updated to match.
+- **telegram not threaded** (finding G6 above) — documented in the spec's ingress-model section (telegram is shared → filter no-op) and here.
+
+## No-deferrals
+The security-hardening (corroborated/leased `yes`), the channel-ACL routing, and the Attention-dedup-wording refinement are tracked follow-ups (`<!-- tracked: CMT-1568 -->` in the spec) — NOT deferrals of THIS fix, which closes the wrong-workspace black-hole completely and is fully tested (71 unit tests across machineServesChannel + PlacementExecutor + SessionRouter, incl. the behavioral proof + the failover wiring-integrity test).
+
+## Phase 5 — Second-pass review (routing decision point)
+An independent implementation reviewer traced every `decide()` branch + the threading. **Concur — implementation correct on the routing hot path, no ship-blocking bugs.** Verified: yes-over-unknown ranking; all-`no` early-return guarded (`candidates.length>0` — never a misleading channel verdict when quota already emptied candidates); `eligible` narrowing makes pin-to-`no`→hard-pin-unsatisfiable while pin-to-`unknown` stays honored; producer is adapter-derived (slack gated on `isConnected`) and the telegram `typeof` guard correctly rejects a `{secret:true}` object marker; undefined workspaceId → `unknown`/fail-open (not `no`); `_connected` lifecycle correct across reconnects; the telegram trap is avoided (verified BOTH telegram `route()` callers + the mesh redrive thread NO `channel` → telegram always `unknown`/no-op).
+
+Two non-blocking forward-looking notes (both tracked, neither a live bug):
+- **RebalancePlanner.decide() doesn't thread `channel`** — a dormant black-hole door (rebalance could move a Slack session onto a non-serving machine). DORMANT: RebalancePlanner is not wired into server.ts. Added a tracked guard-comment at RebalancePlanner.ts:83 to plumb `channel` before rebalance is ever activated. <!-- tracked: CMT-1568 -->
+- **machineServesChannel telegram→`no` foot-gun** — if a future caller threads a telegram channel, a Slack-only machine would be wrongly excluded. Safe NOW by producer discipline (telegram is never threaded — documented invariant). <!-- tracked: CMT-1568 -->
+
+## Phase 6 — CI-ratchet fix (post-review, 2026-06-16)
+Two structural-gate failures surfaced on CI after the advert field landed; both fixed without weakening the gates:
+- **no-silent-fallbacks ratchet (475→474):** the `selfServesChannels` heartbeat producer originally wrapped its reads in a `try/catch { return undefined }`, which the ratchet counts as a silent fallback. Refactored to inline non-throwing reads — `config.messaging.find` + `typeof`/optional-chaining guards never throw on normal input, so an unresolvable field simply omits its block (→ placement treats the machine as `unknown`/fail-open, identical older-peer semantics). No catch, no `@silent-fallback-ok` exemption — the count returns to baseline 474 by ELIMINATING the fallback, not annotating it.
+- **peer-presence-puller wiring-integrity ratchet:** the every-advert-field round-trip test (`SESSION_STATUS_ADVERT_FIELDS`) failed because its fixture didn't set the new `servesChannels` field. Fixture updated; the narrowing return already passed the field through. The ratchet did its job — a forgotten field failed loudly.
+
+No behavior change to the placement hot path; the producer's reachability output is identical. 91 unit tests green (machineServesChannel + PlacementExecutor + SessionRouter + peer-presence-puller + no-silent-fallbacks).