Redesign documents search results header chrome

[BigSimmo]

Summary

• Restructures documents search results chrome so the identity header ("N documents / Results for ...") leads, Sort and type filters share one compact toolbar with a chip-sized Library action, removes "Also in your library" from documents search, and places scope/governance notices below that chrome.
• Services/forms keep the governance notice above the panel; document home still offers Browse library as a start action.

Verification

• npm run verify:pr-local — runtime, format, lint, typecheck, build, and RAG fixtures passed on PR head. Full unit suite locally: 2948 passed / 2 failed in tests/pdf-extraction-budget.test.ts (Python/PDF env artifact; identical on clean main; hosted Unit coverage green).
• Focused Playwright: documents search @critical, deferred source/admin @critical, and forms result-sort URL persistence — all passed.
• npm run check:design-system-contract, check:icon-scale --strict, check:maintainability-budgets — passed.
• UI verification not run: full verify:ui suite deferred; focused Chromium smoke for the redesigned documents controls passed locally and hosted Production UI remains the broader UI gate.

Risk and rollout

• Risk: low–medium UI/UX — documents results chrome, sort/filter toolbar, and governance-notice placement only. No retrieval scoring, migrations, auth, or answer-generation changes.
• Rollback: revert the PR commit; UI returns to the prior overview card + cross-mode strip layout.
• Provider or production effects: None.

Clinical Governance Preflight

• Source-backed claims still require linked source verification before clinical use
• No patient-identifiable document workflow was introduced or expanded without explicit governance approval
• Supabase target remains Clinical KB Database (sjrfecxgysukkwxsowpy)
• Service-role keys and private document access remain server-only
• Demo/synthetic content remains clearly separated from real clinical sources
• Source metadata, review status, and outdated/unknown-source behavior remain conservative
• Deployment classification/TGA SaMD impact was checked when clinical decision-support behavior changed

Notes

• Final review fixed Prettier CI failure, unified toolbar a11y/density, and a memo-busting empty-array default for governance warnings.
• Updates stale leftover PR_POLICY_BODY.md from fix: resolve bottom layout spacing, remove info page footer search, and fix unit test regression #932 so CI syncs an accurate ready-for-review body for this PR.

[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

@cursor[bot], you've reached your PR review limit, so we couldn't start this review.

Next review available in: 1 minute

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

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 Plus

Run ID: b6a590f3-1ca8-4df5-99a5-d0d1da83b29d

📥 Commits

Reviewing files that changed from the base of the PR and between 7d83c28 and fd559a0.

📒 Files selected for processing (3)

• docs/branch-review-ledger.md
• src/components/ClinicalDashboard.tsx
• tests/ui-smoke.spec.ts

📝 Walkthrough

Walkthrough

Document search rendering now uses dedicated result controls, conditionally displays scope and governance notices, removes cross-mode links from document mode, and passes document-specific scope data. Smoke tests cover filtering, sorting, result controls, and the source library dialog.

Changes

Document search workspace

Layer / File(s)	Summary
Document controls and prop contracts src/components/clinical-dashboard/document-search-results.tsx, src/components/clinical-dashboard/search-results-header-band.tsx	Adds document result controls for type tabs, sorting, and library access; adds scope and governance-warning props; supports compact sort labels and shared icon sizing.
Workspace rendering and governance wiring src/components/ClinicalDashboard.tsx, src/components/clinical-dashboard/document-search-results.tsx	Removes cross-mode links from document mode, passes document-only scope data, conditionally renders governance notices, and reorganizes headers, facets, controls, and results.
Document workspace smoke validation tests/ui-smoke.spec.ts	Validates document controls, optional table filtering, URL-backed sorting, expected content, and opening and closing the source library dialog.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Possibly related PRs

• BigSimmo/Database#497: Modifies the same document-search smoke test with additional document-link assertions.
• BigSimmo/Database#501: Changes cross-mode links rendering related to their removal from document mode.
• BigSimmo/Database#560: Refactors shared URL-backed sorting used by the affected document results components.

Suggested labels: codex

Suggested reviewers: claude

🚥 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 accurately summarizes the main UI change to the documents search results chrome.
Description check	✅ Passed	The description follows the template with summary, verification, risk, governance preflight, and notes filled in.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch cursor/documents-search-header-3eab

---

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

[github-actions]

CI triage

CI failed on this PR. Automated classification of the 2 failed job(s):

• Production UI — needs investigation: inspect the failing step and uploaded diagnostics; rerun only after classifying the cause.
• PR required — needs investigation: inspect the failing step and uploaded diagnostics; rerun only after classifying the cause.

Compared with main CI run #3627 (cancelled).

Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/components/clinical-dashboard/document-search-results.tsx (1)

992-1007: 🎯 Functional Correctness | 🔴 Critical | ⚡ Quick win

DocumentTagFacetRail can never be opened — the facet picker is gated behind an already-active facet.

DocumentTagFacetRail (the UI that lets a user pick a tag facet) only renders when activeFacetKeys.length > 0. But the only way to populate activeFacetKeys is toggleTagFacet, which is only invoked via this same component's onToggle prop. Since the component itself already returns null when groups.length === 0 (line 152), the extra activeFacetKeys.length > 0 gate serves no purpose except to make the picker permanently unreachable — users can never select their first tag facet from this control.

🐛 Proposed fix

         <>
-          {activeFacetKeys.length > 0 ? (
-            <DocumentTagFacetRail
-              groups={tagFacetGroups}
-              activeKeys={activeFacetKeys}
-              onToggle={toggleTagFacet}
-              onClear={() => setActiveFacetState({ query, keys: [] })}
-            />
-          ) : null}
+          <DocumentTagFacetRail
+            groups={tagFacetGroups}
+            activeKeys={activeFacetKeys}
+            onToggle={toggleTagFacet}
+            onClear={() => setActiveFacetState({ query, keys: [] })}
+          />
           {activeFacetKeys.length > 0 ? (
             <div className={cn(metadataPill, "min-h-8 w-fit max-w-full text-2xs")}>
               {sortedMatches.length} result{sortedMatches.length === 1 ? "" : "s"} after filters
             </div>
           ) : null}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/components/clinical-dashboard/document-search-results.tsx` around lines
992 - 1007, Render DocumentTagFacetRail whenever tagFacetGroups are available,
rather than gating it on activeFacetKeys.length, so users can select their first
facet; keep activeKeys, onToggle, and onClear wiring unchanged. Retain the
separate activeFacetKeys check for the filtered-results metadata pill.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@src/components/clinical-dashboard/document-search-results.tsx`:
- Around line 992-1007: Render DocumentTagFacetRail whenever tagFacetGroups are
available, rather than gating it on activeFacetKeys.length, so users can select
their first facet; keep activeKeys, onToggle, and onClear wiring unchanged.
Retain the separate activeFacetKeys check for the filtered-results metadata
pill.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: a5aeea3f-495b-4e34-85de-5e3f8fba1d7e

📥 Commits

Reviewing files that changed from the base of the PR and between 27db15c and 7d83c28.

📒 Files selected for processing (4)

• src/components/ClinicalDashboard.tsx
• src/components/clinical-dashboard/document-search-results.tsx
• src/components/clinical-dashboard/search-results-header-band.tsx
• tests/ui-smoke.spec.ts