issues: record fresh #133 evidence and the un-pad fix's Prettier prerequisite - #1465
Conversation
…equisite #133 tracks ledger conflict frequency after `merge=union` was removed. Two things learned today that the row did not yet capture. Removal did not reduce the pain. PR #1451 conflicted on `docs/outstanding-issues.md`; its session resolved the conflict by renumbering a colliding row, and `git merge-tree` showed the branch conflicting again minutes later, because four further `main` commits each touched the table. Both sides had concurrently allocated `#141` from the same marker, so a duplicate id reached a pushed tip and failed `check:outstanding-issues` there independently of the conflict — the read-modify-write allocation race this row already predicts, observed rather than theorised. The row's proposed fix ("stop padding this table") also has an unstated prerequisite: Prettier enforces padded markdown tables under `docs/`. Verified by checking byte-identical ragged content in a Prettier-ignored path (passes) and under `docs/` (fails), so the first result alone would have been a false green. Un-padding therefore needs `docs/outstanding-issues.md` added to `.prettierignore`, exactly as its sibling `docs/branch-review-ledger.md` already is at line 23. Evidence only — no behaviour change, and deliberately not the un-pad itself: that rewrites every open row and would conflict with every in-flight ledger edit, so it wants a quiet queue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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:51 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 (2)
Comment |
Uh oh!
There was an error while loading. Please reload this page.
Summary
Evidence-only update to
#133("Ledger conflicts on nearly everymainadvance (union driver removed)"). One row changed, one line of diff — no behaviour change, no code.docs/outstanding-issues.md; its session resolved that conflict by renumbering a colliding row, andgit merge-tree --write-tree origin/main <tip>showed the branch conflicting again minutes later, because four furthermaincommits (issues: close #122, record #098 delivery and #130 pre-paint guard design #1455, docs(issues): capture the Services viewport-anchor flake as #146 #1446, Close #140 as a duplicate of #133, resolved by #1444 #1445, and the X3 coverage record) each touched the table.#141from the sameissues:next-idmarker — main for "Production--clinical-accent-strongand mockup hover tokens are undefined", the PR branch for "--med-accent-softis dead plumbing". The duplicate reached a pushed tip, wherecheck:outstanding-issuesfailed with#141 appears 2 times (lines 162, 173)independently of the merge conflict.#133predicted exactly this ("concurrent appends need manual renumbering whatever the driver does"); this is it happening.#133says "stop padding this table (Prettier still renders it readably)". Prettier in fact enforces padded markdown tables underdocs/, so un-padding alone would failformat:check. Un-padding needsdocs/outstanding-issues.mdadded to.prettierignore— precisely as its sibling append-only ledgerdocs/branch-review-ledger.mdalready is at.prettierignore:23.Verification
npx prettier --check docs/outstanding-issues.md— clean after formatting.#133's row was already the widest in the table, so re-padding cascaded to nothing. (That it can cascade is the substance of#133itself.)How the Prettier claim was established, since the first result was a false green: byte-identical ragged table content was checked in a Prettier-ignored path, where it passed because zero files matched, and then under
docs/, where it failed withCode style issues found. Only the second result is meaningful.Notes
Deliberately not included here: the un-pad itself. It rewrites every open row and would conflict with every in-flight ledger edit — it wants a quiet queue and its own PR. This change is the note that makes that work correct when someone picks it up.
No source, schema, RAG-surface or clinical-risk paths are touched.
🤖 Generated with Claude Code
Queue-wide measurement (added after opening this PR)
Running the repo's own
npm run sync:pr-branches:applyacross all 29 open PRs gaveupdated=9 failed=17:docs/outstanding-issues.mdordocs/branch-review-ledger.md. None of the 6 non-ledger PRs failed. (The other 2 failures wereexpected head sha didn't matchraces from concurrent pushes, not conflicts.)mainlast re-padded.#133's row for a reason that is itself evidence:#133's row is already the widest in the table (3538 chars, budget for any addition = 0), so appending even one sentence to it makes Prettier re-pad all 72 rows — a diff that would then conflict with the other 28 open PRs. The row cannot absorb its own evidence.