instar 1.3.621 → 1.3.623

package/package.json

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

package/upgrades/1.3.622.md

@@ -0,0 +1,26 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Makes the account-follow-me proof work end-to-end. Driving it as the operator exposed that tapping Approve issued + delivered the mandate to the target machine, but three seams were unwired so nothing happened after ("machine logging in now" then silence). Wired all three:
+
+1. **Delivered-mandate consumer** — a boot-sweep + 60s tick on the target machine walks the delivered-mandate store and drives the real enroll-start route for each approved mandate not already pending/enrolled. Idempotent (survives restart), authority-free (the route still enforces every gate).
+2. **Peer-view email resolution** — `accountFollowMePeerViews` now uses the working peer-resolution path (`resolvePeerUrls`) instead of an empty field, so the target can resolve the approved account's email (fixes the `409 "cannot resolve approved account email"`).
+3. **Pending-login surfacing** — `GET /subscription-pool/pending-logins?scope=pool` merges peers' pending logins (dark-peer-tolerant), and the dashboard polls it pool-scope, so a login created on another machine surfaces on the operator's single dashboard.
+
+## What to Tell Your User
+
+The "let another machine use this subscription" flow now actually completes: tap Approve, and the other machine starts its login and the link shows up on your dashboard for you to tap. Before this, Approve issued the approval but nothing carried it through.
+
+## Summary of New Capabilities
+
+- Account-follow-me works end-to-end: Approve → the target machine enrolls itself → its login link surfaces on your single dashboard. Dark on fleet / live on the dev agent (unchanged gate).
+
+## Evidence
+
+- `tests/integration/pending-logins-pool-merge.test.ts` (NEW, 3 tests) — verifies the `?scope=pool` merge tags logins by machine, tolerates a dark peer (no 500), and leaves the default local-only path unchanged.
+- All existing follow-me / enroll-start / scan / delivered-mandate / resolve / peer-view tests green (no regressions); `tsc --noEmit` clean.
+- The full Approve→enroll→login-link flow driven on the real two-machine setup before release (Live-User-Channel-Proof).

package/upgrades/1.3.623.md

@@ -0,0 +1,21 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Fixes the account-follow-me login link showing a placeholder (a URL ending in `code=t`) instead of a working Claude sign-in link. The long verification URL from `claude auth login` hard-wraps across tmux pane lines with no inserted space; the scrape that reads it stopped at the first wrap and kept only the head fragment. The login was always real — the scrape cut it short. Now `FrameworkLoginDriver.parseArtifact` re-joins wrapped URL fragments before matching, and the capture uses `tmux capture-pane -J` to join wraps at the source.
+
+## What to Tell Your User
+
+The "let another machine use this subscription" login link now comes through complete and usable, instead of a broken placeholder.
+
+## Summary of New Capabilities
+
+- No new capability — a correctness fix so the follow-me device-code login link is the full, usable URL.
+
+## Evidence
+
+- `tests/unit/framework-login-driver.test.ts` — NEW test re-joins the REAL captured (wrapped) Mac Mini login pane into the full URL and asserts it is NOT the `code=t` head fragment; 14 driver tests green.
+- `tsc --noEmit` clean.

package/upgrades/side-effects/ws52-code-t-fix.md

@@ -0,0 +1,37 @@
+# Side-Effects Review — WS5.2: re-join line-wrapped verification URL (code=t fix)
+
+**Version / slug:** `ws52-code-t-fix`
+**Date:** `2026-06-18`
+**Author:** `Echo (instar-dev agent)`
+**Second-pass reviewer:** `not required (pure scrape-parse fix + a source-side capture flag; no decision/auth surface)`
+
+## Summary
+The follow-me device-code login link surfaced as a placeholder ending in `code=t`. Root cause: the long Claude OAuth URL from `claude auth login` hard-wraps across tmux pane lines with no inserted space (`...?code=t` then `rue&client_id=...`); `FrameworkLoginDriver`'s `URL_RE` stopped at the first wrap. Fix: `parseArtifact` re-joins wrapped URL fragments before matching (pure, unit-tested against the real captured pane); the injected `capture` now uses `tmux capture-pane -J` to join wraps at the source. Files: `src/core/FrameworkLoginDriver.ts`, `src/commands/server.ts`, `tests/unit/framework-login-driver.test.ts`.
+
+## 1. Over-block / 2. Under-block
+No block/allow surface. The de-wrap only affects which characters of a verification URL are captured. Under-block: a URL containing internal whitespace would not be a single wrapped token, but real URLs have none; the join stops at the first whitespace/blank line, so non-URL output is never absorbed.
+
+## 3. Level-of-abstraction fit
+Correct — the fix is in the pure scrape parser (where the bug is) + the source capture flag. No higher layer involved.
+
+## 4. Signal vs authority compliance
+No authority. Pure text parsing; reads only the PUBLIC verification URL (never a token). Strictly a correctness improvement.
+
+## 5. Interactions
+`parseArtifact` is also used for Codex device-code + already-unwrapped URLs — covered by existing + new idempotency tests (an unwrapped URL is unchanged). The `-J` capture is scoped to the enrollment login driver only; generic captures are untouched.
+
+## 6. External surfaces
+The operator now receives the full, usable login URL instead of a placeholder. No token exposure (unchanged). No new endpoint.
+
+## 7. Multi-machine posture
+Machine-local: each target machine scrapes its own login pane. No cross-machine state. Both machines get the fix via the normal deploy.
+
+## 8. Rollback cost
+Revert; ship a patch. Pure code, no persistent state.
+
+## Conclusion
+Small, pure, well-tested fix to the actual blocker that made the surfaced login link unusable. 14 driver tests green incl. the real wrapped-pane fixture; tsc clean.
+
+## Follow-up — Pending-logins card UX redesign (operator feedback, 2026-06-18)
+
+Justin: the Pending Logins card was "extremely hard to understand." Redesigned `renderPendingLogins` to be tap-simple: (1) a plain-language headline ("Sign in to finish setting up <account> on <machine>"); (2) the PRIMARY action is a single tappable "Sign in" link — but ONLY when the URL is https AND on a trusted provider host (claude.com/anthropic/openai/google); an untrusted or `javascript:` URL still renders as inert text with NO anchor (safety invariant preserved + unit-tested); (3) removed the confusing "re-issued N times" noise; (4) TTL shown as one short line. Tests updated: subscriptions-render (26), subscriptions-tab (5), subscriptions-tab-lifecycle e2e (2), pending-logins-pool-merge (3) — all green; the javascript:-URL-stays-inert safety test retained.

package/upgrades/side-effects/ws52-enroll-seams.md

@@ -0,0 +1,75 @@
+# Side-Effects Review — WS5.2: wire the 3 enroll seams (make the follow-me proof work end-to-end)
+
+**Version / slug:** `ws52-enroll-seams`
+**Date:** `2026-06-18`
+**Author:** `Echo (instar-dev agent)`
+**Second-pass reviewer:** `required (cross-machine + credential enrollment) — appended below`
+
+## Summary of the change
+
+Completes Part B of the approved `ws52-operator-tap-not-text` spec — the connector that turns an operator's Approve into an actual login on the target machine. Driving the proof as the operator (2026-06-18, topic 13481) exposed that Approve issued + delivered the mandate to the Mini fine, but THREE seams were unwired so nothing happened after ("machine logging in now" then silence). This wires all three:
+
+- **Seam #1 — delivered-mandate consumer** (`src/server/AgentServer.ts`): a boot-sweep + 60s tick (`driveDeliveredFollowMeEnrollments`) walks the `DeliveredMandateStore` and, for each account-follow-me mandate not already pending/enrolled, self-POSTs the REAL `/subscription-pool/follow-me/enroll/start` route. Idempotent (skips accounts already in `pending-logins` or the pool — durable, survives restart) and authority-free (the route enforces the dev-gate + deny-by-default + point-of-use mandate re-verify). Re-entrancy-guarded; timer cleared on stop.
+- **Seam #2 — peer-view email resolution** (`src/commands/server.ts`): `accountFollowMePeerViews` now sources peers from `_resolvePeerUrls()` (the working pool-scope path) instead of the empty `lastKnownUrl` — falling back to `lastKnownUrl`. This is what the `fetchPeerSubscriptionViews` doc comment always intended. Fixes the `409 "cannot resolve approved account email"` I hit driving enroll-start by hand.
+- **Seam #3 — pending-login pool surfacing** (`src/server/routes.ts` + `dashboard/subscriptions.js`): `GET /subscription-pool/pending-logins?scope=pool` fans out to peers' local pending-logins and merges (tagged by machine, dark-peer-tolerant); the dashboard subscriptions controller now polls with `?scope=pool` so a login created on the Mini surfaces on the operator's single dashboard.
+
+## Decision-point inventory
+- `driveDeliveredFollowMeEnrollments` (AgentServer) — **add** — nudges the enroll-start route for delivered mandates; carries NO authority itself (route gates).
+- `accountFollowMePeerViews` peer source (server.ts) — **modify** — resolvePeerUrls (working) vs lastKnownUrl (empty); fallback preserved.
+- `GET /subscription-pool/pending-logins` — **modify** — adds an optional `?scope=pool` merged read; default (no scope) is byte-for-byte unchanged.
+
+## 1. Over-block
+No block/allow surface. The consumer only ADDS enroll attempts for mandates the operator already approved+delivered; it never blocks anything. It SKIPS already-pending/enrolled accounts (correct — prevents re-mint), which is the only "rejection" and is the desired idempotency.
+
+## 2. Under-block
+The consumer relies on the enroll-start route for all gating (dev-gate, deny-by-default, point-of-use mandate re-verify incl. revocation/expiry). It adds no new trust path — a delivered mandate that fails the route's re-verify still gets 403/409 and no login. The idempotency read (pending-logins + pool) is best-effort; a read failure could cause a redundant enroll-start attempt, but the route itself is the backstop (it re-verifies and the wizard's own pending-login dedup applies), so worst case is a logged retry, never a double-mint of a completed account.
+
+## 3. Level-of-abstraction fit
+Correct. Seam #1 is glue at the server layer (where the delivered store lives) that reuses the existing route rather than duplicating credential logic — the lowest-risk placement. Seam #2 swaps a data source to the one the rest of the pool-scope reads already use. Seam #3 mirrors the established `?scope=pool` fan-out pattern (`/sessions?scope=pool`).
+
+## 4. Signal vs authority compliance
+**Required reference:** docs/signal-vs-authority.md
+- [x] No new brittle authority. The consumer is authority-free (it nudges a route that holds the real authority, deterministically gated). The route's authority is unchanged. Seam #3 is a read-merge. Strictly additive wiring; the failure direction is "no login produced" (safe), never "wrong login" — the email gate (S7) + point-of-use re-verify still hold.
+
+## 5. Interactions
+- **Shadowing:** the `?scope=pool` branch is gated on the query param; the default path is unchanged, so existing callers are unaffected.
+- **Double-fire:** the consumer's pending/enrolled skip-set + the wizard's own pending dedup prevent re-driving; the re-entrancy guard prevents overlapping ticks.
+- **Races:** the consumer reads the delivered store + self-GETs state each tick; a mandate mid-enroll shows a pending login → skipped next tick.
+- **Self-call:** the consumer self-POSTs localhost with the agent's own authToken — same-process HTTP, no external surface.
+
+## 6. External surfaces
+- Operator dashboard now shows follow-me logins created on OTHER machines (the whole point). No secrets exposed — pending-logins carry only the device-code + verification URL (already the case; the merge just forwards them, machine-tagged).
+- Peers are queried at their existing `/subscription-pool/pending-logins` with the agent's authToken (5s timeout, dark-peer-tolerant). No new endpoint exposed to the outside.
+
+## 6b. Operator-surface quality
+Touches `dashboard/subscriptions.js` (a one-line URL change to add `?scope=pool`). The rendered surface (the Pending Logins panel) is unchanged in shape — it now simply includes cross-machine logins. Leads with plain language, no raw internals, phone-width (unchanged). N/a for destructive actions.
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+This change EXISTS for multi-machine. Seam #1 is machine-local (each target drives its own delivered mandates). Seam #2 is proxied-on-read (resolvePeerUrls fan-out). Seam #3 is proxied-on-read (the `?scope=pool` merge), dark-peer-tolerant (classified failed entry, never a 500). The login link is the provider's own URL (machine-independent); it surfaces on the operator's single fronting dashboard. Single-machine install: consumer still runs (drives any local delivered mandate); `?scope=pool` returns just local (no peers) — no-op.
+
+## 8. Rollback cost
+Revert the commit; ship a patch. No persistent state shape change (uses existing DeliveredMandateStore + PendingLoginStore). The consumer is additive (stops nudging on revert); the `?scope=pool` branch is additive (default unchanged). Behind the existing dev-gate (dark on fleet) — blast radius is dev agents only.
+
+## Conclusion
+Wires the three seams that made the proof stall, reusing existing route authority (no new brittle gate), with idempotency that survives restart. tsc clean; new pool-merge integration test (3) + all existing follow-me/enroll route + resolve + peer-view tests green (no regressions). Clear to ship pending the appended second-pass. The TRUE verification — me driving Approve→consumer→enroll→login-link-surfaced on the real machines — is done before this reaches the operator (per the Live-User-Channel-Proof standard I violated last time).
+
+## Second-pass review (if required)
+**Reviewer:** independent general-purpose reviewer subagent (read-only), 2026-06-18 — **CONCUR**
+
+Verified all 5 review points against real code (cited file:line): (1) consumer is authority-free (only self-POSTs the real enroll-start route which holds the dev-gate + deny-by-default mandate gate + R4a point-of-use re-verify + S7 email gate), idempotent (handled-set from local pending-logins+pool; PendingLogin.id keyed to accountId so the skip is sound; intra-tick handled.add), re-entrancy-guarded (followMeConsumerRunning, released in finally; serial awaited fetch makes a slow drive skip the next tick not overlap), inert without the store, no secret in logs. (2) seam #2 is a pure data-source swap to resolvePeerUrls (lastKnownUrl fallback, nickname mapped, [] when no peers, authToken unchanged). (3) seam #3 default no-scope path byte-identical; dark peers → classified failed entry never a 500 (AbortSignal.timeout 5s); only non-secret fields (device-code/verificationUrl/machine tags) cross; remote tagged. (4) strictly additive, fails toward "no login produced" — the consumer can't produce a wrong-account login because it passes only mandateId+accountId and the route independently re-derives the email + re-checks exact bounds. (5) no re-mint loop / double-enroll / route hang / auth / missing-await bug. One non-blocking note: the enroll-start self-call has no client-side timeout, which is intentional+safe (start() legitimately runs up to ~180s; the re-entrancy guard, not a timeout, correctly prevents pile-up; the route's EnrollmentDriveError returns a retryable 502 leaving no stuck pending-login). **No concerns.**
+
+## Evidence pointers
+- `npx tsc --noEmit` clean (full worktree).
+- `tests/integration/pending-logins-pool-merge.test.ts` (NEW, 3) + subscription-enrollment-routes (5) + follow-me-controller-wiring (4) + scan/enroll-start/delivered-mandate route tests (14) + resolve-follow-me-enroll-target (6) + fetch-peer-subscription-views (5) — all green.
+
+## Follow-up (CI fix, 2026-06-18)
+
+CI surfaced two real issues from seam #3, both fixed: (1) the `?scope=pool` branch hardcoded `enabled:true`, which broke the dashboard's feature-dark detection (it needs `pending.enabled===false` alongside accounts) — now it mirrors local pool presence (`enabled: !!ctx.enrollmentWizard`), so a dark machine still reads disabled even while forwarding peers' logins; (2) the `subscriptions-tab` integration-test fetch mocks keyed the old `/subscription-pool/pending-logins` URL, but the controller now fetches `?scope=pool` — updated the mock keys. Verified: subscriptions-tab (5) + subscriptions-tab-lifecycle e2e (2) + pending-logins-pool-merge (3) + follow-me-controller-wiring (4) green; tsc clean.
+
+## Follow-up (CI hang fix, 2026-06-18)
+
+CI shard 4/4 hung ~1h46m — root cause in this change: the seam #1 consumer's `setTimeout` (boot-sweep) + `setInterval` (60s tick) in AgentServer were NOT `.unref()`'d, so a test that boots AgentServer kept the event loop alive (vitest hangs on the open handle). Fixed: `.unref()` both timers (matches the sibling pollers), and added `AbortSignal.timeout` to the consumer's self-fetches (5s on the idempotency reads, 200s on the enroll-start drive) so a wedged fetch can't hold the loop either. tsc clean.
+
+## Follow-up (the real "code=t" login bug, 2026-06-18)
+
+Driving the proof to completion (Justin tapped Approve) exposed the actual remaining bug: the device-code login link surfaced as a placeholder ending in code=t. Root cause: the verification URL from `claude auth login` is long and HARD-WRAPS across tmux pane lines with no inserted space (`...?code=t` then `rue&client_id=...` on the next line); FrameworkLoginDriver's URL scrape stopped at the first wrap and kept only the head fragment. The login was always real; the SCRAPE cut it short. Fix: (1) `parseArtifact` now re-joins wrapped URL fragments before matching (pure + unit-tested against the REAL captured Mini pane); (2) the capture switched to `tmux capture-pane -J` (joins wraps at the source). 14 FrameworkLoginDriver tests green incl. the wrapped-URL fixture. This makes the surfaced login link actually usable.