Stop Prettier padding the issues ledger table, closing #133

[BigSimmo]

Summary

• Closes the remaining half of #133 — the fixed-width column padding that turns a ledger edit into a whole-table hunk. Remove merge=union from the issues ledger, per its own #133 #1444 closed the merge=union half; this closes the padding half.
• #133's stated fix was infeasible as written, and measuring it is what showed why. It asked to "stop padding this table (Prettier will still render it readably)". Prettier is what pads the table: stripping the padding and running prettier --write restored the file byte-for-byte identical to the original. Un-padding therefore requires prettier-ignoring the file.
• Follows existing precedent.docs/branch-review-ledger.md is already in .prettierignore for the same class of reason. This adds docs/outstanding-issues.md beside it, with the rationale written down.
• Corrects #133's own claim rather than leaving it overstated (see below).

Measured, not asserted

#133 says "a single row's edit re-pads all 59 open rows." That holds only when the edit raises a column's maximum width. An edit inside the existing maxima is 2 changed lines either way. Measured on the real file:

Edit	Padded	Un-padded
Lengthen a Detail cell (within column max)	2 lines	2 lines
Widen a Summary past the column max	144 lines	2 lines

That distinction is the point, not a caveat: appending a new row is precisely the max-raising operation, and appending is what agents do to this file constantly — so the worst case was also the common case. A 144-line hunk conflicts with anything else touching the table, and each such conflict stops all CI on the PR until resolved (#116).

Nothing structural is lost

Prettier's only contribution to this file was column alignment. Row shape, ids, the issues:next-id marker and the merge attribute are all gated by npm run check:outstanding-issues, which is far stricter than a formatter and is required in both verify:cheap and CI static-pr. A gate's job, not a formatter's.

Verification

• npm run check:outstanding-issues — 144 rows (70 open, 74 archived), unique ids, next-id=147 above the highest, no merge driver.
• npm run docs:check-links — 1407 repo path references resolve.
• npx prettier --check . — clean, with the file now ignored.
• The infeasibility claim is empirical: un-pad → prettier --write → diff against the original reports identical.
• The benefit numbers above come from running the two edits against the real file and diffing, not from reasoning.

Pre-existing failure, not caused by this change:npm run verify:cheap exits 1 on tests/installed-lock-parity.test.ts — expected 10000000 to be less than or equal to 40000. I verified it fails identically on clean main with none of these changes applied, so it is left untouched rather than absorbed into this PR. Everything else passed: 436 passed (437) files.

Risk and rollout

• Risk: low in content — documentation and one ignore entry, no src/, no gate logic, no runtime behaviour.
• Timing is the real cost. The one-time reformat touches 178 rows and will conflict with any open PR that edits this file. Please merge it when the queue is quiet rather than mid-sweep. Under Remove merge=union from the issues ledger, per its own #133 #1444 those conflicts now surface honestly rather than silently doubling the table, but they still need resolving.
• Rollback: revert the commit — Prettier reformats the table on the next npm run format, restoring the previous state exactly.
• Provider or production effects: none.

Clinical Governance Preflight

Not applicable — documentation and formatter configuration only. scripts/pr-policy.mjs classifies no clinical-risk path, no supabase/**, no src/app/api/**, and no RAG-ranking protected surface, so no RAG impact: declaration is required.

---

Generated by Claude Code

[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 ↗︎.

[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:3 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 @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: b2dd2e64-221c-4e46-8b67-9083e7520428

📥 Commits

Reviewing files that changed from the base of the PR and between 00ddb22 and 22cea1b.

📒 Files selected for processing (2)

• .prettierignore
• docs/outstanding-issues.md

---

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