# Real-server delegated-task performance capture

Environment: Linux x86_64, 8 vCPUs (AMD EPYC 9455), Node 26.13.1. The two revisions run sequentially on the same VM. No real model is used. Each server creates its own fresh database with seeding disabled. Synthetic state is produced exclusively through the server's project/thread CLI and the ACP/MCP provider paths. SQLite is opened read-only afterwards to verify persisted outcomes; it is never used to seed or modify state.

The scenario documentation excludes performance regressions because replay timing is simulated. This capture therefore drives the real server using a deterministic scratch ACP provider, as in the reported reproduction. The PNGs render the measurement output, not the app UI.

## Workload

Create an empty git repository and a parent. Repeat 100 times: one turn emitting 400 completed tool calls, then one turn delegating seven quick tasks. Create a tiny parent on the same server. On each parent run seven MEASURE rounds: delegate three quick tasks; read their terminal statuses/results; delegate three long tasks; cancel each; read each cancellation's terminal status. Automatic completion continuations return immediately. Round 0 warms the path; all six subsequent rounds are retained. Quick tasks produce the same fixed synthetic answer on both revisions.

Durations come from the real server's effect-span trace. A CLI round's wall-clock window identifies its spans; span ancestry identifies the operation and store reads. The reported median is the median of six round medians. The displayed range is the minimum and maximum of those round medians, not individual sample extrema. JSON retains individual operation/store samples and sanitized source spans.

## Exact store scopes

- Startup: canonical projection reads under `ProjectionStore.getRunProviderRecords` in `orchestrationV2.dispatch.delegatedTaskRequest` on head; the corresponding initial parent canonical projection read on base. This excludes task-numbering counts and other startup work.
- Completion: canonical projection reads in the read/planning prefix of terminal `Orchestrator.finalizeAppOwnedSubagentTask` calls, before the first event write, excluding its initial child-result read. This includes the parent task, child context transfers, and parent completion-plan records. Only calls that reach `orchestrationV2.planDelegatedCompletionDelivery` count as terminal completions; both quick completion and cancelled/interrupted completion are included.
- Status synchronization: the outer `Orchestrator.finalizeAppOwnedSubagent` reads after its initial child-controls read and before its nested task-finalization work. Base reads the parent's subagents/context transfers in one projection; head reads parent subagents filtered by child thread and the child's context transfers in two projections. The unchanged `Orchestrator.delegatedTaskResultPending` is never used for this metric.
- Cancellation: the initial parent task canonical projection lookup inside `Orchestrator.cancelDelegatedTask`. The interrupt-existence lookup is not separately isolated.

These sum `ProjectionStore.readCanonicalProjection` durations, which include SQL reading and decoding. They exclude enclosing transaction setup/commit and unrelated work. They are in-app traced read timings, not a replay of SQL on a copied database. They do not measure allocated bytes or heap.

Whole-operation rows are also retained: `OrchestratorMcpService.delegateTask`, terminal `Orchestrator.finalizeAppOwnedSubagentTask`, `Orchestrator.finalizeAppOwnedSubagent` (including nested task completion), and `OrchestratorMcpService.cancelTask`. The outer finalize row must not be interpreted as a pure status-sync duration.

For each metric, comparison.json reports the gain, each side's round-median spread, their sum, non-overlap, and both spread verdicts. A missing whole-operation speedup is not inferred from a faster store lookup.

## Reproduction

Install dependencies with `vp i` in clean worktrees of the base and head, then run `bash reproduce.sh <base-checkout> <head-checkout>`. Python 3, Pillow, DejaVu Sans, Git, and Node are required. The script folder is the output root; each run gets a new timestamped subdirectory. `drive.py` owns and stops the server process group it starts. `analyze.py` strips all attributes, events, and error messages from published spans. The uploaded measurement JSON and images contain only synthetic workload data.