# Shared attachment proof

Device: pooled Pixel 9, Android API 36, 1080×2424, portrait, light theme, normal Android animations and Gboard. Both checkouts installed their own native fingerprint through mobile:install and ran their own Metro and isolated server with T3CODE_DEV_SEED=0. Native fingerprints matched because the fix changes JavaScript only. App storage was cleared between the primary base and head comparisons. The synthetic project was registered through the CLI on both servers.

PDF steps: Chrome downloads report.pdf (7002 bytes); cancel Drive PDF Viewer; Files → Downloads → long-press report.pdf → Share → T3 Code Dev → Share evidence project. Select Replay (dev), Multi turn. Recording starts with the populated composer, then Send. Base displays Too much context and retains the file. Head uploads the file, creates the message and completes a replay turn. Android returns to the main activity's thread list after handoff; the driver reopens the same newly sent thread while recording. The final head still and video show the same 12:22 PM PDF message, title Unexplained PDF Attachment, and first fixture turn complete. There is no later PDF send on head.

Image steps: download synthetic chart.png (13759 bytes), then the same Files share path, select Replay (share proof), Multi turn, and Send. The stock Replay provider explicitly advertises image:false, so an initial base image run submitted and uploaded but failed at the provider boundary. configure-replay.py registers a separate local replay agent that differs only in advertising image:true and resolving fixtures from the tested checkout; app code is unchanged. Both image comparisons use that fixture. Image sending already works on base; this is a regression check for the changed image IDs.

Captures are screen recordings from the real device. Recordings begin after project/model selection, at the shared attachment composer. Environment labels in the hero and thread subtitle are redacted for privacy; the attachment, Send action, error, sent message and replay completion remain visible. No timing acceleration is used.

## Included attempts

- Before PDF: final repeated Send validation at 12:33, same original shared PDF draft; before.png and before-send.mp4 both show its Too much context dialog. Earlier validation captures are discarded.
- After PDF: the only head PDF send, at 12:22, title Unexplained PDF Attachment; after.png and after-send.mp4 show that same message and its completed replay.
- Before image: rebuilt send at 12:29, title Synthetic Share Image; before-image-proof.png and before-image.mp4 show that same completed turn. The earlier image attempt with a provider capability error and an earlier completed attempt whose recording ended on the thread list are discarded.
- After image: rebuilt send at 12:36, title Synthetic Share Image; after-image-proof.png and after-image.mp4 show that same completed turn. The earlier 12:24 send had a corrupt recording export and is discarded.

Final stills were taken after consecutive identical screenshots (separated by at least 500 ms). Battery/status-bar changes required another pair for the head image. Videos retain actual playback timing, use 10 fps at half resolution, and hold their last recorded frame for two seconds; Android does not encode unchanged screen frames. Privacy redaction only covers environment labels.

The app was rebuilt from each checkout's Metro bundle and each checkout's own mobile:install was run. There are no application source edits or test results used as evidence. This proof was performed by GPT-6.1-Sol through the Codex harness.

The two-commit scenario runner was not used because this reproduction exercises Android's Files app and system share sheet, which the runner does not support. Native clients were retrieved with mobile:install, not rebuilt from scratch; both commits have the same native fingerprint and different Metro JavaScript bundles.