# Reproduce the GitLab fork-slot proof

Use a current-main checkout with `vp i`. Copy the two scenario files into `scripts/scenarios/`; commit neither. The scripts use real GitLab projects, the real T3 server and clients, and replay only the model turn.

1. `mkdir proof-data`
2. `python3 seed.py proof-data` creates an original project, its feature branch and MR !1, plus a fork with a different feature branch and newer MR !2. The script expects GitLab authentication and permission to create projects in the configured group and user namespaces.
3. Export `MR_FIXTURE_URL` from `proof-data/fixture.json`'s `url` field.
4. Run `T3_SCENARIO_INHERIT_ENV='MR_FIXTURE_URL,SIMLOCK_AGENT_DEVICE_URL,AGENT_DEVICE_DAEMON_AUTH_TOKEN' T3CODE_DEV_SEED=0 vp run scenarios:prove scripts/scenarios/gitlab-fork-slot.e2e.ts --base 382312aba8fd4b2197d2f902495e5ab765aee3ec --head c84a54c303e0dd770ff43efb24f453d596a50336`. This uses the pooled iOS client and records just the push interaction.
5. For the status comparison, create a second fixture with `seed.py`, then `python3 expand.py <fixture.json>` adds twenty closed same-named fork MRs and reopens !2. Export that fixture's URL and run the same proof command with `gitlab-fork-status.e2e.ts` and `T3_SCENARIO_INHERIT_ENV=MR_FIXTURE_URL`.
6. Run `python3 large-descriptions.py <second-fixture.json>` and repeat the status proof unchanged. It sets MR !22's description to one million less-than characters and MRs !19–!21 to 400,000 each. Real glab JSON measures 6,002,009 bytes for the first MR and 13,243,505 bytes for all 22 candidates, requiring smaller pages under the fix's eight-million-byte cap.
7. `python3 capture-candidates.py <fixture.json>` prints live CLI response sizes and candidate identities without copying their descriptions or credentials.

Remove the synthetic GitLab fork and original projects after running; their IDs are in each fixture JSON. All app databases are fresh and isolated. No proof-only UI is injected.