# Delegated follow-up runtime evidence

Both sides run the unmodified real T3 Code server and web app with `T3CODE_DEV_SEED=0 vp run dev`, each from its own checkout. Each database is created fresh by its own server. Node dependencies are installed with `vp i`. Browser: Chromium, dark appearance, 1440 x 1000 CSS pixels (2x capture scale), sidebar and thread details collapsed. The synthetic local ACP provider performs real MCP calls; no model inference, mock orchestration, database fixture, test runner, or product source patch is used.

The same agent script delegates the first child using mode `wait`. The child self-queues FINAL-B via `t3_thread_send` with mode `queue` and `freshContext: true`, and returns HANDOFF-A. The parent receives FINAL-B, sends the finished child a follow-up with the same sequence using HANDOFF-C/FINAL-D, and inspects `task_status` five seconds later. FINAL-D deliberately takes fourteen seconds to return so this inspection occurs while it is executing. The parent prints a completed result immediately if the server reports one; otherwise it ends its turn and prints the result on the server's completion wake.

Before: the server reports completed / result_available / HANDOFF-C, even with hasPendingChildRuns true. The parent prints HANDOFF-C. FINAL-D returns later without replacing that parent result.
After: the server reports running / working / null while FINAL-D executes. After FINAL-D returns, the parent is woken with FINAL-D and prints it.

The JSONL files contain selected real MCP response fields and agent emission timestamps. On base, parent.completion.observed is the summary obtained by task_status; inspecting it acknowledges the completion. On head, parent.completion.delivery is a subsequent server wake whose prompt contains FINAL-D. The videos record the real web client rendering these agent messages and its own task cards. The captured JSON block is printed directly from the real task_status response; the script does not manufacture its status or summary.

## Driver files

- setup.mjs registers a deterministic local ACP provider in the isolated server settings.
- auth.mjs issues a full-access MCP driver credential using the same runtime auth service as the CLI. The resulting token is private and is not included.
- driver.mjs creates the synthetic project and an idle parent thread through MCP.
- start.mjs sends the initial reproduction prompt.
- agent.mjs implements the synthetic ACP provider and performs the delegation, self-queue, and follow-up MCP calls.
- mcp.mjs is the HTTP MCP transport.
- capture.mjs starts the sequence and records the live JSONL output as an asciicast terminal recording.

For each checkout, set ROOT to its path and choose a new timestamped OUT directory. Keep all these scripts together. Run `node setup.mjs "$ROOT" "$OUT"`, then start the dev server with `T3CODE_DEV_SEED=0 EVIDENCE_OUT="$OUT" vp run dev`. Wait for its startup pairing URL. Run `node auth.mjs "$ROOT" "$OUT/token"`, then `node driver.mjs "$ORIGIN" "$OUT/token" "$ROOT" "$OUT"`. Pair the browser and open the created thread. Collapse the sidebar and details panel, set the viewport/theme above, start browser recording, and run `node capture.mjs "$ORIGIN" "$OUT/token" "$OUT" "$SIDE" "$SHA"`. ORIGIN is the server HTTP origin, not the web port. Stop browser recording after the capture completes.

Removed/held continuations and reordered queues were not exercised. Desktop, mobile, and paid provider behavior were not exercised; the behavior proven here is server orchestration through its real ACP/MCP boundary and web client.

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