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

[BigSimmo]

Summary

One queued inbox request, recording an integrity gap found while checking whether an earlier PR had landed cleanly.

A queued request was committed to a branch, that branch merged, and the request is not on main. Nothing detected it.

• PR Queue five ledger corrections: the document-viewer rows say things that are no longer true #1930 (squash a544719a) merged claude/viewer-ledger-truth-pass at head 9525dd7b.
• The branch added six inbox requests across three commits. The squash contains five.
• The missing one is faa4299e, added by 648b86ad. git merge-base --is-ancestor 648b86ad 9525dd7b confirms that commit was genuinely part of the merged head.
• It is absent from main entirely: not under docs/outstanding-issues-inbox/, not under applied/, and its text appears nowhere in docs/outstanding-issues.md.

The mechanism is not established, and the row says so. A GitHub squash does not drop files on its own, so something happened at merge time. The row records what was verified rather than a theory — that seemed more useful to whoever picks it up than a guess dressed as a cause.

Why this instance cost nothing, and why that isn't reassuring

The lost request was a finding whose two remedies — guarding CLAUDE_ENV_FILE in .claude/hooks/session-start.sh, and having checkNodeRuntime's message name that hook — shipped in the same pull request and are on main now. The record was lost; the work wasn't.

A request carrying something not fixed in its own PR would simply have disappeared. That is the whole point of the intake: requests are documented as immutable and merge-safe precisely so a branch cannot silently drop one.

What noticed it: nothing

check:ledger-write-discipline proves request files are immutable from the merge base, and audits canonical-ledger edits against moved requests. No check asserts that a request committed on a branch still exists after that branch merges. This was found by counting five against six by hand, days later, while answering an unrelated question about what work remained.

The row proposes a cheap assertion — for a merge, compare inbox filenames added anywhere in the merged range against inbox filenames present in the resulting tree, and fail on any that vanished. Both sides are just filenames.

Deliberately not re-queued under its old UUID

The obvious move was to restore faa4299e verbatim. Two reasons not to:

1. Its content is already delivered. Both remedies are on main, so reconciling it would create a row that is already resolved.
2. An immutable record that reappears with new provenance is worse than an absent one. The contract's own instruction is to correct with a fresh request rather than resurrect a file, and that reasoning applies at least as strongly to one that was lost.

So this is a new request about the loss, not a restoration of the lost one. The stop rule in the row says the same, so the next person hitting this does not "helpfully" hand-restore a file into the tree.

Verification

• npm run verify:pr-local

- completed: check:runtime, check:installed-lock-parity, format:changed, sitemap:check,
docs:check-index, docs:check-inventory, docs:check-scripts, docs:check-links,
check:branch-review-ledger, check:outstanding-issues, check:ledger-write-discipline
- failed: (none)
- not reached: (none)
Ledger inbox check passed: 76 pending request(s), 19 applied.
Outstanding-issues guard passed: 314 rows, unique ids, next-id=317 above the highest.
Ledger write discipline passed for d47aa6d08b9b..HEAD.

Docs-only scope, so lint, typecheck, the unit suite, build and the RAG fixture scan were skipped by the gate's own risk routing — confirmed with --dry-run before running, not assumed.

• verify:ui, verify:release, eval:*, check:production-readiness — not applicable; one JSON file, no source changes.

Risk and rollout

• Risk: low — a single queued request file. It changes nothing until someone reconciles deliberately.
• Rollback: revert the commit, or cancel the request with its own cancel request.
• Provider or production effects: None.

Notes

• docs/outstanding-issues.md is drifting.check:outstanding-issues reports 76 pending requests against 19 applied. The canonical ledger is described as the durable cross-session memory, and three quarters of the pending mutations against it are unapplied. Reconciliation is deliberately serialised, which is right, but at this ratio the rendered ledger is materially behind reality — including the five document-viewer corrections from Queue five ledger corrections: the document-viewer rows say things that are no longer true #1930, which is why #278 still reads as open and crop → page overlay still has no row.
• Opened from claude/ledger-merge-loss-finding. The designated claude/document-viewer-phase-3-bj5k5v still holds dead history from Document viewer Phase 3: page virtualization, rail windowing, keyboard reading mode, and the first canvas gate #1772 and cannot be deleted from this session — git push --delete and the colon refspec are both refused by the transport, the GitHub MCP surface has no branch-delete tool, and the PAT helper is excluded from agent shells by design. It can be deleted from the GitHub UI; nothing on it is needed.

---

Generated by Claude Code

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in:46 minutes

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 27642d4f-db39-4cb0-9767-b3c2fd3b7435

📥 Commits

Reviewing files that changed from the base of the PR and between 1ebd967 and 934bb77.

📒 Files selected for processing (3)

• docs/branch-review-records/1703bcf7a46123f0e2eaf267dfa37b8b633ddae861b6ef0033aebb4e5867f4b4.record.md
• docs/outstanding-issues-inbox/4b6930e6-fae2-4b4f-9f90-49bf0bcd548c.json
• docs/outstanding-issues-inbox/63419f06-c12a-4a84-a684-6e177f527365.json

---

_{Comment @coderabbitai help to get the list of available commands.}

[supabase]

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:7a8d57da01

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".