# Delegated-task performance capture These scripts drive the actual T3 server. They do not mock its stores, insert database rows, or run unit tests. Prerequisites: each app checkout installed with `vp i`; Node compatible with that checkout; Python 3; Pillow for rendering. 1. Put `drive.py`, `agent.mjs`, `analyze.py`, and `render.py` together in a scratch directory. 2. Run `python3 drive.py base 100`, then `python3 drive.py head 100`. Each run gets a new timestamped directory. The published capture ran head first, then base, sequentially. The small driver check is excluded. 3. Run `python3 analyze.py base` and the corresponding head command. 4. Run `python3 render.py `. The driver starts a fresh isolated real server, disables real model providers, and registers a synthetic ACP provider. It uses the application's CLI and the provider's genuine scoped MCP session. Each of 100 seed cycles adds 400 completed tool calls, then seven app-owned quick delegates. Each measurement round delegates three quick tasks, lets completion wake the parent, reads their results, then starts and cancels three long tasks. Nine rounds run on the large parent, then nine on a new tiny parent. The provider's 250 ms quick-task delay and 1500 ms long-task setup delay are outside the measured operation/store spans. Two seconds separate rounds. `analyze.py` extracts existing server trace spans from those windows. Store-read numbers sum `ProjectionStore.readCanonicalProjection` spans at the exact changed call sites. They include read/decoding and scheduling while the span is open, but exclude transaction begin/commit and connection queue wait. They are live-app measurements, not the PR author's isolated database-copy benchmark. See `definitions` in measurement JSON for the exact mapping. Parent status synchronization is measured under `Orchestrator.finalizeAppOwnedSubagent`; the unchanged `Orchestrator.delegatedTaskResultPending` is a separate control and is never labelled status sync. Terminal finalization includes completed and interrupted child results. A median is the median of nine per-round medians. Spread is the range of those round medians. Stable improvement requires base median minus head median to exceed the larger side's spread. All rounds and samples are retained. The output also gives non-overlap of round-median intervals. Behavior is checked against MCP responses and the synthetic database's persisted task outcomes, opened read-only after measurement. The span exports remove paths, error stacks, and unrelated attributes. SQL query text uses placeholders; all task state is synthetic. No heap allocation result is claimed. The server exits in the driver's `finally` block. ## Confirmation pass The head's first-pass cancellation span had a wide range, so before base results were available the capture added a confirmation pass on both commits. It repeats exactly the same MEASURE action, without changing tasks or delays: three consecutive batches, each containing nine rounds. Run `python3 confirm.py ` after both first-pass servers have stopped, one side at a time. This restarts each side against its own synthetic state; it never copies state across commits or uses live user data. The confirmation uses only the large parent. There are 54 starts, 27 quick results/status checks, and 27 long-task cancellations per batch. Every batch and sample is retained, with no warm-up sample discarded. Analyze with the same `analyze.py`, then render with `render-confirm.py`. The initial-pass output remains published alongside confirmation output. Confirmation reports the median of three batch medians and their full range. Its comparison uses the same criterion: median improvement must exceed the larger side's batch-median range. This is extra repetition of the reported interaction, not a different operation. Original and confirmation output are both available so the effect of sampling can be assessed.