Site-wide search

Generated from the grilling session at /grilling-transcripts/search. Kept short on purpose — every decision below traces back to a question the agent asked.

Problem

The site already has more artifacts than fit comfortably in the nav, and it will keep growing. Visitors should be able to find every prompt, transcript and PRD without clicking through the menu. Search has to exist before the corpus is too big to navigate by hand — i.e. now.

User stories

• As a visitor, I can type any word and see every artifact whose title, description or body contains it.
• As a visitor, I can refine with multiple words — all of them must match, in any order.
• As a visitor, I can see at a glance how many results I have, and click any one to open it.
• As a visitor on a phone, the search field is reachable and usable without scrolling.

Non-goals

• Fuzzy matching (typos, stemming). Wait for evidence anyone needs it.
• Search analytics. Out of scope, possibly forever.
• Filters by kind (prompt vs transcript vs PRD). Three categories is too few to justify a filter UI.
• Global nav entry. Discoverable from /demos/search only for v1.

Acceptance

• Typing “grill” returns at least one result whose body contains “grill”.
• Empty query lists every item.
• No matches shows the literal copy “No matches.” — nothing else.
• All search terms are whitespace-separated and must all match (AND).
• Search payload bundle stays under 200 KB. Above that, move to server.

Tracer bullets

1. Bundle a flat JSON of all three collections at build time from getCollection calls in the page’s frontmatter.
2. React island with an input and a filtered list, autofocus on mount.
3. Wire /search to load the JSON and render the island.

Each bullet is independently testable. The first one is reviewable without any UI; the third one without any real data.