chore(issues): reconcile 35 queued ledger requests - #1956
Conversation
Applies the pending inbox to docs/outstanding-issues.md as one serial transaction from a fresh origin/main base (0011a05), which is the only path allowed to edit the canonical ledger. 35 requests: 17 done, 7 add, 6 update, 5 cancel. Every request moves verbatim to docs/outstanding-issues-inbox/applied/ as its immutable audit record. One row carried competing mutations — #213, two done requests — resolved by the cancel already queued against one of them. Ledger goes from 328 to 334 rows, 115 open to 99. Includes the five requests queued by PR #1944 but left pending when it merged: closes#313 (the write-discipline dirty-tree refusal shipped), carries #211 forward with its re-measured 1,445 errors while keeping the 2026-08-12 deprioritisation judgment, records the documented state of #168 and #258, and opens #335 for the gap between the two merge-loss detectors. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Chrn9bTYFFYzrLZqtpVptW
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:12 minutes 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 (16)
Comment |
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Chrn9bTYFFYzrLZqtpVptW
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:93365d6e4e
ℹ️ 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.
Uh oh!
There was an error while loading. Please reload this page.
Hand-written follow-up to the machine-generated transaction in the previous commit. Separate commit so the reconciliation stays independently revertible and remains purely generated. - newtask: the #292 open-PR duplicate check is DENIED, not merely unavailable, once the PR-handoff stop hook has armed in a session. The existing text only covers "GitHub is unreachable", which reads as a network problem and does not tell a session what to do when the tool itself is blocked. Records git ls-remote --heads as the fallback, and says explicitly not to unlock the hook for it. - handoff: --force-with-lease fails with "stale info" when restarting a branch whose PR merged, because GitHub deleted the remote branch and the local remote-tracking ref is stale. The failure looks like a lease violation inviting --force; it is not. git remote prune origin, then push normally — there is nothing to force. - issues: the visual-register refresh is unavailable off the operator's Windows machine, so a cloud session can reconcile but cannot refresh or even measure staleness. States the limit where the command is, and forbids improvising a substitute renderer: an artifact that looks refreshed but came from a different generator is worse than a visibly stale one. Queues one P3 request for the register drift itself, which is cumulative rather than a single-run failure. No predicted ledger id is cited anywhere — ids are allocated at reconcile, which is the #168 hazard. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Chrn9bTYFFYzrLZqtpVptW
Uh oh!
There was an error while loading. Please reload this page.
BigSimmo
commented
Aug 14, 2026
Final review summary
The PR was not merged by Codex. Final merge is left to the user. |
Summary
Applies the pending outstanding-issues inbox to
docs/outstanding-issues.mdas one serial transaction, from a freshorigin/mainbase (0011a058). This is the only path allowed to edit the canonical ledger; ordinary branches queue immutable requests and never touch it. 35 requests: 17done, 7add, 6update, 5cancel. Each moves verbatim intodocs/outstanding-issues-inbox/applied/as its audit record, so the whole change reads as 35 renames plus the canonical ledger.Reconciliation is all-or-nothing by design, so this is the whole queue rather than a chosen subset —
verifyIssueReconciliationrejects a batch that moves only part of the inbox, precisely so a partial reconciliation cannot happen. One row carried competing mutations (#213, twodonerequests), resolved by the cancel already queued against one of them. No unresolved rows.Includes the five requests queued by PR Five ledger process and tooling fixes: dirty-tree gate, merge-loss detector, three plans #1944 that were still pending when it merged. That PR's substantive content landed in squash
372cb13f; its ledger requests were queued, as intended, for a reconciliation to apply. Specifically: closes#313(the write-discipline dirty-tree refusal shipped and is onmain); carries#211forward with its re-measured 1,445 errors while preserving the 2026-08-12 deprioritisation judgment and its P3 priority; records the documented state of#168and#258without closing either, since neither asked only for a document; and opens#335for the gap between the two merge-loss detectors.Records three handoff traps hit while doing the above (second commit, hand-written, deliberately separate so the generated transaction stays independently revertible).
.claude/skills/newtask— the#292open-PR duplicate check is denied, not merely unavailable, once the PR-handoff stop hook has armed in a session; the existing wording only covered "GitHub is unreachable", which reads as a network problem, so it now namesgit ls-remote --heads originas the fallback and says not to unlock the hook for it..claude/skills/handoff—--force-with-leasefails withstale infowhen restarting a branch whose PR merged, because GitHub deleted the remote branch and the local remote-tracking ref is stale; that presents as a lease violation inviting--force, when the fix isgit remote prune originand a normal push..claude/skills/issues— the visual-register refresh is unavailable off the operator's Windows machine, stated where the command actually is, with an explicit prohibition on improvising a substitute renderer. Also queues one P3 request for the register drift itself, which is cumulative rather than a single-run failure.Ledger moves from 328 to 334 rows, and from 115 open to 99.
Verification
npm run verify:pr-localon the final head — 21 gates, zero failures. (The skill edits widened the routed scope from the 11 gates the reconciliation alone selected.)The decisive line is the write-discipline audit, which independently recomputes the transaction and fails if the canonical file differs by a single byte from what those 35 requests produce:
Shape and id invariants:
Worth recording: run before committing,
check:ledger-write-disciplinerefused to report a verdict and named every uncommitted request file. That is the guard PR #1944 added doing its job on the first real reconciliation after it shipped — the gate can no longer print a pass over an uncommitted ledger edit.npm run verify:uinot run: no UI, routing, styling or browser behaviour changed. Build skipped by the runner — no build-affecting source, config, package or container changes. Thecheck:medication-lexicon-reportfailure reported on PR #1944 is gone, confirming PR #1941 (3d5cd7cb) resolved it at source.Not run — visual register.
.claude/skills/issues/SKILL.mdrefreshes an HTML register via a PowerShell script at an absolute Windows path, which does not exist in this Linux container. Per that skill, a stale visual artifact must not invalidate a valid canonical transaction: the Markdown source is current; the HTML register is stale and needs a refresh from the operator's machine. That limit is now written into the skill, and the drift is queued as its own P3 row.A concurrent reconciliation landed first — read before merging
After this branch was pushed, PR #1954 (
claude/ledger-reconcile-batch-2) merged the same queue, andmainnow already contains every one of these 35 requests inapplied/, including all five inherited from PR #1944. That was checked rather than assumed, and the outcome is benign:docs/outstanding-issues.mdis byte-identical tomain's — same blob OID. Two independent reconciliations of the same queue converged exactly, which is the determinism the transaction design is meant to give.git merge-tree --write-tree origin/main a6d429b9reports 0 conflicts, and the resulting tree has 334 rows,next-id=337, and no duplicate ids — the specific corruptionAGENTS.mdwarns a ledger merge can produce.So the reconciliation half of this PR is now effectively a no-op against
main, and merging is safe. What remains genuinely new here is the second commit (the three skill fixes and the queued P3 register-drift request) plus this branch's review record. If you would rather not carry a redundant transaction commit, closing this PR and re-filing only the second commit is a legitimate alternative — but it is not required for correctness.Risk and rollout
issues:reconciletakes a cross-worktree lock, re-asserts the fresh base and clean tree inside that lock, writes a backup and a transaction journal, and rolls back on any failure. No request was hand-edited and the canonical file was not hand-edited. The second commit is hand-written but touches only agent-facing skill documentation and adds one queued request; it changes no product code and no canonical ledger row.git reverteither commit independently. Reverting the reconciliation restores the canonical ledger and returns all 35 requests to pending, since their moves are plain renames; reverting the documentation commit removes three skill notes and one queued request. Neither depends on the other.Notes
The branch was restarted from the latest
origin/mainrather than continuing the history whose PR (#1944) already merged, as the repo requires; that reset is also the precondition for reconciliation, which refuses to run unlessHEADcontains the fetchedorigin/main.I did not use GitHub's Update branch button and this branch must not be updated with it —
AGENTS.mdforbids it on anything touching the canonical ledger, because its auto-merge has previously produced duplicate rows and anext-idmarker left below the highest live id. The merge-tree check above already proves the merge is clean without needing it.One request from PR #1944 is deliberately absent: the cancel
a8783c79, which targeted0e47904b. That target was already consumed by the reconciliation in PR #1936, so the cancel is now invalid and re-filing it would fail validation. Nothing was lost — the surviving#211update folds the cancelled request's deprioritisation text forward verbatim in substance.The CodeRabbit comment on this PR is a usage-limit notice, not a review. Per
AGENTS.md(#150), a cap notice must not be read as completed review coverage; this PR's automated review coverage is therefore the Codex connector and the CI gates only.