# T3 Connect startup sign-in load recovery

Surface: Linux Electron desktop, built separately at each commit, headless-desktop,
1280 x 900 renderer, light theme, fresh isolated data directories.
Base: 313f601fb2366fad7dd26b7b55844c7c5d750cf0
Head: ab2a31b7c7fff56ff262976ac2d45f67ae72c836

The scenario runner was not used because the prerequisite is a saved authenticated
T3 Connect host connection, rather than project/thread state.

Setup (same on each side):
1. Load test-stage configuration from the supplied environment file; never use production.
2. Build desktop with those variables set, using `vp run --filter @t3tools/desktop build`.
3. Run a separate host server from base with its own --base-dir. Authorize account 1
   using `connect login --headless`, `connect link --headless`, then `serve`.
4. Launch each desktop using control.cjs inside an isolated Linux network namespace.
   Set CHECKOUT, T3CODE_HOME and XDG_CONFIG_HOME to the appropriate isolated directories.
5. Complete the first-run import, open /settings/connections, sign in using the in-app
   Clerk form with account 1 and the supplied email code. Dismiss publication onboarding.
6. Click Add on the test host. Confirm T3 Connect · Connected. Quit the app completely.

Reproduction:
1. Bring down the namespace veth's host-side link (`ip link set <veth> down`).
2. Relaunch the base and head desktop processes on their existing profiles while offline.
3. Open /settings/connections. Run `record(<new-output-directory>)` in each driver.
4. Confirm This device is offline · attempt 1 and Clerk ui.browser.js request failures.
5. About 90 seconds after head launch, restore the veth. Confirm DNS and HTTPS to the
   test Clerk script and /v1/environment from inside the namespace.
6. Leave both windows idle, without a dialog or focused input, for at least 5 minutes.
7. Open Details on each saved host. Capture two PNGs 500ms apart; retain only identical
   frames for final stills. Compare sign-in diagnosis and the recovery control.
8. Use each side's offered recovery control: Retry now on base, Reload T3 Code on head.
   Capture whether the host reconnects. Base's renderer reload is an additional control.

Driver commands are evaluated in a scope with `app` (Playwright ElectronApplication),
`page` (its first window), `snap()`, `record(directory)` and `stopRecord()`.
The driver uses the installed app's own Playwright dependency. It changes no app code
or auth state. Credentials are entered in real forms from environment variables.
All screenshots and recording frames mask environment names for privacy.
Encode frame directories using ffmpeg at 2 frames/second; no test assertion is used as evidence.

Observed timeline (UTC, same network outage for both isolated desktop processes):
- 14:54:04 base relaunched offline; 14:54:15 head relaunched offline.
- Both showed offline attempt 1 and failed Clerk UI-script loads.
- 14:55:57 network restored (about 100–110 seconds after launch).
- Clerk script (following its redirect) and /v1/environment returned HTTP 200.
- Base then repeatedly said sign-in was still loading; head immediately showed
  “T3 Connect sign-in could not load on this device”.
- 14:56:21 base attempt 5; 14:57:27 attempt 6; 14:58:39 attempt 7;
  14:59:46 attempt 8. Head stayed on its explicit sign-in load failure at attempt 1.
- After more than five minutes online and idle, opened Details on both sides.
- Base: session_pending, attempt 8, Retry now. Head: sign_in_failed, attempt 1,
  Reload T3 Code. Final stills were verified identical across a 500ms interval.
- Clicked Reload T3 Code on head: saved host returned to Connected without signing in.
- Clicked Retry now on base: attempts reset, but it remained session_pending.
- Additional control after recording: reloading base's renderer also restored Connected.

Recordings contain the offline launch state, network restoration, the full idle interval,
and the offered recovery actions, captured at 2 fps. The final PNGs and videos are cropped
to the Settings surface; gray masks redact environment names. No production data, account
credentials or machine identifiers are included in the uploaded artifacts.