instar 1.3.741 → 1.3.742

package/package.json

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

package/src/data/builtin-manifest.json

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

package/upgrades/1.3.742.md

@@ -0,0 +1,64 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Closes a check-then-send race in the existing exact-match outbound duplicate guard
+(`OutboundContentDedup`) at the `/telegram/reply` chokepoint — one mechanism behind the
+user-reported double-sends (RCA topics 30823/30837).
+
+The guard recorded a sent fingerprint only AFTER a successful send. Under a server stall a send
+can be in flight for tens of seconds, and a second identical request arriving in that window
+passed the pre-check (nothing recorded yet) and sent a duplicate. The fix adds an atomic
+**reserve → confirm/release** lifecycle to the SAME exact-match guard:
+
+- `tryReserve(topicId, text)` — synchronously re-checks the sent-window AND claims an in-flight
+  reservation in one step; returns suppress when the text was already sent within the window OR
+  is currently in flight. Auto-expires after `reserveTtlMs` (default 3min) so a leaked claim can
+  never permanently suppress.
+- `releaseReservation(topicId, text)` — clears the claim when the send FAILS, so the legitimate
+  retry is not suppressed.
+- `record()` clears the claim on success (the longer sent-window takes over).
+
+Route wiring: the reservation is taken AFTER the tone gate (a held/blocked message never
+reserves — no leak) and immediately before the send; `releaseReservation` runs in the
+send-failure catch. `allowDuplicate` bypasses it; brief acks (below the length floor) are never
+reserved.
+
+Deliberately scoped: this is the **exact-duplicate** half. The **reworded** near-duplicate is
+NOT hard-blocked here — that requires a similarity threshold, and a brittle similarity detector
+must not hold blocking authority (`docs/signal-vs-authority.md`). The reworded/systemic case is
+routed to the RCA shared-primitives spec (topic 30837), not botched into a brittle blocker here.
+
+## What to Tell Your User
+
+If you ever saw the agent send you the same message twice, this fixes one cause of it. When the
+server was briefly slow, a message could start sending, and a second identical copy could slip
+out before the first was marked "done." Now the agent claims a message the instant it starts
+sending, so an identical copy can't sneak through that gap — while a failed send still lets its
+retry go through, and short replies like "got it" are never affected. Note this covers *exact*
+duplicates; the case where the same point comes back slightly *reworded* is a harder problem
+being handled separately.
+
+## Summary of New Capabilities
+
+None — this is a reliability fix to existing duplicate-suppression behavior. The reply endpoint
+keeps the same shape; an in-flight duplicate is suppressed the same way an already-sent one is.
+
+## Evidence
+
+- `npx vitest run tests/unit/OutboundContentDedup.test.ts` → **18 tests** (reserve claims;
+  concurrent identical suppressed before record; window catch after record; release-on-failure
+  retry; TTL auto-expiry; brief-ack exemption; per-topic isolation; disabled no-op).
+- `npx vitest run tests/unit/outbound-content-dedup-route.test.ts` → **8 tests** incl. a route
+  test that literally holds one send IN FLIGHT and proves the identical second is suppressed, and
+  that a FAILED send releases the reservation so its retry reaches Telegram.
+- `npx vitest run tests/unit/OutboundContentDedup.test.ts tests/unit/outbound-content-dedup-route.test.ts tests/unit/outbound-dedup-durable.test.ts tests/unit/relayContentDedup.test.ts`
+  → **41 tests, 0 failures**.
+- `npx tsc --noEmit -p tsconfig.json` → **0 errors**.
+- Independent second-pass reviewer (delivery-path audit): **Concur** — no over-block path drops a
+  legitimate message; reservation taken strictly after the tone-gate early-return; failure
+  release + TTL expiry + allowDuplicate bypass all verified line-by-line.
+- Side-effects review: `upgrades/side-effects/double-send-inflight-reservation.md`.

package/upgrades/side-effects/double-send-inflight-reservation.eli16.md

@@ -0,0 +1,33 @@
+# Double-send in-flight reservation — Plain-English Overview
+
+> The one-line version: when the server was slow, the same message could go out twice because the "have I already sent this?" check happened before the send was marked done — this reserves the message the instant it starts sending, so a second identical copy can't slip through the gap.
+
+## The problem in one breath
+
+Sometimes users saw the same message from the agent twice. One cause: the agent has a guard that says "if I already sent this exact text to this chat recently, don't send it again." But that guard only wrote down "sent!" AFTER the send finished. When the server was stalled, a send could take 30+ seconds — and if a second identical send started during that gap, the guard hadn't written anything down yet, so both went out.
+
+## What already exists
+
+- **The exact-duplicate guard** — already blocks the identical message from being sent twice, and even remembers across restarts (a small durable store). It works fine *once the first send has finished and been recorded*. The gap was only the in-between window.
+- **A separate near-duplicate detector** — notices when two messages are *similar but reworded*. Crucially, this one is only a *hint* fed to the smart safety reviewer; it is deliberately NOT allowed to block on its own, because "80% similar" can mean "a bug repeated itself" OR "the user asked me to say it again," and a dumb similarity score can't tell those apart.
+
+## What this adds
+
+A "reserve" step. The instant the agent decides to send a message, it now *claims* that exact text as in-flight — before the send starts. If a second identical send shows up while the first is still going, it sees the claim and steps aside. When the first send finishes, the claim is upgraded to the normal "already sent" record. If the first send *fails*, the claim is released immediately so the genuine retry can go through. And if something crashes and a claim is never resolved, it auto-expires after a few minutes so it can never permanently block that text.
+
+## The new pieces
+
+- **`tryReserve`** — one atomic step that both checks "already sent or already in flight?" and, if not, claims it. Returns "go ahead" or "stop, it's a duplicate."
+- **`releaseReservation`** — undoes the claim when a send fails, so retries aren't punished.
+- **Auto-expiry** — a claim that's never resolved disappears on its own after ~3 minutes.
+
+## The safeguards
+
+- It only ever suppresses an **exact** duplicate (same text, same chat) — never a reworded message, never a short "got it" ack, and never anything the caller marked "allow duplicate."
+- It is placed AFTER the smart safety reviewer, so a message that reviewer holds for later never gets stuck behind a stale claim.
+- It changes nothing about the *reworded* double-send. That's a harder problem that needs a proper design, because catching "similar" messages with a blunt threshold would start blocking legitimate repeats — exactly the mistake instar's "signal vs authority" rule exists to prevent. That work is tracked separately.
+- Everything is in memory only — nothing new is written to disk, so rolling this back is a clean one-step revert.
+
+## What you need to decide
+
+This is the principle-compliant half of the double-send fix: it closes the exact-duplicate race safely, with full test coverage (unit tests for the reserve/release/expiry lifecycle, plus a route test that literally holds one send in flight and proves the second is suppressed and that a failed send still lets its retry through). The one thing to be aware of: it does NOT stop *reworded* duplicates — that half is intentionally deferred to a proper spec, because doing it naively would violate a core instar principle. So this ships as a real, safe improvement, with the harder half honestly flagged rather than botched.

package/upgrades/side-effects/double-send-inflight-reservation.md

@@ -0,0 +1,100 @@
+# Side-Effects Review — Double-send in-flight reservation (close the exact-duplicate send race)
+
+**Version / slug:** `double-send-inflight-reservation`
+**Date:** `2026-07-03`
+**Author:** `Echo (instar-dev agent)`
+**Second-pass reviewer:** `reviewer subagent (see appended concurrence)`
+
+## Summary of the change
+
+Closes a check-then-send race in the existing EXACT-match outbound duplicate guard (`OutboundContentDedup`) at the `/telegram/reply` chokepoint. The guard recorded a fingerprint only AFTER a successful send, leaving a window: under a server stall a send can be in flight for tens of seconds, and a second identical request arriving in that window passed the pre-check (nothing recorded yet) and sent a duplicate — one mechanism behind the user-reported double-sends (RCA topics 30823/30837).
+
+The fix adds an atomic **reserve → confirm/release** lifecycle to the SAME exact-match guard:
+
+- `OutboundContentDedup.tryReserve(topicId, text)` — synchronously re-checks the sent-window AND claims an in-flight reservation in one step; returns `false` (suppress) if the text was already sent within the window OR is currently reserved (in flight). Reservations auto-expire after `reserveTtlMs` (default 3min) so a leaked claim can never permanently suppress a fingerprint.
+- `OutboundContentDedup.releaseReservation(topicId, text)` — clears the reservation when the send FAILS, so the legitimate retry is not suppressed.
+- `record()` (unchanged call site) now also clears the reservation on success (the longer sent-window takes over).
+
+Route wiring (`src/server/routes.ts`, `/telegram/reply`): the cheap `isDuplicate` pre-check before the tone gate is unchanged (early exit for already-sent duplicates); a new `tryReserve` gate is taken AFTER the tone gate, immediately before the send, and `releaseReservation` is called in the send-failure catch. `allowDuplicate` bypasses the reservation entirely.
+
+Files: `src/messaging/OutboundContentDedup.ts`, `src/server/routes.ts`, plus unit + route tests.
+
+## Decision-point inventory
+
+- `OutboundContentDedup` (exact-match duplicate guard) — modify — adds an in-flight reservation phase to an EXISTING deterministic block. It is NOT a new decision point; it makes the existing one race-safe.
+- `/telegram/reply` send path — modify — the reservation gate is taken before the send and released on failure.
+
+The reservation is placed AFTER the tone gate, so a held/blocked message never reserves (no interaction with the tone gate's own retry/hold path).
+
+---
+
+## 1. Over-block
+
+**What legitimate inputs does this reject that it shouldn't?** Only an EXACT (whitespace-normalized) duplicate of a message currently in flight to the SAME topic. Concretely: if the agent deliberately sends the byte-identical long message twice to the same topic within ~3 minutes while the first is still sending, the second is suppressed. That is the intended behavior and the existing guard already suppresses the same text once recorded — this only extends it to the in-flight window. Legitimate repeats are protected three ways: (a) brief acks (< `minLength`, default 40) are never reserved or suppressed; (b) `allowDuplicate: true` bypasses it; (c) a DIFFERENT (even slightly reworded) message has a different fingerprint and is never touched. The reworded double-send is explicitly NOT addressed here (see §2) precisely to avoid the brittle-similarity over-block the signal-vs-authority principle warns against.
+
+---
+
+## 2. Under-block
+
+**What failure modes does this still miss?** (a) The **reworded** near-duplicate — a resend with changed wording has a different fingerprint and is NOT caught. This is deliberate: catching it requires a similarity threshold, which is a brittle detector that must NOT hold blocking authority (`docs/signal-vs-authority.md` uses this exact example). That case stays a signal to the tone-gate authority and is routed to a proper spec, not this quick-win. (b) A **cross-process/cross-machine** in-flight race (a durable-relay retry from a different process while the first is in flight) — the in-memory reservation is per-process; once the first send records, the existing durable sent-window store catches the retry, but the sub-second cross-process in-flight window is not closed here. Both are named, not silently deferred: the reworded/systemic case is the RCA's shared-primitives spec work (topic 30837); the cross-process reservation is a follow-up tracked below.
+
+<!-- tracked: topic-30823 — reworded near-dup + cross-process in-flight reservation are follow-ups; the reworded case requires the signal-vs-authority-compliant design in the sibling RCA's shared-primitives spec (topic 30837), NOT a brittle hard block here. -->
+
+---
+
+## 3. Level-of-abstraction fit
+
+Correct layer. The reservation lives INSIDE `OutboundContentDedup` (the class that owns the exact-match guard), so it composes with the existing sent-window logic and durable store rather than being bolted onto the route. The route only sequences reserve → send → confirm/release. This is a deterministic guard becoming race-safe — not a new authority and not a re-implementation of one.
+
+---
+
+## 4. Signal vs authority compliance
+
+**Compliant — and deliberately so.** The reservation strengthens an EXISTING deterministic, EXACT-match block (fingerprint equality) by closing a TOCTOU race. It introduces NO brittle/similarity logic and NO new blocking authority. The reworded near-dup — the case that WOULD require a brittle similarity detector — is explicitly kept OUT (it stays a signal to the tone-gate authority), directly honoring `docs/signal-vs-authority.md`'s canonical warning that a similarity score must not hold blocking authority. This change is the principle-compliant half of the double-send fix.
+
+---
+
+## 5. Interactions
+
+- **Tone gate:** the reservation is taken AFTER the tone gate, so a held/blocked message never reserves — no leak on the tone-gate hold/retry path.
+- **Durable sent-window store:** `tryReserve` calls `isDuplicate`, which already consults the durable store; the reservation is additive (in-memory in-flight only) and never conflicts with the recorded sent-window.
+- **`record` on success / `releaseReservation` on failure / TTL expiry** form a complete lifecycle — every reserved fingerprint is resolved (success clears, failure clears) or auto-expires; no path leaks a permanent suppression.
+- **`allowDuplicate`** short-circuits before `tryReserve` (no reserve, no block), preserving the escape hatch.
+- No double-fire with the delivery-id LRU or the byte-identical pre-check — they suppress different windows and all return the same `suppressedDuplicate: true` shape.
+
+---
+
+## 6. External surfaces
+
+- **`/telegram/reply`** — same response shape. A suppressed in-flight duplicate returns `{ ok: true, suppressedDuplicate: true }` (identical to the existing byte-identical suppression). No new error surface; a genuine send failure still returns 500 (and now releases the reservation).
+- Behavior depends on timing (in-flight window) by nature — but the outcome is deterministic given fingerprint equality; the TTL bounds any timing dependence.
+- No change visible to other agents/users beyond fewer duplicate messages.
+
+---
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+
+**Machine-local (in-flight state) BY DESIGN, with a named cross-machine follow-up.** The in-flight reservation is per-process in-memory — correct, because the send it guards executes in THIS process. The already-shipped durable `OutboundDedupStore` handles the cross-restart / cross-process SENT-window (once a send records). The remaining sub-second cross-process in-flight window (a durable-relay retry on another machine racing this process's in-flight send) is NOT closed here and is tracked (§2). On a single-machine agent there is no cross-process race and the fix is complete. No user-facing URL/topic-transfer concerns.
+
+---
+
+## 8. Rollback cost
+
+Low. Two files; straight revert restores the prior record-after-success behavior with no data migration (reservations are in-memory only — nothing persisted). The reservation is bypassable at runtime via `allowDuplicate` per-call, and the whole guard is disable-able via `outboundContentDedup.enabled: false` in config. If the reservation were ever suspected of wrongly suppressing, `reserveTtlMs` can be lowered (or the guard disabled) without a code change.
+
+---
+
+## Second-pass review (independent reviewer subagent)
+
+**Concur with the review.** Line-by-line audit of the delivery path confirmed no over-block:
+
+- `tryReserve` is taken strictly AFTER the tone-gate early-return, so a held/blocked message NEVER reserves — the leak-that-would-suppress-the-retry path does not exist.
+- No `await`/`return` sits between `tryReserve` and the awaited `sendToTopic`; the reserve→send is effectively atomic and any throw lands in the catch which calls `releaseReservation`. Failed send → reservation released → retry passes (confirmed by route test).
+- A leaked reservation (crash before resolve) is freed by `reserveTtlMs` (3min) via the expiry check + `pruneReserved`.
+- `!allowDuplicate &&` guards both the pre-check and `tryReserve`; below-`minLength` acks are never reserved.
+- `tryReserve`/`releaseReservation`/`record`/`pruneReserved` have no await between check and claim (single-threaded atomic), correct TTL math, per-topic isolation, bounded map growth.
+- Signal-vs-authority: only the exact fingerprint-equality guard gained the in-flight phase; no similarity logic gains blocking authority (reworded case deliberately excluded).
+
+**Pre-existing, out-of-scope observations (NOT introduced by this change, NOT blocking):** (1) `record()` fires after any non-throwing `sendToTopic` regardless of whether `sendResult.messageId` indicates real delivery — a relay that "succeeds" without delivering could record+suppress a later legitimate resend; this predates the reservation work. (2) `reserveTtlMs` (3min) correctly stays above the outbound send budget (tone-gate rate-limit wait ≤120s).
+
+<!-- tracked: topic-30823 — pre-existing observation: record()-after-non-throwing-send ignores messageId; a non-delivering "success" could suppress a later resend. Predates this change; folds into the RCA shared-primitives spec (topic 30837) alongside the reworded/cross-process work. -->