← graph

tui-still-cannot

TUI: still cannot select between multiple chats — tui-chat-tab merged but doesn't deliver chat-switching

Metadata

Statusdone
Assignedagent-694
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Created2026-04-27T14:50:29.713424496+00:00
Started2026-04-27T14:51:39.852833775+00:00
Completed2026-04-27T15:22:35.647527040+00:00
Tagseval-scheduled

Description

Description

User created .chat-2, .chat-3, .chat-4 etc. successfully (the wg chat create flow works). The TUI shows them. There's a blue highlight indicating which chat is currently focused. But there is NO WAY TO SELECT A DIFFERENT CHAT — no keystroke, no click, no menu. User stuck on whichever chat is shown by default.

User quote: 'we still can't actually select a different coordinator chat! the blue highlight is cool for showing us which one we're on. but we have no way to pick! lol. so we made a bunch of .chat-4 and so on but these are not available to us!'

tui-chat-tab (commit 5376ed69b, agent-227) supposedly addressed this — its spec said:

'Number keys (1-9) jump to chat tab N' 'Click on a tab in the tab bar switches to it' 'Ctrl-Tab / Ctrl-Shift-Tab cycle through tabs'

None of these work in the live TUI per user. Yet another false-done — agent claimed done without verifying user-visible chat-switching actually happens.

Repro

  1. wg service start && wg tui
  2. Create at least 3 chats: wg chat create --name a; wg chat create --name b; wg chat create --name c
  3. In TUI, observe tab bar / highlight: blue marks one chat
  4. Try EACH of these to switch chats: number keys 1/2/3, mouse click on tab, Ctrl-Tab, Ctrl-Shift-Tab, j/k, arrow keys
  5. Currently: NONE work to actually switch focus to a different chat

Required

At minimum ONE keyboard binding + click-to-switch must work. Recommended set:

  • Number keys (1, 2, 3, ...) jump directly to chat N
  • Click on a tab in the visible tab bar switches focus to that chat
  • (Optional) Ctrl-Tab / Ctrl-Shift-Tab cycle next/prev

Hard gate before claiming done

DO NOT claim done without literally:

  1. Open wg tui with at least 3 chats present
  2. Verify CURRENT focus by send 'hi' in chat (shown chat) — get response in that chat
  3. Press '2' (or click chat-2's tab) — focus visibly moves to chat-2
  4. Send 'hi' in chat-2 — verify response appears in chat-2 (NOT the previous chat)
  5. Verify by repeating with chat-3
  6. Capture as evidence: screenshots / screen recording / scripted test using synthetic key events that asserts the active chat changed

Without that exact end-to-end demonstration: do not call wg done.

Files likely to touch

  • src/tui/viz_viewer/state.rs — active-chat tracking, key handlers for number / arrow / Ctrl-Tab
  • src/tui/viz_viewer/event.rs — key event routing
  • src/tui/viz_viewer/render.rs — tab bar widget (currently shows chats but not interactive)
  • src/commands/tui_pty.rs — mouse event capture for tab clicks

Why this keeps happening

The agency evaluator (haiku) consistently scores tasks 0.7-0.85 based on 'tests pass + code looks reasonable' without verifying the actual end-user behavior. tui-chat-tab merged with this same blind spot. The smoke-gate-is task should fix this systemically; this bug is a concrete addition to the smoke manifest.

Validation

  • Failing test first: test_tui_number_key_switches_chat — synthetic '2' key press with 3 chats present → active_chat_index goes from 0 to 1 (or whatever index chat-2 is)
  • Failing test: test_tui_click_tab_switches_chat
  • Implementation makes tests pass
  • cargo build + cargo test pass with no regressions
  • HARD GATE manual smoke as above

Depends on

Required by

Log