docs(issues): queue 25 ledger requests from a verified sweep of open rows - #2203
Conversation
…rows Verified every open ledger row that makes a concrete code claim against main at 1cc0d29, plus a read-only inspection of the pinned production Supabase project. - 11 done requests for rows whose fix is already in the code - 12 update requests correcting rows partly overtaken by later work - 2 add requests: a production migration absent from this repository, and a worktree sweep that destroyed an in-use session's work Touches docs/outstanding-issues-inbox/ only. The canonical ledger is not edited and issues:reconcile is deliberately not run here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:38 minutes Limit details: You’ve used the included review currently available. Your 87 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 (26)
Comment |
This pull request has been ignored for the connected project Preview Branches by Supabase. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:bd7d109e52
ℹ️ 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.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…eady exists The queued request asked the ledger to record that only a same-machine filesystem lock guards concurrent reconciliation, and left the row open. That was written from a partial read: the same file already implements the cross-worktree interlock the row was asking for. findUnmergedRemoteReconciliations() runs `git ls-remote --heads origin`, flags branches carrying unapplied records, and names #EH9VA6 in its docstring and error text; assertSafeRemoteReconciliation() is called before any reconciliation work and refuses to proceed on detection. So the request is now `done`, with an outcome recording the verification and the two deliberate residuals (offline fail-open and the explicit --allow-concurrent override). Left as an `update` this would have made the canonical ledger advertise completed work as missing, which is how the same work gets built twice. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WeLU8jf7tffA2es9Pk6uSn
Summary
This pull request queues 25 immutable outstanding-issues inbox requests produced by a verification sweep of the ledger's open rows against the code on
mainat1cc0d2987, together with a read-only inspection of the pinned production Supabase project. It touchesdocs/outstanding-issues-inbox/only. It does not editdocs/outstanding-issues.md, and it deliberately does not runissues:reconcile; that stays with a dedicated serialized ledger branch after this lands.donerequests closing rows whose fix is already present in the code, each carrying the file, symbol or command that proves it:#43SSS0(three dead spring easing tokens now absent fromsrc/),#TAQKCN(the hand-drawn tick inrecommend-screen.tsxis gone and lucideCheckis imported),#5JK9FM(RAG impactnow appears four times in the pull request template),#0EKBGC(the services, forms and dictionary homes all readappModeIcons),#6K9YGQ(all threeloading.tsxfiles exist and the contract test enumerates all three routes),#90EVWZ(check-drift.tsnow diffs per column viadiffColumns),#DREDWA(Crockford/ULID fixtures are present in the ledger writer tests),#E0N0QC(probe-generation-quality.tsnow exportsformatAnswerSection),#ZF006G(one sharedui/section-heading.tsxwith the other call sites re-exporting it),#D6G8TC(zero<h1>elements remain undertherapy-compass/) and#HSSHRG(guard-push.mjscarries an explicit in-flight CI push guard naming that issue).updaterequests correcting rows that were partly overtaken by later work, so the recorded scope matches the code:#100,#SZGPAH,#4TBHS8,#EH9VA6,#VTEW3W,#71NT23,#164Z0H,#97VQK5,#6GW95D,#TF6TPJ,#RZQQBTand#102. Each states plainly what was verified and what was not. Two are worth a reviewer's attention.#6GW95Drecorded nine leftover worktrees holding about 4.5 GB; the machine now has 69 registered, so the disk pressure it describes is materially worse than the row says.#102gains a live observation together with an explicit warning not to trust it:documents_title_trgm_idxis reported as unused by the production performance linter, but that index was recreated two days earlier and recreation resets usage statistics, so the reading is expected either way and the row still needs anEXPLAINmeasurement in the operator window.addrequests. The first records that production carries migration version20260820120000(migration_history_versions_rpc) which exists nowhere in this repository:supabase/migrations/holds 210 files with a newest version of20260819110500, andmigration_history_versionshas zero occurrences undersupabase/,scripts/orsrc/. It is plausibly the fix for thePGRST106failure already recorded in pending requestcc60253d, applied live on 2026-08-20 with the repository side still unmerged, and the request cross-references that. It carries an explicit stop rule: the reconciliation belongs in this repository, and nothing may be re-applied, repaired or mark-applied on production to resolve it. The second records that an automated worktree sweep deleted an in-use worktree during this session, destroying 25 staged-but-uncommitted files and leaving the surviving shell resolving into another agent's checkout; it proposes the three preconditions a removal should satisfy before it runs.One deliberate omission. An update to
#Q5JHBJwas written and then dropped rather than queued, because pending requestbbac85a9(2026-08-19) already updates that row with a fuller and more authoritative account: it records Phase 6.2 complete with all fifteen no-statements versions classified and guarded. The queued request supersedes what this sweep observed, and two pending mutations against one row would have forced an unnecessary cancellation decision at reconciliation time.Verification
npm run verify:pr-local— the selector classified this diff as recognised low-risk documentation scope and rancheck: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; lint, typecheck, the full unit suite, the RAG fixture scan and the build were skipped as out of scope. The decisive output line is pasted in the pull request thread.npx prettier --check docs/outstanding-issues-inbox/*.json—All matched files use Prettier code style!UI verification not run: this change adds no executable product code, no route, component, style or browser behaviour, so no UI journey can regress from it.
Risk and rollout
docs/outstanding-issues-inbox/. No executable product code, no schema, no workflow and no configuration changes. The canonical ledger is untouched, so nothing in the recommended queue moves until a later serialized branch runsissues:reconcile. The realistic failure mode is a factual error in a request's prose, which reconciliation would then write into the ledger; each request therefore states its evidence and separates verified findings from unverified ones so a reviewer can check the claim rather than trust it.git revertthis pull request, or delete the individual request files before reconciliation runs. No request has been applied yet, so nothing needs undoing in the canonical ledger.list_projects,get_project,get_advisors(security and performance) andlist_migrationsagainstsjrfecxgysukkwxsowpy. No SQL was executed, no migration was applied, and no row was written. The production security linter returned zero findings during that inspection.src/lib/rag/, no retrieval RPC, no ranking configuration, no eval harness and no golden fixture is touched by this diff.Notes
Three rows named here were checked in the code but could not be settled from this session and are recorded as open rather than closed.
#SZGPAHand#4TBHS8both lost the exact assertion text they described, but confirming the advisory lane is green needs a Chromium mockup run that was not performed.#TF6TPJshares its root cause with the closed#HSSHRGand should be re-checked against that guard with GitHub access before it is closed separately.🤖 Generated with Claude Code