# Proof audit, pass 1

PR [#25662](https://git.cafe/pingdotgg/t3code/pull/25662), local head [5abcaf34fe](https://git.cafe/pingdotgg/t3code/commit/5abcaf34fe13cf513b7335b5cedccc5ccd908a30), against local main [394929af76](https://git.cafe/pingdotgg/t3code/commit/394929af7687886084234ccb92b744f51ede271b). The head is local and not yet pushed; its forge commit link becomes available after push. Audit is read-only in `/home/ubuntu/wt/pr-25662`.

## Findings

No proof blocker found. Exactly two files differ: `Orchestrator.ts` and `DelegatedCompletionDelivery.test.ts`. There are no changed components, props, client contracts, UI branches, styles, routes, or provider adapters. The only production change returns the completion plan's parent run ID and passes it through the existing `updateDelegatedCompletionOnlyRunId` commit option. Inside the existing SQL transaction, EventSink replaces only the stored run's `delegatedCompletion`; status, completion time, checkpoint ID and all other stored run fields survive.

The full existing test file passed **31/31** with transcript instrumentation disabled. The focused runtime transcript passed all three race cases. A negative control substituted main's Orchestrator only in the Vite transform, leaving current tests and all assertions intact: **wake-completed failed**, both acknowledgement controls passed. Baseline restored `running`, null completion time and null checkpoint; head retained the terminal state and planned cohort. No source was changed on disk.

This is proof of the persisted race fix, not proof that a queued provider turn subsequently executes. That broader effect is not asserted by the new case and is not claimed here.

## Call and presentation inventory

- The changed helper `dispatchDelegatedTaskWakePolicy` has one production call site: the `delegated_task.wake-policy` arm of `decideCommand`. Its returned ID travels via `dispatchWithReceiptEffect` to `eventSink.commitCommand`; EventSink reads the current run within the transaction and overlays the planned cohort.
- The ordinary producer is `OrchestratorMcpService.delegateTask`: `mode: wait` begins with `completionWake: settled_only`; an incomplete wait upgrades it to `always`. Terminal results already delivered through the blocking wait do not take this path. Generic `orchestrationV2.dispatchCommand` WebSocket dispatch also accepts the same existing command. ThreadManagementService routes the same shared command path. No dedicated Settings, command palette, keybinding, or mobile control was added or changed.
- A wake-policy update always emits the task update. A parent run update is produced only if policy becomes `always`, the app-owned task is terminal, its spawning run exists and is live (`preparing`, `starting`, `running`), and delivery planning returns an updated cohort. `waiting` is blocking but is not live for this gate. Error and no-plan branches return no parent ID.
- Delivery planning can create a cohort, append a task to a reserved cohort, or append to an existing queued completion and update its message. Already delivered/acknowledged/disposed tasks, archived/deleted parents, closed cohorts, and active/terminal delivery runs have no parent run update on this path. Message text, task ID count/order/deduplication, generation, result truncation and error rendering are unchanged.
- The indirect visible consequence is real: `ProjectionStore` derives shell status and active run from persisted runs; shared `threadWorkflows.resolveActiveThreadRun` treats preparing/starting/running/waiting as active; `startNextQueuedRun` refuses while a blocking run exists. A clobbered run can therefore retain Working and queued follow-ups. Web Sidebar status/shelf, ChatView/QueuedRunsControl, mobile thread lists/ThreadFeed/FloatingWorkingControl and desktop's web UI consume existing state. Their rendering code is unchanged.
- Counts, long/empty text, loading/error shells, light/dark themes, narrow/wide viewports, iOS/Android/Electron, local/remote/relay/tunnel connections and provider identity introduce **no distinct changed render combination**. No layout prop or serialized schema changed. All providers using app-owned delegation share the fix; native-only delegation is outside this command.

## Fixture matrix

`recording` marks every timing- or interaction-dependent fixture: a still cannot demonstrate its transition. For this server-only scope the listed harness runtime transcript replaces video; it does not imply a browser recording exists. No harness image is being passed off as a real-app capture.

| Row | Named fixture and required data | Affected by diff? | Seeding / driver | Minimum viewport × theme × row / medium | Status |
|---|---|---|---|---|---|
| W1 | Checkpoint wins wake-policy race: running parent, open cohort `nextGeneration=2, delivery=null`, terminal app-owned task, `settled_only`, delivery pending; inject completed/time/checkpoint after read and before commit; upgrade to always | Yes; central regression | Existing `seedParentWithTerminalTask`; commit spy awaits real EventSink terminal commit, then original wake-policy commit | N/A × N/A × W1; **recording**, replaced by labelled harness transcript | **PASS** head; **FAIL expected** main; transcript shows terminal fields and new generation-2 delivery both retained |
| W2 | New cohort without race: same pending terminal child, live parent, absent cohort or null delivery; singleton task list | Commit merge applies; ordinary behavior unchanged | Same service harness seed; dispatch wake-policy without injected settlement. Production: wait-mode delegate returns incomplete, child ends before upgrade read | N/A × N/A × W2; **recording**, service trace only | Source traced; W1 exercises the same new-cohort branch plus the adversarial interleaving; no additional visual proof required |
| W3 | Join reserved completion: open cohort with non-null delivery, one or multiple task IDs, no delivery run; append/deduplicate terminal task | Same merge applies; no new text/layout | Harness EventSink seed of cohort and terminal task, then wake-policy dispatch; production pending completion batching reaches this state | N/A × N/A × W3; **recording**, optional service trace | Source traced; full file covers batching/result text; direct wake-policy join not separately asserted; no distinct capture obligation |
| W4 | Join queued completion: cohort delivery has queued completion run and optional matching message; append task IDs; optional message body update | Same merge applies; message algorithm unchanged | Harness seed queued run with matching `userMessageId`, cohort and message, then wake-policy. Multiple/long results reuse existing completion formatting | N/A × N/A × W4; **recording**, optional service trace | Source traced; optional message presence changes no part of the fix; no new visual proof required |
| G1 | No plan: downgrade to settled_only; nonterminal child; null/missing parent run; or parent waiting/completed/failed/interrupted/cancelled instead of live | No updated parent ID; unchanged | Existing task/run records via service harness; dispatch wake-policy. `waiting` specifically takes no-plan branch | N/A × N/A × G1; **recording** for policy interaction, service trace only | Inspected unchanged gates; no captures required |
| G2 | No parent update: task already delivered/acknowledged/disposed; parent archived/deleted; cohort closed; or delivery run active/terminal | No updated parent ID; unchanged | Harness seeds delivery state/cohort/thread lifecycle; ordinary delivered-upgrade fixture is already in test file | N/A × N/A × G2; **recording**, service trace only | Delivered-upgrade regression **PASS**; other unchanged gates source traced; no captures required |
| E1 | Reject invalid/non-app-owned task or redundant policy | No; same dispatch errors/receipt behavior | RPC `orchestrationV2.dispatchCommand` with unknown task ID or matching policy, using disposable thread; no provider required | N/A × N/A × E1; **recording** for command/error interaction; no screenshot | Source traced; unchanged error branch; no captures required |
| A1 | Acknowledge after failure: running parent, claimed terminal child/cohort; commit failed/time/no-checkpoint between acknowledge read and commit | Test refactor/control only | Existing `ack-failed` seed and commit spy; no provider session opened | N/A × N/A × A1; **recording**, labelled harness transcript | **PASS** head and main; planned delivery cleared while terminal state survives |
| A2 | Acknowledge after checkpoint: waiting parent, claimed child/cohort; commit completed/time/checkpoint between acknowledge read and commit | Test refactor/control only | Existing `ack-completed` seed and commit spy; no provider session opened | N/A × N/A × A2; **recording**, labelled harness transcript | **PASS** head and main; planned delivery cleared while checkpoint survives |
| U1 | Optional consequence demonstration: parent shows Working with one queued user follow-up after its provider has ended, then settles/queue becomes eligible | Indirect data consequence; no rendering code change | **Labelled harness** required for deterministic provider-free reproduction: isolated service runtime + EventSink seed after startup + controlled provider adapter; seed running parent, terminal app-owned child and queued follow-up; drive W1 interleaving, expose shell/detail to client at `/$environmentId/$threadId`. Normal RPC can queue a follow-up with `message.dispatch` + `dispatchMode: queue_after_active` and upgrade wake policy, but cannot inject the commit-boundary settlement or arbitrary stored run | Optional only: one web desktop-size viewport, one theme, U1; **recording** required if shown. Extra platforms/themes add no proof of the server race | Not captured; **not required** for server-only acceptance. No ordinary provider-free app reproduction or queue-advance proof is claimed |

**Minimum visual capture set: empty.** Required proof is W1's persisted state trace plus the regression tests. A1/A2 provide useful controls and are already present. W2-W4/G1-G2/E1 enumerate service branches; they do not create visually distinct changed layouts.

## Exact sufficient runtime evidence

The bundle's `commands.txt` contains the literal commands run, and `proof.vite.config.mjs` contains the console-only transform. The config imports the worktree's actual server config, directs caches and temp state into scratch, uses the actual test file and actual SQLite-backed EventSink, and retains all assertions. `PROOF_BASELINE=1` substitutes the saved main Orchestrator source only in memory. The focused command is:

```sh
cd /home/ubuntu/wt/pr-25662/apps/server
TMPDIR=/tmp/lead-25662-r1/proof-audit-1/tmp vp test run --config /tmp/lead-25662-r1/proof-audit-1/proof.vite.config.mjs /home/ubuntu/wt/pr-25662/apps/server/src/orchestration-v2/DelegatedCompletionDelivery.test.ts -t 'keeps a run that settled between a delegated completion update' --reporter=verbose --no-cache --no-fsModuleCache
```

Sufficient output lines, in `head-runtime.log` / `runtime-transcript.txt`:

1. W1 `phase: before`: `status: running`, `completedAt: null`, `checkpointId: null`, cohort `nextGeneration: 2`, `delivery: null`.
2. W1 `phase: expected-settlement`: injected status `completed`, `completedAt: 1970-01-01T00:00:00.000Z`, checkpoint `checkpoint:settle-race-wake-completed`, planned cohort `nextGeneration: 3`, delivery `generation: 2`, task IDs `[node:settle-race-wake-completed-task]`.
3. W1 `phase: after`: all those terminal values and the planned cohort match. The timestamp is deliberate TestClock time, not wall time. Message ID UUID is allocated, so compare it within the run, not across executions.
4. Named `ack-failed`, `ack-completed`, `wake-completed` test lines pass; summary `Tests 3 passed | 28 skipped (31)` and exit 0. The skips are the explicit name filter.
5. Full file with `PROOF_TRANSCRIPT=0` and no name filter: `Test Files 1 passed (1)`; `Tests 31 passed (31)`; exit 0.

The transcript labels expected-settlement explicitly: it is the exact payload the unchanged spy awaited committing before delegating to the original command commit; it is not claimed as a separately polled production checkpoint worker. The assertion checks actual persisted projection after dispatch. Negative-control raw output shows the baseline's actual `phase: after` values are `running/null/null`, and only `wake-completed` fails. No sleeps, wall-time race scheduling, browser, real provider or application server is needed.

## Provider-free VM reachability and limits

**Yes, the bad persisted run state is reachable without a real long-running provider:** this audit reproduced it against main with real orchestration/event-sink persistence and a mocked provider (the adapter's `openSession` deliberately dies if called). A stale running run plus queued user message is also a seedable service state: add `message.dispatch` with `dispatchMode: { type: queue_after_active }`, then inspect the shared active-run/queue workflow or serve the seeded runtime through the normal transport. A deterministic real-client presentation would be a **labelled harness recording**, not an ordinary production-user capture.

**No, this audit has not established a normal installed-app recipe using only settings, chat and public RPC that deterministically triggers the race without a provider.** Public RPC has no arbitrary `run.updated`/EventSink commit hook, and provider completion/checkpoint events come from server services. Simply showing Working, leaving a fake process hanging, or showing a static queued card would not prove the read/commit overwrite. A custom in-process harness must control the commit boundary and prevent recovery/provider cleanup from erasing seeded activity. That additional UI harness is unnecessary for this patch's prescribed server-only proof.

## Coverage and housekeeping

Covered complete requested diff, changed helper and caller, transactional merge implementation, MCP producer, generic WS command surface, shared active-run/queue consumers and representative web/mobile presentations. Full-file test and baseline/head runtime evidence completed within the 60-minute budget. Not a full merge-readiness/CI audit: no forge state refresh, browser/device verification, provider end-to-end run or queue execution claim. The unpushed local head was authoritative. No edits, pushes, comments, persistent servers, live userdata access or worktree changes.

FRICTION: none

VERDICT: SUFFICIENT