# PR #22947 proof audit, pass 2

**Verdict: SUFFICIENT.** All five must-haves have a persisted value and a client-received value on both SHAs:
- workStartedAt of the running turn (R0)
- agent steer (R1)
- automatic queued continuation from a distinct agent (R2)
- child update, as automatic-queue (R3) and as immediate (R4)
- new user turn reset (R9)

An independent rebuild with the committed driver reproduced the BEFORE/AFTER split on every row.

## 1. SHAs

- Transcript BEFORE server: `8d3b061121fe…`. AFTER server: `5d9fd21d7c0c…`. Both appear in the logs' `environment` lines and match the given SHAs.
- `git diff --stat 8d3b0611 5d9fd21d`: only `Orchestrator.ts` (+51/-12 lines in the diffstat) and `runtimeLayer.test.ts` (+185). The diff matches the matrix description: the new `agent && mcp && senderThreadId` arm, with `automatic-queue` for any sender, or `immediate` when the sender is an app_owned `childThreadId`.
- `git diff --stat 5d9fd21d b34ba346`: only `apps/server/scripts/verify-work-timer-start.ts` (+717). Its sha256 is `c2efe39e…`.
- The downloaded `before.log`/`after.log` are sha256-identical to `/tmp/ev-22947/capture`. The capture logs record driver `2e4d6f9c…` on both sides; the committed driver is `c2efe39e…`.

## 2. Row by row (captured logs, re-extracted with my own parser, not rows.py)

Anchor = `ws ?? st ?? req`. Times are 2026-10-22 UTC. "shell" is the `activityRunStartedAt` timeline for T. "thr" is the `workStartedAt` the client received from `subscribeThread`.

| Row | Before | After | Supported? | Note |
|---|---|---|---|---|
| R0 user turn 1 | run1 ws — st 11:26:33.375; shell → 11:26:33.375 | run1 ws — st 11:26:36.220; shell → 11:26:36.220 | yes | Baseline S1 on the running turn. Persisted and client values agree. |
| R1 agent steer (C) | steer msg run_id=ordinal:1, runCount 1→1, shell still S1 | same | yes | Sender C, a distinct thread (agent/mcp). No new run, so this row cannot differ between SHAs. |
| R2 C queue → auto drain | run2 ws — st 11:28:46.456 (S1+133 s); shell → 11:28:46.456 | run2 ws 11:26:36.220 = S1, st 11:28:47.836 (+132 s); thr ws S1; shell: no change event 11:26:36.511 → 11:30:38.959 | yes | Changed row. Reset vs keep is unambiguous (133 s gap). Sender C. |
| R3 child K queue (behind run 2) → drains after run 4 | run5 ws — st 11:30:30.249; shell → it | run5 ws S1, st 11:30:33.163 (+237 s); thr ws S1; shell stays S1 | yes | Sender is an app_owned child of T, present in `subagents`. K queued during run 2, not run 1 as the matrix said, but it is still automatic-queue (endedRunId = run 4). |
| R10a delegated completion (run 4) | ws 11:28:46.456 (R2's reset start) | ws S1 | yes | Same "continue" rule on both sides. The transcript says "thr ws —", but the client value is in the logs (`clientRuns` run 4 ws matches persisted). That understates the evidence; no gap. |
| R9 new user turn | run6 ws — st 11:30:56.349; shell → it | run6 ws — st 11:30:59.122; shell → it | yes | Reset control holds on AFTER: a user turn after inherited runs still gets its own start. |
| R4 child K2 → idle T (immediate) | run7 ws — st 11:31:50.511; shell → it | run7 ws 11:30:59.122 (R9 start), st 11:31:51.464 (+52 s); thr ws same; shell null → 11:30:59.122 at 11:31:51.651 | yes | T was idle: shell null at 11:31:10.959. K2 is a second app_owned child, distinct from K. As the matrix notes, the timer visibly jumps back by the idle gap. |
| R10b delegated completion (run 8) | ws 11:31:50.511 | ws 11:30:59.122 | yes | Continue on both. |
| R5 C → idle T | run9 ws — | run9 ws — | yes | Control unchanged; sender C. |
| R8 CLI queue | run10 ws — | run10 ws — | yes | agent/mcp with **no** senderThreadId, so the guard holds. |
| R6 stop → queue.resume | run12 ws — | run12 ws — | yes | Explicit-queue control; sender C. |
| R7 stop → queued-run.start | run14 ws — | run14 ws — | yes | Explicit-queue control; sender C. |
| R11 restart | not run | not run | n/a | Optional in the matrix; the unit test covers it. Not a must-have. |

Every agent row (R1–R7) has a senderThreadId that is neither T nor the CLI: C on R1, R2, R5, R6 and R7, and two different app_owned children on R3 and R4. The transcript's gap arithmetic (133/132, 237/237, 54/52 s) checks out.

Minor observation, not a defect: in BEFORE the shell briefly shows the starting run's `requestedAt` before its `startedAt` (e.g. 11:28:44.826 → 11:27:09.213). That is the pre-existing `?? requestedAt` fallback while the run is starting. AFTER shows no such flicker on R2/R3, because ws is set.

## 3. Independent rebuild (committed driver c2efe39e, both SHAs, run in parallel 11:41–11:51 UTC)

- AFTER: worktree `/home/ubuntu/wt/pr-22947` at `b34ba346`. Home `/tmp/ev-22947/audit2/home-after`, with `T3CODE_HOME` overridden in my env. The driver also sets it to home for the server child.
- BEFORE: detached worktree at `8d3b0611` with the committed script copied in (`vp i`). Its `environment` line shows dirty `?? verify-work-timer-start.ts` only.
- Both runs: no driver errors, all milestones R0–R10b reached, and the servers stopped themselves. I checked PIDs 755724/755767/758662/758707 and all had exited. Worktree, homes and project dirs are removed; logs are kept in `audit2/run/`.

| Row | Before (rebuild) | After (rebuild) |
|---|---|---|
| R0 S1 | st 11:42:51.526 | st 11:41:36.118 |
| R1 | runCount 1→1, shell S1 | runCount 1→1, shell S1 |
| **R2** | run2 ws —, st 11:44:57.043 (S1+125.5 s), shell → 11:44:57.043 | run2 **ws 11:41:36.118 = S1**, st 11:43:48.036 (+131.9 s), thr ws S1, shell unchanged at S1 from 11:41:36.419 until idle at 11:45:36.927 |
| R3 | run5 ws —, st 11:46:41.850 | run5 ws S1, st 11:45:30.437 |
| R9 | run6 ws —, st 11:47:09.532 | run6 ws —, st 11:45:57.165 |
| R4 | run7 ws —, st 11:47:54.380 | run7 ws 11:45:57.165 (R9 start), st 11:46:48.013; shell null → 11:45:57.165 |
| R5/R8/R6/R7 | ws — on runs 9/10/12/14 | ws — on runs 9/10/12/14 |
| R10a/b | ws = previous anchor (11:44:57.043 / 11:47:54.380) | ws = previous anchor (S1 / 11:45:57.165) |

On structure, both rebuilds match the capture: 13 runs, ordinal 3 skipped on both sides, runs 11/13 interrupted, two app_owned children, and the same senders. **The committed (post-`vp fmt`) driver reproduces the transcript's behavior on every row.** The formatting change did not alter behavior.

## FRICTION

| category | what happened | what would have avoided it |
|---|---|---|
| tooling | My first launch wrote the driver PID file before `mkdir` existed (a race in a compound command), so I recovered the PID from `ps`. | Create the dirs in a separate step before backgrounding. |
| evidence | The transcript lists R10 "thr ws —" and "shell —", although `clientRuns` carries run 4's and run 8's ws. | Have rows.py look up the client run by ordinal in the latest milestone that contains it. |
| matrix | The matrix says R3 is "while T is still in sleep 120" (run 1). In the capture, K queued during run 2. | Word R3 as "while T has an active run". |