fix(ui): keep the mobile search composer in the hero on mode landing pages

[BigSimmo]

Summary

• On mobile, standalone mode landing pages (Forms, Services, DSM, Formulation, Specifiers, Factsheets, Differentials, Favourites, Tools, Therapy‑compass) docked the search composer to the bottom of the viewport and hid it on scroll, while the answer home ("How can I help?") kept its in‑flow "hero pill" in the middle of the page.
• Root cause: PR feat(ui): compact bottom search dock on phones everywhere except the home hero #964 introduced the split via heroComposerBreakpoint="sm-up" on the standalone search shell (before feat(ui): compact bottom search dock on phones everywhere except the home hero #964 all mode homes kept the in‑flow pill on phones). This restores the pre‑feat(ui): compact bottom search dock on phones everywhere except the home hero #964 behaviour so every mode landing page keeps the in‑flow hero pill on phones, matching the home page.
• src/components/clinical-dashboard/global-search-shell.tsx: heroComposerBreakpoint "sm-up" → "all" so the phone composer portals into the in‑flow hero slot at every width.
• src/components/clinical-dashboard/mobile-composer-reserve.ts: standalone mode homes reserve the idle content pad instead of dock clearance, so no empty band opens under the pill.
• The site‑wide APP‑5 privacy notice now rides the hero pill on phone mode homes too (as it already does on desktop and did before feat(ui): compact bottom search dock on phones everywhere except the home hero #964) — a conservative, consistent direction.
• Phone‑only (<640px); desktop and tablet already used the hero at both prop values. The in‑dashboard mode states (/?mode=documents, /?mode=prescribing) are the documents‑search / prescribing workspaces, not landing pages, and are unchanged.

Verification

• npm run lint + npm run typecheck — pass
• npm run test (vitest) — 3028 passed. The only failure is the pre‑existing tests/pdf-extraction-budget.test.ts (Python child‑tree deadline), which fails identically on clean main (this VM has no Python OCR stack) and is unrelated to this diff.
• npm run verify:ui (focused) — the affected Chromium specs tests/ui-tools.spec.ts + tests/ui-phone-scroll.spec.ts pass 12/12 (hero pill on all standalone mode homes incl. the visible privacy notice, @critical composer presence, tablet hero, results dock unchanged, phone‑scroll geometry stable).
  • The environment's pinned Playwright browser build was not installed (only the older prebuilt Chromium is present), so the run used `PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH=/opt/pw-browsers/chromium` and was scoped to the affected specs rather than the full `test:e2e:pr` matrix. Worth a full `verify:ui` on CI.
• npm run verify:release — not run (release‑only).
• Retrieval / ranking / answer‑contract gates — N/A (no retrieval, ranking, selection, chunking, source/citation, or answer‑generation change).
• npm run check:production-readiness — not run: UI‑only composer placement. The only governance‑adjacent effect is the APP‑5 privacy notice becoming more visible on phone mode homes; no privacy/env/Supabase/governance logic changed.

Risk and rollout

• Risk: Low. Phone‑only (<640px) layout change to search‑composer placement on mode landing pages; desktop/tablet unchanged; no data, auth, or retrieval logic touched.
• Rollback: Revert this commit — restores the bottom‑dock behaviour.
• Provider or production effects: None.

Clinical Governance Preflight

• Source‑backed claims still require linked source verification before clinical use (unchanged)
• No patient‑identifiable document workflow was introduced or expanded (the APP‑5 "do not enter patient‑identifiable information" notice is now more visible on phone mode homes)
• Supabase target remains Clinical KB Database (sjrfecxgysukkwxsowpy) (unchanged)
• Service‑role keys and private document access remain server‑only (unchanged)
• Demo/synthetic content remains clearly separated from real clinical sources (unchanged)
• Source metadata, review status, and outdated/unknown‑source behavior remain conservative (unchanged)
• Deployment classification/TGA SaMD impact checked — no clinical decision‑support behaviour changed (UI placement only)

Notes

• The heroComposerBreakpoint="sm-up" value is now unused (the prop default is already "all"); the prop and its branch are left in place. Removing the dead path is optional follow‑up cleanup.

🤖 Generated with Claude Code

---

Generated by Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Improved standalone mode home layouts on phones and smaller screens.
  • The search composer now remains visible in the page content at all widths instead of appearing in a fixed bottom dock.
  • Removed unnecessary empty dock spacing while preserving appropriate content padding.
  • Search content now scrolls naturally with the page, while the header continues to collapse as expected.

[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]

📝 Walkthrough

Walkthrough

Standalone mode homes now keep the global search composer in-flow within the hero at all widths, including phones. Mobile reserve logic uses only idle content padding, while UI and unit tests verify the absence of a bottom dock and command dropdown.

Changes

Standalone mobile composer behavior

Layer / File(s)	Summary
Keep the composer in the hero at all widths src/components/clinical-dashboard/global-search-shell.tsx, tests/ui-tools.spec.ts, tests/ui-phone-scroll.spec.ts	Standalone hero rendering now applies at phone widths, with tests checking hero ownership, non-fixed positioning, absent footer dock, privacy visibility, and no universal command list.
Reserve only idle content padding src/components/clinical-dashboard/mobile-composer-reserve.ts, tests/mobile-composer-reserve.test.ts	Standalone mode homes now return the idle content pad instead of shell dock clearance, with updated unit expectations.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• BigSimmo/Database#473: Covers keeping home-page search in the hero and removing the phone command popup.
• BigSimmo/Database#964: Modifies the same standalone mobile composer breakpoint and reserve paths.
• BigSimmo/Database#899: Updates related mobile composer reserve and dock-padding behavior.

Suggested labels: codex

Suggested reviewers: cursoragent

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title is concise and accurately summarizes the mobile hero composer placement change on mode landing pages.
Description check	✅ Passed	The description follows the template and includes summary, verification, risk, governance, and notes with relevant details.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/mobile-search-bar-position-iwa5a8

---

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

[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.