# Conditional Retry reproduction

Both recordings show the real web app, built by Vite from separate unchanged checkouts, connected to real source servers through the real service launcher. Environment: Linux x64, Chromium, light theme, 1280x800 CSS viewport (device scale factor 2). Videos show the same lower-left 400x240 CSS region, preserving the update capsule and its details while excluding unrelated operational details.

Before: 871b00907d0bcf2705224de6c6e90de925c7cbb9.
After: 2da120cb65ee08791607497195867f848b132582.

Each checkout created its own database with T3CODE_DEV_SEED=0. No live database was copied. The source manifests report server version 0.1.8. launch-service.mjs creates a development executable shim for that source and starts the production Launcher class, including its real IPC rejection of same-version updates. No update implementation is mocked.

Run launch-service.mjs with the checkout root and its server port. Run T3CODE_DEV_SEED=0 vp run dev:web in that checkout. Pair the browser with that server using a fresh token. Evaluate seed-retry.js and interaction.js in the Vite page, then call runRetryEvidence(). Pairing tokens are deliberately excluded from these scripts.

The driver explicitly seeds the reported stale-failure precondition through the app's exported state setter: an already-connected server reports 0.1.8, while the failed update run retains a server target of 0.1.8. It does not alter the reported server config or replace the updater. It then opens the real capsule and clicks its real Retry control. It repeats with a synthetic provider diagnostic. The WebSocket observer forwards every send unchanged and counts update method messages; the JSON records those counts and resulting run state.

Observed before: Retry sends a real update RPC; the service launcher rejects it with "Remote updates must select a newer server version." The capsule retains Retry. Repeating with a provider diagnostic still shows the server rejection.

Observed after: Retry sends no update RPC and closes the run without a provider failure. With a provider failure, the diagnostic remains and the server target is cleared; the remaining action is Dismiss.

Limitations: This is conditional proof of Retry from the stale state, not an end-to-end reproduction of the original Nightly desktop download, postponement, failed update, successful service restart, and reconnect. The original trigger that retains the failed target remains unknown. Electron and a genuine Nightly binary upgrade were not exercised. Multiple outdated servers and a concurrent downloaded desktop update were not exercised.

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