instar 1.3.977 → 1.3.979

package/package.json

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

package/upgrades/1.3.978.md

@@ -0,0 +1,88 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+**The standards audit's own honesty field was overclaiming, and reported `trustworthy: true` over the
+exact defect it was added to expose.**
+
+Verified on the LIVE endpoint two hours after v1.3.975 deployed: `total: 22`,
+`enforcedRatio: 0.0455`, **`assessmentTrustworthy: true`**, zero canary failures — while the source
+registry carries **81** articles. The stale agent-home copy is not malformed; it is a self-consistent
+document that is a quarter of the real one, so it passes every INTERNAL check by construction.
+
+`assessmentTrustworthy` was `total > 0 && canaryOk` — i.e. "my internal checks passed" — but it READ
+as "this assessment is trustworthy". Those are different claims.
+
+- **`assessmentConfidence`** (new): `'verified' | 'unverified' | 'untrustworthy'`.
+  - `untrustworthy` — a check actively failed (nothing parsed, or the canary objected).
+  - `unverified` — internal checks passed but NO external expectation existed to confirm this is the
+    CURRENT constitution rather than a coherent older copy.
+  - `verified` — internal checks passed AND a same-build expectation matched.
+- **`confidenceReason`** (new): always populated, plain English.
+- **`assessmentTrustworthy`** — deprecated, retained one release, TRUE only on `verified`.
+
+`'verified'` is **unreachable today**: the expectation mechanism is a separate, not-yet-approved
+change. So every passing read now reports `unverified` — including a complete, correct registry,
+because the instrument genuinely cannot verify completeness. Anything stronger would be the same
+overclaim in nicer clothes.
+
+**A project item could never be recorded as merged if its pull request's CI had ever been red — even
+after it was fixed.**
+
+`StageTransitionValidator.ciIsGreen` evaluated EVERY entry in GitHub's `statusCheckRollup`. GitHub
+returns every run of every check, **including superseded ones**, so a check that failed and was
+re-run to green appears twice and the failure never disappears. Verified on the live PR #1641
+(merged legitimately): 31 rollup entries, four check names duplicated, including
+`eli16 FAILURE 01:44:01Z` beside `eli16 SUCCESS 01:45:32Z`. Branch protection merged the PR because it
+uses each check's CURRENT state; the tracker refused it with `CI_NOT_GREEN` because it also counted
+the stale run.
+
+The rollup is now collapsed to the **latest run per check name** (by `completedAt`, falling back to
+`startedAt`) before greenness is judged — which is what GitHub's own merge gate does.
+
+Three safeguards so the dedupe can never hide a genuine failure: the latest run is authoritative in
+BOTH directions (a success followed by a later failure is still not green); runs that cannot be
+ordered FAIL CLOSED (equal or missing timestamps ⇒ the failing run wins); and unnamed status entries
+are keyed individually so a failing one is never collapsed into a passing one.
+
+End-to-end, against the two real merged pull requests with the route's exact helper wiring: both went
+from refused to accepted.
+
+## What to Tell Your User
+
+If you read a standards-enforcement figure, it now comes with a confidence verdict and a plain
+reason beside it. Most installs will see the verdict "unverified" — that is honest rather than a
+fault. It means the numbers are arithmetic over whatever copy of the rules was on disk, and nothing
+yet confirms that copy is the current one. A verdict of "untrustworthy" means a check actually
+failed and the figures describe only a fragment of your rules.
+
+If you track work in projects, marking an item as merged now succeeds for a pull request whose checks
+went red and were then fixed — which previously failed with a confusing "CI is not green" long after
+the pull request had merged.
+
+## Summary of New Capabilities
+
+- Greenness is evaluated per check against its latest run, matching branch-protection semantics.
+
+## Evidence
+
+- `tests/unit/standards-enforcement-auditor.test.ts` — a coherent-but-stale registry passes every
+  internal check (zero dropped headings, `parsed === articleHeadings`) and still must not read
+  `verified`; plus all four `deriveAssessmentConfidence` verdicts in both directions.
+- `tests/integration/conformance-dev-gate-route.test.ts` — the HTTP body carries the verdict.
+- `tests/e2e/standards-coverage-lifecycle.test.ts` — the verdict + reason survive production init.
+
+- `tests/unit/StageTransitionValidator.test.ts` — five new cases: the live superseded-failure shape;
+  the reverse direction (later failure still refuses); unorderable runs fail closed across three
+  variants; unnamed entries never collapsed; an in-flight latest run still not green.
+
+## Known Gap (stated, not resolved)
+
+A coherent stale registry is still reported with real-looking figures; it is now LABELLED
+`unverified` with a reason naming that possibility, but the instrument cannot say which case it is
+in. Closing that needs an external expectation shipped beside the registry — the blocked
+`standards-registry-snapshot-refresh` spec. This change makes the uncertainty visible; it does not
+resolve it.

package/upgrades/1.3.979.md

@@ -0,0 +1,26 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Completed the guard-posture false-all-clear fix across machines. Capacity heartbeats now carry the full count and at most 16 sorted keys for load-bearing protections whose existing posture is `missing`, `errored`, `on-stale`, or `off-runtime-divergent`. The Machines dashboard displays that read-only result in each machine’s detail record. Existing guard classification, critical-gap membership, machine health, probe anomalies, and notifications are unchanged.
+
+The key ceiling is explicit: today’s 13 load-bearing guards all fit, while a future larger set keeps its full count and marks a truncated sample instead of growing every 30-second heartbeat without bound.
+
+## What to Tell Your User
+
+The cross-machine safety-check view now says when a machine cannot prove a critical protection, instead of letting an empty critical-gap list look like a complete all-clear. This adds detail only; it does not create another alert.
+
+## Summary of New Capabilities
+
+- Machine details now show load-bearing protections that are loudly unproven.
+- The frequent heartbeat carries a bounded key sample plus the complete count.
+
+## Evidence
+
+- Refusal-first unit coverage failed before implementation because the heartbeat dropped the list and the fleet record did not display it.
+- Unit coverage constructs an errored load-bearing guard and proves it stays out of the gap list, enters the new bounded heartbeat list, and produces exactly one existing anomaly with no second notification track.
+- Integration coverage proves the fields survive heartbeat persistence and the real authenticated `/pool` route.
+- End-to-end coverage opens the shipped Machines glance and requires the remote guard key in the machine record.

package/upgrades/eli16/guard-heartbeat-unproven-summary.md

@@ -0,0 +1,44 @@
+# Fleet guard-posture completeness — Plain-English Overview
+
+> The one-line version: every machine now carries a bounded list of load-bearing protections it cannot currently prove, and the fleet view displays that list without creating another alarm.
+
+## The problem in one breath
+
+The local guard readout already distinguishes two different questions: which critical protections are silently unguarded, and which critical protections are loudly unproven because their posture is missing, errored, stale, or contradicted by runtime state. The compact heartbeat omitted the second answer. That meant the cross-machine view could still show an empty critical-gap list and be mistaken for a complete all-clear even though the sending machine had explicitly found a load-bearing protection it could not prove.
+
+## What already exists
+
+- **Local guard inventory** — names load-bearing guards in the four existing unproven posture classes while leaving them out of the silent-gap class.
+- **Guard posture alarms** — raise the existing missing, errored, stale, or runtime-divergent anomaly. They deliberately do not raise a second load-bearing-gap alarm for the same guard.
+- **Machine heartbeat and pool view** — carry a compact guard-posture block from each machine and retain its last known value for a dark peer.
+- **Machines dashboard** — reads the pool response and opens a per-machine detail record.
+
+## What this adds
+
+The heartbeat gains a full count and a bounded key sample for load-bearing protections whose existing posture cannot currently prove protection. The producer sorts the keys and sends at most 16 of them. Sixteen covers all 13 load-bearing guards in today’s manifest, and the uncapped count remains present if the manifest later grows past the key ceiling, so truncation is visible rather than becoming another false all-clear.
+
+The machine detail record displays the count and the keys received from that machine. If the count is larger than the key sample, it says how many keys are shown. This is the actual reader for the new wire field; it prevents the fix from stopping at a decorative payload that no operator surface consumes.
+
+## The new pieces
+
+- **Bounded heartbeat projection** — copies the already-derived unproven list into a count plus at most 16 deterministic keys. It cannot classify a guard, change a gap, or trigger an action.
+- **Fleet detail rendering** — displays “Load-bearing protection unproven” inside the existing machine record. It does not change the machine headline, attention tile, warning tone, or notification path.
+- **Durable semantic comparison** — treats the new count and key sample as meaningful heartbeat state, so a changed sample persists even when the older aggregate posture counts happen to remain equal.
+
+## The safeguards
+
+**Prevents double-alarming.** The peer probe continues to ignore the new fields. A load-bearing errored guard still produces exactly one existing errored anomaly and no load-bearing-gap episode or fleet notification.
+
+**Prevents classification drift.** The local effective-state precedence, `loadBearingGap` membership, gap keys, and machine-health calculation are unchanged. The new fields are a read-only projection of an existing list.
+
+**Prevents heartbeat growth from becoming open-ended.** At most 16 key strings ride each 30-second heartbeat. The full count travels independently, so a future seventeenth key is omitted from the sample but not from the truth.
+
+**Refuses a decorative wire field.** Unit coverage pins the producer, bound, and no-second-alarm rule. Integration coverage carries the fields through durable pool state and the real `/pool` route. End-to-end coverage opens the shipped Machines glance and requires the remote key to appear in the machine record.
+
+## What ships when
+
+This is one additive patch completing the same guard-read-surface item as the local summary. Older peers and consumers remain compatible because the two wire members are optional on read; upgraded senders always emit both.
+
+## What you actually need to decide
+
+Does this patch complete the cross-machine read without changing any existing guard classification, anomaly, notification, or fleet-health decision?