docs(issues): reconcile 19 queued ledger requests into the canonical ledger - #2260
Conversation
…ledger Applies every pending inbox request, including this session's four, and moves each to the immutable applied/ audit trail. Two of the nineteen are cancellation decisions, one of them retiring my own earlier record whose diagnosis was partly wrong. Ran with --allow-concurrent, which needs justifying rather than assuming. The guard refused because four reconcile-shaped branches sit unmerged on origin, and it infers "in flight" from the branch name. All four were checked against main request by request, and every one is fully superseded: claude/issues-reconcile-2026-08-19 94 marked applied, 94 already on main claude/ledger-reconcile-2026-08-21 29 marked applied, 29 already on main claude/ledger-reconcile-issues-c1trbj 274 marked applied, 274 already on main claude/rag-r0-reconcile-inbox 268 marked applied, 268 already on main Not one carries an unlanded reconciliation, none has an open PR, and they are 123, 123, 4636 and 4631 commits adrift. The concurrency the guard exists to prevent (#EH9VA6) is therefore not present: there is no second live reconcile to collide with. The 2026-08-21 branch additionally no longer merges cleanly, which is expected — a reconcile transaction is computed against its base, so a stale one cannot be landed by merging and has to be redone from a fresh base, which is what this is. Those four branches should still be deleted so the next session is not blocked by the same false signal. That is a destructive act on other sessions' branches and is left for the owner. Run from a fresh base: HEAD was exactly origin/main (226bd32) with a clean tree. check:outstanding-issues passes — 0 pending, 504 applied, 431 rows, 72 open, no ids deleted from base. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JEzkroXdtL9kYo8rW5eZh2
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:23 minutes Limit details: You’ve used the included review currently available. Your 89 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:b369d985af
ℹ️ 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".
Uh oh!
There was an error while loading. Please reload this page.
PR #2260's review raised that queue row 1 still presents `#231` as A1 "Immediate approved live investigation" into retrieval binding the fast route, while the #231 Open-items row this PR updates records the P1 -> P2 re-grade and the measurement that closed that cause. The finding is correct, and the row itself asks for the queue entry to be re-graded "AT RECONCILE". It cannot be honoured here, for structural reasons rather than oversight: - `updateIssue` edits only Open-items columns; the sole queue-touching function is `pruneResolvedIdFromQueue`, which runs on `done` and only deletes the row. Nothing can re-grade one. - A hand edit of the canonical ledger is refused by `check:ledger-write-discipline` — its self-test asserts that accepting a manual canonical edit is a failure. - Creating a request on this branch and applying it in the same transaction is refused: the applied batch must equal the base inbox exactly. So this files the gap as a pending inbox request for the next serialized reconcile, which is the one shape the guard accepts, rather than editing the canonical ledger. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ApB8NBygQn9cosxCQ8omk9
…o claude/clever-edison-167y82
Summary
docs/outstanding-issues.mdand move each to the immutableapplied/audit trail. Two are cancellation decisions, one of which retires a record filed earlier today whose diagnosis was partly wrong.origin/main(226bd32c) with a clean tree, as the serialization rule requires.Four of the nineteen are this session's; fifteen were queued by other sessions and had been waiting.
Why
--allow-concurrent, and why that is not a shrugThe guard refused, naming four reconcile-shaped branches unmerged on
origin. It infers "in flight" from the branch name, so a dead branch blocks forever. Rather than override on the strength of that, each branch was checked againstmainrequest by request — does it mark requests applied thatmainstill has pending?mainclaude/issues-reconcile-2026-08-19claude/ledger-reconcile-2026-08-21claude/ledger-reconcile-issues-c1trbjclaude/rag-r0-reconcile-inboxEvery request all four would reconcile is already applied. Not one carries unlanded work, and none has an open PR. The hazard the guard exists to prevent — two live reconciles colliding and corrupting the ledger or its journal (
#EH9VA6) — is therefore absent: there is no second live reconcile.The
2026-08-21branch additionally no longer merges cleanly intomain, which is the expected and instructive result. A reconcile transaction is computed against its base, andcheck:ledger-write-disciplinerequires the canonical diff to equal that recorded transaction exactly. A stale reconcile branch therefore cannot be landed by merging or rebasing — it has to be redone from a fresh base. That is what this PR is, and it is why those branches were never landable in the first place.Follow-up this PR deliberately does not do
Those four branches should be deleted, so the next session is not blocked by the same false signal and does not repeat this investigation. That is a destructive act on other sessions' branches, so it is left for the repository owner rather than taken unilaterally.
Worth noting for
#CCZ4HBand#6GW95D, both updated in this very batch: four abandoned reconcile attempts is the same pattern those rows describe — work started, not finished, quietly accumulating until it blocks someone. It has now shown up in the worktrees (253 checkouts), the review budget, and here.Verification
npm run issues:reconcile -- --dry-run --allow-concurrent—Would reconcile 19 request(s) … with 2 cancellation decision(s)npm run issues:reconcile -- --allow-concurrent—Applied 19 request(s), exit 0npm run check:outstanding-issues—Ledger inbox check passed: 0 pending request(s), 504 applied(was 19 pending / 485 applied);Outstanding-issues guard passed: 431 rows (72 open, 359 archived), unique display and durable ids, collision-free allocation enabled, no merge driver, no ids deleted from base 226bd32cc5aa#CCZ4HBand#6GW95Dupdates landed with their prior text preserved verbatimnpm run format— cleanVerification not run: npm run test,lint,typecheck— the diff isdocs/outstanding-issues.mdplus 19 file renames underdocs/outstanding-issues-inbox/. No executable path, no source, no test, no config.check:outstanding-issuesis the gate that covers this scope and it passes; CI'sLedger write disciplineandOutstanding-issues ledger integritysteps re-check it independently.UI verification not run:no UI, routing, styling, or browser behaviour in the diff.Risk and rollout
git revertthe single commit; theapplied/moves and the ledger edit travel together.Generated by Claude Code