# Proof audit pass 1

PR [#19352](https://git.cafe/pingdotgg/t3code/pulls/19352), pinned head [589b34e2](https://git.cafe/pingdotgg/t3code/commit/589b34e2bada363733901973a51f61eae1ac612e).
Read-only audit. No checkout, edits, server, browser, or tests run. No PR review posted because the brief explicitly requests read-only proof planning.

Scope: full merge-base diff against local origin/main (8acbefefc51b4d281dcd04108c82baa1ab902b0e): four files, 549 additions / 57 deletions. Forge reports base 1451e7cb23034d29774338608368a15d8845df36; distinguish its base from the current tracking ref. Production changes: shared task-result resolver; finalizer status/node/item synchronization and shared transfer ownership; MCP status/wait result resolution; paginated result-read acknowledgement. No client or contract changes.

## Exception ruling

An empty *user-visible behavioral* matrix is not justified. Existing web/desktop QueuedRunsControl.steer and mobile ThreadQueueControl dispatch the promotion. Existing parent task/timeline/relationship surfaces consume stored subagent/node/item status and result. SubagentTooltipContent renders working/completed/failed styling and result preview; mobile SubagentRow renders statusLabel, tone and result detail. This fix changes those visible states even though the renderers are untouched. No new layout/design screenshot matrix is needed, but interaction and time-based behavior needs recordings. A server-only label describes file placement, not the absence of visible effects.

Settings/composer default Steer is not itself queued-run promotion. Do not multiply fixtures across unrelated settings. Web queue keyboard steerNext invokes the same steer function: add a brief keyboard trigger segment, not a second lifecycle matrix. Desktop wraps the web path; native mobile has its own queue action and task renderer. No provider-by-provider or local/relay/tunnel Cartesian matrix is justified for unchanged transports/adapters. Use one supported steer-capable provider path and state the tested surface/mode; do not claim untested platforms verified.

## Smallest fixture matrix

Use one reusable isolated parent+child topology, cloned/reset for these branches. Distinct synthetic prompt/result markers identify each task. Each row is an observable behavior, not necessarily a separate recording file. R means recording for any claim of integrated client verification; S means service/state evidence suffices. Existing evidence is inspected output, not independently rerun proof.

| Row | Fixture/action | Required observation | Evidence |
| --- | --- | --- | --- |
| 1 | App-owned delegated child has active task A; follow-up B queued, including queue-held/idle variant | Parent B pending/idle; child queue contains B; no B result or premature delivery | R, opening of lifecycle clip |
| 2 | Promote B using existing queue Steer while A is deliberately held active | Queue entry disappears/moved message has Steer intent; queue run cancelled internally; B parent task/node/item become running, summary absent; MCP status running/working; bounded task_wait must not falsely return cancelled terminal result | R for interaction and visible cards; S for task/node/item, status/wait |
| 3 | Release A to completed with unmistakable result | A and B complete with joined result; no stopped/cancelled flash while held; one shared transfer; one completion per task; result preview correct | R; S for transfer/delivery counts |
| 4 | Repeat with joined task failing; combine queue-held opening here | B follows failed result rather than cancelled queue artifact; failed card/detail matches joined result | R; S for outcome/transfer identity |
| 5 | Promote B into taskless active monitor turn | B stays running then completes with monitor result; first promoted task publishes exactly one transfer rather than suppressing all publication | R; S for ownership/count |
| 6 | Two restart cuts of joined run, second before continuation starts; unrelated later task with pending continuation | B remains pending work through both cuts, never settles from cancelled queue or unrelated task; after continuation finishes use final joined result and transfer | R across restart/reconnect/state transition if claiming real restart verification; S for chain IDs/outbox. Persisted synthetic recovery is not process-restart proof |
| 7 | Completed rows 3 and 5, read assistant-only one-item result page excluding moved user message | Delegated owner: acknowledge both tasks; monitor owner: acknowledge B; same result transfer ID. No acknowledgement merely because another run/page was read | S for IDs/delivery state; record the agent/tool interaction if performed in client. No invented acknowledgement badge required |
| 8 | Pagination guards: non-result page, truncated result, nonzero textOffset; then full eligible result page | No early acknowledgement; eligible full result read acknowledges once | S; if shown as client tool interaction, record whole sequence |
| 9 | Repeated recovery/read/status and reconnect after settlement | No duplicate result/transfer/wake or regression of settled task; client retains same terminal card/result | S for counts/idempotency; R for reconnect/visible persistence |
| 10 | Genuine unpromoted cancellation (message still belongs to cancelled queue run), plus ordinary unpromoted completion | Genuine cancellation remains cancelled; ordinary result stays task-owned; resolver does not borrow unrelated result | S control; R only if making client regression claims |
| 11 | Joined run waiting, starting, interrupted or genuinely cancelled | Follow joined run: stored waiting/running as applicable; terminal interrupted/cancelled only when actual joined work terminates, with correct result/fallback | S minimal parameter cases; record any client-visible transition claimed as verified |

Rows 1-5, 6 and 9 have real interaction/time behavior: still images alone are insufficient. Rows 7-8 are primarily MCP delivery semantics: recording a card cannot prove acknowledgement. Rows 10-11 complete resolver/finalizer outcome boundaries without demanding a new platform matrix.

## Minimum real-app capture plan

Minimum distinct behavioral sequences on one real client: (A) delegated success, with queued opening, click Steer, sustained running parent card and child active turn, terminal result detail, assistant-only read and reload/reconnect; (B) queue-held -> promotion -> joined failure; (C) taskless monitor -> promotion -> running -> completion/result; (D) restart-continuation sequence, showing both cuts and final result. These can be chapters in one recording. Include a short keyboard promotion in the web pass. Capture baseline before-fix promotion failure versus fixed behavior with the same fixture on a pinned base, labeled Before/After; existing service output is not a visual Before. A single static final screenshot does not prove the fix.

A real web capture satisfies minimum shared-server/client integration evidence, not blanket native-client coverage. If claiming all client surfaces verified, add one native-mobile success recording (its own Steer action and task row) and a desktop smoke segment. Reuse server fixture and avoid a full cross-product. The unchanged Electron shell does not create a new server outcome branch. Missing native captures must be reported, not silently counted as passed.

## Seeding approach

Follow test-t3-app / test-t3-mobile workflows only when authorized by lead/user. Prepare disposable dev home/worktree, never live ~/.t3/userdata or the lead's /home/ubuntu/wt/issue-19351. Copy real data with migrate-dev-db while that isolated server is stopped if needed; add a small dedicated parent/child fixture with actual app-owned lineage and task/node/item IDs. Do not start copied agents or scheduled work.

Drive actual delegate/follow-up queue and queued-message.promote-to-steer commands; do not fake a cancelled row and call it interaction proof. For deterministic captures use a gated provider adapter/test fixture through the real server, effect worker, SQLite projections and WebSocket client: gate on received steer/persisted milestones, release completion/failure deliberately. Explicitly label deterministic adapter versus live provider. Seed monitor run through its actual notification path so no delegatedTaskId is fabricated. For restart capture stop only a PID owned by that disposable fixture server, preserve its sandbox DB and restart; record reconnect and task state. Never kill by pattern. Event/Deferred milestones rather than sleeps establish ordering; a visible held-working interval is useful footage but not a test synchronization primitive.

Auth or MCP availability is not a hard stop to deriving this plan. If a real authenticated client/provider cannot be run later, use a supported isolated fixture transport and report the remaining limitation. Do not invent successful client proof. Page boundary, truncation and acknowledgement identities need structured service trace alongside video; screenshots cannot prove them.

## Existing evidence assessment

[Existing runtime proof](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/a83a1195e182273a/19352-final-proof.txt) reports actual promotion through real MCP toolkit/event stores/effect worker with a deterministic adapter. Both delegated and monitor variants assert stored task/node/item running before release, completed after release, one shared transfer, and assistant-only acknowledgement counts 2/1. Strong service evidence for rows 2,3,5,7. Permanent added tests cover success/failure, queue-held state, unrelated restart work, two synthetic restart cuts, repeated recovery and assistant-only pages. The public text reports 65/65 targeted cases but contains only the two-probe output, not reproducible temporary probe source. It explicitly excludes native UI, real crash/relaunch and live inference. It provides no client video, no direct task_wait transcript, and no displayed negative pagination-guard proof. Those remain unproven by this artifact. latestTerminalStatus may still refer to the cancelled queue run; distinguish historical terminal-run metadata from current status/workState.

## FRICTION

- No browser/server launched, as instructed; therefore real-app captures remain a lead follow-up, not an audit execution failure.
- Existing public output is headless, and temporary probe source is not committed. Do not describe it as real-client, native, live-provider, or real-process-restart evidence.
- A documented promotion-commit/status-sync crash window may leave a stored card pending until final settlement. A restart clip must expose that limitation if encountered; do not promise uninterrupted stored running state across that window.
- Completion-before-steer-delivery fallback is pre-existing and can enqueue new follow-up work; keep completion gated until steer receipt to prove the intended joined-run branch, then describe the race limitation honestly.
- No auth/MCP hard-stop requirement was imposed. No forge review posted under the read-only brief. No changes made to either checkout.