414d282a

test: e2e — auto-start arcs (proxy + pty), muxd stop teardown, pins bumped

a73x   2026-08-10 19:05

test: e2e — auto-start arcs (proxy + pty), muxd stop teardown, pins bumped

Two scenarios, one per auto-start call site, each ending in `muxd stop`:
the verb under test is also the teardown, and the trap only backstops it.

The proxy arc attaches over `--via "muxd proxy --sock SOCK14"` with
nothing serving that path, so the attach itself has to produce the
daemon. It pins the cold shape (`muxd proxy: starting…`, a pid on the
up-line, that pid alive), then a warm attach that must print NO spawn
progress and must reach the SAME daemon — asserted by the pid as well as
by the marker, because "a second daemon would have started a fresh
shell" is a fact a reader should not have to derive. Teardown is stop's
own pins: `muxd: stopped`, the socket gone, and the daemon OBSERVED dead
by polling `kill -0` on the tracked pid rather than believing the
command's claim. Then the idempotence control — stop with nothing there
is exit 0 and says `nothing listening on <sock>`.

The pty leg runs local `mux --sock SOCK15` under the M12 fixture with
PATH prefixed by the build dir, so findInPath must resolve exactly the
muxd under test. `mux: starting…` proves it did; the up-line's pid gives
this daemon a handle too, which the plan had assumed the suite could not
have, and stop's death is observed here the same way.

Three shape adjustments, all of them following the suite rather than the
plan's sketch:

  the pty script opens on `expect \x1b[?1049h` before the first `send`,
  as every M12 leg does. The client takes the tty raw with TCSAFLUSH
  (client.zig:520), which DISCARDS input queued before it got there —
  and on this leg that window is a whole cold spawn wide, so a leading
  `send` would be typing into /dev/null.

  the marker is printed as `printf 'pty-%s\n' auto`, and the detach
  waits on `settle 500`, not on the marker. tp2a's two rules: a marker
  must not appear in the line that produces it, and the last thing
  waited for must not be the output, because a shell writes its result
  and its next prompt as two separate writes and a capture that stops
  between them diverges from a grid that is correct.

  the fixture's own output goes to `> LOG 2>&1` behind `set +e`/`RC=$?`,
  the tp2a/tp2b shape, so a fixture failure is reported with its exit
  code and its tail rather than aborting the run bare. The plan's
  `2> LOG` would have left the fixture's stdout unredirected.

Two smaller ones: `|| true` on both `--via` invocations, for the reason
the M6 --via scenario carries it (set -e would abort on the client's
status before the labelled diagnostics print), and the warm-silence grep
is written in the suite's negative-control shape at :460 — `grep -q … &&
{ fail; }` with no trailing `|| true`, which is correct under set -e
because a failing command that is not the last of an AND-list does not
trip it.

Pin arithmetic. Scenarios 13 → 15: one `ok` per scenario, two added.
Convergence points 25 → 28, not the 27 the plan predicted:
assert_converged increments once per CALL, and the proxy arc makes two
of them — the cold attach's capture and the warm attach's, which are
different captures of different grids and neither is redundant — plus
one for the pty leg. 25 + 2 + 1 = 28, and 28 is what the run reports.

Verified: `make e2e` → `e2e OK (15 scenarios, 28 convergence points)`;
`SOAK_N=10 make soak` → 10/10 green. After both, `ps -eo comm` shows no
muxd, mux, or ptyclient process, and no muxd-e2e-*/mux-e2e-* files are
left in /tmp.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>