Record a queued ledger request that was lost between a branch and its squash

docs/branch-review-records/1703bcf7a46123f0e2eaf267dfa37b8b633ddae861b6ef0033aebb4e5867f4b4.record.md

@@ -0,0 +1 @@
+| 2026-08-14 | claude/ledger-merge-loss-finding | 7a8d57da01b3221c61c87d2f14ace392ab33fb67 | ledger merge-loss finding | PR #1937 — one immutable inbox request (P2 issue) recording that a queued outstanding-issues request was created on a branch and never reached main through that branch's squash. Verified before writing: the request's own remedies had already shipped on main independently (hook guards CLAUDE_ENV_FILE; check:runtime names the hook), so the request was NOT re-queued verbatim — a re-queue would have opened an already-resolved row. The row filed instead is about the undetected loss itself. Docs-only; no source changes. | npm run verify:pr-local — failed: (none), 11 checks completed; ledger inbox check passed: 76 pending request(s), 19 applied |

docs/outstanding-issues-inbox/4b6930e6-fae2-4b4f-9f90-49bf0bcd548c.json

@@ -0,0 +1,13 @@
+{
+  "version": 1,
+  "id": "4b6930e6-fae2-4b4f-9f90-49bf0bcd548c",
+  "createdOn": "2026-08-14",
+  "action": "add",
+  "payload": {
+    "pri": "P2",
+    "type": "issue",
+    "summary": "A queued inbox request was lost between a PR branch and its squash on main, and nothing detected it",
+    "detail": "**Outcome:** a request that is committed to a branch either reaches main or fails loudly; 'merge-safe' means the loss is impossible or visible, not merely unlikely. **Detail, verified 2026-08-14.** PR #1930 (squash a544719a) merged branch claude/viewer-ledger-truth-pass at head 9525dd7b. That branch added SIX inbox requests across three commits; the squash on main contains FIVE. The missing one is faa4299e-0a68-4747-9509-e3eb2578b64c, added by commit 648b86ad, and 'git merge-base --is-ancestor 648b86ad 9525dd7b' confirms that commit was genuinely part of the merged head. The file is absent from main entirely: not under docs/outstanding-issues-inbox/, not under applied/, and its text appears nowhere in docs/outstanding-issues.md. Mechanism NOT established — a GitHub squash does not drop files on its own, so something happened at merge time; this row records the verified facts rather than a theory. **Why this instance cost nothing, and why that is not reassuring.** The lost request was a finding whose two remedies — guard CLAUDE_ENV_FILE in .claude/hooks/session-start.sh, and have checkNodeRuntime's failure message name that hook — shipped in the SAME pull request and are on main now. So the record was lost, not the work. A request carrying something not fixed in its own PR would simply have disappeared. **Nothing detected it.** check:ledger-write-discipline audits canonical-ledger edits against moved requests and proves request files are immutable from the merge base; no check asserts that requests committed on a branch are still present after it merges. The loss was found by counting 5 against 6 by hand, days later, while answering an unrelated question. **Next:** consider a cheap post-merge assertion — for a merge commit, compare inbox files added anywhere in the merged range against inbox files present in the resulting tree, and fail on any that vanished. Cheap because both sides are just filenames. Alternatively have reconcile report UUIDs referenced in git history but absent from the tree. **Stop:** do not respond by making request files editable or by hand-restoring a lost file into the tree under its old UUID — an immutable record that reappears with a new provenance is worse than an absent one. Queue a fresh request instead, as was done here.",
+    "source": "session 2026-08-14; PR #1930 squash a544719a vs branch head 9525dd7b; commit 648b86ad"
+  }
+}

docs/outstanding-issues-inbox/63419f06-c12a-4a84-a684-6e177f527365.json

@@ -0,0 +1,10 @@
+{
+  "version": 1,
+  "id": "63419f06-c12a-4a84-a684-6e177f527365",
+  "createdOn": "2026-08-14",
+  "action": "cancel",
+  "payload": {
+    "requestId": "4b6930e6-fae2-4b4f-9f90-49bf0bcd548c",
+    "reason": "The final PR #1930 head deliberately removed the resolved queued runtime request during review-and-fix. Comparing all historical additions with the squash therefore creates a false loss. Any future integrity proof must compare the final PR-head inbox tree with the squash tree."
+  }
+}