docs(issues): reconcile 16 queued ledger requests after PR #2093

[BigSimmo]

Summary

Dedicated ledger reconciliation, run from a fresh base off origin/main (9d832452d) with no product change riding along, per the serialization rule.

• Applies 16 queued inbox requests into docs/outstanding-issues.md, honouring 4 cancellation decisions.
• Includes the Phase 2 result for #056 (PR Replay the migration chain onto staging to parity, and record that the chain does not reproduce schema.sql (Phase 2, #056) #2093, merged): staging replayed to 194/194 migration parity with every row md5-verified byte-identical to its repository file, and check:drift run against staging returning 19 findings showing the committed migration chain does not reproduce supabase/schema.sql.
• One of the cancellations is my own superseded #056 request, which recorded check:drift as blocked on a missing credential before the gate was actually run. Cancelled and replaced rather than edited, per the immutable-request rule.

Verification

• npm run check:outstanding-issues — 360 rows (104 open, 256 archived), unique display and durable ids, no ids deleted from base 9d832452dc31
• npm run check:ledger-write-discipline — passed for 9d832452dc31..HEAD
• npm run issues:reconcile — Applied 16 request(s), inbox now 0 pending / 250 applied
• npm run format
• Verification not run: browser/build gates — no executable, UI or build-affecting change in the diff.

Risk and rollout

Documentation-only. No code, schema, migration or config change. Rollback is an ordinary git revert; the immutable audit records under docs/outstanding-issues-inbox/applied/ preserve the transaction either way.

Do not use GitHub's Update branch button on this PR — it carries a reconciliation, and merging main into it turns a complete transaction into a partial one that the guard correctly rejects.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in:34 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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: dc117b23-eea9-4142-88ef-670def58412a

📥 Commits

Reviewing files that changed from the base of the PR and between fb22551 and 1bfa9b0.

📒 Files selected for processing (19)

• docs/branch-review-records/fddd42a9e93d9f7e66607077eb77d2a71ad979f40926fb3f0452cd67ade9e0c8.record.md
• docs/outstanding-issues-inbox/applied/1505ba13-1b2a-47c9-b6cc-03b060f7a878.json
• docs/outstanding-issues-inbox/applied/1591ee4a-ce24-4091-93ba-ac4e7819fb60.json
• docs/outstanding-issues-inbox/applied/1ead9bb9-5e9d-4b54-b530-87586d594f0a.json
• docs/outstanding-issues-inbox/applied/4302ff5b-582a-4204-94bf-d554c953900f.json
• docs/outstanding-issues-inbox/applied/48e960d3-36e0-4be0-af16-7959d62b1907.json
• docs/outstanding-issues-inbox/applied/6697868a-cc70-48e3-ad6f-598ff4031110.json
• docs/outstanding-issues-inbox/applied/779bc0e9-c28f-40ab-abda-cfdcf93ea752.json
• docs/outstanding-issues-inbox/applied/7c1f5850-ddcd-47da-89ad-99314d0040fe.json
• docs/outstanding-issues-inbox/applied/8650e564-7835-47b3-a7e2-476f369b9eea.json
• docs/outstanding-issues-inbox/applied/8e28c783-d655-4480-852c-bafaf0b3c07b.json
• docs/outstanding-issues-inbox/applied/993a1c72-96bd-4e48-b1a4-3ea3b603acac.json
• docs/outstanding-issues-inbox/applied/a1c319d6-a098-460b-8b42-6794ca6690fd.json
• docs/outstanding-issues-inbox/applied/a39af37c-b4dd-4e4b-84dc-395d86937615.json
• docs/outstanding-issues-inbox/applied/a727ac1a-1d72-41bd-88f9-76945528bc97.json
• docs/outstanding-issues-inbox/applied/d25147c8-3da0-4062-9ce0-356e59a16c63.json
• docs/outstanding-issues-inbox/applied/d958d671-362d-41ed-b72f-102357dbf156.json
• docs/outstanding-issues-inbox/applied/f6798c46-7f43-4481-8e02-bcac1bf9b262.json
• docs/outstanding-issues.md

---

_{Comment @coderabbitai help to get the list of available commands.}

[supabase]

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[github-actions]

CI triage

CI failed on this PR. Automated classification of the 2 failed job(s):

• Static PR checks — needs investigation: inspect the failing step and uploaded diagnostics; rerun only after classifying the cause.
• PR required — needs investigation: inspect the failing step and uploaded diagnostics; rerun only after classifying the cause.

Compared with main CI run #11938 (cancelled).

Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger.

[BigSimmo]

Fixed and pushed. The two failures shared one cause: the reconciliation was cut against base 9d832452d, but main advanced to dda4956ff while the PR was opening, so a later-arriving inbox request (a727ac1a) was left pending and the write-discipline guard correctly rejected the transaction as partial.

Re-cut from dda4956ff and re-ran the reconcile — 17 requests now, not 16. Verified against the same base CI uses:

Ledger inbox check passed: 0 pending request(s), 251 applied.
Outstanding-issues guard passed: 361 rows (105 open, 256 archived) ... no ids deleted from base dda4956ff4ad
Ledger write discipline passed for dda4956ff4ad..HEAD

Published by force-push because the fix required re-cutting onto a newer base; merging main in was not an option, since that is what turns a complete reconciliation into a partial one. Auto-merge was disarmed first with the owner's explicit approval, per the mutation-freeze rule. The prior ledger review record is superseded rather than edited.

🤖 Addressed by Claude Code