# Proof audit, pass 1 — delegated completion acceptance

PR: [#25666](https://github.com/pingdotgg/t3code/pull/25666), GitCafe [#25667](https://git.cafe/pingdotgg/t3code/pull/25667). Issue: [#25000](https://git.cafe/pingdotgg/t3code/issues/25000).

Audited local head: [34668f0e46](https://git.cafe/pingdotgg/t3code/commit/34668f0e468d534622a3b3a907c7a68372d26ffd), branch `pr-25666`, source branch `fix/issue-25000`. Compared to merge-base [5522180329](https://git.cafe/pingdotgg/t3code/commit/5522180329c70c7050852ae0d948400d845f55da), not stale local `main`. Head is not pushed yet. Read-only audit in `/home/ubuntu/wt/pr-25666`; no edits, tests, providers, servers, browsers, pushes, or forge comments executed. Pass 1 defines evidence; it does not supply test or runtime captures.

## Findings first

1. **Evidence blocker:** all three mandatory rows below are missing at the audited head. The [previous proof](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/e1058947302e07c8/proof.md) explicitly reconstructs older historical logs without a fresh run, and the [previous matrix](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/6a98e39d870c8dc5/matrix.md) has zero rows. They are background, not evidence satisfying these rows.
2. **No changed render path:** the complete diff is two server files: three implementation lines in `Orchestrator.ts` and expansion of an existing table-driven test in `DelegatedCompletionDelivery.test.ts` (67 insertions, 26 deletions overall). There is no React component, changed prop, layout, style, client, or wire schema. Minimum required UI captures: zero. Minimum proof rows: three, not zero. The repository requires “the test plus a short runtime transcript” for this server-only fix.
3. **The runtime path matters:** a successful delegated child after an idle parent can be handled by a separate delivery run and settlement. That does not demonstrate the changed acceptance command. R3 must contain a real `notification.delivery.accept` command receipt and its correlated persisted events. Codex supports active steering, so this is feasible on this VM using a background (`completionWake: always`) app-owned delegation while a parent turn remains active.
4. **Exact race is a harness fixture:** the regression intercepts `EventSink.commitCommand`, commits a synthetic checkpoint-completed parent after acceptance has read a waiting parent, then commits acceptance. It uses in-memory SQLite and a mocked provider; it does not create a real provider checkpoint. Public UI/RPC has no supported pause between those two internal points. Runtime timing may encounter the race, but cannot deterministically force it without instrumentation. R1/R2 prove the interleaving; R3 proves real integration. Do not call R3 a demonstrated reproduction of the original production incident.
5. **Head provenance:** read-only GitCafe metadata still reports remote head [de5ee510e2](https://git.cafe/pingdotgg/t3code/commit/de5ee510e2cc34865b25adae30d09343df7bd961), with reviews/checks attached there. Those do not validate the unpushed audited head. The forge's conflict result also concerns that older head, not this local diff. Exact-head logs must record the local SHA before execution.

## Fixture matrix

Every temporal row is marked **recording**: retain continuous execution/event transcripts, not a still. Server rows require text recordings, not screen videos. The optional visual row requires video.

| ID / fixture | Required / affected | Data and observable result | Medium / minimum viewport × theme | Seed through real app or labelled harness | Reproducible on this VM / race forcing | Pass-1 status |
| --- | --- | --- | --- | --- | --- | --- |
| R1 — accept/checkpoint race, merge-base red | Required; directly affected | One waiting parent, one terminal app-owned child, open cohort generation 1, child claimed, ownership-matching delegated completion message, no pending siblings. Force parent to `completed` with `completedAt` and exact checkpoint ID before acceptance commit. Delivery becomes `delivered`, but baseline regresses lifecycle/checkpoint assertion. | **recording — full raw test stdout/stderr**, command, SHA, exit code; viewport/theme N/A | **Labelled harness**, not real UI. In a separate disposable lead-owned checkout of the merge-base implementation, overlay only the exact head test file so the new accept row exists. Run the focused accept test. Do not modify the lead's current checkout. | Yes; no provider OAuth required. Test hook deterministically forces the race. The bare base suite alone cannot supply red because it lacks the new row. | **PENDING — not run** |
| R2 — head green and existing delivery guards | Required; directly affected accept plus existing controls | Same accept fixture must preserve `completed`, exact `completedAt`, exact checkpoint ID and mark child `delivered`. Full focused file also covers acknowledge `running → failed`, acknowledge `waiting → completed`, pending siblings, stale/duplicate acceptance, settled-only sibling handling, and restart delivery cases. These are protocol fixtures sharing one suite artifact, not separate visual variants. | **recording — full raw focused-suite stdout/stderr**, head SHA, command, exit code; viewport/theme N/A | **Labelled harness** from the existing table and fixtures. Run the complete head `DelegatedCompletionDelivery.test.ts` once. Head accept result must pass, as must the existing suite. | Yes; in-memory SQLite, test provider, installed dependencies; no real Codex/Claude call required. Same hook forces race. | **PENDING — not run** |
| R3 — real Codex acceptance, checkpoint and continued work | Required; exercises changed production route | Fresh project + parent Codex thread + one real background Codex child. Child reaches terminal state while parent has an active steerable turn; delivery is claimed and accepted, child becomes delivered. Parent finally completes with a real checkpoint. Persisted accept event must retain the parent lifecycle/checkpoint fields current immediately before its commit; if already checkpointed, exact ID/time must remain unchanged. A queued or subsequent manual follow-up then starts and completes with its own checkpoint. | **recording — short chronological runtime transcript** backed by raw provider/server/event logs and final read-only DB/RPC projections; viewport/theme N/A | **Real app**, UI or authenticated RPC driver. Launch exact head against a new timestamped home with `T3CODE_DEV_SEED=0`. Create project/thread and submit prompt through normal project/launch/message RPCs (or UI). Parent calls capabilities then background `delegate_task` with explicit available Codex target. Use harmless external gates to let child finish while parent is still executing an active turn. Let normal worker steering dispatch acceptance; do not fake it by writing SQLite or issuing a synthetic accept. Submit follow-up through normal message RPC. | Feasible with Codex CLI 0.163.0 via the configured hub, per the brief; CLI presence/version checked, live authentication not exercised in this audit. No Claude OAuth needed. Ordering gates can ensure active-parent delivery, but **cannot force the internal read/commit checkpoint race**. | **PENDING — no fresh runtime** |
| U1 — parent visibly settles and accepts follow-up | Optional supplement only; no render code changed | Same real R3 parent: show delegated result arrival, activity ending, and follow-up proceeding. A UI may aggregate latest-run/child activity, so correlate shown thread with R3 IDs; do not assume the UI literally displays the run enum `waiting`. | **recording — actual UI video**; one web viewport (e.g. 1280×900), one theme (e.g. light). No dark/narrow/platform cross-product required. Still alone is insufficient for transition/continued-work claims. | Same real app fixture and thread route as R3. UI capture only after browser authorization; no browser needed for mandatory text proof. An injected stale UI store would be a **labelled harness capture**, never production race proof. | Feasible on this VM with authorized Browser panel access and Codex. Runtime race still cannot be forced through the UI. Desktop/macOS/mobile capture is unnecessary for this server-only change. | **OPTIONAL — not captured** |
| X1 — Claude version of R3 | Not required; shared persistence logic unchanged per provider | Equivalent real child delivery through Claude would be supplemental provider coverage. | **recording** if attempted; no extra viewport/theme set | Real app with a configured authenticated Claude provider, not a fabricated success. | **Unavailable here:** no Claude OAuth per brief. Do not block the minimal Codex proof on this or substitute a test double while calling it real Claude. | **EXCLUDED — unavailable, unnecessary** |

## Changed-path and branch inventory

- `dispatchNotificationAccepted` is not a component. Its sole production handler caller is the `notification.delivery.accept` case in `dispatchOnce`. This diff returns the parent run ID from that helper and carries it as `updateDelegatedCompletionOnlyRunId` through `dispatchWithReceiptEffect` into `EventSink.commitCommand`.
- Production command emitter: `EffectWorker.ts`, successful `provider-turn.steer`, only when the steered message has delegated-completion ownership. Other direct occurrences are tests (the delivery test and the steering integration fixture). The public command union/RPC also permits dispatching this command, but no existing web/mobile direct acceptance control was found. An RPC-only synthetic accept can test persistence, not prove genuine provider acceptance.
- Normal setup is `ProviderContinuationService` creating a server-owned delegated `message.dispatch`; the orchestrator changes it to active steering only for all-`always` task ownership, an active `running` parent run/turn/session, a non-maintenance parent message, active-steering capability, and steering that does not interrupt tools. Otherwise it queues/starts a delivery run. That alternative uses settlement logic and cannot substitute for R3's acceptance receipt.
- Eligibility/no-op branch: missing ownership/parent/cohort, closed disposition, absent delivery, mismatched message ID or generation emits only unchanged thread metadata and returns no run ID. This diff does not enable merging for that branch. Existing duplicate/stale acceptance control in R2 is sufficient; no new visual fixture.
- Valid acceptance branch: archive/delete suppresses pending sibling collection; otherwise pending terminal app-owned siblings from this parent qualify, with `always` required while parent is live and both wake modes eligible after it settles. Zero eligible siblings clears delivery; one or more reserves next generation. Each pending sibling becomes claimed; accepted claimed tasks become delivered; unrelated tasks produce no update. R1/R2's new race uses zero siblings; R2's existing batch and settled-only tests cover the adjacent branches. No new multiplicity-dependent UI or layout.
- Commit branch: the already-existing sink helper reads the current run inside the command transaction and replaces only `delegatedCompletion` for the selected run ID. Other run IDs/non-run events remain unchanged; a missing current run keeps the incoming event. Normalization occurs before event append and projection, so both must tell the same lifecycle story. This diff changes no EventSink implementation. Post-accept offering of further completion deliveries is unchanged.
- The new test row is `accept`, `waiting → completed`, capture true. Existing acknowledge rows remain (`running → failed`, capture false; `waiting → completed`, capture true). The hook commits the settled event before original acceptance commit. It asserts delivery state plus final projection status/time/checkpoint. It does not independently assert the returned stored event; R3 should retain persisted event payloads as well as the projection.
- Prop shapes, counts/lengths affecting layout, empty/loading/error rendering, theme, width, platform-specific UI branches, navigation, keybindings, settings and command palette: **none changed**. All clients consume the same preserved server run state. No feature-specific mobile/desktop/remote/local screenshot matrix is justified. Provider adapters/contracts are unchanged; Codex is both available and the reported incident's provider.

## Execution handoff

R1 must run the **head test against the base implementation**. Running the original base test file with a name filter can silently yield no matching test and is not red proof. Record the base implementation SHA and the head test-file provenance explicitly. A disposable base checkout/test overlay belongs to the lead/capturer; this audit did not create one.

Focused R1 selector (from its disposable checkout):

```sh
vp test run apps/server/src/orchestration-v2/DelegatedCompletionDelivery.test.ts -t "keeps a completed run that settled between accept's read and commit"
```

R2 (from exact audited head):

```sh
vp test run apps/server/src/orchestration-v2/DelegatedCompletionDelivery.test.ts
```

Capture entire output and exit status, with no `tail`, lost pipeline exit status, timeout-based retries, or historical reconstruction. Red must fail the lifecycle preservation assertion after delivery becomes delivered, not fail setup or module loading. Green must show the new accept case and entire file passing; record actual count, not the old historical 29 count. A later head needs its own provenance and relevant rerun.

For R3, create a new timestamped run directory beneath `/tmp/lead-25666-r1/` for the driver's logs, prompt, gate files, home and outputs. Start from the audited worktree with:

```sh
T3CODE_DEV_SEED=0 vp run dev --home-dir /tmp/lead-25666-r1/<new-timestamped-run>/home
```

Read actual ports from dev-runner, keep the spawn session/PID, use single-origin development, and retain auth privately. Seed through normal UI/RPC project creation, thread launch and message dispatch; neither direct database fixture insertion nor the live T3 database is needed. A driver must use the app's authenticated RPC client/transport rather than guessing a JSON WebSocket envelope. Gate a real child until the parent is demonstrably running, then release the child; after a real acceptance receipt, release any parent-side command gate so it finishes. Gating the outer flow does not gate the internal acceptance transaction. If steering is rejected because the turn ended, that attempt is not R3 coverage; retain its log and make a fresh run directory for a subsequent attempt.

Minimum R3 transcript fields: UTC times plus durable event sequence; head SHA; Codex version/model; fresh-home identity and `T3CODE_DEV_SEED=0`; project, parent thread/run, child task/thread/run IDs; terminal child event; message ID/generation linking claimed delivery to `provider-turn.steer` and accepted `notification.delivery.accept` receipt; parent `run.updated` status/completedAt/checkpointId immediately before and in the acceptance commit and final projection; actual checkpoint capture/storage evidence, not just a UI badge; follow-up submitted/started/completed/checkpointed. Read the isolated SQLite database in read-only mode or query projections via the app; correlate command receipt sequences with event payloads. Keep raw provider/server logs and sanitized machine-readable extracts. Upload evidence before removing the isolated state. Do not upload auth tokens, startup pairing URLs, provider secrets or unrelated conversation data.

No fresh red/green/runtime execution is part of this pass. A UI still showing a completed parent can support a final-state statement, but cannot replace the required transcript, prove checkpoint preservation, demonstrate queue progress, or establish the race.

## Audit provenance and friction

Read-only inputs and prior downloaded artifacts: [audit input bundle](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/1124e18fa5afb312/audit-inputs.tar.gz). Commands used: `git diff` against supplied merge-base, source/caller inspection, `cafe pr view/comments/reviews/status`, `cafe issue view`, `curl` for prior artifacts, `codex --version`, and disk/status checks. Origin is GitCafe; no GitHub API/gh reads used. Worktree remained clean, disk available 23 GB. No own process or lease was started. Only this step's scratch directory will be removed after upload; lead worktree remains untouched.

FRICTION: none
VERDICT: INSUFFICIENT R1 base red, R2 head green, R3 fresh Codex runtime transcript