Fixed TUI tab naming to correspond to the web client.

[BobDickinson]

Closes #1779

Summary

• Rename TUI monitoring tabs to match web: Messages → Protocol, HTTP Requests → Network, Logging → Console
• Reassign accelerators so each is a unique letter in the tab name (Protocol p, Network n, Console o; Prompts moves to m so Protocol can take p; Connect keeps c)
• Underline the accelerator mid-word in the tab bar; update pane headers and TUI README

Test plan

• npm run ci
• Manually: open TUI, confirm tab bar shows Protocol / Network / Console
• Manually: p / n / o switch those tabs; m opens Prompts; c still Connect on a disconnected stdio server

[BobDickinson]

@claude review

[claude]

Claude finished @BobDickinson's task in 3m 35s —— View job

---

Review: TUI tab naming alignment (#1780)

• Read the diff
• Verify accelerator wiring in App.tsx / tabsConfig.ts / Tabs.tsx
• Cross-check labels against the web client
• Run the TUI suite + coverage gate
• Post review

Verdict: looks good — no correctness issues found. A few small suggestions below, plus one process item.

---

What I verified

Naming matches web. clients/web/src/components/views/InspectorView/InspectorView.tsx:214 defines MonitorTab = "Tasks" | "Logs" | "Protocol" | "Network" | "Console", and the comment at :210-212 confirms Console is stdio stderr and mutually exclusive with Network. The three TUI renames map onto exactly the right web tabs:

TUI id	old label	new label	web equivalent
messages	Messages	Protocol	Protocol (JSON-RPC) ✅
requests	HTTP Requests	Network	Network (fetch traffic) ✅
logging	Logging	Console	Console (stdio stderr) ✅

No stale hardcoded keys. The accelerator map in clients/tui/src/App.tsx:1306-1317 is built from tabsConfig, so the rebinds are data-driven; I grepped src/ and found no leftover "l"/"h"/"m" literals for tab switching. c/d (App.tsx:1422,1427) are handled after the accelerator chain and are not in the tab map, so no collision — the o choice for Console is doing real work.

Tests + gate pass locally (had to npm install in clients/tui first):

• npx vitest run → 282 passed / 25 files
• npx vitest run --coverage → 96.2 stmts / 93.07 branch / 96.53 funcs / 96.6 lines, per-file ≥90 gate clean.

This also settles the thing I'd have worried about with a mid-word split: Tabs.test.tsx's toContain("Console") passes, so ink-testing-library frames are ANSI-stripped and the three-chunk <Text> doesn't fragment assertions. Nested <Text underline> inside the tab's styled <Text> renders inline, so wrapping/flexShrink behavior in the tab bar is unchanged.

---

Suggestions (non-blocking)

1. splitLabelAtAccelerator fallback underlines a letter that isn't the accelerator — clients/tui/src/components/Tabs.tsx:14-15

if (idx < 0) {
  return { before: "", accel: label.slice(0, 1), after: label.slice(1) };
}

When the accelerator isn't in the label, this underlines the first character anyway, telling the user a key that won't work. Unreachable with today's config (and the new invariant test keeps it that way), but a silent-lie fallback is worse than no underline. { before: "", accel: "", after: label } degrades honestly. Fix this →

2. The new invariant test doesn't guard the constraint the doc-comment cites — clients/tui/__tests__/tui.test.ts:40-46

The doc-comment in tabsConfig.ts:18-19 says Console uses o because c/d are the global Connect/Disconnect keys — but the test only asserts intra-tab uniqueness and label containment. A future rename could quietly take c back and break connect from every tab with all tests green. One more line encodes it:

for (const tab of tabs) {
  expect(["c", "d"]).not.toContain(tab.accelerator.toLowerCase());
}

Fix this →

3. m for Prompts is the one rebind that breaks existing muscle memory. Every other change moves a key that was already changing. An alternative that leaves Prompts alone: Prompts keeps p, and Protocol takes l (Protocol — the only free letter in that word), with Network=n / Console=o unchanged. That's 3 changed keys instead of 4. Trade-off is real though — a trailing underlined l is much less discoverable than a leading P, and the current scheme reads better in the tab bar. Your call; just flagging that the swap is the most surprising part for existing users.

4. clients/tui/README.md Navigation doesn't list the accelerators at all. Since this PR changes four of them, a one-line key list under Navigation would make the new bindings discoverable outside the tab-bar underline (which is easy to miss on terminals that don't render underline well). The Features section update looks right otherwise.

5. Minor cohesion nit: splitLabelAtAccelerator is pure logic exported from an Ink component file, tested from tui.test.ts (which otherwise only imports tabsConfig). tabsConfig.ts is arguably its natural home — that's where the label/accelerator invariant lives, and Tabs.tsx would just consume it. Coverage-neutral either way (vitest.config.ts now includes the whole React surface). Take it or leave it.

---

Process

This PR is missing the v2 label. Per AGENTS.md, PRs targeting v2/main must carry it (issue #1779 has it; the PR has none):

gh pr edit 1780 --add-label v2

Closes #1779 is correctly the first line — remember it won't auto-close on v2/main, so close #1779 and move its board card to Done manually on merge.
· branch v2/tui-polish

[BobDickinson]

That was the nitpickiest PR review I've even seen. I'm taking zero of that feedback. The point was to make a small fix to change the naming only as we are close to a release, which I did.

@cliffhall - Ready for your review and merge.

[cliffhall]

That was the nitpickiest PR review I've even seen. I'm taking zero of that feedback. The point was to make a small fix to change the naming only as we are close to a release, which I did.

@cliffhall - Ready for your review and merge.

Adding the accelerators to the clients/tui/README.md might be helpful.

[cliffhall]

LGTM! 👍