fix-wg-owns

Metadata

Description

## Description
wg's chat persistence (implement-tmux-wrapped, commit ce6ca245a) wraps each chat in a tmux session. Tmux has its own config (status bar, status colors, mouse mode, etc.) but wg has its own desired state for those settings. Currently wg sets these at session-creation time (`spawn_via_tmux` in pty_pane.rs) but never re-asserts.

User framing 2026-04-29: 'to assert the settings from the host so it can be changed while the tmux is running?'

The right architectural pattern: **wg owns the desired tmux-session state. wg re-asserts that state whenever it could drift.**

## Scope

### A function: `sync_tmux_settings()`
Reads wg's current desired state for tmux sessions:
- `status off` — bar hidden (current default; future: themed)
- Mouse mode (per fix-mouse-wheel-3 outcome — depending on whether we let tmux handle wheel or claim it ourselves)
- Status-style colors (when fix-tmux-status's option B / theme-aware bar lands later)
- Any other knobs we add later

Iterates every `wg-chat-*` tmux session and applies the desired state via `tmux set-option -t <session> <key> <value>`. Idempotent.

### Hook points
Call `sync_tmux_settings()` from:
1. **TUI startup** — at the orphan-sweep hook (`fn ensure_user_coordinator` in state.rs:13294, same place implement-tmux-wrapped sweeps orphans). Subsumes fix-tmux-status-2's scope (existing pre-fix sessions get the bar disabled on next startup).
2. **Theme toggle** — when the user flips dark/light theme in the TUI, push the new theme's tmux palette to all sessions immediately.
3. **Future settings changes** — any user-controllable knob that affects tmux gets a sync call when changed.

## Why this is the right shape
- Single source of truth: wg's settings code
- Self-healing: tmux drift gets corrected on next sync
- Composable: adding a new tmux-relevant setting later means adding one line to sync_tmux_settings, not threading through every callsite
- Subsumes fix-tmux-status-2 (existing sessions retroactively get status off — abandoned that narrower task in favor of this)

## Validation
- [ ] Failing test: pre-existing tmux session with status bar on; TUI startup; ASSERT `tmux show -t <session> status` returns 'off'
- [ ] Failing test: theme toggle while TUI running with active chat sessions; ASSERT all wg-chat-* sessions reflect new theme palette (when option B lands; for now, just status-off remains constant — but the framework is in place)
- [ ] sync_tmux_settings() is idempotent — running twice produces no change
- [ ] sync_tmux_settings() is no-op on non-wg-chat-* sessions (don't mess with the user's own tmux work)
- [ ] No regression: implement-tmux-wrapped's persistence + orphan-sweep still work
- [ ] Live smoke: kill TUI, modify a wg-chat-* session manually (e.g. `tmux set -t wg-chat-X status on`), restart TUI, confirm the manual change is reverted
- [ ] cargo build + cargo test pass
- [ ] cargo install --path . was run before claiming done

Depends on

• done .assign-fix-wg-owns

Required by

• (none)

Log

• 2026-04-29T21:06:00.503634894+00:00 Task paused
• 2026-04-29T21:06:19.472913513+00:00 Task published
• 2026-04-29T21:06:51.737155824+00:00 Lightweight assignment: agent=Careful Programmer (f5143935), exec_mode=full, context_scope=graph, reason=Careful Programmer with proven track record (0.78 score, 352 tasks) best fits this correctness-critical tmux integration fix requiring idempotent state management, regression testing, and live smoke validation across multiple components.
• 2026-04-29T21:06:51.828484829+00:00 USER ARCHITECTURAL INSIGHT 2026-04-29: 'and the chat have pids in the .wg right? so we can see when they're there. just like tasks really. finally they are merging back.' User pointing out that chat tasks and worker tasks are converging architecturally: - Both are graph entities with task ids (.chat-N for chats, regular IDs for workers) - Both have PIDs tracked in .wg/ (registry.json, surfaced by wg agents) - Both are spawned via the same handler dispatch (claude/codex/nex) - Both surface in wg agents output This is the right framing for sync_tmux_settings discovery: **read chat sessions from the GRAPH state, not from `tmux list-sessions`.** Why this matters: - Graph is authoritative source of which chats SHOULD exist - tmux list-sessions catches everything including orphans (those should be killed by orphan-sweep, not sync'd) - Reading from graph also naturally extends as chats become more task-like — `wg list --type chat` could become the discovery mechanism REVISED IMPLEMENTATION: - sync_tmux_settings() should iterate the graph's active chat tasks (read from registry / chat metadata wherever it lives) - For each, compute the expected tmux session name (matches spawn_via_tmux's session_name format) - Apply current desired tmux state via `tmux set-option -t <name> ...` - If a chat task is in the graph but its tmux session doesn't exist (e.g., user killed tmux manually), log a warning but don't crash — the chat will be respawned next time the user opens it - Stays composable with the orphan-sweep which goes the OTHER direction (find tmux sessions that DON'T match a chat task and kill them) These two routines together (sync + orphan-sweep) are dual: - sync: 'every chat task should have a correctly-configured tmux session' - orphan-sweep: 'every wg-chat-* tmux session should correspond to a chat task' Both run at TUI startup. Together they keep the graph and tmux in lockstep.
• 2026-04-29T21:06:59.627990711+00:00 Spawned by coordinator --executor claude --model opus
• 2026-04-29T21:07:11.972280197+00:00 Starting work: investigating pty_pane.rs spawn_via_tmux and TUI startup orphan-sweep
• 2026-04-29T21:11:04.554195595+00:00 USER OBSERVATION 2026-04-29: 'the scrollback seems kind of limited. Maybe it's just limited to the one I reattached. Now it's governed by tmux. And not an actual log file or whatever.' The user is correctly noticing that tmux scrollback is bounded (default ~2000 lines) AND ephemeral (dies with session). The durable record is the JSONL chat-history file at `~/.wg/chat/<ref>/*.jsonl` — but tmux doesn't replay it. ADD TO sync_tmux_settings desired-state list: - `history-limit 100000` (or whatever generous default makes sense) This is a runtime-applicable tmux option (`tmux set-option -t <session> history-limit 100000`) that increases the per-session ring buffer. Doesn't help replay-on-reattach (that's a separate, harder problem) but at least keeps the visible scrollback long enough to be useful for the lifetime of an active chat. Other possibly-relevant tmux options to consider including in the desired-state set: - `mode-keys vi` (consistent navigation when entering tmux's copy mode for scrolling) - `escape-time 0` (responsive escape-key handling — relevant if any vendor CLI uses Esc shortcuts) - `destroy-unattached off` (probably already off; ensures the session survives detach for our persistence model) Implementer: add these as initial desired-state entries with sensible defaults; make the set easy to extend as we discover more knobs that need wg's opinion. NOTE on the deeper fix (replay JSONL into tmux on reattach): out of scope for this task. If user wants 'reattach shows the full conversation', file as a follow-up — it requires writing the JSONL contents into the tmux pane via control-mode, which is more complex and orthogonal to the settings-sync framework.
• 2026-04-29T21:20:37.660459662+00:00 Implementation complete: added apply_session_options + sync_chat_session_settings in pty_pane.rs, sync_chat_tmux_settings + chat_tmux_session_prefix on App in state.rs. Hooked into ensure_user_coordinator (TUI startup) and tui.color_theme config-edit handler. spawn_via_tmux now re-asserts on every spawn (not just create). 5 new tests pass: status revert, idempotency, scope-non-matching, no-match noop, reattach reassert.
• 2026-04-29T21:21:18.011310594+00:00 Committed: e4e7e9708 — pushed to remote
• 2026-04-29T21:21:31.444546349+00:00 Task pending eval (agent reported done; awaiting `.evaluate-*` to score)
• 2026-04-29T21:23:14.861153781+00:00 PendingEval → Done (evaluator passed; downstream unblocks)