instar 1.3.546 → 1.3.548

package/package.json

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

@@ -0,0 +1,24 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Completes Increment B's tooling with the promotion gate made reachable: `POST /credentials/livetest` runs the §5 livetest battery (the harness built in Step 10) against the real swap executor + identity oracle.
+
+- **Double-gated credential-action route.** A real credential move needs BOTH `armed:true` in the request body (the harness performs zero swaps otherwise) AND a deliberate `dryRun:false` (the executor writes nothing otherwise). Either gate alone keeps every credential untouched.
+- **Defence-in-depth.** Dark → 503 (the lever guard); every named slot is validated against the enumerated ledger set → 400 before the harness runs (a `../`/`~`/absolute path can't reach a write); the report is scrubbed and carries no token material.
+- **The report.** Surfaces the automatable round-trip verdicts (identity-verified exchange-then-restore, always restoring) and the inherently-manual items (refresher correctness, the §0.c residual via a disposable grant, liveness) — `promotable` stays false while any manual item remains.
+
+## What to Tell Your User
+
+The "is this safe to turn on?" check is now a button you can press when you're ready. It runs the real safety battery — a live account-swap and swap-back, verified with the trustworthy identity check, always restoring — and tells you whether the automatic moves landed correctly. Two separate safety catches protect it: it does nothing unless you explicitly arm it, and even armed it won't move a real credential until you've also flipped off dry-run. Two parts of the full battery are hands-on (waiting out a token refresh, stressing a throwaway login), which it lists for you. This is the last rung before the go/no-go: when you want to actually turn on real credential moves, you run this first, watch it pass, then decide.
+
+## Summary of New Capabilities
+
+`POST /credentials/livetest` — the reachable promotion gate for live credential re-pointing. Runs the §5 livetest battery against the real executor + oracle; double-gated (armed:true AND dryRun:false both required to move a real credential), dark → 503, slots validated → 400, report scrubbed. The operator-run last rung before the dry-run→live go/no-go.
+
+## Evidence
+
+- `tests/integration/credential-routes.test.ts` (+4 = 13) — DARK → 503; ENABLED + NOT armed → refused report with zero swaps + the manual items surfaced; ENABLED + armed → the battery runs (armed report, both round-trip steps present, promotable false); unknown slot → 400 (no harness run). tsc + full lint clean; docs-coverage route floor preserved. Independent second-pass review CONCUR (two independent gates intact — armed AND dryRun:false; dark 503s before construction; path-traversal slots rejected; report scrubbed; harness always-restores).

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.