# Launcher protocol compatibility: real server proof

The driver launches the unmodified published Linux x64 executable from
`t3@0.0.46-nightly.20261003.2610` with `__service-launcher`. It creates fresh
isolated homes, runtime selection records and local runtime-cache entries. It
uses real HTTP authentication, WebSocket RPC, staged preflight, migrations,
launcher IPC, child replacement and durable update commits. It uses no tests,
mock services, copied user databases or provider turns.

Run the driver once with `before <base-checkout>` and once with `after <head-checkout>`.
Each checkout needs `vp i` and `vp run build:bundle` in `apps/server`.
The driver expects the extracted published executable at `legacy/package/t3`
beside itself. Obtain it from the `@t3code/t3-linux-x64` npm package at the version
above. It writes a new timestamped home on each run and stops its tracked launcher.

For the second head update, first build another head bundle with only the
`apps/server/package.json` version changed from `0.1.9` to `0.1.10`. Preserve that
bundle at `apps/server/dist-next`, restore the original package file, and keep
the unmodified-version bundle in `apps/server/dist`. This is a synthetic compatible
release; it is not a claim that version 0.1.10 is published.

The candidates are shell wrappers that exec the actual built CLI with inherited
IPC. They record command arguments without altering preflight or launcher messages.
Both candidates are cached before starting the launcher, so network download and
archive validation are outside this proof. The initial server is the published
nightly itself; the intermediate protocol-3 0.1.9 server from the report was not
available as an npm platform package (HTTP 404).

The driver requests `server.updateServer` with target 0.1.9. Base returns the
protocol-3/protocol-4 mismatch and keeps the original selection. Head commits,
starts serving and accepts an authenticated reconnection. The driver then requests
0.1.10, reconnects again and captures the committed state and both actual preflight
invocations naming protocol 3.

The old release's pairing session does not have the maintenance scope required by
the current server. Candidates therefore enable a preprovisioned reusable dev
credential for reconnection. This is prepared before launcher startup, not issued
with a host-shell command during the update. Continued authorization of the old
pairing session is not established by this proof.

The videos replay timestamped stdout captured from the driver at original speed.
The PNGs are rendered views of that same output, not screenshots of the web UI.
`render-recording.py` reproduces them from the timestamped JSON recordings with
ImageMagick and ffmpeg. Private raw startup logs and credentials are not published.

AI-assisted; verified with the tests and tools listed above.