Reproducible promoted-delegation runtime evidence
PR: https://git.cafe/pingdotgg/t3code/pulls/19352
Tested head: 321edbb8bdf1dca19f779cfeb984ef1d7988b285
Production fix: fa914efc1b8af9ba4438102f60e08a4a7d242d77
Fixture: apps/server/scripts/verify-promoted-delegation.ts
Fixture SHA256: 39c9a4d23747bd43bcaeefee000bb0e524627ebcb034b138769ef1b1ada27144
Command (repository root): node apps/server/scripts/verify-promoted-delegation.ts
Working tree clean at execution. No server/browser process started; no live DB or provider credentials read.

4/4 scenarios passed: delegated completed, delegated failed, monitor completed, monitor failed.
For each: actual delegated_task.request and message.dispatch/notification topology; actual queued-message.promote-to-steer command; queue run cancelled internally and message moved to joined run with promoted_queued_to_steer intent; parent task/node/item held running with absent task result; MCP status running/working; resolver reports pending; repeated recovery retains running; joined adapter outcome sets task/node/item completed/failed; one shared transfer; task_status resolves each task to the same transfer after page acknowledgement; repeated read/recovery keeps tasks/runs/transfers unchanged.
Delegated outcomes acknowledge two tasks; monitor outcomes acknowledge one. Before result reads tasks are claimed, not already acknowledged. Non-result page, truncated result and nonzero textOffset leave delivery claimed. Eligible one-item assistant result page (completed) / error result page (failed) acknowledges exactly the intended tasks.

Evidence classification: headless actual server services, real SQLite event/projection stores and effect worker, deterministic adapter. Harness uses in-memory SQLite and an isolated temporary git workspace. MCP reads run through OrchestratorMcpService with a forwarding ThreadManagement test facade. The fixture writes a deterministic assistant message/item through EventSink before emitting the adapter terminal event; failed terminals use a structured provider_error. This is not HTTP/WebSocket, UI, native-client, live-inference or process-restart evidence.

Artifact index: manifest.json records exact heads/source hash; verdict.json records run outcome; trace.ndjson contains commands, held projections, negative-page reads/delivery states, resolved tasks and final parent projections. index.json maps each case to trace line numbers and checksums.

Missing matrix rows/claims: queue-held/idle opening; task_wait/bounded pending wait; synthetic two-cut restart chain; real crash/relaunch/reconnect; unpromoted cancellation; waiting/starting/interrupted/cancelled boundary cases; all client interaction/video/platform evidence. Existing 32-test result is lead/implementer-owned and not independently re-run by this fixture.

task_wait limitation: no current exposed task_wait capability. OrchestratorMcpService.waitForTask is private and only reached by delegate_task(mode=wait), which cannot select the promoted follow-up task. No new capability or copied wait algorithm was added. delegatedTaskResultPending and running task_status are proven, not a bounded task_wait transcript.

FRICTION
- Heavy host contention: initial import took approximately nine minutes; a later single-file format took 147 seconds. The first four-case development run passed three scenarios and reached held-running in the fourth before the 45-second operational deadline. Final committed run uses a five-minute failure deadline; ordering is exclusively persisted event/Deferred milestones, never sleeps/polling.
- Scoped server typecheck was stopped on lead request during contention; no new typecheck/build was launched. Single-file formatting and lint passed; final runtime assertions passed 4/4.
- Stored promotion synchronization is asynchronous: an immediate projection can still be pending while MCP derives running. Fixture waits for persisted subagent.updated before asserting synchronized task/node/item; it does not claim atomic status synchronization or crash-window coverage.
- No browser/server launched, no PR comment, no push. UI verification belongs to lead.