# Reproduce the diff metadata proof

Use a current main checkout with dependencies installed. Copy the web scenario into scripts/scenarios and run:

```
T3CODE_DEV_SEED=0 T3_SCENARIO_INHERIT_ENV='T3CODE_DEV_SEED,SHELL' vp run scenarios:prove scripts/scenarios/diff-tree-change-type.e2e.ts --base 1e9f93a48e231db3ccc5bcde6c5d84a00d5b9e9a --head 4254ead57de6aadf60c668a2a835aa6f6d1bad7c --upload-command 'ghdrop upload'
```

For the iOS comparison, copy diff-tree-change-type-mobile-large.e2e.ts, hold-file-patches-network.ts and t3-mobile-held.ts into scripts/scenarios, apply mobile-runner-config.patch, and use the same command with the mobile scenario path and `--target ios`. The standard pool environment variables must be configured. The runner prepares the native client, leases and releases the iPhone, starts an isolated server and Metro, and installs and pairs the client.

Both scenarios create synthetic git repositories with 30 modified files, an untracked two-line addition, a staged two-line deletion, a staged pure rename and a staged rename with one changed line. They use real projects and replay-agent threads through the application's CLI.

The web scenario captures metadata before selecting each of the four target files, then opens their real patches. The mobile fixture widens the 30 modified lines to produce more than 120 KB of diff. Mobile only enters its lazy placeholder path for truncated previews; the small original reproduction is delivered as one complete patch. The file names and insertion/deletion counts are otherwise identical. The t3-mobile-held fixture pairs through the proxy port while the server CLI continues to use the real server port. The native scenario places a transparent local HTTP/WebSocket proxy between the mobile client and the real server. It holds only file-specific review.getDiffPreview requests for the four target files. Metadata, authentication and other RPC continue unchanged. After scrolling to the target headers and capturing the pending state, it releases those requests and captures again after the requested rename patches load. The addition and deletion can remain pending until explicitly selected, which is also visible in the recording. The web scenario opens all four target files and supplies the fully rendered addition/deletion patch-body evidence. The native assertion reads the added/deleted icon colors in the pending screenshot; the screenshots also show the rename icons and pure-rename notice.

No production database or real provider is used. Neither application commit is edited.