# Reproduction driver

Run the app at each supplied commit in its own git worktree, with dependencies installed using `vp i`.
The driver uses real server HTTP/WebSocket, the real Bitbucket provider adapter, and Chromium at 1280×800 in the light theme. Each run creates a fresh isolated scenario home and a synthetic Bitbucket project through the application CLI. No live user database is seeded.

1. Run `python3 bitbucket-stub.py` (loopback port 18995).
2. Apply `web-harness.patch` to `scripts/e2e.config.ts`: it selects only the web target and explicitly forwards the synthetic Bitbucket environment variables.
3. Put `rate-limited-open-pr.e2e.ts` under `scripts/scenarios/`.
4. From `scripts/`, run:

```sh
T3CODE_DEV_SEED=0 \
T3CODE_BITBUCKET_API_BASE_URL=http://127.0.0.1:18995/2.0 \
T3CODE_BITBUCKET_ACCESS_TOKEN=synthetic-only \
vp exec e2e run scenarios/rate-limited-open-pr.e2e.ts --target web --output .e2e/pr-rate-limit
```

The literal access token is synthetic and only sent to the local stub. To drive a second checkout's app from the same harness, set `T3_SCENARIO_APP_DIR` to that checkout. `HOST_REQUEST_LOG` optionally writes the stub's observed requests to a chosen file.

PR 1 responds HTTP 429 with Retry-After: 600. PR 2 accepts requests. The driver waits for PR 1's rate-limit error, opens uncached PR 2, captures the result after two identical screenshots at least 500 ms apart, then views its timeline and expands the comment group. Base cannot proceed past the description assertion; head loads description and activity. Recordings are trimmed to start at PR 1's error, omitting pairing.

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