fix(search): show default cards on empty search state

[jcserv]

Intent

The developer wanted to fix a bug where the card search page at /search showed no cards when loaded with no query or filters. The fix required adding a getDefaultCards function in lib/search/card-search.ts that returns a cached sample of cards ordered by name, updating the SearchResults component in the search page to call that function when all filter fields are empty, and adding a UI label in SearchForm to communicate to users that they are seeing popular cards rather than filtered results. The developer also wanted to run the no-mistakes validation pipeline to verify and ship the change as a PR.

What Changed

• Added getDefaultCards to lib/search/card-search.ts — returns a cached alphabetical sample of 25 cards when no query or filters are active, replacing the previous empty-results state
• Updated app/(ui)/search/page.tsx to call getDefaultCards when all filter fields are empty, and updated app/_components/search/search-form.tsx to show a "Browse cards — search to filter" label (guarded against AI mode) instead of the earlier "Popular cards" label that misrepresented the alphabetical ordering
• Added 7 tests covering getDefaultCards behavior and the isDefault label guard

Risk Assessment

✅ Low: Round-1 fixes applied correctly: label renamed to "Browse cards — search to filter" and AI mode guard added; no new issues introduced.

Testing

Added 7 unit/component tests covering getDefaultCards (DB query, cache tag, null fallbacks, empty result) and the isDefault label in SearchForm (shows in simple mode, hidden in AI mode, absent without flag). All 2124 tests pass. Browser screenshot confirms the /search page loads 25 default cards and displays "Browse cards — search to filter" instead of the previous empty state.

• Evidence: Search page default state screenshot (local file: /var/folders/b2/rft4yv4177d6mpkbhbwj7svc0000gn/T/no-mistakes-evidence/01KWCBF8QXSCEVWDBTPRDZ8C5W/search-default-state.png)

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

🔧 **Review** - 2 issues found → auto-fixed ✅

• ⚠️ app/_components/search/search-form.tsx:237 - getDefaultCards uses ORDER BY c.name with no WHERE clause — it returns alphabetically-first cards, not popular ones. The function comment says 'representative sample', but user intent says 'popular cards'. The label should match the actual ordering (e.g. 'browse cards' / 'sorted by name') or the query needs a real popularity signal.
• ℹ️ app/_components/search/search-form.tsx:236 - The isDefault check should also be gated on initialMode !== 'ai'. Low-traffic edge case (requires ?mode=ai bookmark with no query), but the label is contradicted by the empty AI prompt state visible right below it.

🔧 Fix: rename label and guard default badge in AI mode
✅ Re-checked - no issues remain.

✅ **Test** - passed

✅ No issues found.

• pnpm test -- lib/search/__tests__/card-search.test.ts app/_components/search/__tests__/search-form.test.tsx — 2124 tests pass (7 new tests for getDefaultCards and isDefault label behavior)
• Manual browser screenshot of http://localhost:3099/search with no query — confirmed 25 results and 'Browse cards — search to filter' label rendered

✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.

[coderabbitai]

Warning

Review limit reached

@jcserv, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 53 minutes

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: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 6dfabdb1-973b-4494-a1b7-bc4f8f9f65af

📥 Commits

Reviewing files that changed from the base of the PR and between 8559708 and a650759.

📒 Files selected for processing (6)

• app/(ui)/search/page.tsx
• app/_components/search/__tests__/search-form.test.tsx
• app/_components/search/search-form.tsx
• docs/runbook/postgres.md
• lib/search/__tests__/card-search.test.ts
• lib/search/card-search.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fm/fix-search-default-r5

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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