feat(tui): ctrl+p operator menu, and ctrl+g chords to jump straight there

[plombeer31]

Stacked on #170 — base is valeryb/tui-menu-registry, so the diff here is only the menu. Merge #170 first and this retargets to main cleanly.

Why

Manage → Privacy was fourteen Tab presses from chat, and the fourteen destinations plus every verb were discoverable only by reading the source. This is the browsable half, rendered entirely from the registry #170 landed.

What it does

ctrl+p opens a menu above the prompt, on the prompt's own left rail rather than as a full-screen takeover — it should read as belonging to the input you were already typing in.

╭──────────────────────────────────────────────────────────╮
│ Menu  ❯ █                                                │
│ GO                                                       │
│ ▸ Run                                           ctrl+g r │
│   Toggle debug pane                                      │
│   Observe →                                              │
│   Manage →                                               │
│ SESSION                                                  │
│   New session                                   ctrl+g n │
│   Switch session…                               ctrl+g u │
│ ↓ 10 below                                               │
│ ↑↓ move   → open   enter go   type to search   esc close │
╰──────────────────────────────────────────────────────────╯

(captured from the built TUI in a real PTY, not a mockup)

Typing flattens the tree. Hierarchy is for browsing; a query ranks across the whole registry, drops whatever submenu you had walked into, and puts a breadcrumb on each hit. That is why the list moves on arrows only and never j/k — the letters belong to the search box.

ctrl+g then a key jumps directly. The leader is the point: the chord namespace stays disjoint from the panels' own letter hotkeys (r refresh, a add, d remove …), so nothing had to be renamed to make room. An unclaimed chord is swallowed rather than passed on, so a mistyped leader cannot leak a letter into the prompt or trip a panel hotkey.

Activation runs the node's slash command where it has one — the menu is a second door onto slash-command-handler.ts, never a second dispatch path. / keeps working unchanged.

The backdrop dims. One flag on the theme proxy — the same read-at-render machinery that makes /theme live-preview repaint everything — rather than threading a dimmed prop through every component. Every colour collapses to the active theme's muted, because a terminal has no alpha channel and "faded" has to mean one low-contrast tone. The menu reads chromeTheme, which ignores the flag. Measured against a real terminal: distinct foreground colours drop from 4 to 2 when the menu opens.

The Ink hazard this had to be built around

Ink delivers every keypress to every live useInput, child first. The prompt editor's handler therefore runs before the app's, and a return true upstream cannot stop it — the "returns true so the editor ignores it" contract in app-key-bindings.ts describes a mechanism that does not exist.

Left alone, ctrl+g t would navigate and type t into the prompt. The editor is unfocused while the menu is open and while the leader is armed, and there is a test asserting the letter never reaches the buffer:

it("ctrl+g then a chord jumps straight to a panel, and the chord letter never reaches the prompt")

Verification

• npm run lint clean.
• 14 new unit tests + 4 integration tests — open, search, submenu in and out, activation, key swallowing, paste bursts, escape-fragment rejection, the chord path.
• npx vitest run src/tui — same five pre-existing failures as main, plus two that pass in isolation and fail only under parallel load. No new failures.
• Driven in a real PTY at 100×30 against the repo's stub llama server: menu renders, search filters, ctrl+g t lands on Manage → Tasks, backdrop dims.

A bug this caught during development: the search box first accepted only single characters, so a paste — which arrives as one input event — was silently swallowed. It now takes a whole burst and rejects escape-sequence fragments per code point.

Not in this PR

? keys overlay, generated docs/KEYBINDINGS.md, and narrowing Tab to sub-tabs within a section. The Tab change is the only breaking one and stays separable on purpose.

[plombeer31]

Pushed 60320f2 — the menu is now a genuine overlay rather than an inline panel.

It was rendered in the content column, so opening it pushed the chat log and everything below it around. It now sits in the content pane with position="absolute", anchored to the pane's bottom edge so it still hangs off the prompt, and caps its own height to the rows the pane has.

Terminals have no compositing and Ink has no z-index, so occlusion is earned: every interior line is padded to the popup's exact inner width, painting spaces over whatever was beneath. Rows are fixed-width columns rather than flexGrow for the same reason — a flexed row stops at its content and lets the background through. Ink's paddingX is not painted by our rows either, and left a ragged column of debris down both edges; the gutter is baked into the padded strings now.

A backgroundColor would do this in one line, but only by picking a colour, and the TUI ships eleven themes across light and dark grounds. Spaces are theme-agnostic.

New test pins the property — opening the menu must not change the frame's row count or its last line:

it("floats over the UI without moving it — the frame below is unchanged")

Verified in a real PTY at 100×30: the splash art behind stays put, the prompt and hint strip do not move, and the popup shrinks around a search result instead of resizing the screen.

[plombeer31]

Pushed 3229cfd — the header menu is gone.

The Run · Observe · Manage pill row was a menu drawn into the header, and a poor one: it could only ever list three of the fifteen destinations and had no keys attached to it. ctrl+p now holds all of them.

What replaces it is a breadcrumb — Manage › Tasks — which is the one thing the popup cannot tell you, because you have to open it to read it. The tab half comes from the registry (menuPlaceByTab), so renaming a destination renames it in the header too.

Nine smoke tests were using the pill row as their way to detect the active section; they now assert the breadcrumb instead, and one asserts the pills are gone, which is the actual behaviour change.

Run modes (Local · Cloud · Fusion) in the menu are #172, stacked on this and on #163.

[sosidudku1]

The menu layer is solid — no new key handler is registered (handleMenuKey is a pure function called from the existing useInput), state resets fully on close, and routing through runSlashCommand means it inherits the palette's existing guards instead of adding a second dispatch path.

One blocker: resolveLeaderChord ignores modifiers, which makes Ctrl+C unreachable while the leader is armed.

export function resolveLeaderChord(input: string, key: Key): MenuNode | null {
  if (key.escape || input.length === 0) return null;
  return menuNodeByChord(input);   // key.ctrl / key.meta never consulted
}

Press ctrl+g, then change your mind and press Ctrl+C. Ink delivers input === "c" with key.ctrl === true, that resolves to go.manage.mcp, and the armed branch in app-key-bindings.ts:122 returns true unconditionally before the Ctrl+C handler is ever reached — so instead of aborting the turn, the app navigates to the MCP tab.

The same class hits ctrl+q → help.quit, which quits the app outright, and ctrl+l → go.manage.llm, where ctrl+L is the conventional clear-screen.

The fix matches a guard style already in the same file — isMenuOpenKey and isMenuLeaderKey both check key.ctrl && !key.meta && !key.shift, so this is just making the third function agree with its two siblings:

if (key.ctrl || key.meta) return null;

Smaller one: menuLeaderArmed has no disarm timeout, unlike the ctrlCArmed flag it's modelled on (which has a useEffect timer a few lines away). Since editorFocus includes !menuLeaderArmed, a stray ctrl+g leaves the editor unfocused indefinitely, and the next keystroke is swallowed — or, if it happens to be h, opens the theme picker. It does reset on that next key, so it's not a permanent wedge, but there's no timeout and no on-screen indicator that the leader is pending.

One process note: the head commit subject reads "status bar shows where you are, not a menu of where to go", which doesn't match the PR title. The branch may have been amended — worth confirming the intended head before merging.

[plombeer31]

Fixed in 279eec2.

Blocker — resolveLeaderChord ignoring modifiers. It now returns null when key.ctrl || key.meta, matching the guard its two siblings in the file already use. That alone was not enough, though: the armed branch in app-key-bindings.ts swallowed everything it could not resolve, so ctrl+c would have been dropped instead of aborting. Swallowing is still right for a bare key (a mistyped leader must not leak a letter into the prompt), but a modified key was never aimed at the leader, so it disarms and falls through to the bindings below. Tests in app-key-bindings.test.ts: ctrl+c reaches the abort handler (onAbort + abort_requested), ctrl+q does not quit, ctrl+l is not claimed, a bare chord still activates, an unclaimed bare key is still swallowed, and Esc still cancels.

Disarm timeout. menuLeaderArmed gets a useEffect timer with the same shape and the same 1500 ms window as ctrlCArmed (MENU_LEADER_WINDOW_MS = CTRL_C_WINDOW_MS, so they cannot drift apart). Pinned by a tui-app.test.tsx case that arms the leader and then presses nothing at all — only the timer can clear it.

Pending indicator. In the hint strip, which is where transient key state already lives (ctrl+c → "press again to quit") and needs no room in the breadcrumb the header just became: [ctrl+g] waiting for a chord · [ctrl+p] full menu · [esc] cancel. It takes the whole strip while armed, ordered after the approval footer to match key precedence.

One thing I did not test: typing into the prompt right after the auto-disarm. Ink re-subscribes an editor's useInput in a passive effect one commit after the render that refocused it, so a keystroke that lands in that gap is dropped — reproducible in the harness under load, and the same race the comment in multi-line-editor.tsx already describes for the opposite direction. Out of scope here; the test asserts the indicator clears itself and that no chord fired on the way out.

Head commit. 3229cfd was the intended head before this fix — the subject reads oddly next to the PR title because the branch grew three commits: ac5e287 added the menu and the chords, 60320f2 made it a real overlay, and 3229cfd replaced the header pill row with a breadcrumb. New head is 279eec2.

npm run lint clean. npx vitest run src/tui/menu/ src/tui/app-key-bindings.test.ts src/tui/components/hotkey-hint.test.tsx src/tui/tui-app.test.tsx → 85 passed, 2 failed, both pre-existing on this branch without the diff ("returns to chat when Shift+Tab is pressed from the Run screen", "shows the two-mode LLM panel").