e2e2session

Overview ¶

Command e2e2session starts ONE session on a running daemon and exits, so that scripts/pbe2e2-emulator-smoke.sh has something for the phone to observe, take control of and type into.

IT IS NOT PART OF THE PRODUCT AND MUST NEVER BECOME PART OF IT.

It lives under scripts/ rather than cmd/ deliberately. .goreleaser.yaml builds swarm, swarm-remote and swarm-relay from ./cmd; a fourth directory there would read as a fourth binary to a reader scanning the tree, and this one is a test fixture. `go build ./...` still compiles it, which is the point of keeping it in the module: a helper that stops compiling between demonstrations is a demonstration that cannot be repeated.

WHY IT EXISTS AT ALL, and why it is not a new verb. PB-E2E-2's five in-app actions all need a session to already exist on the machine, and this repository has no non-interactive way to create one: `swarm` is daemon|shim|hook|remote|version plus a TUI that refuses a non-terminal ("the TUI needs an interactive terminal"), and `swarm remote` has no launch. Adding one was ruled out at closure and the reasoning stands -- product surface added so a demonstration can be automated is how a demonstration stops being about the product.

So this speaks the daemon's EXISTING owner protocol, over the same UDS the TUI uses, and calls the same protocol.Client.Launch the TUI calls. The exit demonstration (internal/skeleton, TestPBE2E1) already drives that API from Go for the same reason. A session created here is indistinguishable to the daemon from one the TUI created: same LaunchSpec, same shim, same PTY, same registry row. Nothing about the phone's half is simulated, substituted or bypassed -- the smoke still drives the installed APK through its own controls, which is what PB-E2E-2 is about.

The smoke's own contract already expected this: SWARM_E2E2_SESSION_CMD is documented there as "the operator's" command. This is that command, checked in so the run is reproducible rather than depending on what a particular operator happened to type.