fix(home): give the shared mode home the full hero design on phones - #2112
Conversation
The mode pill never navigates to a mode's own route — `changeMode` sends every selection to `/?mode=<id>` (global-search-shell.tsx), so the shared home at `/` is the only home most modes ever show. It rendered as a bare icon and title with the composer docked at the bottom, while the standalone routes it shadows carried a subtitle, the in-flow hero composer, the suggestion ticker, the privacy notice and the mode's caveat. Two independent causes: - The Tools phone-dock exception was keyed on `resultKind`, not on the Tools directory being mounted. Factsheets, Dictionary and Therapy Compass borrow `kind: "tools"` as a benign search kind, so on `/` they inherited the dock and lost the hero composer, ticker and privacy notice with it. `shouldShowSharedHome` already excludes `mode=tools`, so `showSharedHome` is the correct opt-back-in for both `heroComposerBreakpoint` and `centeredModeHome`. - `sharedHomePresentation` carried only a title. It now carries the subtitle and the review-before-use caveat for every mode, taken verbatim from that mode's own standalone home so the wording matches whichever door a clinician came through. Because the mode home is vertically centred, per-mode caveats of different lengths moved the composer between modes (Formulation sat 8px above Specifiers at 320px). `--mode-home-verification-reserve` holds that slot at a constant height, measured across every mode at 320/360/390/412px: the composer top is now pixel-identical for 12 of 14 modes. The two that still differ (Therapy Compass, Dictionary) have no entry in `searchCommandSurfaceByMode`, so they render no suggestion ticker at all — a content gap in a separate subsystem, reported rather than guessed at here.
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
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:57 minutes Limit details: You’ve used all 1 included review currently available under your plan. You completed 102 included PR reviews in the past 7 days; at that activity level, included reviews refill at 1 review per hour. 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 (10)
Comment |
CI triageCI failed on this PR. Automated classification of the 2 failed job(s):
Compared with main CI run #12142 (success). Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger. |
`check:maintainability-budgets` failed CI at 4149 lines against the 4140-line no-growth ceiling for ClinicalDashboard.tsx (Static PR checks > Maintainability hotspot budgets). The two rationale comments this PR added around heroComposerBreakpoint/centeredModeHome accounted for the overage; condense them to the same information in fewer lines. No logic change — heroComposerBreakpoint and centeredModeHome are byte-identical expressions. Run PR sweep fix for PR #2112.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…epage-routing-obr8g4
…epage-routing-obr8g4
…epage-routing-obr8g4
Summary
changeMode(global-search-shell.tsx:675) sends every selection to/?mode=<id>, so the shared home at/is the only home most modes ever show. It rendered as a bare icon and title with the composer docked at the bottom, while the standalone routes it shadows (/factsheets,/dsm, …) carried a subtitle, the in-flow hero composer, the suggestion ticker, the privacy notice and the mode's caveat. Earlier work landed on those standalone routes, which the mode pill does not open.resultKind, not on the Tools directory being mounted. Factsheets, Dictionary and Therapy Compass borrowkind: "tools"as a benign search kind (see theirapp-modes.tscomments), so on/they inherited the dock and lost the hero composer, ticker and privacy notice with it.shouldShowSharedHomealready excludesmode=tools, soshowSharedHomeis the correct opt-back-in forheroComposerBreakpointandcenteredModeHome.sharedHomePresentationcarried only a title. It now carries a subtitle and an optional review-before-use caveat for every mode, taken verbatim from that mode's own standalone home so the wording matches whichever door a clinician came through. Previously only Answer showed a caveat here.--mode-home-verification-reserveholds that slot at a constant height. Measured in Chromium across all 14 modes at 320/360/390/412px, the composer top is now pixel-identical for 12 of them.searchCommandSurfaceByMode, so they render no "Try this" suggestion row and sit 28px lower than the rest. Adding entries would also flip on remote search for those modes (commandSurfaceRemoteSearchEnableddefaults true), and the example queries are a clinical-content decision — left for a separate change rather than guessed at.Verification
npm run verify:phone-chrome— exit 0, all five stages green:lock-paritythe complete installed tree matches package-lock.jsonruntimeNode and npm runtime match the repository contractcontracts—Test Files 9 passed (9) / Tests 130 passed (130)changed-browser(tests/ui-tools.spec.ts) —95 passed (2.0m)focused-browser—10 passed (28.6s)full-ui(verify:ui, complete Chromium suite) —447 passed (14.1m)npm run test(full offline unit suite) —Test Files 665 passed (665) / Tests 7101 passed | 4 skipped (7105)npm run typecheck— cleannpm run format— run and committedNote on the log: a
[phone-chrome] stage "focused-browser" failedline appears in thecontractsoutput. That is stderr fromtests/verify-phone-chrome.test.ts > aborts on the first non-zero stage exit, which exercises the runner's own abort path. The stage itself passed and the gate exited 0.Not run:
verify:release,eval:*,check:supabase-projectand any other provider-backed gate — none of the touched surfaces are retrieval, ranking, ingestion or answer-generation code, and provider access was not authorized for this task.Risk and rollout
pr-policyclassifies the diffclinicalRisk: false,operationalRisk: false,ragRanking: false,ui: true. No retrieval, ranking, ingestion, auth or schema code is touched. The behavioural change is that three modes move from the phone bottom dock to the in-flow hero on/— the placement every other mode already used there — and that every mode now shows its own subtitle and caveat instead of only Answer.Notes
docs/search-chrome-behaviour.mdis updated: the first ownership row now names the shared home explicitly, and a note records that the Tools row is scoped to the mounted directory rather than toresultKind, so the exception cannot leak back onto/.--mode-home-copy-reservenext to it: Calculators' caveat wraps to three lines at every phone width, so a per-width band would resolve to the same value three times. The rationale and the measurements are in the CSS comment.--mode-home-copy-reservealready absorbs every title/subtitle pair identically (103/83/83/73px at 320/360/390/412px across all modes), so adding subtitles cost nothing geometrically./?mode=factsheetsand/?mode=dictionarywere added to the in-flow-hero loop as regression cases for the composer-placement fix.Generated by Claude Code