fix-nex-tui

Metadata

Description

## Description
Verification task verify-fix-nex found the A fix still fails canonical steps 12-13. Against the live lambda01 endpoint with qwen3-coder, the TUI can create a nex chat, receive the first 'hi' response, receive a follow-up response, exit, restart, and reattach the .chat-1 tab with prior conversation visible. After restart, sending a new prompt displays the user prompt in the reattached [PTY] pane but no model response appears, even with a 90s wait. This blocks implement-generalize-chat/B.

Evidence from verify-fix-nex: permanent tests/smoke/scenarios/tui_nex_chat_end_to_end.sh passed, but manual canonical add-on failed twice at step 13. Pane showed 'remembered verify-nex-2087b' from before restart and then '> What token did I ask you to remember? Reply with only the token.' with no assistant response.

## Validation
- [ ] Reproduce the post-restart no-response failure with wg tui + nex + lambda01/qwen3-coder
- [ ] Fix the reattached TUI nex PTY/session path so a post-restart message gets a response from prior context
- [ ] Add or update a permanent smoke scenario to cover canonical steps 7-13, including post-restart message response
- [ ] cargo install --path . before live validation
- [ ] Live smoke PASSes against https://lambda01.tail334fe6.ts.net:30000 with model qwen3-coder

Depends on

• done implement-nex-chat
• done .assign-fix-nex-tui

Required by

• done implement-generalize-chat

Log

• 2026-05-03T22:11:35.786790595+00:00 Lightweight assignment: agent=Careful Programmer (f5143935), exec_mode=full, context_scope=task, reason=Careful Programmer is the best fit for this correctness-critical TUI/nex session state debugging task requiring code fixes, test coverage, and live validation.
• 2026-05-03T22:11:38.590150005+00:00 Spawned by coordinator --executor claude --model opus
• 2026-05-03T22:11:48.316199588+00:00 Starting investigation: post-restart no-response in nex TUI
• 2026-05-03T22:13:04.992910230+00:00 Reading prior fix; key concern: argv 'wg nex -m -e' has no --chat or --resume so each invocation creates a FRESH UUID session. tmux preserves nex process across TUI restarts but I need to verify why post-restart prompts go unanswered.
• 2026-05-03T22:37:50.354605242+00:00 Reproduced: second message in nex TUI chat shows no response in TUI pane, BUT inner tmux session has the response. Bug is the TUI pane's vt100 view going stale, not nex itself failing. Root cause: pty_pane reader thread advances bytes_processed counter BEFORE parser.process; main loop's chat_pty_has_new_bytes/update_task_pane_byte_watermarks race can update the watermark to the new counter value while the parser still holds the old screen, never re-firing a redraw once the parser catches up. Fix: increment bytes_processed AFTER parser.process so watermark advance is gated on screen state actually being current.
• 2026-05-03T23:25:26.099086911+00:00 Validated: cargo build pass; cargo test --release --bin wg pass (3376 tests); new bytes_processed_never_outpaces_parser unit test pass; live smoke tests/smoke/scenarios/tui_nex_chat_post_restart_response.sh PASSes against lambda01/qwen3-coder for the canonical 13-step user flow including post-restart message + rendered reply (the original verify-fix-nex blocker).
• 2026-05-03T23:25:26.170262315+00:00 Manual repro before fix: short-reply prompts (e.g. 'reply with one character') consistently showed the bug — inner tmux session had the model's reply, TUI's rendered chat pane stayed at the user prompt with no reply visible. After fix: same prompts show the reply in the rendered TUI pane within seconds. Pre-restart and post-restart both verified.
• 2026-05-03T23:26:32.371356439+00:00 Committed: cb30d1da5 — pushed to remote branch wg/agent-2090/fix-nex-tui.
• 2026-05-03T23:26:46.879446905+00:00 Task pending eval (agent reported done; awaiting `.evaluate-*` to score)
• 2026-05-04T00:54:23.787598794+00:00 PendingEval → Done (evaluator passed; downstream unblocks)