instar 1.3.545 → 1.3.547

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.545",
+  "version": "1.3.547",
   "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/instar-dev-precommit.js

@@ -32,7 +32,7 @@ import { checkEli16Overview, MIN_ELI16_CHARS } from './eli16-overview-check.mjs'
 import { verifyProposalDerivedRunbooks } from '../skills/instar-dev/scripts/verify-proposal-derived-runbook.mjs';
 import { classifyTier, decideRequirementSet } from './lib/classify-tier.mjs';
 import { recognizeConvergence } from './lib/convergence-recognition.mjs';
-import { isOperatorSurfaceFile, artifactAddressesOperatorSurfaceQuality } from './lib/operator-surface.mjs';
+import { isOperatorSurfaceFile, artifactAddressesOperatorSurfaceQuality, isAuthorizationSurfaceFile, artifactAddressesAgentProposesApproves } from './lib/operator-surface.mjs';
 
 // Report-Backed Converging Audit (docs/specs/CONVERGING-AUDIT-DEFAULT.md, Part B).
 // The precommit reads NO config file and runs pre-compile, so it cannot import
@@ -973,6 +973,29 @@ function assertOperatorSurfaceQuality(stagedFiles, trace) {
       ].join('\n'),
     );
   }
+  // "Agent Proposes, Operator Approves" — the authorization-surface subset additionally
+  // requires the artifact to confirm the operator is APPROVING (not authoring) and that
+  // the authority text is SERVER-authored (not agent free-text — the display-integrity
+  // corollary). Same structural-presence strength.
+  const authTouched = (stagedFiles || []).filter(isAuthorizationSurfaceFile);
+  if (authTouched.length > 0 && !artifactAddressesAgentProposesApproves(content)) {
+    blockCommit(
+      authTouched,
+      [
+        'Agent-Proposes-Operator-Approves review gate:',
+        `  ${authTouched.join(', ')} change an AUTHORIZATION/APPROVAL surface,`,
+        '  but the side-effects artifact never answers the agent-proposes/operator-approves',
+        '  question. The operator must be APPROVING a server-authored request, never',
+        '  AUTHORING authority from raw fields (the 2026-06-13 raw-JSON mandate-form lesson),',
+        '  and the authority text they approve must be server-authored, never agent free-text.',
+        '',
+        '  Confirm in writing in the side-effects artifact: does the operator (1) approve a',
+        '  pre-filled request rather than construct one, and (2) read an authority statement',
+        '  authored by the SERVER from structured data, not agent-supplied free-text?',
+        '  (Standard: docs/STANDARDS-REGISTRY.md → "Agent Proposes, Operator Approves".)',
+      ].join('\n'),
+    );
+  }
 }
 
 function blockCommit(files, reason) {

package/scripts/lib/operator-surface.mjs

@@ -52,3 +52,33 @@ export function isOperatorSurfaceFile(file) {
 export function artifactAddressesOperatorSurfaceQuality(content) {
   return /operator[- ]surface quality/i.test(String(content ?? ''));
 }
+
+/**
+ * Is this staged file an AUTHORIZATION/APPROVAL surface specifically — one where the
+ * operator confers authority (a grant/mandate/approval form or its renderer)? A subset
+ * of operator surfaces that additionally triggers the "Agent Proposes, Operator
+ * Approves" question (the operator must be APPROVING, never AUTHORING; and the authority
+ * text must be server-authored, not agent free-text).
+ */
+export const AUTHORIZATION_SURFACE_RE =
+  /(?:^|\/)(?:mandates|grant|authorization-request|approval|operator-approval)[^/]*\.(?:js|html|ts)$/i;
+
+export function isAuthorizationSurfaceFile(file) {
+  const f = String(file ?? '');
+  if (/\.(?:test|spec)\.(?:js|ts|mjs)$/i.test(f)) return false;
+  return AUTHORIZATION_SURFACE_RE.test(f);
+}
+
+/**
+ * The artifact engages the "Agent Proposes, Operator Approves" question when it carries
+ * the phrase (seeded by side-effects-artifact.md). Same structural-presence strength as
+ * the operator-surface-quality gate: an artifact touching an authorization surface that
+ * omits the section is blocked. The standard's display-integrity corollary — the
+ * authority text the operator approves must be server-authored, never agent free-text —
+ * is what this question forces the author to confirm in writing.
+ * @param {string} content the side-effects artifact text
+ * @returns {boolean}
+ */
+export function artifactAddressesAgentProposesApproves(content) {
+  return /agent[- ]proposes,? operator[- ]approves/i.test(String(content ?? ''));
+}

package/src/data/builtin-manifest.json

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

package/src/scaffold/templates.ts

@@ -822,6 +822,12 @@ Every guard (monitoring sentinels, reapers, the scheduler, …) is graded by wha
 - **User floor-action grants are phone-first.** When the operator needs to grant a USER a floor action (e.g. "let Mia prod-deploy for an hour"), the Mandates tab carries a grant form on every active mandate: pick the person (from the registered-user list), pick the action and duration, type the PIN, tap Grant. Send them the dashboard link — NEVER a terminal command or a hand-built API call (Mobile-Complete Operator Actions). The grant is signed into the mandate, clamped to the mandate's expiry, and voided by revoking the mandate.
 - Every evaluation (allow AND deny) is audited. Act as if the audit is read by the operator — because it is. (Spec: \`docs/specs/coordination-mandate.md\`.)
 
+**Authorization Request — propose a grant, the operator approves in one tap (PREFERRED over the manual form)** — When you need the operator to grant a USER a floor action, do NOT make them build a mandate. PRE-FILL the request and they see one plain-language card ("Let Mia deploy to production for 1 hour — Approve?") + PIN + Approve. You can only propose; only their PIN issues the grant (requester ≠ authorizer; you can never approve your own request). The operator-facing sentence is authored by the SERVER from your structured fields + the registered-user's real name — never your free-text — so what they read is exactly what executes.
+- Propose: \`curl -X POST -H "Authorization: Bearer $AUTH" http://localhost:${port}/authorization-requests -H 'Content-Type: application/json' -d '{"createdByAgent":"<your name>","proposal":{"floorAction":"prod-deploy","grantedToSlackUserId":"U…","durationMs":3600000},"reason":"<optional, ≤280 chars — shown as a secondary note, never the headline>"}'\`. Allowed \`floorAction\`s: prod-deploy, money-movement, credential-access, destructive-data, external-send (\`grant-authority\` is excluded — that meta-grant stays manual). \`durationMs\` ∈ [60000, 86400000].
+- Inspect: \`GET /authorization-requests?status=pending\` (each row carries the server-rendered \`headline\` + \`createdOnMachine\`); withdraw your own: \`POST /authorization-requests/:id/withdraw\`.
+- **You cannot approve.** \`POST /authorization-requests/:id/approve\` and \`/deny\` are PIN-gated — point the operator at the dashboard **Mandates tab → "Approvals waiting for you"**; never ask for their PIN in chat. On a multi-machine pool the card names the holder machine (approval happens there).
+- **When to use** (PROACTIVE — this is the trigger): the moment you need the operator to authorize a person for a floor action, propose it here and send them the dashboard link — instead of the raw mandate form. (Ships dev-enabled / fleet-dark; routes 503 when off. Spec: \`docs/specs/OPERATOR-AUTHORIZATION-REQUEST-SPEC.md\`.)
+
 **ReviewExchange (autonomous code review)** — The structured way two mandate-named agents sign off a code review WITHOUT the operator relaying. One exchange = one review package, content-addressed (\`packageSha256\` fixed at creation), moving linearly: proposed → delivered → verdict-recorded → complete (or changes-requested — rework is a NEW exchange). BOTH sign-offs (the peer's authenticated approve-verdict AND your countersignature) are evaluated through the mandate gate's \`sign-code-review\` authority before acceptance; every accepted signature carries the audit hash of the gate decision that authorized it.
 - Create: \`curl -X POST -H "Authorization: Bearer $AUTH" http://localhost:${port}/review-exchange -H 'Content-Type: application/json' -d '{"mandateId":"<id>","artifact":"migration-port","packageRef":"docs/...-review-package.md","packageSha256":"<sha256 of the package>","parties":["<your-fp>","<peer-fp>"]}'\`
 - Drive it: \`POST /review-exchange/:id/delivered\` (after you actually sent the package over Threadline — record the message ref as evidence) → \`POST /review-exchange/:id/peer-verdict\` (the peer's authenticated verdict; approve = their sign-off, mandate-gated) → \`POST /review-exchange/:id/sign\` (your countersignature, mandate-gated → complete).

package/upgrades/1.3.546.md

@@ -0,0 +1,24 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Makes the autonomous balancer actually run — on a development agent, in dry-run — so it dogfoods its decisions instead of sitting as unwired code.
+
+- **Wired into the server** — the `CredentialRebalancer` is constructed in the credential-repointing bundle with the snapshot-mapper providers (ledger → slots, subscription pool → accounts, config resolver) and an `isEnabled` that mirrors the location gate exactly (dev-gate-resolved AND not env-token-refused). A reentrancy-guarded, interval-clamped (`[60s, 60min]`), `.unref()`'d `setInterval` runs the pass; tick errors are caught so a throw never crashes the loop.
+- **Live status surface** — `GET /credentials/rebalancer` now reports `balancerWired:true` + `rebalancer.status()` (enabled, the P19 breaker state, cooldown counts, and the last pass's decisions/degraded/attention) when the feature is live, scrubbed via the audit chokepoint; it stays a strict 503 no-op while dark.
+- **Dry-run dogfood, zero writes** — on a dev agent the loop runs the full decision loop and audits what it WOULD do, but the executor's `dryRun` default keeps every credential write off until a deliberate `dryRun:false`.
+
+## What to Tell Your User
+
+The automatic account-balancer is now actually running on me — but in dry-run, so it's all observation, no action. Every few minutes it looks at your quota picture, decides whether a login should move, and records what it WOULD do — moving zero real credentials. You can watch it at the rebalancer status endpoint (which account it would shuffle and why, plus its safety circuit-breaker). It only runs on a development agent like me (your wider fleet stays dark), and the step where it actually starts moving logins is still your deliberate switch, after the livetest. This is the dogfooding rung of the maturity path — it's live and watchable, with nothing irreversible happening.
+
+## Summary of New Capabilities
+
+The autonomous balancer (Increment B) is now wired + running in dry-run on a development agent. `GET /credentials/rebalancer` reports the live balancer status (last pass + P19 breaker). On a dev agent the balancer pass runs every ~5min (interval-clamped, reentrancy-guarded) computing + auditing its decisions; zero credential writes while `dryRun` holds (the default). The fleet stays dark (strict 503/no-op). No new write authority — the executor's dry-run gate is the load-bearing write guard.
+
+## Evidence
+
+- `tests/e2e/credential-repointing-routes-alive.test.ts` (6) — the rebalancer route now surfaces `balancerWired:true` + the live `rebalancer.status()` (enabled + breaker) on a production-shaped bundle with a real wired CredentialRebalancer; the dark path still 503s (strict no-op). tsc + full lint clean. Independent second-pass review CONCUR (gate mirrors the location gate; dry-run defaults true with the executor as the write guard; timer reentrancy-guarded/clamped/unref'd/error-caught; route is a leak-free 503-while-dark surface).

package/upgrades/1.3.547.md

@@ -0,0 +1,26 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Added an **Operator Authorization Request** flow: when the agent needs the operator to grant a person a floor action (e.g. "let Mia deploy to prod for an hour"), it now pre-fills a structured request and the operator approves it in one tap on a plain-language "Approvals waiting for you" card — instead of hand-building a mandate in a raw-JSON form. This fixes the operator-reported defect where the Mandates tab forced the operator to construct a mandate from a raw-JSON authorities editor. The raw-JSON "author a mandate by hand" form is demoted behind an "Advanced" disclosure. A new constitutional standard — "Agent Proposes, Operator Approves" — is enforced by a precommit gate so authorization surfaces must be approvals, never authoring tasks, with the authority text authored by the server (never agent free-text). Ships dev-enabled / fleet-dark.
+
+## What to Tell Your User
+
+Nothing yet — this is an experimental, dark-by-default capability. On a developer agent it is live: when I need you to authorize a person for something (a deploy, a credential, etc.), you'll see a simple card on the dashboard Mandates tab — one plain sentence, your PIN, and Approve. You never build a "mandate" or touch JSON. Only your PIN turns my request into a real grant.
+
+## Summary of New Capabilities
+
+- `POST /authorization-requests` — the agent pre-fills a structured grant request (Bearer; confers no authority).
+- `GET /authorization-requests?status=pending` — the dashboard's "Approvals waiting for you" cards (server-authored plain-language text).
+- `POST /authorization-requests/:id/approve|deny` — PIN-gated operator approval/decline; approve issues the grant via the existing signed MandateStore path.
+- `POST /authorization-requests/:id/withdraw` — the proposing agent withdraws its own pending request.
+- Constitutional standard "Agent Proposes, Operator Approves" + a blocking precommit gate.
+
+## Evidence
+
+The operator reported (2026-06-13, topic 22367) that the Mandates grant flow still showed raw JSON and forced him to "create a mandate" — reproducible by opening the Mandates tab and attempting a grant with no active mandate (the grant form never appears; only the raw-JSON issue form does). Fixed: the new "Approvals waiting for you" card is the primary surface; the raw-JSON form is demoted behind "Advanced". A naive version of the fix would have reopened a deceptive-display hole (agent-authored card text diverging from the executed grant); that is closed by server-authoring the headline from the structured proposal + the registry name, and is asserted at all three test tiers (a malicious agent `reason` never becomes the headline). 67 tests green (unit/integration/e2e + gate + dark-gate golden map).
+
+<!-- ci: re-trigger workflow dispatch after force-push (capability-index fix) -->

package/upgrades/side-effects/operator-authorization-request.md

@@ -0,0 +1,65 @@
+# Side-effects review — Operator Authorization Request
+
+Spec: `docs/specs/OPERATOR-AUTHORIZATION-REQUEST-SPEC.md` (converged 3 rounds / 6 reviewers, approved).
+
+## Summary of the change
+
+Adds an **Authorization Request** primitive: the agent (Bearer) pre-fills a structured request to grant a user a floor action; the operator approves it with their dashboard PIN on a dead-simple "Approvals waiting for you" card; on approval the server issues the grant via the EXISTING signed `MandateStore.issue()` path. Replaces the raw-JSON "build a mandate by hand" form as the primary surface (it is demoted behind an "Advanced" disclosure). Ships dev-enabled / fleet-dark (`resolveDevAgentGate`, `enabled` omitted from ConfigDefaults).
+
+## Decision-point inventory
+
+The only new authority-conferring decision point is the PIN-gated `POST /authorization-requests/:id/approve`. It routes through the existing signed `MandateStore.issue/addGrants` — it does NOT introduce a new authority primitive, modify the MandateGate deny-ladder, the GrantStore read path, or the SlackPermissionGate evaluate-path.
+
+## 1. Over-block
+Could a legitimate operator be blocked from approving? The approve route is PIN-gated with the existing rate-limited `checkMandatePin` (5/5min per IP). A locked-out operator self-heals after the window. The feature is additive — if its store is unreadable the routes 503 and the existing manual mandate/grant path is unaffected. No new over-block on existing flows.
+
+## 2. Under-block
+Could an agent get authority it shouldn't? No. A pending request confers ZERO authority (inert). The grant issues ONLY inside the PIN-gated approve, via the existing signed path — requester ≠ authorizer is preserved and the agent can never approve its own request (no PIN). The proposable floor-action allowlist EXCLUDES `grant-authority` (the meta-escalation stays manual). The grantee must resolve to a registered principal at create AND approve (rejects phantom/sybil ids).
+
+## 3. Level-of-abstraction fit
+A new primitive at the right layer: it is an operator-friendly FRONT DOOR to issuing a grant, built atop the proven mandate read/issue path (one-carrier-per-grant, `meta.carrier:true`, operator-invisible). Not a parallel authority store.
+
+## 4. Signal vs authority compliance
+The PIN-gated approve is a legitimate human authority chokepoint (the operator sees the named person + plain-language action and decides). No automated trust-policy gate is layered on top (that would re-introduce brittle blocking authority on a human authority). Foundation note: the SlackPermissionGate `FLOOR_ACTIONS` enum-as-authority (flagged 2026-06-09) is inherited UNCHANGED and explicitly NOT worsened — recorded in the spec's Foundation Audit; resolving it is a separate spec.
+
+## 5. Interactions
+- MandateStore: approval issues a fresh per-grant carrier mandate (expiry == grant expiry); revoking one never affects another; hourly prune bounds the `activeGrant` hot-path scan.
+- SlackPermissionGate: unchanged — `activeGrant` returns the issued grant and the gate flips refuse→allow with no gate change.
+- Manual issue form: demoted behind "Advanced", still functional for the rare agent-pair credential/code-review case.
+
+## 6. External surfaces
+- HTTP: 6 new `/authorization-requests` routes (Bearer for propose/list/withdraw; PIN-gated for approve/deny). 503 when the feature is off.
+- Dashboard: a new "Approvals waiting for you" section + the demoted manual form (`dashboard/index.html`, `dashboard/mandates.js`).
+- Audit: every issued grant lands in the existing hash-chained `MandateAudit`.
+
+## 6b. Operator-surface quality (Operator-Surface Quality standard)
+The change touches operator surfaces (`dashboard/index.html`, `dashboard/mandates.js`). Answering the quality question in writing:
+1. **Leads with the primary action?** YES — the "Approvals waiting for you" card renders open at the top of the tab with Approve as the primary, always-visible button; the destructive/advanced paths are below and collapsed.
+2. **Exposes zero raw internals as primary content?** YES — the card shows only a server-authored plain-language sentence ("Let Mia deploy to production for 1 hour.") + an optional escaped secondary reason. No JSON, fingerprints, slugs, or the carrier mandate. The raw-JSON authorities editor is demoted behind "Advanced — author a mandate by hand".
+3. **De-emphasizes destructive actions?** YES — Decline is a quiet secondary button; there is no destructive primary.
+4. **Plain language at phone width?** YES — single-column cards, real tap targets, plain sentences; no horizontal scroll.
+
+## Agent Proposes, Operator Approves (the new standard)
+The change touches an authorization/approval surface, so it answers the agent-proposes/operator-approves + display-integrity question:
+1. **Does the operator APPROVE a pre-filled request rather than construct one?** YES — the agent supplies only structured fields; the operator reads one sentence and taps Approve. They never assemble a mandate, pick enums, or edit JSON.
+2. **Is the authority statement SERVER-authored, not agent free-text?** YES — `renderAuthorizationCard` builds the headline from the structured proposal + the registry display name; the agent's optional `reason` is carried as a clearly-secondary, escaped note and can never become the headline. A unit + integration + e2e test each assert a malicious `reason` never appears as the authority. This closes the deceptive-summary class.
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+The AuthorizationRequest store is **machine-local by design** (the grant it issues lands in the holder's machine-local MandateStore). Each request stamps `createdOnMachine`. The pending-approval card on a NON-holder machine shows "Asked on <machine> — open that machine's dashboard to approve" instead of a dead Approve button (no silent cross-machine hole). Documented in FD-6.
+
+## 8. Rollback cost
+Clean. The feature is dev-gated: setting `monitoring.authorizationRequests.enabled:false` (or fleet default) routes every route 503; nothing else changes. Disabling mid-flight leaves pending requests inert (they confer nothing) and any already-issued grants stand as normal mandate grants (revocable via the existing path). No migration to unwind (no `migrateConfig` entry; the dashboard serves from the package dir).
+
+## Conclusion
+Loss-reducing + additive. The single safety invariant (requester ≠ authorizer; PIN-only authority) is preserved and strengthened (server-authored display). Ships dark-on-fleet behind the dev gate.
+
+## Evidence pointers
+- Spec + convergence report: `docs/specs/OPERATOR-AUTHORIZATION-REQUEST-SPEC.md`, `docs/specs/reports/operator-authorization-request-convergence.md`.
+- Tests (67 green): `tests/unit/AuthorizationRequestStore.test.ts` (20), `tests/unit/operator-surface-gate.test.ts` (13), `tests/integration/authorization-request-routes.test.ts` (7), `tests/e2e/authorization-request-lifecycle.test.ts` (3), `tests/unit/lint-dev-agent-dark-gate.test.ts` (24, golden map recomputed).
+- The deceptive-summary defense is asserted at all three tiers (server-authored headline ≠ agent free-text).
+
+## Second-pass review (if required)
+The spec passed 3-round convergence with 6 independent reviewers (security, adversarial, integration/multi-machine, decision-completeness, lessons-aware/foundation, scalability) — the multi-angle adversarial review that catches what a single pass misses. The round-1 CRITICAL (deceptive display) and round-2 HIGH (bounds-as-deception) were both closed before convergence.
+
+## Implementation note (CapabilityIndex)
+The 6 `/authorization-requests` routes are classified in `src/server/CapabilityIndex.ts` as the agent-facing `authorizationRequest` capability (surfaced in `/capabilities`), satisfying the capabilities-discoverability ratchet.