Add per-view hotkeys, in-window-only by explicit decision (task #9)

New capability, not previously named anywhere in SPEC.md. Cmd+1
through Cmd+5 jump straight to a top-level view (Composition/Configure/
Activity/Runs/Spec, matching the sidebar's own order) via a plain
keydown listener in App.tsx calling the existing useAppStore setView --
no new navigation mechanism, reuses exactly what the sidebar's own nav
links already call.

Deliberately in-window-only, not a real OS-level golang.design/x/hotkey
registration the way per-workflow and summon hotkeys use (§3.4/§3.7):
registering these globally would mean checking each combo against
TriggerService's own claimed-combo conflict space, the same
bidirectional check the summon hotkey already goes through -- a bigger
design surface this pass intentionally didn't take on. The safer,
reversible default named directly in the session goal that built this.

Active regardless of which element has focus -- matches browsers'/
Slack's own Cmd+1-9 tab-switching precedent (Cmd+digit isn't a combo
real typing produces, so there's no need to scope it away from text
inputs). Verified directly, not assumed: a real e2e test confirms a
hotkey fires correctly even while a text field has focus.

Verified end-to-end via Playwright against the real server-mode
backend (view-hotkeys.spec.ts, run twice): all five hotkeys navigate
correctly from a cold start, checked against real existing markers
per view (Composition/Configure's own tablist aria-labels, Activity/
Runs' own h1 headings, Spec's own capability-index testid) rather than
new testids added just for this; a bare digit key without Cmd does
nothing. Full frontend check suite (tsc, eslint, boundaries, vitest)
clean. Documented in docs/SPEC.md §3.7.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYwojT8GdUbYSoggbvEFft

Author: alicoding

frontend/e2e/view-hotkeys.spec.ts

@@ -0,0 +1,49 @@
+import { test, expect } from '@playwright/test'
+
+// Real Go bindings over HTTP (Wails3 server mode), not mocks -- same
+// setup as the rest of this suite. Exercises task #9's in-window Cmd+1
+// through Cmd+5 view hotkeys (App.tsx), each checked against a real,
+// already-existing marker unique to that view rather than a new testid
+// added just for this test.
+
+test('Cmd+1 through Cmd+5 jump to their view from anywhere else in the app', async ({ page }) => {
+  await page.goto('/')
+
+  // Start on Composition (the default landing view) and confirm each
+  // hotkey lands somewhere else first, so a false positive (already
+  // being on the target view) can't hide a broken hotkey.
+  await expect(page.getByRole('tablist', { name: 'Composition' })).toBeVisible()
+
+  await page.keyboard.press('Meta+2')
+  await expect(page.getByRole('tablist', { name: 'Configure' })).toBeVisible()
+
+  await page.keyboard.press('Meta+3')
+  await expect(page.getByRole('heading', { name: 'Activity', level: 1 })).toBeVisible()
+
+  await page.keyboard.press('Meta+4')
+  await expect(page.getByRole('heading', { name: 'Runs', level: 1 })).toBeVisible()
+
+  await page.keyboard.press('Meta+5')
+  await expect(page.getByTestId('capability-index')).toBeVisible()
+
+  await page.keyboard.press('Meta+1')
+  await expect(page.getByRole('tablist', { name: 'Composition' })).toBeVisible()
+})
+
+test('A view hotkey works while a text field has focus, matching browser tab-switching precedent', async ({ page }) => {
+  await page.goto('/')
+  await page.getByTestId('new-workflow').click()
+  await page.getByLabel('Label').click()
+
+  await page.keyboard.press('Meta+3')
+  await expect(page.getByRole('heading', { name: 'Activity', level: 1 })).toBeVisible()
+})
+
+test('Plain digit keys without Cmd do not navigate', async ({ page }) => {
+  await page.goto('/')
+  await expect(page.getByRole('tablist', { name: 'Composition' })).toBeVisible()
+
+  await page.keyboard.press('3')
+  await expect(page.getByRole('tablist', { name: 'Composition' })).toBeVisible()
+  await expect(page.getByRole('heading', { name: 'Activity', level: 1 })).toHaveCount(0)
+})

frontend/src/app/App.tsx

@@ -11,6 +11,7 @@ import SettingsView from "../views/SettingsView";
 import PlaceholderView from "../views/PlaceholderView";
 import { CompositionService, CapabilitiesService } from "../../bindings/github.com/alicoding/mill";
 import { useAppStore, viewFor, viewsEqual, statusVariant } from "../shared/store";
+import type { View } from "../shared/store";
 import { COLOR_MODE_STORAGE_KEY, SIDEBAR_OPEN_STORAGE_KEY } from "./theme";
 import { CAPABILITY_ICON, SPEC_ICON } from "./navIcon";
 import styles from "./App.module.css";
@@ -47,6 +48,39 @@ function App() {
   // worth chasing further for a dev-convenience ribbon -- see SPEC.md.
   const [loadedAt] = useState(() => new Date().toLocaleTimeString());
 
+  // Per-view hotkeys (task #9, docs/SPEC.md §3.7) -- Cmd+1 through
+  // Cmd+5 jump straight to a top-level view, matching the sidebar's own
+  // order (Composition/Configure lead, Activity/Runs follow, Spec is
+  // always last). Deliberately in-window-only, not a global OS-level
+  // hotkey: this reuses plain browser keydown handling, the reversible/
+  // safer default named directly in the session goal that built this,
+  // distinct from TriggerService's real OS-level golang.design/x/hotkey
+  // registration (§3.4) that per-workflow and summon hotkeys use --
+  // registering these globally too would mean checking them against
+  // TriggerService's own claimed-combo conflict space, a bigger design
+  // surface this pass deliberately doesn't take on. Matches
+  // browsers'/Slack's own Cmd+1-9 tab-switching precedent: active
+  // regardless of which element has focus, not scoped away from text
+  // inputs, since Cmd+digit isn't a combo real typing produces.
+  useEffect(() => {
+    const VIEW_HOTKEYS: Record<string, View> = {
+      '1': { kind: 'composition' },
+      '2': { kind: 'configure' },
+      '3': { kind: 'activity' },
+      '4': { kind: 'runs' },
+      '5': { kind: 'spec' },
+    };
+    const onKeyDown = (e: KeyboardEvent) => {
+      if (!e.metaKey || e.ctrlKey || e.altKey || e.shiftKey) return;
+      const target = VIEW_HOTKEYS[e.key];
+      if (!target) return;
+      e.preventDefault();
+      setView(target);
+    };
+    window.addEventListener('keydown', onKeyDown);
+    return () => window.removeEventListener('keydown', onKeyDown);
+  }, [setView]);
+
   // Icon-rail collapse (narrow persistent strip, not full hide/show) is a
   // well-established pattern -- but Primer genuinely ships none of its
   // mechanics. Checked exhaustively, not assumed: grepped @primer/react's