[feature] the app answers a right-click, and remembers where you have been

[yui0303]

Closes #338.

The app did not answer the two things a hand reaches for without thinking. A right-click anywhere in the tree or the library did nothing at all, and there was no way back to where you just were — every navigation overwrote the last one.

What changed

A right-click works. ui/context-menu.tsx wraps Radix's ContextMenu using dropdown-menu.tsx's styling class for class, so the app has one menu look rather than two. Radix's context menu ships in the radix-ui package already depended on, so this adds nothing to package.json.

• Folder rows offer Rename and Delete; the section headers and the empty space below the tree offer New folder.
• Recording cards offer Open, Rename, Move to folder (a submenu listing the same targets as the existing move popover, current folder disabled and check-marked) and Delete.

In both places the menu calls the paths that were already there — the same useLibraryTree operations behind the hover icons, the same onRenameStart / onMove / onDelete props on a card. It is a second way in, never a second implementation. Two rules that had been written twice, cardCapabilities() and moveTargets(), are now shared between the toolbar and the menu.

Back and forward. There is no router here; screens change by writing appMode in the store, so a navigation used to overwrite the previous position rather than stack on it. nav/history.ts keeps a capped stack of Location values — home, a library selection, or a recording — bound to ⌘[ / ⌘← and ⌘] / ⌘→ and to the mouse's side buttons.

CommandPalette.activate() was already a complete "go to this location" switch, so it was extracted as navigateTo(location) and both the palette and traversal now go through it. One implementation of "go there" is the point; two would drift.

A shortcut registry. lib/shortcuts.ts gives every window-wide shortcut one shared listener, one platform-correct mod modifier, and — the property the whole thing stands on — one implementation of "not while the user is typing". A global ⌘[ that fires while the caret sits in a rename field navigates the window out from under a half-typed name. ⌘K moved onto it.

Two shortcuts deliberately stayed where they are, and the code says why: zoom (lib/zoom.ts) is installed before React mounts and runs in windows that never render an AppShell; ⌘F (ReplayTranscript) is scoped to one panel and must keep working while its own find field has focus.

Three things a reviewer should look at

1. Deleting a recording still does not ask. Tracing remove() in LibraryScreen through deleteHistoryEntry / deleteCloudRecording / deleteOrgRecording finds no confirmation anywhere; the only globalThis.confirm() calls in src/ are the two folder deletes in useLibraryTree. The card's hover trash icon has always deleted on one click, and the menu matches it rather than growing a prompt only one of the two entry points has.

That consistency is correct and the behaviour is not. A context menu opens under the cursor with Delete a single click away, which makes an already-unguarded destructive action markedly easier to hit by accident. Adding a confirmation belongs on both entry points at once, in its own change — flagging it here because this PR is what makes it urgent.

2. Keyboard invocation is reasoned, not executed. macOS has no context-menu key and WebKit does not synthesise contextmenu from Shift+F10, so openMenuFromKeyboard dispatches a real bubbling MouseEvent — the only thing Radix listens for. The test suite runs in plain Node with no jsdom and no component-testing path, so this was verified by reading Radix's source rather than by running it. It wants a manual check in the running app, along with onCloseAutoFocus={preventFocusRestore}: without that line Radix restores focus off a freshly mounted rename input, the input's blur handler commits the untouched draft, and Rename silently does nothing.

3. Not every navigation is in the stack yet. Only navigateTo call sites are recorded, so sidebar clicks, exitReplay and the history-list open are still invisible to back/forward. locationOf in CommandPalette.tsx shows the mapping; routing the rest through navigateTo is the obvious follow-up.

Two constraints in the traversal are worth reading rather than trusting: a running meeting owns the window and the store refuses mode changes while one is active, so a refused navigation must not enter the stack, and a deleted recording must be dropped rather than throw. refused and unavailable are kept distinct for exactly that reason — collapsing them to a boolean would let one active meeting drain the whole stack.

Not in this PR

The long tail the registry exists to make cheap: ⌘F promoted to app level, arrow-key movement through the tree, Enter to open, F2 to rename, ⌘N, Delete.

Checks

bunx tsc --noEmit clean · bunx vitest run 33 files / 373 tests green, 21 of them new (shortcuts.test.ts, nav/history.test.ts) · bun run build succeeds.

The menus themselves are untested: there are no existing tests for AppSidebar.tsx or LibraryCards.tsx and no component-test harness to add them to. Standing up jsdom and a testing library is its own change.

[github-actions]

✅ SonarQube Quality Gate passed — pathorsAI_parley

0 open issues on this PR.