instar 1.3.440 → 1.3.442

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.440",
+  "version": "1.3.442",
   "description": "Coherence infrastructure for self-evolving AI agents — on the Claude Code or Codex subscription you already have.",
   "type": "module",
   "main": "dist/index.js",

package/src/data/builtin-manifest.json

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

package/src/data/state-coherence-registry.json

@@ -125,6 +125,18 @@
       ],
       "grandfathered": false
     },
+    {
+      "category": "slack-pending-registrations",
+      "description": "Durable pending Slack self-registration requests awaiting admin approval (SlackUserRegistry). Cleared on approve/deny. See docs/specs/SLACK-ORG-INTEGRATION-SPEC.md §6.3.",
+      "scope": "machine-local",
+      "freshness": "eventual",
+      "conflictShape": "single-writer",
+      "transport": "none",
+      "paths": [
+        "state/slack-pending-registrations.json"
+      ],
+      "grandfathered": false
+    },
     {
       "category": "topic-placement-history",
       "description": "Topic<->machine placement history (does not exist as its own store yet; the journal's first stream materializes it). Distinct from current-owner pool state.",

package/upgrades/1.3.441.md

@@ -0,0 +1,26 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+feat(permissions): Slack org permissions **Phase 1** — conversational user registration + the enforce path, both **dark by default**. Builds on Slice 0 (the observe-only permission gate, #1005).
+
+- **Registration** (`SlackUserRegistry` + `POST /permissions/registrations/{register,approve,deny}`, `GET …/pending`): admins register users with a role; self-registration creates a pending entry for approval. Persists to `state/slack-pending-registrations.json` (registered machine-local).
+- **Enforce path** (`SlackAdapter._handleMessage`): when the injected permission observer is `enforcing`, a non-`allow` verdict sends the conversational refusal/clarify reply (in-thread, via the existing `sendToChannel`) and blocks the message from reaching the session. When NOT enforcing (the default), behavior is identical to Slice 0 observe-only.
+
+The enforce path installs the blocking authority but leaves it **inert** — enabling `enforce:true` is gated behind a later phase that requires real false-positive-rate data from the observe ledger and the LLM judgment band holding authority (carried over from the Slice 0 §4 follow-up). No new Slack Web API surface (the reply reuses the contract-tested `sendToChannel`).
+
+## What to Tell Your User
+
+None — internal change (no user-facing surface).
+
+## Summary of New Capabilities
+
+None — internal change (no user-facing surface).
+
+## Evidence
+
+- 14 tests green: `slack-user-registry.test.ts` (7), `slack-permission-enforce.test.ts` (3), `slack-registration-routes.test.ts` (4). `tsc --noEmit` clean. `/permissions` prefix classified INTERNAL in CapabilityIndex (capabilities lint green).
+- Side-effects review (`upgrades/side-effects/slack-org-permissions-phase1.md`) with an independent Phase-5 second-pass (block/allow on inbound messaging).

package/upgrades/1.3.442.md

@@ -0,0 +1,28 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+feat(coordination): user→agent authority grants in the Coordination Mandate — a verified operator can grant a specific floor action to a specific Slack user, **signed into the mandate** so it can't be forged. Completes the Slack-permission floor-authorization path (the gate's `GrantStore.activeGrant` now has a signature-backed implementation).
+
+- `canonicalMandate()` appends grants to the signed bytes **only when non-empty**, so every existing no-grant mandate serializes byte-for-byte as before and its `authProof` still verifies (backward-compatible by construction).
+- `addGrants()` re-signs through the PIN-gated path and rejects any grant whose expiry exceeds the mandate's (a grant can't outlive its delegation); `issue()` enforces the same clamp.
+- `MandateBackedGrantStore` reads grants deny-by-default: authorship + mandate-revocation + mandate-expiry + grant-expiry all checked before a grant clears a floor action.
+- New PIN-gated route `POST /mandate/:id/grants`; every grant decision audited through the hash-chained `MandateAudit`.
+
+Dark/no-op until an operator mints a grant; the Slack gate that consumes it is still observe-only.
+
+## What to Tell Your User
+
+Nothing changes for you right now — this ships dark. It's an operator capability that becomes useful once the Slack permission gate is enabled: from then on you (the verified operator) can grant a *specific* Slack person permission for a *specific* high-risk action (e.g. a production deploy), time-boxed, signed so it can't be forged, and minted only behind your dashboard PIN. Until you mint a grant and turn the gate on, agent behavior is unchanged.
+
+## Summary of New Capabilities
+
+- **PIN-gated `POST /mandate/:id/grants`** — your verified operator grants a Slack user a specific floor authority, signed into the Coordination Mandate (can't be forged or widened by an agent; can't outlive its mandate; every grant decision is written to the tamper-evident audit log). Operator/internal — not surfaced in `/capabilities` while the Slack gate is dark.
+
+## Evidence
+
+- 19 new unit tests incl. the backward-compat test (legacy no-grant mandate verifies) + the forged-grant tamper test (grant added without re-signing → verification FAILS) + expiry-clamp/revoke/expiry-bypass coverage. `tsc --noEmit` clean; lint clean; 130/130 in the related coordination/permission sweep.
+- Side-effects review (`upgrades/side-effects/mandate-user-grants.md`) + an independent adversarial Phase-5 second-pass on the signing path.

package/upgrades/side-effects/mandate-user-grants.md

@@ -0,0 +1,78 @@
+# Side-Effects Review — Coordination Mandate user→agent authority grants
+
+**Version / slug:** `mandate-user-grants`
+**Date:** 2026-06-09
+**Author:** Instar Agent (echo)
+**Second-pass reviewer:** REQUIRED (authority/signing crypto — trust-level decision) — independent adversarial review, see Phase 5
+
+## Summary of the change
+
+Extends the Coordination Mandate so a verified operator can grant a SPECIFIC floor authority to a SPECIFIC Slack user, signed into the mandate so it cannot be forged. This is what lets a non-owner be permitted a floor action (e.g. a prod-deploy) — the Slack permission gate's floor check already calls `GrantStore.activeGrant(slackUserId, scope, now)`; this provides the production, signature-backed implementation.
+
+Files: `src/coordination/types.ts` (the `UserAuthorityGrant` type + optional `grants?` on `CoordinationMandate`), `src/coordination/MandateStore.ts` (the security-critical `canonicalMandate()` change + `addGrants()` re-sign path + `issue()` carrying grants), `src/permissions/MandateBackedGrantStore.ts` (new — reads signed grants, deny-by-default), `src/permissions/index.ts`, `src/server/routes.ts` (PIN-gated `POST /mandate/:id/grants`), `src/server/CapabilityIndex.ts` (route registration), `src/commands/server.ts` (wire the store into the gate).
+
+Decision points touched: the floor-authorization decision (a grant can now clear a floor action for a non-owner) — but only via a SIGNED grant minted on the PIN-gated path.
+
+## Decision-point inventory
+
+- `MandateBackedGrantStore.activeGrant` — **add** — resolves a signed grant → clears a floor action for the named user. Deny-by-default; authorship + mandate-expiry + mandate-revocation + grant-expiry all checked before a grant is honored.
+- `canonicalMandate()` — **modify (security-critical)** — grants are now part of the signed bytes (append-only-when-non-empty for backward-compat).
+- `POST /mandate/:id/grants` — **add** — PIN-gated issuance (re-signs the mandate with the grant); mirrors `issue`/`revoke`.
+
+---
+
+## 1. Over-block
+
+The grant store is the ALLOW side (it clears a floor action). Over-allow, not over-block, is the risk here — see §4. No legitimate input is wrongly blocked: absent a valid grant, the gate's pre-existing behavior (owner authorizes floor / others refused) is unchanged.
+
+## 2. Under-block (the real risk for an allow-path)
+
+The danger is honoring a grant that shouldn't be honored. Mitigations, all enforced before a grant clears a floor:
+- The mandate's `authProof` must verify (the grant is part of the signed bytes — a forged/added grant fails).
+- The mandate must not be revoked and not be expired.
+- The grant itself must not be expired, and its `expiresAt` is clamped to never exceed the mandate's `expiresAt` (a grant cannot outlive its delegation — enforced at `addGrants` AND at `issue`).
+- Match is exact on `grantedTo` (slackUserId) and `floorAction` (no substring/coercion).
+Deny-by-default: any check failing → no grant returned.
+
+## 3. Level-of-abstraction fit
+
+Correct. The mandate is already the audited, HMAC-signed authority primitive (requester ≠ authorizer; PIN-gated issuance). User→agent grants are a natural extension of the same signed object — NOT a new parallel authority. The gate consumes grants via the existing `GrantStore` interface (Slice 0), so this is the consume side of an established seam.
+
+## 4. Signal vs authority compliance
+
+**Required reference:** docs/signal-vs-authority.md. This IS an authority (a grant clears a floor action), and it is NOT brittle:
+- A grant only has force if it is covered by the mandate's HMAC `authProof`, which is only produced by the PIN-gated issuance path (`MandateStore.sign`). An agent cannot mint or widen its own grant.
+- `MandateBackedGrantStore` verifies authorship BEFORE trusting `grants` — it never reads a grant off an unverified mandate.
+- The expiry clamp + revoke + mandate-expiry checks are deterministic (no LLM, no heuristic in the authorization path). Fail-closed.
+
+## 5. Interactions
+
+- **Backward-compat (the #1 interaction):** existing signed mandates have no `grants` field; `canonicalMandate()` appends grants ONLY when present + non-empty, so a no-grant mandate serializes byte-for-byte as before → every previously-signed mandate (incl. Dawn's live ones) still verifies. Proven by the backward-compat test (legacy on-disk mandate with no `grants` key verifies TRUE) + the append-only guard in `issue()`.
+- **Two `MandateStore` instances:** the gate (built in `commands/server.ts` before AgentServer) uses a second, stateless, READ-ONLY `MandateStore` reader over the same file with the same HMAC derivation (`config.authToken`). It only reads/verifies — no writes — so there's no write race; the writer is the AgentServer/route path.
+- **Audit:** every grant decision (allow on accept, deny on reject) is recorded through the existing hash-chained `MandateAudit`.
+
+## 6. External surfaces
+
+- **Other agents / install base:** none by default — no grants exist until an operator mints one on the PIN-gated route; the Slack gate is dark/observe-only. Pure no-op for existing agents.
+- **External systems:** none (no new outbound calls).
+- **Persistent state:** grants live inside the existing `state/coordination-mandates.json` (no new state file); the field is optional + append-only-when-non-empty.
+- **HTTP:** one new PIN-gated route `POST /mandate/:id/grants` (registered INTERNAL in CapabilityIndex + documented).
+
+## 7. Rollback cost
+
+Low / additive. Back-out = revert + patch. Because `canonicalMandate` is append-only-when-non-empty, reverting it does NOT invalidate existing no-grant mandates. The only durable artifact is grants inside mandates; if reverted, a grant-bearing mandate would fail to verify (its proof covers grants the reverted code wouldn't serialize) — but NO deployed mandate carries grants yet, so there is no live signed-grant data to break. No agent-state repair needed for the no-grant fleet.
+
+## Phase 5 — Second-pass review (independent, adversarial)
+
+REQUIRED (authority/signing crypto). An independent reviewer attempted to forge a grant, break backward-compat, and escape the expiry/revoke checks. Verdict appended below.
+
+### Verdict: CONCUR — no exploitable issue found (independent adversarial review)
+
+The reviewer attempted 9 distinct attacks against the live source (forge-a-grant, backward-compat break, expiry-clamp escape, revoke/expiry bypass, privilege confusion, issuance-auth bypass) via a standalone probe script + the full test suite, and could not land an exploit:
+- **Forge:** `MandateBackedGrantStore.activeGrant` calls `verifyAuthorship(mandate)` BEFORE reading `mandate.grants` — no path trusts grants off an unverified mandate; a re-signed-with-attacker-key mandate is rejected by the HMAC `timingSafeEqual`.
+- **Backward-compat:** `grants` undefined / `[]` / no-key all canonicalize byte-identically to the pre-extension baseline; a legacy on-disk no-grant mandate verifies TRUE.
+- **Expiry/revoke:** `activeGrant` skips revoked + expired mandates and past-expiry grants; the effective expiry is `min(grant, mandate)`.
+- **Privilege confusion:** strict `!==` equality on `grantedTo` + `floorAction` (no substring/coercion).
+- **Issuance auth:** `POST /mandate/:id/grants` is PIN-gated (same timing-safe gate as issue/revoke); Bearer-only → 403.
+
+**One hardening the reviewer flagged — IMPLEMENTED in this change:** the `issue()` library path originally did not enforce the `grant.expiresAt <= mandate.expiresAt` clamp that `addGrants()` does (it was unreachable from any untrusted surface — the issue route drops grants — and neutralized by the query-side clamp, so "hardening, not a blocker"). To make the library contract uniformly safe for any future caller, `issue()` now applies the same validation + clamp (throws on an over-long or malformed grant), covered by a new test (`issue() with grants applies the SAME expiry clamp as addGrants`). Total unit tests: 20.

package/upgrades/side-effects/slack-org-permissions-phase1.md

@@ -0,0 +1,68 @@
+# Side-Effects Review — Slack org permissions Phase 1 (registration + enforce path)
+
+**Version / slug:** `slack-org-permissions-phase1`
+**Date:** 2026-06-09
+**Author:** Instar Agent (echo)
+**Second-pass reviewer:** REQUIRED (block/allow on inbound messaging) — see Phase 5 below
+
+## Summary of the change
+
+Builds on Slice 0 (the dark/observe-only Slack permission gate, merged in #1005). Phase 1 adds two things:
+1. **Conversational registration** (`src/permissions/SlackUserRegistry.ts` + `src/server/routes.ts` `POST /permissions/registrations/{register,approve,deny}` + `GET …/pending`): admins register users with a role; self-registration creates a pending entry for approval. Persists to `state/slack-pending-registrations.json` (registered in `state-coherence-registry.json`).
+2. **The enforce path** (`src/messaging/slack/SlackAdapter._handleMessage`): when the injected permission observer is **enforcing**, a non-`allow` verdict sends the conversational refusal/clarify reply (via the existing `sendToChannel`, in-thread) and returns — blocking the message from reaching the session. When NOT enforcing (the default), the observe call stays fire-and-forget exactly as in Slice 0.
+
+Decision points touched: the inbound-message block/allow in `_handleMessage` (the enforce branch).
+
+## Decision-point inventory
+
+- `SlackAdapter._handleMessage` enforce branch — **add** — when `observer.enforcing`, a non-allow verdict blocks message processing + sends the gate reply. Dark by default (`enforcing=false` → unchanged observe-only behavior).
+- `SlackUserRegistry` register/approve/deny — **add** — identity/role assignment; not a message gate (data layer feeding the principal resolver).
+- `POST /permissions/registrations/*` routes — **add** — Bearer-gated admin/operator routes; classified INTERNAL (capabilities) like the rest of `/permissions`.
+
+---
+
+## 1. Over-block
+
+When `enforcing=true`, the gate blocks any inbound message whose verdict ≠ `allow`. Over-block risk: a legitimate message mis-classified as floor/clarify is withheld from the session and gets a refusal/clarify reply instead. **Mitigation:** the path ships dark (default `enforcing=false`); the verdict logic is Slice 0's (floor = deterministic-conservative; the judgment band routes ambiguity to CLARIFY, which still replies to the user rather than silently dropping). Enabling enforce is gated behind a later phase that requires real FP-rate data from the observe ledger first (carried over from the Slice 0 §4 follow-up).
+
+## 2. Under-block
+
+When `enforcing=false` (default) the gate blocks nothing — identical to Slice 0 observe-only. That is intentional: Phase 1 ships the mechanism dark; it does not claim to protect anything yet. The registration layer does not itself enforce (a registered role only matters once the gate consumes it). No new protection is asserted.
+
+## 3. Level-of-abstraction fit
+
+Correct layer. The enforce decision sits in `_handleMessage` AFTER the fail-closed `authorizedUserIds` AuthGate and uses the SAME observer/verdict the observe path already produced — so it's the consume side of an existing signal, not a new parallel detector. Registration is a data layer (identity → role), feeding the existing `SlackPrincipalResolver`; it does not re-implement identity.
+
+## 4. Signal vs authority compliance
+
+**Required reference:** docs/signal-vs-authority.md. This is the change that turns the Slice 0 SIGNAL into an AUTHORITY (it can block) — so the compliance bar is real:
+- The blocking authority is NOT brittle: the floor is deterministic-conservative-fail-closed; the judgment band is the injectable `IntentClassifier` (heuristic = deterministic test/fallback; LLM-backed in production) and routes ambiguity to CLARIFY, never to a silent allow. A blocked **directed** request (DM or @mention) always gets a conversational reply. (Precise nuance, per the second-pass review: the one no-reply block path is an *overheard/undirected* actionable message in `respondMode:'all'` — verdict `refuse/overheard/''` — which is correctly NOT actioned and NOT replied-to per §6.9; that is by design, not a silent drop of a directed user request.)
+- It ships **dark** (`enforcing=false`), so the authority is installed but inert until a later, FP-data-gated phase explicitly enables it with the LLM judge holding the band — not the heuristic. **This artifact does NOT authorize `enforce:true`.**
+
+## 5. Interactions
+
+- **Shadowing:** the enforce branch runs in the same spot as the Slice 0 observe call (after AuthGate, before the mention-only skip). When enforcing, it returns early (blocks) — so it shadows the normal handler BY DESIGN for non-allow verdicts; when not enforcing it changes nothing.
+- **Double-fire:** the observe ledger write and the enforce decision use the same single verdict; no double evaluation.
+- **Races:** `SlackUserRegistry` writes `slack-pending-registrations.json` (single-writer per process, atomic write); the enforce decision is synchronous in the handler (no race with the fire-and-forget observe path, which only runs when NOT enforcing).
+- **Registration vs gate:** an unregistered user resolves to the lowest role → the gate treats them conservatively; registration only ever raises trust via an explicit admin/approval action.
+
+## 6. External surfaces
+
+- **Other agents / install base:** none — dark by default (no permission observer attached unless configured); pure no-op for every existing agent.
+- **External systems (Slack):** **no new Slack Web API calls** — the enforce reply reuses the existing `sendToChannel` (already contract-tested in Slice 0). The Slack API contract surface is unchanged by Phase 1 (verified: no new `client.*`/`postMessage` calls in the diff).
+- **Persistent state:** one new file `state/slack-pending-registrations.json` (registered machine-local in `state-coherence-registry.json`). Created lazily; bounded.
+- **HTTP:** four new Bearer-gated routes under `/permissions/registrations/*` (classified INTERNAL — agent-invisible while dark).
+
+## 7. Rollback cost
+
+Low / additive. Back-out = revert the 3 commits + ship a patch. No migration: `slack-pending-registrations.json` is observe/admin data (deletable with no consequence); the enforce branch is inert while dark, so reverting it changes nothing on any install (no one has `enforcing=true`). No agent-state repair, no user-visible regression.
+
+## Phase 5 — Second-pass review
+
+REQUIRED: this change adds a **block/allow decision on inbound messaging**. An independent reviewer must audit this artifact and append "Concur" or "Concern: …" below before the trace is written with `--second-pass true`.
+
+## Second-pass review (independent reviewer)
+
+**Concur with the review.** Verified against the actual code: the blocking authority is genuinely fail-closed — the floor (`SlackPermissionGate` lines 140–180) is deterministic, regex-detected via `HeuristicIntentClassifier` (no LLM in the floor path), `roleCanAuthorizeFloor` clears only `owner`/explicit grant, an unregistered user resolves to `guest`/`registered:false` and is refused, ambiguity routes to `clarify` (line 131), and `NullAnomalyScorer` (default) can't spuriously raise step-up; the enforce branch sits after the fail-closed AuthGate, reuses the single observe verdict, and is genuinely inert when `enforcing=false` (`observer.enforcing` → `deps.enforce ?? false` → original fire-and-forget path, proven by the `enforcing=false` unit test), with no new Slack API calls (reuses pre-existing `sendToChannel`; diff grep for `client.*`/`postMessage`/`chat.*` additions returns none).
+
+*Minor wording nuance (not a blocker, no code change needed):* §4's "a blocked message **always** gets a conversational reply" is slightly overstated. The one non-allow verdict carrying an empty message is `refuse / overheard / ''` (gate line 108), reachable only for an **undirected** (non-DM, non-mention) actionable message in `respondMode:'all'` — in that case the enforce branch blocks with no reply (`if (verdict.message)` is false → silent `return`). This is correct by design (an overheard command must not be actioned per §6.9, and replying to a message not directed at the bot would be channel noise) — it is not a silent drop of a *directed* user request, and it ships dark regardless. Worth a one-word softening of §4 ("a blocked *directed* request always gets a reply") at the authoring agent's discretion; the behavior itself is sound.