# Thread-wait real-app proof The scenario, `driver.mjs`, and `issue-client.ts` are scratch proof drivers, not product changes. Use the same scenario and drivers on each commit in separate installed worktrees. Put the three files in a temporary directory, copy `wait-blocking-input.e2e.ts` into `scripts/scenarios/`, and run: ```sh WAIT_PROOF_DIR= T3CODE_DEV_SEED=0 \ vp run scenarios scenarios/wait-blocking-input.e2e.ts --target web ``` The app starts with its own fresh home. The scenario creates a synthetic git project through the real CLI, signs into the web client, and enables Linked environments in Settings > Labs. It adds only a replay-provider prompt hook: the parent calls the real HTTP MCP endpoint using its actual thread credential; the child uses the normal replay question/approval recordings, or calls the real request_secret tool. The server implementation under comparison is untouched. The parent prints normalized actual server responses into its conversation, omitting opaque IDs from approval metadata to keep captures readable. `elapsedMs` measures the real request. It also records its original unabridged responses locally; only synthetic, normalized observations are published. No credential files are evidence or uploaded. The recorded sequence: 1. Leave a structured question unanswered. Wait on its existing run with a 15-second budget. 2. Queue a second run behind that question and wait specifically on the second run. 3. Start another question run and wait before the question arrives. 4. Leave a command approval unanswered and wait on its run. 5. Call delegate_task in wait mode; its child calls request_secret. Then wait directly on the existing secret-blocked child run. 6. Cancel that delegated run, start unrelated question work in its child thread, and inspect the earlier task's pending-input metadata. Repeat with an approval task and later approval. 7. Using independently issued outside-MCP and linked-peer credentials, wait on an unanswered question with a 3-second budget. Start another wait and then interrupt the run: it must return the terminal interrupted status, not return early for input. 8. Run the actual `t3 thread start --wait --json` CLI against a question and a completing replay turn; capture both its exit code and its returned status. Every stage records the pending card and the caller's actual response in the same 1280x800 light web client. CSS motion is paused for stills only. A retained still has a byte-identical PNG taken 500 ms earlier. The continuous recordings show the complete scripted interaction. Linked-peer controls authenticate through the real linked-client MCP gate on this server; they do not use a second host or exercise network transport between separate machines.