naps62-yoloandClaude Opus 4.7
7814ca99de
ci / rust (push) Failing after 1m45s
`SessionManager::create` used to call `tmux new-session` (which exec's the user's command immediately), run an async `PtyBridge::start_with_replay` (mkfifo + open + spawn reader), then issue a *separate* `tmux pipe-pane`. Any output the child wrote between exec and that third tmux subprocess landing went into the pane but never into the FIFO. Hit in NAP-252 dogfood: `bash -c 'echo X; exec bash'` sessions showed only the trailing prompt, never the X. Two changes: 1. New `Tmux::new_session_piped(id, cwd, cmd, sink)` chains `; pipe-pane -t maestro-<id> <sink>` into the same tmux command argv as `new-session`. Within a tmux command chain, `pipe-pane` is processed immediately after `new-session` returns — before the child has finished `execve` — so the FIFO is wired up before the first write. 2. `SessionManager::create` now builds the FIFO + reader task **before** spawning the session, then calls `new_session_piped` instead of the two-step `new_session` + `pipe_pane`. `Tmux::pipe_pane` and the standalone `Tmux::new_session` stay around — `recover()` (NAP-228) still needs a standalone pipe-pane re-attach, and some integration tests want a bare session without a pipe. Tests: - Unit: argv assertion that the chained `pipe-pane` follows `new-session` when a sink is supplied. - Integration: `create_captures_initial_output_in_replay_buffer` spawns `sh -c 'echo NAP_253_FIRST_LINE_MARKER; exec sleep 30'` and polls `subscribe_pty_with_replay` until the marker shows up in the replay buffer (or fails after 5s). Fails before the fix, passes after. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>