fix(navigation): keep focus and search context when seeding the home mode

[BigSimmo]

Summary

Follow-up to PR #1744 (merged as a503c22), which made / the single mode-routed home page. Three changes, each its own commit:

• Keep focus=1 and the scope/queryMode context when seeding the home mode.useHomeModeSeed rewrote a cold / visit with appModeSelectionHref(lastAppMode) and nothing else, so a visit to /?focus=1 — or to / carrying scoped-search context — silently lost the requested composer focus and the scope on the replaceState. It now parses the incoming params with readSearchNavigationContext and carries focus, queryMode, scopeFilters and scopeRef through the rewrite, matching what (search-app)/page.tsx and medications/page.tsx already do. This was the one genuinely outstanding CodeRabbit finding from feat(navigation): one shared home page, mode-routed search #1744; the other three it raised were already fixed on main, verified rather than assumed (sitemap:check passes, and the drift manifest reports sanctionedPatternsPresent: [] for the medications route).

• Repoint that hook's contract test at behaviour instead of an exact string.tests/search-route-ownership.test.ts pinned the old single-line replaceState call verbatim. It now pins the two things that actually matter — replaceState rather than pushState (no history entry per mode seed), and the carried navigation context. Its fixed 1800-character slice window is also gone in favour of slicing to end of file: that window had already silently stopped covering the effect once the hook's doc comment grew, so the assertion was passing against a region that no longer contained the code under test.

• Three docs/outstanding-issues.md rows, deduped against the existing 140 open items. New #285 records that this web container runs Node 24.13.0 while jsdom@30.0.1 requires ^24.15.0, so npm ci cannot complete under engine-strict. New #286 records that tests/pr-handoff-stop.test.ts fails on a clean checkout of main in this container, which reads as a false regression to any session that runs the full unit suite here. The third is an update to existing #255, described below.

The #255 update is a self-correction

#255 already carried a stop rule: "do not point executablePath at the mismatched 1194 build to force a green browser run — a browser gate run against the wrong revision is not evidence." The session that prepared PR #1744 did exactly that, and quoted the resulting 406 passed, 2 failed into that PR's body as browser evidence. CI's Production UI jobs did pass on correct binaries, so the change merged in #1744 is genuinely proven — but by CI, not by that local run. The ledger row now records this as a third reproduction, along with the two contributing causes: the tooling's own preflight actively recommends the override, and the prohibition lives only in the ledger rather than in docs/testing.md where a session would look for it.

Verification

Run on this exact tree, before npm run format was committed:

• npm run lint — clean, 0 problems
• npx tsc --noEmit — clean
• Full offline unit suite — Tests 1 failed | 5710 passed | 4 skipped (5715). The single failure is tests/pr-handoff-stop.test.ts, which is the pre-existing container-specific failure this PR records as #286; it fails identically on a clean checkout of main.
• npm run check:maintainability-budgets — Maintainability hotspot budgets passed
• npm run check:outstanding-issues — passed, 284 rows … unique ids
• npm run format — run, and the result committed

UI verification not run: this container's Playwright/Chromium revisions are mismatched (#255), and forcing a green run by pointing executablePath at the wrong build is the exact anti-pattern this PR documents — a browser gate run against the wrong revision is not evidence. Browser proof is delegated to CI's Production UI jobs, which run against correct binaries. That is what #255 prescribes.

npm run verify:pr-local was not run as a single command: it fails closed on the same npm ci floor recorded in #285. The gates it would have selected for this scope — lint, typecheck, the full unit suite, format — were each run directly and are listed above.

Risk and rollout

• Risk: Low, and confined to the cold-/ seeding path. The changed hook only runs when the URL names no mode and no query, and the change strictly adds parameters to a URL it was already rewriting; it cannot make the rewrite fire in a case where it did not fire before. The remaining two commits are a test and documentation.
• Rollback: git revert 51fc832 restores the previous single-argument replaceState, and reverting the test commit alongside it restores the old assertion. The ledger rows are append-only documentation and need no rollback.
• Provider or production effects: None. No Supabase, OpenAI, or hosted-CI call was made from this session, and no provider-backed gate was run.

Notes

RAG impact: no retrieval behaviour change — the diff touches only a client-side URL-seeding hook, its contract test, and a documentation ledger. No file under src/lib/rag/**, clinical-search, retrieval-selection, ranking-config, answer-ranking, the eval harness, or the golden fixture is modified. This line is stated for the record; classifyPullRequestFiles reports ragRanking: false for this file set, so the declaration is not gate-required here.

## Clinical Governance Preflight is omitted deliberately: classifyPullRequestFiles reports clinicalRisk: false for these three paths. use-home-mode-seed.ts sits under src/components/clinical-dashboard/ but matches none of the access-control, privacy, patient-data, or upload/download patterns that make a presentation surface clinical-risk — the classifier's own comment calls out that living in the clinical-dashboard tree is not itself a trigger. Verified by running evaluatePullRequestPolicy against this body and file list rather than inferred.

---

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:53 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: b75095da-3002-45be-bd29-14f1b8bd40ff

📥 Commits

Reviewing files that changed from the base of the PR and between b877421 and 7393205.

📒 Files selected for processing (4)

• docs/branch-review-ledger.md
• docs/outstanding-issues.md
• src/components/clinical-dashboard/use-home-mode-seed.ts
• tests/search-route-ownership.test.ts

---

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