docs(issues): queue corrected #316 ledger request pending reconciliation - #2118
Conversation
PR #2110's reconciliation found two pending requests targeting #316 with an identical stale baseRowFingerprint (one already had a cancel in the original batch; the other did not). This queues that second cancel plus a freshly-fingerprinted reissue of its content as ordinary pending inbox requests, so #2110 can pick them up as genuine base-pending entries on its next resync rather than inventing them mid-branch, which trips check:ledger-write-discipline's requirement that an applied record's content have existed as pending at the PR's base commit. Docs-only, zero risk. Does not touch the canonical ledger itself -- only #2110's dedicated reconciliation branch does that.
|
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: 11 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 (3)
Comment |
2 participants
Summary
#316with an identical stalebaseRowFingerprint. One (10e480da) already had a cancel in the original batch (8b0650ed). The other (22946f19, the more complete of the two — describing the finished two-window staging proof) did not.22946f19and reissuing its content fresh directly on PR docs(issues): reconcile seven queued requests into the outstanding-issues ledger #2110's branch worked functionally (npm run issues:reconcileapplied it correctly,check:outstanding-issuespassed), butcheck:ledger-write-disciplinerequires an applied record's content to have existed as a pending request at the PR's own base commit — content invented mid-branch on the reconciliation PR itself can never satisfy that, no matter how the commits are ordered.Verification
npm run check:outstanding-issues— passed (Ledger inbox check passed: 74 pending request(s), 251 applied; guard passed against base).npm run docs:check-links— passed (1902 repo path references resolve— full batch-apply simulation covering this file).npx prettier --checkon both new files — clean.verify:pr-local,verify:ui,verify:release,eval:retrieval:quality,eval:rag,check:production-readiness— this diff is two immutable JSON request files underdocs/outstanding-issues-inbox/, no source, config, or clinical/RAG-surface files changed; none of those gates have a failure path here.Risk and rollout
Notes
docs/outstanding-issues.md— only queues requests for a future reconciliation to apply, per this repo's ledger-write discipline.Generated by Claude Code