# Delegated task startup: real-app comparison

Base: 2c61677d59bf28730779a578a7b543528f0ca683.
Head: e0a42fa7dbc6d8eb880f4982a43dea7e7f9d3216.

The head changes both local and linked-environment task reads. The earlier description saying linked tasks were unchanged does not describe this head.

## Environment

Linux web development builds, Chromium preview browser, light theme, 1280 by 800 CSS-pixel viewport, device pixel ratio 2. Every uploaded PNG and MP4 is a full-frame 2560 by 1600 capture. No crops, stitched views, generated result overlays, or video cuts. Still captures followed two byte-identical browser screenshots at least 500 ms apart.

Both commits ran from separate, unmodified worktrees with dependencies installed using `vp i`. Each server used its own fresh home with `T3CODE_DEV_SEED=0`. Synthetic git projects were registered with the T3 CLI. No live database was seeded. Real Codex CLI 0.169.0 and gpt-6-luna executed the parent and child turns.

Each side had two real servers: the browser's local environment and a linked peer on loopback HTTP. The peer proxy forwards the real protocol and only replaces the discovery display label with `Proof peer`; it records tool request names and arguments, without authentication headers. `linked-peer-read-trace.json` selects the requests occurring inside the three relevant tool executions, excluding later completion-follower message reads.

## Startup hold

`hold.cjs` is the binary for provider instance `codex-held`, driver `codex`. It launches the real Codex app-server and waits before forwarding its incoming `thread/start` message. The gate therefore holds actual provider startup, rather than synthesizing tool responses or editing database state. Releasing the gate forwards the message; the real child then executes its requested sleep.

Configure the provider's `binaryPath` to the executable wrapper, and set `PROOF_GATE` to a separate empty gate directory in each server's environment. A file named `release` in that directory opens the gate. Provider instance `codex` uses the ordinary binary. Enable linked environments in the two local servers and link each to its corresponding peer using the normal CLI pairing flow.

## Same steps on both commits

1. With the child gate closed, use `drive.py` without `--thread` to start the parent. It calls orchestrator_capabilities, delegates an async child to codex-held/gpt-6-luna, and calls task_status once. The child task is `Run sleep 60 in the shell, then reply done.` For the linked case, supply the peer environment and project IDs.
2. Open the parent in the real web client. Hide the sidebars, expand the completed turn, and expand `Got delegated task status`. Scroll its actual JSON result to status/workState and capture it while the gate remains closed.
3. Start an uncut recording on that result. Use the same driver with `--thread` and `--release-gate` to send the follow-up. The real parent executes `bash ./release-provider.sh` (or `release-linked-provider.sh`), runs sleep 5, and calls task_status once. The driver creates that relative release script in the synthetic project; its only effect is opening the gate and printing a confirmation. The provider may combine the release and sleep into one shell command.
4. Expand the follow-up's actual command and tool rows in the client. Show the release command and stdout, then scroll the post-release raw task_status result to status/workState. End the recording.

Example driver invocations, using your own synthetic directories and IDs:

```sh
python3 drive.py --checkout CHECKOUT --home LOCAL_HOME --project PROJECT
python3 drive.py --checkout CHECKOUT --home LOCAL_HOME --project PROJECT --thread THREAD_ID --release-gate GATE
python3 drive.py --checkout CHECKOUT --home LOCAL_HOME --project PROJECT --peer PEER_ENVIRONMENT_ID --peer-project PEER_PROJECT_ID
python3 drive.py --checkout CHECKOUT --home LOCAL_HOME --project PROJECT --peer PEER_ENVIRONMENT_ID --thread THREAD_ID --release-gate PEER_GATE
```

## Observed results

| Real tool result | Base local | Head local | Base linked | Head linked |
| --- | --- | --- | --- | --- |
| Initial delegate_task.status | running | starting | running | starting |
| Held task_status.status | running | starting | running | starting |
| Post-release task_status.status | running | running | running | running |
| workState throughout | working | working | working | working |

The four results JSON files contain the actual persisted delegate_task and task_status outputs and the real child run's startup time. The initial tool calls precede that startup time in every case. `base-linked-held-results.json` additionally captures the projection while the gate is closed: run status starting and startedAt null, alongside the incorrect running tool outputs. These are supplemental transcripts; the primary visible proof is the expanded raw tool output in the app.

The task card's generic `Running` label remains visible on both versions. The proven change concerns the tool JSON status field, which is expanded beneath the card.

In the linked comparison the head makes one real t3_thread_read (limit 1, runLimit 50) during delegate_task and during each of the two task_status calls. The base makes none during those calls. The request trace records this additional path as exercised, rather than assuming linked behavior is unchanged.

## Viewing the recordings

All recordings begin on the held raw result. The app collapses previous tool rows when the next turn starts; the follow-up rows are then expanded. Release output and post-release raw status are visible before the recording ends. Approximate viewing points:

- Base local: initial result 0-4 s; release output near 58 s; post-release status near 62 s.
- Head local: initial result 0-4 s; release output near 22-28 s; post-release status near 29 s.
- Base linked: initial result 0-4 s; release output near 20-32 s; post-release status near 34 s.
- Head linked: initial result 0-4 s; release output near 20-32 s; post-release status near 34 s.

## Why manual

The scenario documentation was read first. This reproduction depends on a real provider's startup handshake and real delegation tool execution. The replay provider renders recorded tool events and does not execute these delegation tools against the server, so it cannot supply the required held-provider condition. No unit or integration test is being used as proof.

Unverified: disconnected-peer fallback and relay/tunnel transport. Linked peers were reachable over loopback HTTP throughout these runs.