# HTTP-only Forgejo login: real-app comparison

Use setup-forgejo.sh to create the synthetic HTTP-only server and official fj login.
In two checkouts, one at ddc4f576023b3bf7ead6c831510c1d72316bb1c2 and one at e4941d02c4ecd824dd460d69d763f6346cf34043:

1. Run `vp i`.
2. Start `T3CODE_DEV_SEED=0 XDG_DATA_HOME="$fixture_dir/xdg" PATH="$fixture_dir/bin:$PATH" vp run dev`. Each checkout creates its own fresh database. Never use a copied database.
3. In the shared Preview browser, open that server's startup pairing URL. Wait for pairing to finish before navigating to `/settings/source-control`. If the tab was already displaying `/pair` without a token, reload the pairing URL to submit it on mount.
4. Use the same 1280×800 CSS viewport and light theme for both sides. Settings applies to all projects and all environments; no project remote is selected.
5. Scroll the Forgejo row into view with this browser evaluation:

```js
[...document.querySelectorAll('span')]
  .find(e => e.textContent === 'Forgejo / Gitea')
  .scrollIntoView({block: 'center'});
```

6. Save two browser snapshots at least 500 ms apart. Compare their PNG SHA-256 hashes; retain the second once identical. Open and inspect each capture before uploading.

Observed base: "Not authenticated" plus a request to sign in or configure credentials.
Observed head: "Could not verify Forgejo / Gitea. Could not reach https://localhost:3410 to verify the fj login." No Forgejo sign-in warning.

Both captures were taken in the shared Preview Chromium browser on Linux. Screenshots use the same device scale, producing 1996×1248 PNGs from the 1280×800 CSS viewport. Other account names remain blurred by the app.

The initial scenario was attempted twice. Its managed app command did not inherit XDG_DATA_HOME, so it did not read the synthetic login and was unsuitable as proof. For future scenario runs, add XDG_DATA_HOME to app.command.inheritEnv in e2e.config.ts. Final evidence uses the manual comparison above, not those scenario verdicts.