Close #140 as a duplicate of #133, resolved by #1444 - #1445
Conversation
#140 was opened mid-session for the union-driver damage before I noticed #133 had already recorded the same finding, earlier and with the same conclusion. Two open rows described one condition, and PR #1444 has since removed that condition: `merge=union` is gone from `.gitattributes`, `check:outstanding-issues` now requires an unspecified `merge` attribute, and regression tests cover `union`, `-merge` and an unparsed reading. Moved to the archive table rather than deleted, pointing readers at #133 — whose still-open half is the real conflict-frequency cause: fixed-width column padding makes any one-row edit re-pad every row, so git sees the whole table as one hunk. The surviving evidence (four merges on PR #1430 each reporting success while duplicating the entire open-items table) lives there too. Verified: check:outstanding-issues 138 rows, 66 open / 72 archived (was 67/71 — moved, not copied), unique ids, next-id=141, no merge driver; docs:check-links 1361 references resolve; prettier clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XrPbbfU9yWuEjEVypCr4ZQ
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:52 seconds 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.
…ge gaps (#1496) * issues: close#130 by decision; capture the stale-install and reviewer gaps #130 is archived because the owner decided not to pursue it, NOT because the acceptance was run. The row says so in its first sentence, because a "CLOSED" line is exactly the thing a future reader could mistake for evidence: docs/phone-chrome-physical-acceptance.md on main is still the blank template, and nothing in CI covers what it covers — headless Chromium was explicitly stated as unable to certify Safari chrome-minimisation or cold-launch PWA paint. Residual risk is unchanged and unmeasured, and the row says to open a fresh one if phone-chrome misbehaves on a real device. Two risks that surfaced during today's work were never written down, and neither had an existing row (checked before adding, after creating a duplicate earlier today by not checking): #149 — the SessionStart hook reported "node_modules matches the lockfile" while brace-expansion was installed at 1.1.16 against a lockfile pinning 1.1.18, the CVE-2026-14257 patch. Every local gate run in that window was weaker than reported, including verify:cheap runs called green during #1430/#1444. It surfaced only because installed-lock-parity asserts the patched behaviour directly, and its failure was first misread as a pre-existing repo defect because it also failed on clean main in the same stale container. Notes that check:installed-lock-parity is only in verify:ui, so the broad local gate cannot catch its own stale foundation. #150 — CodeRabbit reviewed none of #1404, #1430, #1444, #1445 or #1479; every comment was a spending-cap rate-limit notice that renders as ordinary bot activity. Codex was the sole substantive reviewer and found three real defects that survived local gates and self-review. Fast checks run against this tree: check:runtime, check:installed-lock-parity (now passing, confirming the drift is resolved), check:outstanding-issues, check:branch-review-ledger and check:migration-role all PASS. check:supabase-project and check:production-readiness fail only on absent provider credentials, which AGENTS.md states is expected in demo mode. Verified: check:outstanding-issues 148 rows (57 open, 91 archived), unique ids, next-id=151, no merge driver, no ids deleted from base; docs:check-links clean; whole-tree prettier clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XrPbbfU9yWuEjEVypCr4ZQ * issues: correct #149 — parity check scope, not its placement Codex review is right on both counts and this rewrites the row rather than patching around it. The earlier text said check:installed-lock-parity lives only in verify:ui and proposed adding it to verify:cheap; verify:cheap:internal already runs it, so that follow-up was a no-op — and it ran green throughout the stale window. The real gap is scope. criticalInstalledPackages lists seven top-level names (next, react, react-dom, eslint, playwright, typescript, vitest), so a stale transitive dependency is invisible. Proved by faking node_modules/brace-expansion back to 1.1.16 against the 1.1.18 lockfile pin: check:installed-lock-parity exits 0. That also explains why both the hook and the gate reported parity while the tree was stale — neither was looking at the package that drifted. Next step is now to broaden the check (full tree, or a lockfile-hash install stamp) rather than move it, and the row warns against reading a green parity run as proof the install is current. Verified: check:outstanding-issues 148 rows, unique ids, next-id=151, no ids deleted from base; docs:check-links 1413 references; prettier clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XrPbbfU9yWuEjEVypCr4ZQ --------- Co-authored-by: Claude <noreply@anthropic.com>
Summary
#140, a duplicate row I created and then left behind. It was opened mid-session for the union-driver damage before I noticed#133had already recorded the same finding — earlier, and with the same conclusion. Two open rows described one condition.merge=unionfrom.gitattributes, invertedcheck:outstanding-issuesto require an unspecifiedmergeattribute, and added regression tests forunion,-mergeand an unparsed reading. Leaving#140open would describe a fixed problem as live.#133— where the surviving evidence lives (four merges on PR Name which value holds the phone header open, not just that it did #1430 each reporting success while duplicating the entire open-items table) and where the still-open half sits: fixed-width column padding makes any one-row edit re-pad every row, so git sees the whole table as one hunk. That is the real conflict-frequency cause, and it is deliberately left open.One row moved between tables. No other content changes.
Verification
npm run check:outstanding-issues—138 rows (66 open, 72 archived), unique ids, next-id=141 above the highest, no merge driver.The open count drops by one and the archived count rises by one, which is what proves it was moved rather than copied — an id present in both tables is one of the failures this gate catches.npm run docs:check-links—1361 repo path references resolve.npx prettier --check docs/outstanding-issues.md— clean.npm run verify:cheapnot run: the diff is one line of one markdown table, and the two gates that actually cover this file's structure and its links both ran above. Say the word if you'd rather see the broad gate on it anyway.Risk and rollout
src/, no config, no gate logic.Clinical Governance Preflight
Not applicable — documentation only.
scripts/pr-policy.mjsclassifies no clinical-risk path, nosupabase/**, nosrc/app/api/**, and no RAG-ranking protected surface, so noRAG impact:declaration is required.Generated by Claude Code