Give the Guide Centre footer search the shared edge-to-edge phone dock

[BigSimmo]

Summary

• The Guide Centre composer was the only phone search bar not using the shared dock chrome. GuideDialog renders its composer through the generic Sheet footer slot, and Sheet always wraps that slot in border-t border-[color:var(--border)] p-3 sm:p-4 (src/components/ui/sheet.tsx:554); the guide then layered bg-[color:var(--surface-raised)] + shadow-[var(--e4)] on top. On phones that is a full-width opaque raised band with a hard top border sitting over the content behind the pill — the "cover" the shared dock exists to avoid.
• Every other phone composer keeps the band itself transparent — .answer-footer-search-dock.answer-footer-search-edge (src/app/globals.css) sets flush left/right/bottom: 0, safe-area padding and background: transparent — and paints one localized .answer-footer-search-backdrop scrim that tints around the pill and tapers to zero at the physical edge. The guide footer now carries exactly that pair and renders the scrim child; its own border, surface and elevation moved to sm: only, so the tablet/desktop dialog footer is unchanged.
• The dock stays on the default scrim height rather than document-mobile-search-compact: the tour action row sits above the pill, the same shape the differentials-compare and patient-details dock addons take, and the compact 5rem scrim would end mid-row.
• docs/search-chrome-behaviour.md gains a Guide Centre row in the page-ownership table plus a short section recording why the footer is a dock and not a footer band.
• tests/guide-centre-design-contract.dom.test.tsx now pins the dock chrome (dock/edge classes present, phone band chrome off, sm: band chrome on, scrim child sm:hidden). The old assertion that the footer carries shadow-[var(--e4)] was pinning the elevated slab itself and is replaced; the guard against the unapproved --shadow-elevated token is kept.
• docs/design-system/adoption-manifest.json regenerated (the edited test file now registers under the Sheet component's testFiles).

Verification

• npm run verify:pr-local

PR-local verification summary:
- 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, check:ledger-write-discipline, lint, typecheck, test, build, check:rag:fixtures, check:medication-interactions, check:medication-lexicon-report
- failed: (none)
- not reached: (none)

Unit suite within that run: Test Files 673 passed (673) / Tests 7277 passed | 4 skipped (7281).

• npm run verify:phone-chrome — static and unit stages passed (Test Files 9 passed (9) / Tests 130 passed (130), covering header-scroll-hide-contract, mobile-composer-reserve, ui-overlay-css-contract, use-hide-on-scroll). Its focused-browser stage could not run in this container: the Playwright browser preflight reports the pinned revision missing (/opt/pw-browsers/chromium_headless_shell-1234/...; the image ships 1194), the known browser-revision drift. Per the repo rule, the mismatched path was not forced — UI verification not run: pinned Playwright Chromium revision unavailable in this container; delegating the Chromium journey proof to CI Production UI.

Manual browser evidence was still gathered against the container's own Chromium 1194 on the running dev server, measuring the footer's computed style at 393×852:

left 0, right 0, bottom 0, width 393
background rgba(0, 0, 0, 0) borderTopWidth 0px boxShadow none
paddingBottom 8px paddingLeft 12px
backdrop present, display block, height 160px

and at 1024 wide (unchanged desktop band):

position static, background rgb(28, 33, 38), borderTopWidth 1px, padding 16px, backdrop display none

Scroll-hide still works on phones (footer aria-hidden="true", opacity 0 after scrolling the guide body).

• npm run verify:release — not run; no release or handoff confidence claim is made here.

Risk and rollout

• Risk: Low, and confined to phone widths inside the Guide Centre dialog. The change is presentational: it swaps the dialog's own footer band chrome for the shared dock classes that already style every other phone composer. Desktop/tablet rendering is byte-for-byte the previous band (verified by computed style above). The one behavioural coupling worth naming is that the guide footer now inherits future edits to .answer-footer-search-dock — which is the intent, since the point is a single owner for phone composer chrome.
• Rollback: revert the single commit; no data, schema, or config is touched.
• Provider or production effects: None.

Notes

• No RAG impact: line and no Clinical Governance Preflight: classifyPullRequestFiles returns clinicalRisk: false, operationalRisk: false, ragRanking: false, ui: true for this diff.

---

Generated by Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[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 current included review allowance is based on your included PR review attempts over the past 7 days.

Next review available in:24 minutes

Limit details: You’ve used the included review currently available. Your 101 included PR review attempts over the past 7 days set your current allowance 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 @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 within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 56a7add1-6faf-42b5-a30e-b313311d7ca7

📥 Commits

Reviewing files that changed from the base of the PR and between 2763e96 and ea132c1.

📒 Files selected for processing (7)

• docs/branch-review-records/19cdca49e6751aaf2914f2d6ee4ab144b1689c076eb51580aff9534f27b98c65.record.md
• docs/branch-review-records/5ef27bddd67e7684747a62117c9d75bf90397fb061f937dc1df32ca05c31fbbc.record.md
• docs/design-system/adoption-manifest.json
• docs/search-chrome-behaviour.md
• src/components/clinical-dashboard/guide-dialog.tsx
• tests/guide-centre-chrome.spec.ts
• tests/guide-centre-design-contract.dom.test.tsx

---

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