docs(issues): unstick the ledger write path — reconcile 21 queued requests and rescue two orphaned review records - #2268
Conversation
…ledger The inbox write path had been stuck since 2026-08-17. Four reconcile branches on origin (claude/issues-reconcile-2026-08-19, claude/ledger-reconcile-2026-08-21, claude/ledger-reconcile-issues-c1trbj, claude/rag-r0-reconcile-inbox) each started this transaction and none landed, and the guard against concurrent reconciliation correctly refused to start a fifth while they existed. None has an open pull request, so nothing was in flight to wait for. Verified before overriding the guard, rather than assuming: every request UUID on all four branches is already present on main, so no queued note would be lost. Their only content absent from main is two branch-review records (added in the next commit) and five source files that main deleted deliberately in #2211. Applies 21 requests with 4 cancellation decisions. One cancellation, 76390200 against 0a0ab127, arrived after its target had already been applied by an earlier reconciliation; the tool recorded it and changed nothing, and correcting that row needs a fresh update request. Six new rows, including the hydration-gap guard filed today as #2TAQDC; #231 re-scoped, #6GW95D demoted P2 -> P3, and the three CLS rows carry the root cause. Pending inbox is now zero. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UksCoUHQMp72XUdp7RjchE
…cile branches These are the only content on the four abandoned reconcile branches that exists nowhere on main. Both record real 2026-08-17 reconciliation reviews whose transactions were later redone and landed by other branches, so the reviews happened but their audit records never did. Recovered verbatim from claude/ledger-reconcile-issues-c1trbj and claude/rag-r0-reconcile-inbox rather than rewritten, since the records are content-addressed and immutable by contract. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UksCoUHQMp72XUdp7RjchE
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:6 minutes Limit details: You’ve used the included review currently available. Your 90 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 (24)
Comment |
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Uh oh!
There was an error while loading. Please reload this page.
Summary
npm run issues:reconcileapplies them. That step had not succeeded in five days, so 21 queued notes — including today's Lighthouse CLS root-cause records — were invisible indocs/outstanding-issues.md.claude/issues-reconcile-2026-08-19,claude/ledger-reconcile-2026-08-21,claude/ledger-reconcile-issues-c1trbjandclaude/rag-r0-reconcile-inboxeach started this transaction and none landed.assertSafeRemoteReconciliationcorrectly refused to start a fifth while they existed (#EH9VA6). None has an open pull request, so there was nothing to land or close and nothing to wait for.main— checked by comparing each branch'sdocs/outstanding-issues-inboxtree againstmain's, in both the pending andapplied/directories — so no queued note could be lost. Their only content absent frommainis the two branch-review records rescued in the second commit, plus five source filesmaindeleted deliberately in Restrict document uploads to administrator backend #2211 (use-upload-desktop-layout.ts,service-group-nav.tsx,therapy-compass/icons.tsxand two upload tests). The four branches themselves are left untouched for the owner to delete.#S4R2W3,#M6JNR8,#NPQJKP,#2TAQDC,#JZM7RM,#VV83VA.#231re-scoped to separate initial provider timeouts from quality-retry exhaustion,#6GW95Ddemoted P2 → P3 now the Dev Drive capacity emergency is resolved, and#50QRCF/#TYZK23/#KFRC3Hnow carry the mobile-/CLS root cause landed in feat(dictionary): merge Search and Browse into one catalogue and rebuild the phone header #2253.76390200cancels0a0ab127, which an earlier reconciliation had already applied. The tool recorded the cancellation, changed nothing, and printed the reason; correcting the affected row needs a fresh update request. It is called out here so the next reader does not read the audit trail as though the cancellation had bitten.65d188be…,42c9767e…), recovered verbatim rather than rewritten because the records are content-addressed and immutable by contract. Both document real 2026-08-17 reconciliation reviews whose transactions were later redone and landed by other branches — the reviews happened, their audit records never did.The two commits are kept separate deliberately:
check:ledger-write-disciplinerequires the canonical ledger diff to equal exactly its recorded reconciliation transaction, so the record rescue cannot ride inside that commit.Verification
npm run verify:pr-localAll 11 selected steps completed, none failed:
Every step ran fresh; no gate receipt was reused. Recognised low-risk documentation scope, so lint, typecheck, the full unit suite, the RAG fixture scan and the build were skipped, each with its reason reported rather than passing silently.
The three gates that actually bite on this change:
npm run formatwas run against the whole tree before committing and reported nothing to change.npm run verify:uiwhen UI, routing, styling, browser behavior, reduced-motion, or forced-colors behavior changedUI verification not run: no UI, routing, styling, browser, reduced-motion or forced-colors behaviour changed. The diff is the canonical ledger, inbox request files moving to
applied/, and two review records.npm run verify:releasebefore release or handoff confidence claimsVerification not run: release confidence is not claimed, and the gate is provider-backed.
npm run eval:retrieval:quality(must stay 36/36) when retrieval, ranking, selection, chunking, or scoring behavior changedVerification not run: no retrieval, ranking, selection, chunking or scoring behaviour changed. Nothing under
src/lib/rag/, clinical-search, retrieval-selection, ranking-config, answer-ranking, the eval harness or the golden fixture is touched — the diff contains no executable code at all. The gate is also provider-backed.npm run eval:rag -- --limit 15+npm run eval:quality -- --rag-onlywhen answer generation, the synthesis prompt, or answer post-processing changedVerification not run: answer generation, the synthesis prompt and answer post-processing are untouched. The gates are provider-backed.
npm run check:production-readinesswhen clinical workflow, privacy, environment, Supabase, source governance, or deployment behavior changedVerification not run: none of those changed.
npm run check:deployment-readinesswhen deployment startup, hosting, or rollout behavior changedVerification not run: deployment startup, hosting and rollout behaviour are unchanged.
Risk and rollout
npm run issues:reconcileand not hand-edited, andcheck:ledger-write-disciplineverifies the canonical diff equals exactly that recorded transaction. The genuine risk was losing a queued note by overriding the concurrency guard, which is why every request UUID on all four branches was checked againstmainfirst; none is unique to a branch.git revertof the two commits restores the previous ledger and returns the 21 requests to pending. No IDs are burned irrecoverably by a revert-and-redo, because allocation is driven by the request files themselves.Notes
--allow-concurrentis the documented path for this case, not a bypass. The guard's own message offers it, and its stated hazard is a concurrent reconciliation corrupting the journal. There is no concurrent reconciliation here: the newest of the four branches is five days old, none has an open pull request, and the override's use plus its evidence is recorded in the commit message so a later reader can audit the judgement rather than infer it.check:outstanding-issuesprints the count as part of a passing line, so a growing queue reads as a healthy gate. A follow-up worth considering is a threshold that warns above, say, ten pending requests — recorded here rather than filed as a request, to avoid adding to the very queue this PR just drained.Generated by Claude Code