docs(issues): reconcile 74 queued requests into the outstanding-issues ledger - #2119
Conversation
…s ledger Fresh reconciliation from current main (ddc7e89, which already includes PR #2118's corrected #316 requests), replacing PR #2110. That branch's reconciliation was pushed once with SKIP_LEDGER_WRITE_GUARD after a duplicate-target collision fix, which permanently baked two applied records (an update and a cancellation) whose pending predecessors never existed on any base commit -- structurally unfixable via forward-only commits, since the ledger tool forbids ever cancelling a cancel-type request and #316's row-update and 22946f19's cancellation slots were each already claimed by then. Building fresh here instead of rewriting that branch's history. Applied 74 requests (10 cancellation decisions) in one clean pass with no manual duplicate-target resolution needed, confirming PR #2118 left main's inbox internally consistent.
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
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:39 minutes Limit details: You’ve used all 1 included review currently available under your plan. You completed 101 included PR reviews in the past 7 days; at that activity level, included reviews refill 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?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
CI triageCI failed on this PR. Automated classification of the 2 failed job(s):
Compared with main CI run #12087 (cancelled). Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger. |
…as open main advanced past this branch's original base (ddc7e89 -> ce702ba) after an automatic branch sync merged main in, bringing 14 new pending outstanding-issues-inbox requests that the earlier reconciliation never saw. check:ledger-write-discipline correctly flagged the branch for processing only part of the base inbox. Re-ran issues:reconcile against the current branch tip to apply the remaining 14 requests.
Uh oh!
There was an error while loading. Please reload this page.
* docs(issues): reconcile the post-B4 inbox (2 requests; #9DGA6R closed) and mark HANDOVER S7 (B4) merged Fresh-base issues:reconcile: closes #9DGA6R (packet B4 landed as PR #2170, squash 5437c30); records the earlier cancel dc18b947 as ineffective. HANDOVER §2 S7 row -> Merged. The stale closed-PR branch claude/issues-reconcile-20260818 (#2110, superseded by #2119) was deleted so the concurrent-reconcile guard could clear. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(issues): queue the docling-lab-fixtures.v2 request (pending; applies at the next reconcile) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(ledger): record the post-B4 reconcile review Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Summary
docs/outstanding-issues.md, from a freshorigin/mainbase (ddc7e899, which already includes docs(issues): queue corrected #316 ledger request pending reconciliation #2118's corrected#316requests).Why a fresh branch instead of continuing #2110
#2110's reconciliation was pushed once with
SKIP_LEDGER_WRITE_GUARD=1after resolving a duplicate-target collision on#316(two pending requests, same stale fingerprint). That push permanently created two applied records — an update to#316and a cancellation of a superseded request — whose pending predecessors never existed on any base commitmainhas ever had. This turned out to be structurally unfixable via forward-only commits:check:ledger-write-disciplinerequires an applied record's content to have existed as an identical pending request at the PR's own base commit.mainfirst (PR docs(issues): queue corrected #316 ledger request pending reconciliation #2118) fixed the update side, but not the cancellation side: the ledger tool hard-forbids ever cancelling a cancel-type request (scripts/ledger-inbox.mjs:198,214), and the one valid cancellation slot for the superseded request was already claimed by a different (correctly-formed) request landed via docs(issues): queue corrected #316 ledger request pending reconciliation #2118.maincould ever contain, short of rewriting docs(issues): reconcile seven queued requests into the outstanding-issues ledger #2110's git history — which needs explicit user authorization for the force-push it requires.Rebuilding fresh from current
mainavoids all of that: every one of the 74 requests reconciled here already existed as a genuine pending request onmainbefore this branch was created, so the pending→applied transition is fully visible in an ordinary diff. NoSKIP_LEDGER_WRITE_GUARDneeded.Verification
npm run issues:reconcile—Reconciling 74 request(s) into docs/outstanding-issues.md with 10 cancellation decision(s),Applied 74 request(s), no manual duplicate-target resolution needed (confirms docs(issues): queue corrected #316 ledger request pending reconciliation #2118 leftmain's inbox internally consistent).npm run check:outstanding-issues—Ledger inbox check passed: 0 pending request(s), 325 applied;Outstanding-issues guard passed: 365 rows (62 open, 303 archived)... no ids deleted from base ddc7e8998267.npm run docs:check-links—1902 repo path references resolve(full batch-apply simulation).npm run check:ledger-write-discipline—passed for ddc7e8998267..HEAD— no override.npm run format(prettier --check) — clean.Not run, with reason: lint, typecheck, the unit suite and any browser gate. The diff is the canonical ledger plus inbox audit records — no source, config, or test file changes, so none of those gates has a failure path here.
Risk and rollout
Notes
AGENTS.mdcalls that out specifically for PRs touching the canonical ledger. If it goes stale, re-reconcile from a fresh base instead of syncing in place.Generated by Claude Code