chore: refresh Lighthouse budget baseline for HeadlessChrome/151 - #1690
Merged
Conversation
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Co-authored-by: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Copilot
AI
changed the title
[WIP] Fix issues in Copilot actions run
chore: refresh Lighthouse budget baseline for HeadlessChrome/151
Aug 7, 2026
BigSimmo
marked this pull request as ready for review
August 7, 2026 13:47
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
BigSimmo
approved these changes
Aug 7, 2026
BigSimmo
merged commit Aug 7, 2026
669640b
into
claude/search-bar-mobile-layout-buu0io
3 of 4 checks passed
cursor Bot
pushed a commit
that referenced
this pull request
Aug 7, 2026
…1689) * fix(search-band): drop the sort segments from the phone results bar The shared results band puts count, query, sort and Filter on one line. On a phone the two sort segments ("Relevance" / "A-Z") take roughly half of that line, so the query truncates to pay for a control that is set about once a session and already defaults to the order a phone reader wants. ResultSortControl is now sm-and-up. Only the affordance moves: `?sort=` still carries an alpha order onto a phone from a link or a wider session, and the results honour it. The display class lives in the component's own base string because `cn` here is a plain join with no Tailwind conflict resolution, so a caller's `hidden` would resolve by stylesheet order rather than by intent. Pages whose only utility is sort (forms) would have kept an empty utilities group mounted on a phone -- and in `inline` placement below 414px that child is `w-full basis-full`, i.e. a blank second line. Guard it with hasPhoneUtilities. Tests move rather than disappear: ui-smoke asserts the group is hidden at 390px and exercises the A-Z/Relevance interaction at the 1440px viewport the same test already resizes to, and the two ui-tools differentials phone tests assert hidden while keeping the 44px tap floor on the page filter. The 320-540px clip sweep measured the sort node by name, which would have measured a display:none element and passed blindly at every width; it now measures the last rendered control. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013mcqh46SDdiR5KxScihkFQ * chore: refresh Lighthouse budget baseline for HeadlessChrome/151 (#1690) * chore: format the refreshed Lighthouse baseline The HeadlessChrome/151 baseline refresh landed with `0.060` / `0.080` trailing zeros, which Prettier normalises to `0.06` / `0.08`. That is the whole diff -- no measurement changes. `format:changed` runs Prettier over the PR's entire changed set, so the unformatted blob failed the required Static PR checks job on this branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013mcqh46SDdiR5KxScihkFQ * test(search-band): assert the phone sort group is mounted, not merely absent The three phone assertions claimed a guarantee they did not provide. `toBeHidden()` passes for a hidden node AND for a node that does not exist, and in ui-tools the plain `getByRole` locator filters hidden nodes out before the assertion sees them -- so both would have passed with ResultSortControl deleted from the component entirely, which is exactly the regression the comment says they catch. Resolve the group with `includeHidden: true`, assert `toHaveCount(1)`, then assert `toBeHidden()`. A deleted control now fails the count; a control returned to the phone line fails the visibility. Raised by CodeRabbit on #1689. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013mcqh46SDdiR5KxScihkFQ --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com> Co-authored-by: Cursor Agent <cursoragent@cursor.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The CI
check:lighthouse-budgetjob was failing because the committed baseline was recorded with HeadlessChrome/150 and the CI runner upgraded to HeadlessChrome/151. The budget script unconditionally treats a browser-version mismatch as "evidence incomplete" (regardless ofenforce: false) and exits 1.Changes
lighthouse-budget.json— refreshed all 10 baseline entries (chromeVersion,lcpMs,tbtMs,cls) with values measured in the failing Chrome 151 CI run; updatedupdatedAtThis is the same operation as
npm run check:lighthouse-budget -- --updateafter a known-good run — replaces the baseline so Chrome 151 becomes the new reference point.Summary
Verification
npm run verify:pr-localDuring development, use
npm run verify:cheapas the faster iteration gate before the final PR-local preflight.npm run verify:uiwhen UI, routing, styling, browser behavior, reduced-motion, or forced-colors behavior changednpm run verify:releasebefore release or handoff confidence claimsFor retrieval, ranking, selection, chunking, source/citation rendering, or answer-contract changes,
verify:pr-localrunseval:rag:offlineautomatically. Run the offline command directly during iteration before spending a live eval.npm run eval:retrieval:quality(must stay 36/36) when retrieval, ranking, selection, chunking, or scoring behavior changed — CI cannot run it (needs live keys), so run it locally and paste the summary. A metadata/governance-weighting change once buried correct docs (recall 1.0→0.76) and only this eval caught it.npm run eval:rag -- --limit 15+npm run eval:quality -- --rag-onlywhen answer generation, the synthesis prompt, or answer post-processing changed (grounded-supported must not drop; citation-failure 0)npm run check:production-readinesswhen clinical workflow, privacy, environment, Supabase, source governance, or deployment behavior changednpm run check:deployment-readinesswhen deployment startup, hosting, or rollout behavior changedVerification not run: data-only JSON baseline refresh; no executable code changed. The fix will be validated by the CI run on this PR.
Risk and rollout
enforce: false; this is a data file refresh, no logic changeClinical Governance Preflight
Not applicable — no ingestion, answer generation, search/ranking, source rendering, document access, privacy, env, or clinical output touched.
Notes