docs(issues): capture the next-id collision and two gaps live on main - #1395
Conversation
Two of these are live on `main`, not pending decisions. #1385 and #1390 were both merged while their findings were still open, and an open thread on a merged PR is exactly the thing nothing tracks. #112 — `issues:next-id` has no concurrency protection. It collided twice in one hour on 2026-07-29; PR #1391 lost three id pairs in succession. This file has no union merge driver, so every collision presents as an ordinary content conflict that a hurried resolution can settle by dropping one side's rows, and nothing checks for duplicate ids afterwards. #113 — `ModeNav` clips its labels at every phone width. Measured in Chromium, not inferred: 320px shows 15 of Compare's 56px, and 430px is the worst case with three of four labels clipped, because crossing that band adds a fourth slot to the same space. `grid-auto-columns: 1fr` plus `truncate` makes the shortfall silent. The CSS block's stated budget is ~80px short of the measured intrinsic width. Three candidate fixes recorded with their trade-offs. #114 — the live Web-Vitals instrument runs Lighthouse once per route, so it cannot measure dispersion and therefore cannot detect the "evidence is too noisy" condition #17 itself tells the operator to stop on. Against a hard 2500ms threshold a route near the line resolves on variance alone, and a favourable sample would mark seven gated findings WONTFIX. The unpinned runner Chrome is folded in: the build is now recorded per report so a cross-version comparison is visibly invalid, but nothing prevents one. Each row carries the measurement or the reproduction, the next action, and a stop rule. Marker moved to 115. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FvU8z73P6TXUXoYBqN5K1P
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:52 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 (1)
Comment |
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Uh oh!
There was an error while loading. Please reload this page.
Summary
Three rows added to
docs/outstanding-issues.md, from the 2026-07-29 open-PR sweep. Two of them describe defects live onmain, not pending decisions: #1385 and #1390 were merged while their findings were still open, and an open thread on a merged PR is exactly the thing nothing tracks.#112—issues:next-idhas no concurrency protection. The marker is a plain HTML comment, read-modify-written with no lock and no post-merge check. It collided twice in one hour on 2026-07-29: PR #1391 claimed#096/#097, lost them, claimed#098/#099, lost those, and its final#108/#109collided a third time with branch-cleanup work that reachedmainfirst. Each collision is silent — this file has no union merge driver (unlikedocs/branch-review-ledger.md), so it presents as an ordinary content conflict that a hurried resolution can settle by dropping one side's rows, and nothing checks for duplicate ids afterwards. Next action recorded is a duplicate-id and marker-consistency test, which turns a silent loss into a red gate.#113—ModeNavclips its labels at every phone width. Measured in Chromium against the running app, not inferred:The 26rem band is the worst point because crossing it adds a fourth slot to the same space, so the bar gets less legible as the screen gets wider. Root cause is
grid-auto-columns: 1fr(globals.css:2373) — equal tracks make the widest slot set what every slot needs — plustruncate, which makes the shortfall silent. The CSS block's stated budget of 394px for four labels is ~80px short of the measured 471px, roughly the0/4badge and its gap. This contradicts the component's own contract that labels are never abbreviated. Three candidate fixes are recorded with their trade-offs.#114— the live Web-Vitals instrument cannot measure its own noise.live-web-vitals.ymlruns Lighthouse once per route/strategy.#017asks for reproducible evidence and says to stop when it is too noisy; one sample can do neither, so the instrument cannot detect the condition its governing item tells the operator to stop on. Against a hard 2500 ms threshold a route near the line resolves on run-to-run variance, and a favourable sample would mark seven gated findings WONTFIX. The unpinned runner Chrome is folded into the same row: the build is now recorded per report insummary.json, so a cross-version comparison is visibly invalid, but nothing prevents one.Each row carries the measurement or the reproduction, a concrete next action, and a stop rule.
issues:next-idmoved to 115.RAG impact: no retrieval behaviour change — this PR adds three markdown rows to
docs/outstanding-issues.mdand touches no code.Verification
npm run verify:cheap— exit 0,Test Files 432 passed (432),Tests 4450 passed | 4 skipped (4454)npx prettier --check docs/outstanding-issues.md—All matched files use Prettier code style!#111, which had been archived earlier that day) and were moved. Now verified — Open items is 55 rows all at 7 cells, and the archive is byte-identical tomainat 59 rows. 114 ids total, no duplicates, marker (115) above the max (114).Risk and rollout
Clinical Governance Preflight
No ingestion, answer generation, search/ranking, document access, privacy or clinical output path is touched.
Clinical KB Database(sjrfecxgysukkwxsowpy)Notes
#113and#114are recorded as open defects rather than as decisions awaiting an answer, because both PRs have already merged. If either is intentionally accepted, the rows should be archived with that reasoning rather than deleted.🤖 Generated with Claude Code
https://claude.ai/code/session_01FvU8z73P6TXUXoYBqN5K1P
Generated by Claude Code