Command palette

Build the command registry and the keyboard state machine that drives the palette. The registry is a flat map of `{id, label, action, keywords?, scope?}` with register/unregister at runtime so any feature can add commands. The palette opens/closes with ⌘K (and Ctrl+K on non-Mac), captures arrow keys to move the active item, Enter to run it, and Escape to close — all without the mouse. Focus is trapped inside the open palette (Tab cycles within it) and restored to the trigger element on close so keyboard users don't lose their place. The keyboard logic is a pure reducer `(state, key) → state` with no DOM access: selection wraps correctly in both directions, works with a single-item or empty list, and handles rapid key presses without dropping events. Prove it: open with ⌘K, navigate with arrows (including wrapping at boundaries), run with Enter, close with Escape, and show focus returns to the trigger — all in a headless test without a DOM.

Add fuzzy filtering where the ranking is a pure function `(items, query) → sorted items` with no side effects — no state mutations, no DOM, no async. Subsequence matching (every character of the query appears in order, not necessarily adjacent) is cheaper and more intuitive than Levenshtein: 'fc' matches 'fuzzyCheck' because 'f' appears before 'c', and scoring rewards prefix matches and contiguous runs while penalizing scattered matches and gaps (e.g. bonus for matching at word boundaries/camelCase initials). The function highlights matched characters, handles empty query (show all) and no-match (explicit empty state), breaks ties deterministically, and handles Unicode boundaries correctly. Its complexity is O(n·m) per item (n=query len, m=item len) and O(N·m log N) total — state it and justify it. Keep it separately testable in Node: same inputs → same output, so memoization is trivial and the rendering layer stays a thin view.

Support async action sources (e.g. a search API) alongside sync commands without race conditions. Two mechanisms matter: (1) debouncing — delay invoking the async source until the user pauses typing (150–250 ms) so you don't fire a network round trip on every keystroke; (2) cancellation — use AbortController to cancel the in-flight fetch when the next keypress fires before the previous result arrives, so a slow response from an earlier query never overwrites a faster response from a later one (the classic out-of-order race). The palette shows a loading indicator while an async source is in-flight, merges sync + async results through the same pure ranking function, and never shows stale results. Measure: with debounce 200 ms and simulated 300 ms vs 50 ms responses, prove the 300 ms result from query 'a' never overwrites the 50 ms result from query 'ab'.

Add scoping so a command can push a new context with its own filtered list — e.g. entering 'Switch project >' shows only project names, 'Theme >' shows only themes. Each scope is a stack frame `{query, activeIndex, results, breadcrumb}`; Enter on a scoping command pushes, Backspace on empty query (or a dedicated Back) pops, and breadcrumbs show the path (e.g. 'All > Switch project'). The keyboard reducer extends to handle scope push/pop as pure state transitions, and the ranking function re-runs against the scoped item set. Prove it: register a scoping command with 20 scoped items, enter it, filter within the scope, pop with Backspace, and show the breadcrumb updates and focus stays trapped. Document why scoping is a navigation model, not just a filter — it changes the item set, not just the query.

Make the palette accessible and fast at scale. Accessibility: correct ARIA — the input is `role=combobox` with `aria-expanded`, `aria-controls` pointing to the `role=listbox`, each item is `role=option` with `aria-selected`, and a live region (`aria-live=polite`) announces result count changes ('3 results' / 'No results') so screen readers don't miss updates. The focus trap from milestone 1 stays enforced. Performance: a list of 10,000+ commands must render without jank — virtualize so only the 8–12 visible rows plus a small overscan buffer are in the DOM, keeping the DOM constant-size regardless of list length. The tradeoff is scroll-position bookkeeping complexity; for lists under ~200 items virtualization overhead exceeds benefit, so measure before adding it. Benchmark: render 10k commands and record INP/keystroke latency with and without virtualization, and record memory for pre-indexed (trie/inverted index built once on registration, per-keystroke sub-linear) vs brute-force ranking. Justify the choice with numbers.