# Retry proof driver

Run each commit's unmodified web client in development mode with fresh isolated server state and T3CODE_DEV_SEED=0. Both captures used Chromium, a 1280×800 CSS viewport (2560×1600 screenshots), and the light theme. No agent turns were needed.

The server was run through that checkout's real serviceLauncher.ts, using protocol 3 and activeVersion 0.1.8 in the isolated service-state.json. The pinned 0.1.8 runtime executable was a shell wrapper that execs node <checkout>/apps/server/src/bin.ts with its original arguments. Its .install-complete sentinel contains 0.1.8. Thus the launcher starts the real source server over IPC, and same-version update rejection is real. It is not an installed OS service or a packaged Nightly binary.

Start the web dev runner with dev:web, an explicit isolated --home-dir and the server's port. Complete pairing and choose Start without an agent if onboarding appears.

Evaluate seed.js in the signed-in browser. It reads the actual connected environment and version, seeds only the failed update-run atom, and observes outgoing WebSocket requests without intercepting or changing them. No application source code or update responses are modified.

For the main paired recordings evaluate:

```js
retryProof.seed({providerFailure: 'Provider update failed: diagnostic retained', localVersion: '0.1.9'})
```

Record: wait 2 seconds; open the failed sidebar capsule; wait 2 seconds; click the sidebar Retry; wait 3 seconds; reopen the capsule; wait 2 seconds. Take two screenshots 600 ms apart and compare their hashes before retaining a still. The published detail images crop the same 800×320 lower-left region of the full screenshots.

Read `retryProof.read()` for the sanitized request/state transcript. On base, Retry sends server.updateServer for 0.1.8 and the real launcher rejects it. On head, no request is sent, serverTarget becomes null, the provider diagnostic is displayed, and localVersion remains 0.1.9.

Also exercised the same server-only seed on both commits (`retryProof.seed()`): base remains failed and retryable; head closes the run with no request. The supplied server-only recordings show that interaction.

A separate control on both commits (`retryProof.seed({targetVersion: '0.1.9'})`) sends one real update request for the newer target and retains the failed target when the release download returns HTTP 404. This verifies retry dispatch, not successful installation. It does not establish mixed-version selection within one run.

The failed-run state, provider diagnostic, and pending localVersion are synthetic fixtures. The original Nightly update/restart race and Electron's downloaded-update state are not reproduced.

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