docs(issues): close #290 as not-reproducible over three full ui-smoke runs, capture the browser-preflight traps (#312)

[BigSimmo]

Summary

• #290 archived — the ui-smoke phone scroll-hide flake could not be reproduced on current main (3dc1f37). Full tests/ui-smoke.spec.ts --project=chromium run three consecutive times: 97 passed / 0 failed / 0 flaky each (3.0m, 2.8m, 2.8m) — 291 test executions, zero failures. All four named members passed every time. Separately, the row's named "reliable reproducer" was run in isolation with --repeat-each=5: 5 passed, each in 0.98–1.2s, against the row's documented failure signature of an ~11.5s timeout versus ~1.4s when passing. They sit in the passing regime, not marginally inside it.

• Recorded as evidence, not proof, and the archive entry says so. The row measured failure rates of 2/5 and 3/5 on full-suite runs, so a single clean run had roughly even odds even under the old behaviour; three consecutive clean runs put that at roughly 6–22%. Meaningful, not conclusive, for an intermittent failure. The archive tells a future reader to reopen rather than re-file, and keeps the reproducer name and the ~11.5s-vs-~1.4s timing signature as the fastest way to recognise a recurrence.

• Resolved by drift, not by anything in this PR.main has advanced several hundred commits past the row's base commit 9ab3b73a (9 August) and nothing in this session touched src/.

• #312 (new) captures two browser-proof traps that cost two failed runs before the measurement could start:

  • check:playwright-browser-revision reporting OK (managed-or-unconstrained) means no browser root is forced — it does not assert any browser exists. I read it as a green light for verify:ui; the container actually had chromium-1194 while Playwright 1.62.1 requires chromium_headless_shell-1234, with firefox-1538 and webkit-2336 absent entirely.
  • Installing the matching revision is a cheap first option that archived #255 does not mention: npx playwright install chromium fetched 114.7 MiB in about a minute and made local Chromium proof possible. Also recorded: PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD was empty in this container despite the environment note implying otherwise, and --project=chromium skips the unused Firefox/WebKit requirement because scripts/playwright-browser-preflight.mjs:127-152 honours project scoping — so two ~100MB downloads are avoidable.

Verification

• npm run verify:pr-local

- completed: check:runtime, check:installed-lock-parity, format:changed, sitemap:check,
docs:check-index, docs:check-inventory, docs:check-scripts, docs:check-links,
check:branch-review-ledger, check:outstanding-issues
- failed: (none)
- not reached: (none)

Outstanding-issues guard passed: 310 rows (114 open, 196 archived), unique ids,
next-id=313 above the highest, no merge driver, no ids deleted from base 3dc1f37337d2.

Browser evidence, captured to files and read from the real process exit code rather than through a pipe:

97 passed (3.0m) run 1 0 failed 0 flaky
97 passed (2.8m) run 2 0 failed 0 flaky
97 passed (2.8m) run 3 0 failed 0 flaky
5 passed (12.4s) isolated --repeat-each=5 on the named reproducer

Docs-only diff, so the router skipped lint, typecheck, the unit suite and the build. No src/ change, so no UI verification is owed beyond the ui-smoke evidence above — which is itself the point of the PR.

Risk and rollout

• Risk: none to the product. Documentation-only; one row archived, one row added. The residual risk is that #290 is archived while the flake is merely dormant — mitigated by recording the probability arithmetic explicitly, keeping the reproducer name and timing signature in the archive, and instructing a reopen rather than a re-file.
• Rollback: git revert this single commit; #290 returns to the open table with its original text intact.
• Provider or production effects: None. No provider was called and nothing was deployed; the only network access was a Playwright browser download.

Notes

The --project=chromium scoping detail is worth keeping in mind for any future local browser proof in a cloud session: the preflight demands every project's browser by default, so an unscoped run insists on Firefox and WebKit even for a Chromium-only spec.

---

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:46 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: 629bb5b9-fdf1-4d89-8d7c-826a3a33cd16

📥 Commits

Reviewing files that changed from the base of the PR and between c5f7e05 and 32d889c.

📒 Files selected for processing (2)

• docs/branch-review-ledger.md
• docs/outstanding-issues.md

---

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

[BigSimmo]

Independent verification from a second session (worked #290 in parallel before finding this PR), with one correction to the archive's causal story.

Measured in a fresh cloud container (Chromium headless-shell 1234 installed per this PR's #312 note):

• Current main (a76f280), reproducer isolated --repeat-each=5: 5 passed (11.2s), each ~1.0s — agrees with this PR.
• Bad SHA 9ab3b73ad (detached worktree, its own npm ci + production build), reproducer isolated ×5: 5 passed (10.4s), each ~1.0s.
• Bad SHA, full tests/ui-smoke.spec.ts --project=chromium: 98 passed (2.5m), 0 failed, 0 flaky.
• Bad SHA, reproducer ×10 under deliberate CPU contention (6 busy-loop processes on 4 cores; run times rose to 1.2–1.5s so the load was real): 10 passed (28.6s).

Correction: the Summary attributes the recovery to drift ("Resolved by drift… main has advanced several hundred commits"). But the bad SHA itself — the exact commit where #290 measured 2/5 and 3/5 failures — passes 30/30 executions in this container, including the full-suite shape and under induced load. So drift is not what resolved it: the failure was specific to the original machine/environment (its load profile or toolchain), not to the commit window. The archive row's "reopen on recurrence" instruction still stands; suggest a future reader treat the e8adde1b9..9ab3b73a "regression window" as unconfirmed rather than established, since the bad end of the window no longer reproduces anywhere.

Not-reproducible remains the right disposition, and archiving #290 is the right call — no second PR needed from my side.

One residual mechanism note for whoever meets a recurrence: computeScrollHideUpdate (use-hide-on-scroll.ts) only re-evaluates on scroll/resize events, and its viewportHeightChanged/range-change guards zero accumulated down-travel by design. If geometry churn consumes the final scroll steps of a gesture, the not-hidden state is permanent until the next event — consistent with the recorded ~11.5s timeout signature (the toHaveAttribute retry never sees a flip). A failing page.on("console") trace of which guard fires would be the fastest confirmation.

---

Generated by Claude Code