test(tools): repair the three assertions the tools mockup spec had stale on main

[BigSimmo]

Summary

Repairs the three assertions in tests/ui-tools-search-mode-mockup.spec.ts that were stale on main.

Measured on a clean origin/main worktree with no PR applied, the spec reported 2 failed | 14 passed. Because Advisory UI is not in pr-required's needs list, it could not block anything — it simply went red on every UI PR in the repo, which is worse than a blocking failure: it trains reviewers to ignore the lane. It was reported against #2095 (a mockup-only change that cannot reach the tools surface) and against #2096, and diagnosing it twice is what prompted this.

Two unrelated changes had moved under the spec:

• The seeded Compare query now matches two tools, not one. The Clinical Dictionary (feat(dictionary): add the eight-route Dictionary reference mode #2096) lists compare among its keywords and sits in the reference area, alongside Differentials in assessment. Confirmed against the catalogue rather than assumed — rankToolRecords("Compare") returns Clinical Dictionary [reference] | Differentials [assessment]. The desktop count assertion and the All tools (n) radio name follow from that.
• The filter sheet reports " tools", not " showing", since the catalogue toolbars were standardised in feat(ui): standardize catalogue toolbars, wire dose & footer provenance, and update adoption proofs (#039, #235, #267) #2086. That accounts for three assertions.
• The sheet's confirm control is labelled from its live summary — View 2 tools — and only falls back to Done when there is no summary (result-filter-control.tsx). It is now targeted by the stable tools-search-filter-sheet-done test id, so this assertion cannot break again when a result count changes.

Every replacement value was read from the running page through a temporary probe that dumped the sheet's inner text and each radio's accessible name. Nothing here is inferred from the diff.

Verification

• node scripts/run-playwright.mjs --project=chromium-mockups tests/ui-tools-search-mode-mockup.spec.ts — 16 passed, against 2 failed | 14 passed on the same worktree before the change.
• npm run ensure first, per the repo's browser-work rule; the run used the isolated production Playwright build.
• Prettier clean.

Not run, with reason: lint, typecheck and the unit suite. The diff is four assertion lines in one Playwright spec — no source, config or type surface is touched, so none of those gates has a failure path here. CI runs them anyway.

Risk and rollout

• Risk: Low, and it is the kind that matters in the safe direction — this makes a test assert what the product actually renders. No product code changes.
• Rollback: revert this PR's squash commit; the lane returns to failing on every UI PR.
• Provider or production effects: None.

Notes

• Tracked as an outstanding-issues entry queued during the feat(mockups): linked Caring Contact suicide-prevention prototype #2095/feat(dictionary): add the eight-route Dictionary reference mode #2096 review; it is reconciled into the ledger by docs(issues): reconcile seven queued requests into the outstanding-issues ledger #2110.
• Worth knowing for the future: because this lane is advisory, nothing forced anyone to notice the drift. If it goes red again after this, the assertions are worth quarantining per the flake-ledger rules rather than leaving it permanently failing.

[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: 52 minutes

Limit details: You’ve used all 1 included review currently available under your plan. You completed 102 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 @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: d83e172c-ab54-4331-8c43-58458b4b3f61

📥 Commits

Reviewing files that changed from the base of the PR and between 2a4ac2e and fbe365a.

📒 Files selected for processing (2)

• docs/branch-review-records/9c83ebb18e9d5bf0c5a2f2840eccad03527562a9d96d800d1cdf6b970eaa126a.record.md
• tests/ui-tools-search-mode-mockup.spec.ts

---

_{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.

[github-actions]

CI triage

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

• Unit coverage — 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 #12010 (success).

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