docs(issues): reconcile 38 queued ledger requests into the canonical ledger - #2229
Conversation
…ledger Applies every request pending on main at 5d2d2f0, including the 12 cancellation decisions other sessions queued for requests superseded by the earlier 2026-08-21 reconciliation. Produced solely by npm run issues:reconcile on a dedicated fresh-base branch; no hand edits to the canonical ledger. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (48)
📝 WalkthroughWalkthroughThe PR refreshes the outstanding-issue ledger. It adds versioned records for open findings, partial resolutions, cancellations, completed issues, and resolved archive entries. It also updates migration status and related issue rows. ChangesOutstanding issue ledger
Estimated code review effort: 2 (Simple) | ~10 minutes ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
💡 Codex Review
When this reconciliation applies this cancellation and the matching 3eb84c6a-97fa-4b1c-9167-190ba928c200 cancellation, it acknowledges that the successful 16-test run is exactly the missing verification for #4TBHS8 and #SZGPAH, but queues no replacement requests before moving every request to applied/. Consequently, both canonical rows remain open and claim the spec was not rerun even though this transaction contains proof that it passed. Reissue the two done requests against the current fingerprints, or otherwise preserve that outcome in the canonical rows, before marking the stale requests applied.
The conflicting totals use different units rather than describing incompatible measurements: at the reviewed tree, therapyBtn has 21 textual occurrences across eight files, but eight of those are its definition plus seven imports, leaving exactly the canceled request's 13 raw-control applications across seven consumer files. Because #VTEW3W claims to count controls that therapyBtn dresses, retaining the 21/8 figure overstates the remaining migration and discards the accurate update. Recount only JSX/class applications and apply the 13/7 update.
ℹ️ 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".
CI triageCI failed on this PR. Automated classification of the 2 failed job(s):
Compared with main CI run #12877 (success). Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger. |
Origin/main advanced past this branch's base after the original 38-request reconciliation was recorded, landing 9 additional pending inbox requests (8 already present at the merged base, plus one more added mid-fix by a concurrently-merged PR). check:ledger-write-discipline correctly rejected the stale diff. Synced with origin/main (clean merge-tree, no conflicts) and re-ran npm run issues:reconcile to pick up the newly-pending requests; no concurrent-reconciliation branches were detected this time. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015StJgDC2dfef8PXN9dfriw
…ncile The prior fix commit applied 9 newly-landed pending requests in a second, separate batch on top of the branch's original 38-request application. check:ledger-write-discipline replays the entire moved-request set as one combined applyRequestBatch call against the current origin/main base, so a two-batch history (different ID-allocation ordering per batch) cannot reproduce the same markdown even when every individual request was applied correctly. Resetting docs/outstanding-issues.md and docs/outstanding-issues-inbox/ to exactly match origin/main here undoes both prior batches in the tree (history commits are untouched) so the next commit can reconcile all 47 currently-pending requests in a single npm run issues:reconcile call, matching what the discipline check independently recomputes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015StJgDC2dfef8PXN9dfriw
…atch Applies npm run issues:reconcile once against the reset ledger state, moving all 47 currently-pending outstanding-issues-inbox requests (the branch's original 38 plus the 9 that landed on main afterward) into docs/outstanding-issues-inbox/applied in one batch, with the 12 cancellation decisions the original reconciliation already reported. This produces a single applyRequestBatch application matching what check:ledger-write-discipline independently recomputes against the current origin/main base, resolving the "does not exactly match the audited application of 47 moved inbox request(s)" failure that a two-batch history could not satisfy. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015StJgDC2dfef8PXN9dfriw
…nto claude/ledger-reconcile-0821b
Uh oh!
There was an error while loading. Please reload this page.
BigSimmo
commented
Aug 21, 2026
No fix is possible or needed here: this pull request merged at 2026-08-21T13:52:54Z (merge commit The failing Deliberately not doing anything about it: pushing a fix would mean recreating a deleted branch on a merged pull request, which is the exact race that recreated a branch on #2217 earlier today. Read the red as post-merge noise, not a regression on 🤖 Addressed by Claude Code |
BigSimmo
commented
Aug 21, 2026
Finding: this PR is not a duplicate of #2218, and the disposition question is moot — it's already mergedI was asked to check whether this PR duplicated #2218's reconciliation and to recommend close-as-superseded or recompute-on-fresh-base. The evidence says no, it does not duplicate #2218, and separately, this PR merged at 2026-08-21T13:52:54Z (commit (a) Request IDs this PR applied47 request files were moved (b) Are those IDs already applied on current main?Yes — checked all 47 against current (c) Does it duplicate/contradict/overwrite #2218's rows?No overlap. #2218 (squash (d) What would |
Summary
Second serialized ledger reconciliation of 2026-08-21, applying every request pending on
mainat5d2d2f069. The queue had returned to 38 pending within hours of the previous reconciliation as other sessions filed their own sweeps. The canonical ledger diff was produced solely bynpm run issues:reconcileon this dedicated fresh-base branch; no hand edits, and no file outsidedocs/outstanding-issues.mdanddocs/outstanding-issues-inbox/is touched.38 request(s) ... with 12 cancellation decision(s)— the collisions predicted in the previous reconciliation's notes were already resolved before this ran. Other sessions had queued explicitcancelrequests for the requests their sweeps duplicated, so nothing had to be forced and no request was discarded silently.Net effect on the ledger: open rows 61 to 60, archived rows to 356, pending requests to zero, 476 requests applied in total.
#339,#WJDQ0X,#D8JBCV,#YJ3R7Y,#TWKWE4and#90Y0FD— the favourites timestamps, the search-chrome landmark failures, the missing phone privacy notice on/tools, the skipped SSR height reservation, the two competing mode-home title systems, and the triplicated suggestion data.#3SG2H9,#72G3XZ,#TYZK23,#CHW9N3and#61TZJA.#DREDWAresidual coverage gap raised in review on pull request docs(issues): reconcile 29 queued ledger requests into the canonical ledger #2217 and landed by pull request docs(issues): queue the #DREDWA residual test-coverage gap raised in review #2224.The small net movement is expected: this transaction closes six rows and opens five, so the open count barely moves even though 38 requests were applied.
Verification
npm run verify:pr-local— recognised low-risk documentation scope. All eleven selected checks completed and none failed: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-issuesandcheck:ledger-write-discipline. Exit code 0, captured directly rather than through a pipe.check:ledger-write-discipline—Ledger write discipline passed for 5d2d2f06981b..HEAD.This is the decisive gate for a reconciliation: it proves the canonical ledger diff equals exactly the recorded reconciliation transaction, with no direct table-row editing.check:outstanding-issues—Ledger inbox check passed: 0 pending request(s), 476 applied.andOutstanding-issues guard passed: 416 rows (60 open, 356 archived), unique display and durable ids, collision-free allocation enabled, deprecated next-id marker ignored, no merge driver, no ids deleted from base 5d2d2f06981b.UI verification not run: no executable product code, route, component, style or browser behaviour is touched.
Risk and rollout
check:ledger-write-disciplinerather than by review alone.git revertthis pull request. That restores the previous ledger and returns the 38 requests to pending, since request files are immutable and revert simply moves them back out ofapplied/.src/lib/rag/, no retrieval RPC, no ranking configuration, no eval harness and no golden fixture is touched.Notes
Worth recording as a process observation rather than as a defect in this change: the inbox went from zero to 38 pending in a few hours because at least three sessions swept the same ledger rows independently on the same day, none aware of the others. That duplication is what produced the 12 cancellations applied here. It is the pattern already tracked as
#292, and the cost is now measurable — roughly a third of this transaction was work that had to be withdrawn rather than applied.🤖 Generated with Claude Code
Summary by CodeRabbit