# Service update backup ordering proof

Run on Linux ext4 with Node 26.12.1. Each side is the built CLI from its own commit, with an isolated fresh T3 home. The synthetic project and conversation are created through the real CLI and replay provider; no existing userdata is read.

Build each checkout with `vp i`, then `vp run --filter t3 build:bundle`. Run `python3 record.py before <base-checkout>` and `python3 record.py after <head-checkout>`. Requires Python 3, Xvfb, GNOME Terminal, D-Bus and ffmpeg. The recorder uses 1280x800, the same terminal appearance, and live driver output on both sides.

The driver uses the real service launcher and real HTTP server. The active executable shim preloads an IPC request sender, then executes the built CLI. After a real completed replay conversation, it sends the launcher's normal request-update message to a staged deliberately failing candidate. The database path is symlinked, with the WAL beside the target. The filesystem is ext4 and cannot reflink the database. A PATH shim pauses the actual main-file cp invocation for eight seconds, then runs /usr/bin/cp with the original arguments. All other cp invocations pass through unchanged. HTTP probes use /.well-known/t3/environment every approximately 250ms.

This controlled gate demonstrates ordering; it does not measure copy throughput. Base stops serving before cp; head keeps serving until the main copy finishes. The recordings then show a candidate failure and rollback to a serving server. The CLI reads the conversation before and after; the driver compares all message records and checks SQLite integrity.

Not exercised: Settings Update server, operating-system service installation, a successful published candidate, a multi-gigabyte database, checkpoint pressure and sustained concurrent writes. No unit tests are used as evidence.

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