fix(filters): resolve PR #1998 merge conflicts and required CI failures - #2025
Conversation
…ntract after main merge
…ests The filter overhaul rewrote these assertions to expect the tools hero composer visible at every width, but never changed the production composer-placement logic (ClinicalDashboard.tsx, global-search-shell.tsx) that deliberately keeps /tools on the phone footer dock per the documented contract in docs/search-chrome-behaviour.md. Restore the phone/desktop branching so the tests match shipped behaviour.
…nder the ClinicalDashboard line budget PR #1998 added a new inline callback (handleDocumentFiltersApply) that pushed ClinicalDashboard.tsx to 4146 lines, past the 4140-line no-growth budget check:maintainability-budgets enforces. Extract it into use-apply-filters.ts following the same pattern already used for useScopeFilterRelax — a hook module beside the component instead of inline growth. Pure extraction, no behaviour change.
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 94 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 (61)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
CI triageCI failed on this PR. Automated classification of the 4 failed job(s):
Compared with main CI run #11281 (cancelled). Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger. |
…arget and layout-transition ratchets check:design-system-contract regressed on this PR's head: - favourites-command-library-page.tsx's new 'Recently used' toggle used bare min-h-10 (40px) on every viewport instead of the file's own min-h-tap ... sm:min-h-10 pattern, dropping below the 48px phone tap floor. - result-filter-control.tsx's new coverage progress bar animated width directly (transition-[width]), which is a real layout-thrash risk the ratchet exists to catch; switched to the scaleX(...) + origin-left pattern already used by ui/progress.tsx and DocumentManagerPanel.tsx. Both are genuine fixes to new code from #1998, not baseline bumps.
Summary
codex/filter-system-overhaul) forward, merged cleanly onto currentmain, with the specific fixes needed to satisfy the requiredpr-requiredCI aggregate:mainindocs/design-system/COMPONENTS.md,docs/design-system/adoption-manifest.json, andsrc/components/ui/sheet.tsx(kept theheaderRef/headerHidden/data-sheet-headerheader-collapse attributes that landed onmainvia feat(guide): pin guide chrome controls to shared scroll-hide behavior #2007 after feat(filters): implement clinical result filter overhaul #1998 branched).npm run design-system:design-sync:update,generate-design-system-adoption.mjs --write) socheck:design-sync-contractand thedesign-sync-contract/design-sync-visual-exportsunit tests pass again — they were failing withdtsPropsFor must be generated from source public Props typesbecause the merge left the generated artifacts stale relative tosheet.tsx.tests/ui-tools.spec.ts: feat(filters): implement clinical result filter overhaul #1998's first commit rewrote several assertions to expect the/toolshero composer visible at every viewport width, but never changed the production composer-placement logic inClinicalDashboard.tsx/global-search-shell.tsx, which deliberately keeps/toolson the phone footer dock per the documented contract indocs/search-chrome-behaviour.md("Tools directory... Compact bottom dock on phones; in-flow hero composer fromsm"). Restored the phone/desktop branching in the 4 affected tests to match the shipped, documented behaviour instead of changing production code on a protected search-chrome surface.handleDocumentFiltersApplycallback out ofClinicalDashboard.tsxintosrc/components/clinical-dashboard/use-apply-filters.ts(mirroring the existinguseScopeFilterRelaxpattern) because feat(filters): implement clinical result filter overhaul #1998's addition pushed the component to 4146 lines, past the 4140-line no-growth budgetcheck:maintainability-budgetsenforces. Pure extraction, no behaviour change.mainafter this branch started (Add outstanding-issues row-staleness fingerprint checks #2009, a URL-regex assertion robustness fix in the same test file).Verification
npm run verify:pr-local— see below (ran the constituent gates directly: full unit suite, typecheck, lint, design-sync/adoption/maintainability-budget checks, targeted + fullui-tools.spec.tsChromium Playwright run, and a cleanrm -rf .next && npm run build)npm run verify:ui— rantests/ui-tools.spec.ts(95/95 passed) against a clean production build with--project=chromium, including the 4 tests that were failing in feat(filters): implement clinical result filter overhaul #1998's CI (Production UI (3))npx vitest run— 635 files / 6771 tests passed, 4 skippednpx tsc --noEmit -p tsconfig.json— cleannpx eslinton all changed files — cleannode scripts/check-design-sync-contract.mjs— passes (54 components, 7 guidelines)node scripts/generate-design-system-adoption.mjs --check— passes (54 components, 59 roots)node scripts/check-maintainability-budgets.mjs— passes (ClinicalDashboard.tsx: 4136/4140 lines)npm run format— clean, nothing to reformatRisk and rollout
ClinicalDashboard.tsxextraction, which is a pure refactor (same logic, moved to a hook module) — verified by the unchangeddocument-filter-panel.dom.test.tsx/medication-prescribing-workspace.dom.test.tsxsuites and typecheck/lint. Thesheet.tsxconflict resolution keeps both features (existing header-collapse frommain+ this PR's filter-sheet changes) with no logic removed on either side.Clinical Governance Preflight
Notes
main, plus the fixes above needed to pass the requiredpr-requiredchecks (static-pr,coverage,production-ui) that were failing on feat(filters): implement clinical result filter overhaul #1998's head. feat(filters): implement clinical result filter overhaul #1998's own branch was left untouched (per this session's branch policy) — recommend closing feat(filters): implement clinical result filter overhaul #1998 once this PR merges, to avoid duplicate/conflicting history.Advisory UI's one quarantined-lane failure (tests/ui-tools-search-mode-mockup.spec.ts— a@mockup"2 showing" filter-summary text assertion) is unrelated and non-blocking (not part ofpr-required); left as-is since it's outside this fix's required scope.Generated by Claude Code