research-nex-chat

Metadata

Description

## Description
graph.jsonl carries `\"endpoint\":\"https://lambda01.tail334fe6.ts.net:30000█\"` for chat-31 (the FULL BLOCK U+2588 cursor glyph appended to the URL). Other chats with the same endpoint are clean. Find where the cursor cell got captured into the value.

## Investigation scope (READ ONLY — no source mods)
- src/tui/viz_viewer/event.rs:1548-1559 (Endpoint AddNew field per-keystroke handler)
- src/tui/viz_viewer/event.rs:807-820 (paste handler routing)
- Hypotheses to test:
  1. Bracketed paste of own-rendered field captured the rendered cursor cell
  2. Kitty / iTerm cursor-position reporting (escape sequence) leaks into the input
  3. Tab-out-of-field / select-by-mouse copies the cursor cell glyph
  4. crossterm key event for the cursor block char itself (some terminals emit it)
- Reproduce: open `wg tui` against scratch dir, fill out new-chat dialog with focus on Endpoint, try various flows (Tab off, Enter submit, click outside, paste own value back via terminal-level bracketed paste).

## Deliverable (via wg log)
- Root cause: file:line of the path that introduces \"█\" into the value
- Concrete fix proposal: exact patch shape (filter chars > U+2500? strip cursor glyph in submit-handler? block bracketed paste of own UI? etc.)
- Repro script that produces the corruption deterministically (so the fix has a regression test)

## Validation
- [ ] Root cause cited with file:line
- [ ] Fix proposal is concrete (line-level, not architectural hand-wave)
- [ ] Repro script produces corruption pre-fix
- [ ] No source modifications in this task

Depends on

• done design-nex-chat
• done .assign-research-nex-chat

Required by

• done fix-nex-cursor-corruption

Log

• 2026-05-02T23:52:57.973432535+00:00 Task paused
• 2026-05-03T00:51:27.907168829+00:00 Task published
• 2026-05-03T00:53:26.155189726+00:00 Spawned by coordinator --executor claude --model opus
• 2026-05-03T00:53:42.609956175+00:00 Starting research: cursor-block U+2588 corruption in nex chat new-dialog Endpoint field
• 2026-05-03T00:54:02.178455983+00:00 Reading both Endpoint code paths: per-keystroke (1548) and paste (807). Will check render to find where '█' might come from
• 2026-05-03T00:54:30.094841703+00:00 Renderer at render.rs:7174 emits U+2588 as cursor cell. Looking for how add_endpoint persists to graph.jsonl
• 2026-05-03T00:59:27.765568966+00:00 RESEARCH COMPLETE — root cause + fix proposal + repro script. ROOT CAUSE (file:line) Two input paths in src/tui/viz_viewer/event.rs both push the U+2588 cursor glyph into launcher.add_endpoint with no filtering. They are siblings; the glyph then passes byte-clean through resolved_launch_args() → state.rs:14380-14383 (launch_from_launcher pushes --endpoint $ep verbatim) → wg service create-chat IPC → graph.jsonl. Every layer downstream of the field IS a byte-clean pipe (verified end-to-end in Part A of the repro: passing $'https://example.com:30000\xe2\x96\x88' to wg service create-chat lands as "endpoint":"https://example.com:30000█" in graph.jsonl). PRIMARY (most likely producer of chat-31): src/tui/viz_viewer/event.rs:807-818 — bracketed-paste handler for LauncherSection::AddNew(AddNewField::Endpoint). Filter is currently: let clean: String = text.chars().filter(|c| *c != '\n' && *c != '\r').collect(); This admits U+2588. The producing UX flow: the renderer at src/tui/viz_viewer/render.rs:7174 and :7190 paints the cursor cell as Span::styled("\u{2588}", ...) AFTER the typed text. If the user mouse-selects the visible Endpoint line in the terminal (drag-select, triple-click, block-select), the terminal copies the rendered cells INCLUDING the "█" cursor cell. Pasting that string back via terminal-level paste (Cmd+V, shift-insert, middle-click) reaches this handler verbatim and appends "█" to add_endpoint. trim() at state.rs:1482 does not strip it (U+2588 is not Unicode whitespace; trim only strips ws). SECONDARY (per-keystroke fallback path): src/tui/viz_viewer/event.rs:1552-1554 — KeyCode::Char(c) handler for AddNewField::Endpoint. Body: KeyCode::Char(c) if !modifiers.contains(KeyModifiers::CONTROL) => { launcher.add_endpoint.push(c); } Pushes any printable char unconditionally. Some terminals (urxvt, certain tmux setups) deliver paste as a stream of Char events when bracketed-paste mode is off, hitting this path instead of :807. crossterm does emit a KeyCode::Char for U+2588 if the byte sequence appears on the input pipe. Both paths affect the Model and Name fields too (event.rs:1540-1546 and :1564-1570; paste handler dispatch at :811, :814, :820), and all three fields render U+2588 cursor cells (render.rs:7123, 7136, 7174, 7190, 7224, 7237). Endpoint is the one that surfaced because it is the URL the user actually reads back — Model and Name are equally vulnerable. HYPOTHESIS TRIAGE H1 (bracketed paste of own-rendered field captured the cursor cell): CONFIRMED — only filter is \n/\r; U+2588 from terminal mouse-copy-paste survives. H2 (Kitty/iTerm cursor-position reporting leaks in): NOT REQUIRED to explain the observed corruption. CSI cursor-position replies are escape sequences (CSI digits R), not bare U+2588 bytes; they would land in stdin as Esc-prefixed key events that the launcher field handler discards via the `_ => {}` fallthrough at :1558. Not the producer. H3 (tab-out-of-field copies the cursor cell): Tab itself does NOT auto-copy anything; the user must explicitly drag-select. But this is a real flow: "user typed URL → tabbed to Name → mouse-selected URL line to verify it → tabbed back to Endpoint → terminal-pasted to fix a typo" reproduces H1. H4 (crossterm key event for U+2588 itself): TRUE in principle (crossterm decodes UTF-8 input and emits Char(U+2588) if the byte sequence arrives), but only relevant when bracketed paste is disabled — falls back into H1's sibling path at :1552. Conclusion: H1 is the realistic producer for chat-31, H4 is the sibling failure mode. Fix MUST cover both code sites — filtering only the paste path leaves the keystroke path corruptible on terminals without bracketed paste. CONCRETE FIX PROPOSAL (line-level) 1. Add a tiny helper near the top of src/tui/viz_viewer/event.rs (or as a free fn in src/tui/viz_viewer/state.rs near LauncherState): /// Reject characters that should never appear in a launcher text /// field: ASCII control chars, DEL, the Unicode block-element range /// (U+2580–U+259F — these are the cursor-cell glyphs the launcher /// renders for itself; allowing them lets a terminal mouse-copy + /// paste flow corrupt the field), and the Unicode line separators. fn is_safe_field_char(c: char) -> bool { !(c.is_control() || ('\u{2580}'..='\u{259F}').contains(&c) || c == '\u{2028}' || c == '\u{2029}') } 2. PATCH event.rs:807 (paste handler) — replace the existing filter: let clean: String = text.chars() .filter(|c| *c != '\n' && *c != '\r' && is_safe_field_char(*c)) .collect(); 3. PATCH event.rs:1552-1554 (Endpoint keystroke), :1540-1542 (Model keystroke), :1564-1566 (Name keystroke) — gate the push: KeyCode::Char(c) if !modifiers.contains(KeyModifiers::CONTROL) && is_safe_field_char(c) => { launcher.add_endpoint.push(c); } Why filter the whole U+2580–U+259F range, not just U+2588: ratatui ships block partial-cell glyphs (U+2596 ▖, U+2597 ▗, U+2580 ▀, U+2584 ▄ etc.) for half-cell cursors; if the cursor style is ever changed the same class of bug recurs. Filtering the range is one line and immune to the next round of UI tweaks. Out of scope for the fix but worth noting: the simpler "fix" of just trimming trailing U+2588 from add_endpoint at submit time (state.rs:1482) is brittle — a paste in the MIDDLE of the URL still corrupts. The fix has to live at the input edge. REPRO ARTIFACTS Written to .wg/research/research-nex-chat/repro.sh — two parts: PART A: runs `wg service create-chat --endpoint <U+2588-tainted URL>` against a scratch dir and asserts graph.jsonl carries the bytes verbatim. Verified on this branch — observed: "endpoint":"https://example.com:30000█" Proves downstream is a byte-clean pipe; the fix has to be at the input edge. PART B: prints a Rust unit-test snippet (two #[test] fns) that exercises both the bracketed-paste filter and the per-keystroke handler against the real LauncherState. The snippet is designed to drop into the existing #[cfg(test)] mod tests block in src/tui/viz_viewer/state.rs (next to add_new_with_nex_resolves_with_endpoint at ~line 25457). FAILS pre-fix, PASSES post-fix. The implementer of fix-nex-cursor-corruption should paste it in as the regression test. (Cannot ship as a tests/ integration test because src/tui is not pub-exported in lib.rs — verified.) VALIDATION - [x] Root cause cited with file:line — event.rs:807-818 (primary), :1552-1554 (secondary), state.rs:1482 (trim doesn't help), state.rs:14380-14383 (verbatim downstream pass-through). - [x] Fix proposal is concrete (line-level) — three patch sites + helper fn, no architectural hand-wave. - [x] Repro script produces corruption pre-fix — Part A confirmed live on this branch, output: "endpoint":"https://example.com:30000█". - [x] No source modifications in this task — only .wg/research/research-nex-chat/ artifacts written; src/ untouched (git status confirms).
• 2026-05-03T01:00:00.645739387+00:00 Validated: root cause cited (event.rs:807 + :1552), fix proposal concrete (3 patch sites + is_safe_field_char helper), repro deterministic (Part A live-reproduced corruption end-to-end through wg service create-chat → graph.jsonl), zero source modifications (git status: only .wg/ untracked).
• 2026-05-03T01:00:00.779014852+00:00 Task pending eval (agent reported done; awaiting `.evaluate-*` to score)
• 2026-05-03T01:03:03.758994166+00:00 PendingEval → Done (evaluator passed; downstream unblocks)