Both captures: real T3 Code development server and web client, separate git worktrees and freshly created databases, T3CODE_DEV_SEED=0. Linux x86_64, Chromium browser, dark theme, 1280x800 CSS viewport (recorded at device scale 2, exported at 1280x800). Pi provider with the same inherited provider configuration on both sides. Runtime model identifiers are deliberately omitted.

Base: d91915db9e36b03450aa7d6dbd35ff27cb027ffe
Head: 7987405ace74b9de78e22674b54f9663f0328cbd

Identical seed: 32000 synthetic tracked text files in 32 directories; each file has 16 repeated lines. No production database was used. No application source changes or test instrumentation were introduced.

Identical retained steps: use driver.py's numbered prompt to launch 12 background shared-folder children, each launching 2 background grandchildren. Every descendant and the parent runs sleep 900. Confirm 37 running turns and 37 running sleep commands. Record the web client. Click Stop generation, type Reply with only READY., wait until the parent's own interrupt, delegated-tasks.stop and checkpoint.capture succeed, then press Enter. Keep recording through READY and capture drain. Close thread details on both sides. Only private model-selector text and the bottom notification area were redacted; conversation and status UI are unchanged.

Read-only observer samples persisted server effects every 100 ms. It changes no database state. UI labels can say Working while provider-turn.start is still pending; runtime output distinguishes actual start from that label.

Base replacement enqueue: 00:02:01.467 UTC; first observed running: 00:02:17.149 UTC (about 15.7 seconds). The parent's checkpoint had succeeded at 00:01:57.302 UTC. Four descendant captures occupied all worker slots while the replacement remained pending.
Head replacement enqueue: 00:06:30.788 UTC; first observed running: 00:06:30.923 UTC (about 0.14 seconds). The parent's checkpoint had succeeded at 00:06:25.705 UTC. At replacement claim, 24 descendant captures remained pending and three were still running.

Limit: provider scheduling varied during startup. Initial head attempts launched only two direct children and were discarded; both retained runs use the same explicit numbered prompt and full 36-descendant tree. Running both trees simultaneously overloaded the VM, so the successful head run was restarted fresh and captured with base stopped. Elapsed end-to-end timings are observations, not a benchmark. The scheduling order is shown directly in runtime output.

No tests are used as evidence. AI-assisted; verified with the tests and tools listed above.