instar 1.3.1003 → 1.3.1004

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.1003",
+  "version": "1.3.1004",
   "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/scripts/lib/classify-tier.mjs

@@ -92,7 +92,21 @@ const NEW_CAPABILITY_PATTERNS = [
 // object literal). Without this guard the bare `key: value` pattern fires on
 // almost every TS change. We only treat a `key: value` addition as a new config
 // key when the diff also mentions a recognizable config anchor.
-const CONFIG_SURFACE_HINT = /(ConfigDefaults|config\.json|defaultConfig|InstarConfig|\.config\b|configSchema)/;
+// `\.config\b` used to be an alternative here, and it matched a FILENAME REFERENCE rather than a
+// config surface. A script that merely READS `vitest.push.config.ts` matched it; combined with any
+// ordinary object literal (`const out = { slice: 6, runs: 2 }`) it fired "new config key added" and
+// raised that change's risk floor to 2 — for a read-only developer script that adds no config key at
+// all.
+//
+// WHY THAT IS WORTH A FIX RATHER THAN A SHRUG. The floor is what makes a tier declaration mean
+// something, and declaring under it is treated here as a serious, audited act. A floor that fires on
+// a filename teaches authors that below-floor declarations are routine — which is exactly how a real
+// floor gets argued past later. A noisy guard degrades the guard it belongs to.
+//
+// The remaining anchors are all genuine config SURFACES: a config module, the config file itself by
+// name, or a config type. `foo.config.ts` as a mere mention is no longer one of them — a diff that
+// really adds a config key will name one of the others.
+const CONFIG_SURFACE_HINT = /(ConfigDefaults|config\.json|defaultConfig|InstarConfig|configSchema)/;
 
 /**
  * @param {object} input

package/src/data/builtin-manifest.json

@@ -1,8 +1,8 @@
 {
   "$schema": "./builtin-manifest.schema.json",
   "schemaVersion": 1,
-  "generatedAt": "2026-07-27T12:32:20.149Z",
-  "instarVersion": "1.3.1003",
+  "generatedAt": "2026-07-27T15:44:54.818Z",
+  "instarVersion": "1.3.1004",
   "entryCount": 202,
   "entries": {
     "hook:session-start": {
@@ -418,7 +418,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:agents": {
@@ -426,7 +426,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:backups": {
@@ -434,7 +434,7 @@
       "type": "route-group",
       "domain": "operations",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:git": {
@@ -442,7 +442,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:memory": {
@@ -450,7 +450,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:semantic": {
@@ -458,7 +458,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:status": {
@@ -466,7 +466,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:capabilities": {
@@ -474,7 +474,7 @@
       "type": "route-group",
       "domain": "mapping",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:project-map": {
@@ -482,7 +482,7 @@
       "type": "route-group",
       "domain": "mapping",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:coherence": {
@@ -490,7 +490,7 @@
       "type": "route-group",
       "domain": "coherence",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:topic-bindings": {
@@ -498,7 +498,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:context": {
@@ -506,7 +506,7 @@
       "type": "route-group",
       "domain": "context",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:scope-coherence": {
@@ -514,7 +514,7 @@
       "type": "route-group",
       "domain": "coherence",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:canonical-state": {
@@ -522,7 +522,7 @@
       "type": "route-group",
       "domain": "state",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:ci": {
@@ -530,7 +530,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:sessions": {
@@ -538,7 +538,7 @@
       "type": "route-group",
       "domain": "sessions",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:jobs": {
@@ -546,7 +546,7 @@
       "type": "route-group",
       "domain": "scheduling",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:skip-ledger": {
@@ -554,7 +554,7 @@
       "type": "route-group",
       "domain": "scheduling",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:telegram": {
@@ -562,7 +562,7 @@
       "type": "route-group",
       "domain": "communication",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:attention": {
@@ -570,7 +570,7 @@
       "type": "route-group",
       "domain": "communication",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:relationships": {
@@ -578,7 +578,7 @@
       "type": "route-group",
       "domain": "relationships",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:feedback": {
@@ -586,7 +586,7 @@
       "type": "route-group",
       "domain": "feedback",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:updates": {
@@ -594,7 +594,7 @@
       "type": "route-group",
       "domain": "updates",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:dispatches": {
@@ -602,7 +602,7 @@
       "type": "route-group",
       "domain": "dispatches",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:quota": {
@@ -610,7 +610,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:publishing": {
@@ -618,7 +618,7 @@
       "type": "route-group",
       "domain": "publishing",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:private-views": {
@@ -626,7 +626,7 @@
       "type": "route-group",
       "domain": "publishing",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:tunnel": {
@@ -634,7 +634,7 @@
       "type": "route-group",
       "domain": "networking",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:events": {
@@ -642,7 +642,7 @@
       "type": "route-group",
       "domain": "networking",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:evolution": {
@@ -650,7 +650,7 @@
       "type": "route-group",
       "domain": "evolution",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:watchdog": {
@@ -658,7 +658,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:topic-memory": {
@@ -666,7 +666,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:state-sync": {
@@ -674,7 +674,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:intent": {
@@ -682,7 +682,7 @@
       "type": "route-group",
       "domain": "intent",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:triage": {
@@ -690,7 +690,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:operations": {
@@ -698,7 +698,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:sentinel": {
@@ -706,7 +706,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:trust": {
@@ -714,7 +714,7 @@
       "type": "route-group",
       "domain": "safety",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:monitoring": {
@@ -722,7 +722,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:commitments": {
@@ -730,7 +730,7 @@
       "type": "route-group",
       "domain": "commitments",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:episodes": {
@@ -738,7 +738,7 @@
       "type": "route-group",
       "domain": "memory",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:messages": {
@@ -746,7 +746,7 @@
       "type": "route-group",
       "domain": "coordination",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:system-reviews": {
@@ -754,7 +754,7 @@
       "type": "route-group",
       "domain": "monitoring",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "route-group:machine-mesh": {
@@ -770,7 +770,7 @@
       "type": "route-group",
       "domain": "security",
       "sourcePath": "src/server/routes.ts",
-      "contentHash": "675cd3e00c868dcd0262d7964ec0ee503afc0e7436a46eda9af4aa3e9e93b990",
+      "contentHash": "6576dddf2ae6a47a18f00cd06d178f2080d3aabee319f5da1cccb12225091e8c",
       "since": "2025-01-01"
     },
     "cli:init": {

package/upgrades/1.3.1004.md

@@ -0,0 +1,111 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+`GET /channels` covers WhatsApp and iMessage. Both adapters existed but had no registry row — a gap
+recorded explicitly when the direct user channels shipped, and a hole in the registry's own
+"absence is impossible" property, since a channel with no row cannot report that it is missing.
+
+WhatsApp is read from `getStatus().state`, a real state machine rather than a boolean, so
+`qr-pending` maps to `reachable-no-credential` — the link is alive and waiting for a human to scan a
+pairing code, and a restart will not help. `connecting`/`reconnecting` report `unknown` with the phase
+named rather than being guessed; `disconnected`/`closed` are `broken`; an unrecognised state is
+`unknown`, never `working`.
+
+iMessage is read from `getConnectionInfo().state`, deliberately NOT the sibling `connectedAt` — that
+field is computed as `started ? new Date().toISOString() : undefined`, so it reports the moment you
+asked rather than the moment it connected. A source ratchet fails if anyone wires it in.
+
+`scripts/lib/classify-tier.mjs` no longer treats a `.config` FILENAME reference as evidence of a
+config surface. The `\.config\b` alternative in `CONFIG_SURFACE_HINT` matched any text containing
+`.config`, including filenames — so a script that merely READ `vitest.push.config.ts`, combined with
+an ordinary object literal, fired "new capability: new config key added" and raised that change's risk
+floor to 2.
+
+## What to Tell Your User
+
+Your agent can now tell you whether WhatsApp and iMessage are actually working, alongside Telegram and
+Slack.
+
+The useful part is what it says when WhatsApp is waiting for you to scan a pairing code. That is not
+broken — the connection is fine, it just needs you for a moment — and restarting things would not fix
+it. It now says exactly that, instead of lumping it in with a dropped connection.
+
+It is also careful about what it does not know. If a link is mid-connection it says so rather than
+guessing, and a working link means the connection was up when it checked, not a promise that a message
+to one particular person will arrive.
+
+None — internal change (no user-facing surface).
+
+## Summary of New Capabilities
+
+No new endpoint, command, or config key. `GET /channels` gains `user-whatsapp` and `user-imessage`
+rows with live-state verdicts.
+
+None — internal change (no user-facing surface).
+
+## Evidence
+
+Falsified by flattening `qr-pending` to `broken` in production:
+
+```
+× THE STATE A BOOLEAN LOSES: qr-pending is reachable-no-credential, not broken
+  → expected 'broken' to be 'reachable-no-credential'
+  Tests  1 failed | 15 passed (16)
+```
+
+Restored byte-identical. Green across every suite touching the change:
+`Test Files 5 passed (5) · Tests 59 passed (59)` (`user-channel-wa-imessage`,
+`user-channel-liveness`, `channel-registry`, `channel-registry-claims`, `channels-route`);
+`tsc --noEmit` exit 0. The integration test pinning the exact channel set and the audience partition
+was updated in this change rather than left for CI to catch.
+
+Falsified by restoring the alternative:
+
+```
+× does NOT fire on a mere .config FILENAME reference — the reproduction of the real case
+  → reading a .config filename is not adding a config key: expected 2 to be 1
+  Tests  1 failed | 48 passed (49)
+```
+
+Restored byte-identical; 49 passed, including all 47 pre-existing classifier tests unchanged. A second
+new test iterates every remaining anchor (`ConfigDefaults`, `defaultConfig`, `InstarConfig`,
+`configSchema`) and asserts the floor still rises — narrowing a check must not blind it.
+
+## Also in this change: the Telegram row now names its subject
+
+Found by checking the shipped feature on a running agent rather than only in tests. `/capabilities`
+reported `telegram: { configured: true, adapter: true, bidirectional: true }` while `/channels`
+reported `user-telegram: unknown — the Telegram poll loop is not running` — the config surface and the
+live surface disagreeing, which is exactly what this registry exists to expose.
+
+But the row was measuring the SERVER process's adapter and presenting it as the channel's state. On a
+lifeline deployment inbound never goes through that adapter: a separate lifeline process polls and
+forwards, and the server logs "Telegram relay wired (via lifeline callback forwarding)". Inbound was
+healthy; a stopped server poller is normal there.
+
+That is the same scope error the `threadline-relay` row was fixed for in #1667 — a true statement
+whose subject is unstated, so the reader concludes something about a path that was never measured.
+The verdict stays `unknown` (what it can see is genuinely undetermined); it now names the server
+adapter and says plainly that this alone does not mean messages are not arriving.
+
+## Known limits
+
+`working` means the link was up when probed — not that a message to a particular chat or contact
+would land. Neither row probes a round-trip, because a status read must not send. iMessage is bound to
+the host running its backend, recorded as a real cost of choosing it.
+
+If a genuine config-key addition mentions only a `*.config.ts` filename and none of the remaining
+anchors, its floor will no longer rise. The remaining anchors cover this repo's actual config
+surfaces, and the both-sides test guards against a future narrowing that blinds the check — but this
+is a heuristic over diff text and always was.
+
+## Why it mattered
+
+The floor is what makes a tier declaration meaningful: declaring under it is permitted but audited as
+a deliberate override. A floor that fires on a filename teaches authors that below-floor declarations
+are routine, which is how a real floor gets argued past later. A noisy guard degrades the guard it
+belongs to.

package/upgrades/side-effects/channels-wa-imessage.md

@@ -0,0 +1,77 @@
+# Side-effects review — WhatsApp + iMessage join the channel registry
+
+**Change:** `buildUserChannelDefinitions` gains `user-whatsapp` and `user-imessage` rows, with
+exported `whatsappStateFrom` / `imessageStateFrom` mappers and route wiring from
+`ctx.whatsapp.getStatus().state` and `ctx.imessage.getConnectionInfo().state`.
+
+**Decision point touched?** No new gate. This is additive read-only observability on an existing
+`advisory: true` route. It does change what a caller CONCLUDES about reachability, which is why the
+verdict mapping is the whole of this review.
+
+---
+
+## 1. Over-block
+
+Nothing is blocked or rejected — the route is advisory and gates nothing. The over-claim risk runs the
+other way and is handled: `qr-pending` is reported as `reachable-no-credential` rather than `broken`,
+because the link is alive and needs a HUMAN to scan a code. Reporting it as broken would send an
+operator to debug a connection behaving exactly as designed.
+
+## 2. Under-block
+
+The honest limit, stated in both rows' own text rather than left to assumption: `working` means the
+link was up when probed. It does NOT prove a send to a particular chat or contact would land. Same
+caveat the Telegram and mutual-ssh rows already carry.
+
+Unrecognised states from either adapter map to `unknown`, never to `working`. That is the failure
+direction that matters — a state this module has not seen must not read as healthy — and it is
+pinned by a test.
+
+Not addressed: neither row probes a round-trip. A true reachability proof would require sending, which
+a status read must not do.
+
+## 3. Level-of-abstraction fit
+
+Correct, and it follows the pattern already established for Telegram and Slack: the STATE→VERDICT
+mapping is an exported pure function testable without constructing an adapter, and the route supplies
+live state through a narrow context. The mapping is where a wrong verdict would come from, so it is
+the part that is pinned.
+
+## 4. Signal vs authority compliance
+
+Compliant. Pure signal on an advisory route with no blocking power. Adding rows strengthens the
+registry's "absence is impossible" property — the invariant that a channel with no row cannot report
+that it is missing.
+
+## 5. Interactions
+
+`UserChannelProbeContext` gains two required fields, so any other constructor of it must supply them
+— there is exactly one (the `/channels` route), updated here. The `/channels` payload grows from 6
+rows to 8; the integration test that pins the exact set and the audience partition was updated in
+this change rather than left for CI to catch.
+
+`WhatsAppLiveState` mirrors the adapter's own union. If the adapter adds a state, the mapper reports
+`unknown` rather than mis-classifying — a deliberate fail-safe, not an oversight.
+
+## 6. External surfaces
+
+`GET /channels` returns two additional rows. Additive; existing consumers reading known ids are
+unaffected. No endpoint added, no config key, no behaviour change to messaging itself.
+
+## 7. Multi-machine posture
+
+**Machine-local by design for iMessage**, and this is a real property rather than a shortcut: the
+backend it talks to runs on this host, so the channel genuinely exists only where that backend is.
+That is recorded in the row's own `cost` text so a caller choosing it knows the work will not survive
+this machine going away.
+
+WhatsApp is pairing-bound to the operator's phone through whichever host holds the session — the same
+locality. Neither introduces replicated state; both are per-host reads of a per-host adapter, and a
+cross-machine merged view would be actively misleading since another machine's link says nothing
+about this one's.
+
+## 8. Rollback cost
+
+Trivial: remove the two rows, the two mappers, the two context fields and the route wiring, and
+restore the integration test's expected set. No persisted state, no schema, no migration. Rolling back
+re-opens the stated gap, so it should carry a reason.