Keyboard-driven operation

Now I have a thorough picture. Here's what exists today: **No centralized keymap or hotkey library.** No `react-hotkeys`, no `useHotkey`, no central registry. Keyboard handling is scattered as ad-hoc `window.addEventListener("keydown", ...)` and `onKeyDown` props. **Cmd+K — the only app-wide shortcut.** Currently handled exclusively inside `spec-editor.tsx` (lines 94-101): it toggles `specPickerOpen` (a `SpecPicker`/`CommandDialog`). Only works when the spec editor route is mounted, because the `useEffect` lives in the spec editor component. The Topbar shows "⌘K" as a label on the "Specs" nav button and calls `openSpecPicker()` on click — which dispatches a custom `zenorm:open-spec-picker` event that the spec-editor picks up via `useSpecPicker`. **Existing keyboard interactions (all scoped to focused input areas):** - `⌘+Enter` to submit: capture box, chat pane, comments on block/task focus pages, spec content pane - `Escape` to close/dismiss: editing title, inline editing, dependency picker, tree-node editing, question cards - Question cards: keyboard-driven entirely when focused — `A/B/C/D` picks an option, `Enter` confirms recommended, `Esc` skips. This is the one keyboard-forward interaction pattern in the product. **What happens outside the spec editor:** Dashboard home (`/dashboard`) and projects (`/dashboard/projects`) have zero keyboard shortcuts. The specs listing page and settings page also have none. No keyboard navigation between pages, no shortcut to create a spec, no way to navigate the topbar, no search available outside the editor. **The product architecture:** React + React Router (lazy routes, code-split by page), shadcn/ui components, `cmdk` library (`@opensource/command-k` style command palette) already imported and used for the SpecPicker but with no "commands" — it's only a spec search list. Now — you said "keyboard-driven operation of the product, not one dialog" and "my hands are already on the keyboard." I need to understand the scope. That's the lay of the land. Key findings: - **No hotkey library**, no central keymap. Every shortcut is ad-hoc `addEventListener` or `onKeyDown`. - **Cmd+K** opens the spec picker, but only when the spec editor component is mounted. The Topbar also calls `openSpecPicker()` which dispatches a custom event. - **The only other keyboard interactions** are focused-input patterns (⌘Enter to submit, Escape to dismiss, A/B/C/D on question cards). - **`cmdk` (command palette library)** is already in the dependency tree and used by the SpecPicker, but today the palette shows only spec search + "Create new spec" — no commands, no actions. - **Zero shortcuts exist** on the Board, Projects, Settings, or specs-list pages. No keyboard page navigation. What's missing: a real, app-wide keyboard system that covers navigation between pages, creating specs, the question workflow, and whatever else you reach for.

Good call. Cmd+K becomes the universal palette. The spec picker keeps its search + navigate behavior as one mode of the palette. Noted. The thing I'm most worried about: **input-focus conflicts.** Today there are at least six text-entry surfaces in the app — capture box, chat pane, block editor (TipTap), comment inputs on block/task focus pages, inline editing on tree nodes, and the rich text content pane. If I register a global `keydown` listener for Cmd+K that doesn't check `event.target`, typing Cmd+K to cut text in any of those will open the palette instead. The current question-card handler has the right guard pattern (`if (target.tagName === "INPUT" || ...) return`). The existing spec-editor Cmd+K handler does NOT have this guard — it's the first line inside `useEffect` with no target check — which only works today because the spec editor's own content fields are inside TipTap which stops propagation. So the question: One way to think about it: Cmd+K inside a text field is an unusual keystroke to begin with — it's not a standard text-editing shortcut in the way Cmd+C/V/X are. The main casualty would be Mac text substitutions or input-method toggles where the user happens to hit K with a modifier. But the cost of getting it wrong is making the product feel "broken" in a way users blame on the app, not their keyboard.

Clear, detailed constraint. Captured. Let me write up what's decided and what still needs pinning down. Good, blocks committed. Now let me score intent — the input-focus decision is captured, but the first open question (what specifically needs keyboard operation) is still unanswered and the palette's command set is undefined. Intent scores 0.65 — the safety constraints are solid but the actual command set is undefined. Let me resolve the scope. I've asked the concrete question about command scope. The answer determines whether v1 is narrow (navigate + find specs) or broad enough to eliminate the multi-click pain you started with.

Clear scope. Capturing the navigation-only palette and the explicit non-goals. The PM explicitly stated this. Let me rephrase to match their exact language. Good, committed with an advisory (non-blocking). Let me score intent now — the scope is locked, non-goals are captured. Intent is done at 0.9. Moving to acceptance per your instruction — let me define the checkable criteria, starting with the typing case you asked for. Acceptance criteria committed. Let me score the section. Acceptance is done at 0.9. Let me close constraints too. All three sections pass. One demoable capability — the universal palette — covers all ACs. Let me create the task. Task created. Now building the full trace graph. Description too long when enriched with AC titles. Let me trim it. Spec complete. Here's the final picture: --- **Summary**: Central keymap and universal command palette (Cmd+K) on every dashboard route. Palette subsumes the old route-limited spec picker. All shortcuts are modifier chords, inert inside text inputs. Existing question-card single-key shortcuts are preserved. **3 goals**: universal Cmd+K palette, keyboard-driven navigation/search, discoverable keymap source. **6 constraints**: - Modifier chords only (no bare keys) - Inert inside text inputs (text input always wins) - Palette subsumes spec picker (it's one mode, not a separate dialog) - Backward compatible with existing ad-hoc listeners (not replacing them in v1) - Navigation and search only in the palette (no destructive actions) - No configurable key bindings or plugin commands **6 acceptance criteria**, each Playwright-assertable — including the one you asked for: focus input, send Meta+K, assert no dialog appears. **1 task** — the whole capability as one coarse slice: create `lib/keymap.ts` with a global keydown gate that skips shortcuts when focus is in an input/textarea/contentEditable; mount a Cmd+K handler at the dashboard layout root (so it works on Board, Specs, Projects, Settings); extend the current `CommandDialog` to offer page-navigation commands alongside the existing spec search (grouped by project with type badges); remove the spec-editor-specific Cmd+K binding.