# PR #23559 proof audit, pass 1: fixture matrix

Diff: `git diff 8d3b061121 2d0622b17b`. Change: in `resolveDeliveryIntent` (`apps/server/src/orchestration-v2/CommandPolicy.ts`), the explicit `steer` early return now sits below the provider-turn gap check.
Test file: `apps/server/src/orchestration-v2/CommandPolicy.test.ts`.
Test names: **T1** = "resolves automatic message delivery from authoritative provider capabilities"; **T2[s]** = "queues automatic and steer messages while the handoff run is %s"; **T3[x]** = "queues automatic and steer delivery when the active run's provider turn %s".

| # | Row (intent, state) | Unit fixture | Before | After | How a real server reaches it | Practically reachable | Runtime transcript covers it? |
|---|---|---|---|---|---|---|---|
| 1 | steer, active run `preparing` | T2[preparing] | steer_active (Orchestrator rejects: "No running provider turn found") | queue_after_active | Send a steer right after a start, before the worktree/session handoff finishes | Yes (ms window) | **Partial/ambiguous.** The transcripts send start+steer in the same ms. Before shows the rejection; after shows a success and a queued delivery. Neither records the run status at dispatch time. Run 11 has no `startedAt`, so preparing or starting is implied, but which one is not. |
| 2 | steer, active run `starting` | T2[starting] | steer_active (rejected) | queue_after_active | Same as row 1, slightly later | Yes (ms window) | Same as row 1: the transcripts cover rows 1–3 together, not each row on its own |
| 3 | steer, run `running`, no provider turn | T3["has not started"] | steer_active (rejected) | queue_after_active | Run marked running before the provider emits turn start | Yes (narrow) | Same as row 1 |
| 4 | steer, run running, provider turn `pending` | T3["is pending"] | steer_active (rejected) | queue_after_active | Turn requested but not yet confirmed running | Narrow | No |
| 5 | steer, run running, provider turn `completed` (between turns) | T3["has completed"] | steer_active (rejected) | queue_after_active | Provider turn finished while the run is still active (checkpoint/finalize, or multi-turn run) | Yes, but timing is tight | No |
| 6 | steer, running turn from previous attempt | T3["belongs to a previous attempt"] | steer_active (rejected) | queue_after_active | Run retry/new attempt before the new attempt's turn starts, with the stale turn row still `running` | Rare; mostly reachable only with synthetic projection state | No (accept as unit-only) |
| 7 | steer, running matching turn (control) | T1 (3rd assert, steer → steer_active) | steer_active | steer_active (unchanged) | Steer during a long-running turn | Yes, easy | **No.** The transcripts never steer a live turn |
| 8 | restart, gap states (control) | T2[*] restart assert; T3[*] restart assert | restart_active | restart_active | Restart right after start | Yes | No |
| 9 | restart, running matching turn (control) | **None.** No explicit fixture; the code path sits above the gap check and is unchanged by the diff | restart_active | restart_active | Restart during a long-running turn | Yes | No |
| 10 | auto, gap states | T2[*] auto; T3[*] auto | queue_after_active | queue_after_active (unchanged) | Send a normal message right after start | Yes | **Incidental only**: the first message in each pair is auto with no active run (row 12), not auto in a gap |
| 11 | auto, running matching turn (capability-driven) | T1 asserts 2, 4, 5 (steer/queue/restart by capability) | per capability | per capability (unchanged) | Normal follow-up during a turn | Yes | No |
| 12 | no active run (any intent) | T1 1st assert (auto only; steer/restart with no run not asserted) | start_immediately | start_immediately | First message on an idle thread | Yes | **Yes**: messages 900001 and 910001 (auto on an idle thread) succeed in both runs |

## SHA check
- runtime-before.json: `"base": "8d3b061121"` ✔
- runtime-after.json: `"head": "2d0622b17b"` ✔ (the worktree HEAD is 2d0622b17b4c9881d5a0ae3f83b6d5b64d90f205)
- sanitized-tests.log: Head 2d0622b17b4c… ✔. The log shows 3 files passed and 106 tests passed.

## Verdict: SUFFICIENT (for merge), with one recommended capture

The fix is proven: rows 1–3 collectively reproduce the bug (rejection before) and the fix (queued success after) on a real server. Rows 4 and 6 need synthetic state or narrow races; accept them as unit-only. Row 5 is real, but its timing is tight and it is covered by unit tests. Accept it as unit-only.

Uncovered but practically reachable and worth capturing:
- **Row 7 (steer during a running matching turn → steer_active, still steers live).** This is the regression control that the reorder must not break. It is easy to reproduce: start a long turn, wait for the turn to be `running`, then send an explicit steer. The after build should show the steer accepted mid-turn, not queued.
- Optional: **row 9** (restart during a running turn). The reorder does not touch this path, which is above the moved block, so it is low value.

Minor test gap (non-blocking): row 9 has no unit fixture. Steer and restart with no active run (row 12) are not asserted.