# Proof audit pass 1 — issue 21772

Scope: [#21772](https://git.cafe/pingdotgg/t3code/issues/21772), branch fix/issue-21772, base 8d3b061121, head a64184c7d3. Read-only source audit; no tests, browser, server, edits to checkout, pushes or comments performed.

## Exemption and render fixture matrix

Server-only exemption APPLIES. Complete diff contains only apps/server/src/orchestration-v2/Orchestrator.ts and DelegatedCompletionDelivery.test.ts. No component, render caller, prop, visual conditional, layout, client interaction handler, stylesheet, or contract changes. Existing clients consume existing subagent/run/notification projections; changed delivery behavior requires semantic runtime evidence, not visual styling proof.

| Named render fixture | Render paths/callers/props/conditionals/interactions | Affected visual rows | Minimum viewport × theme | Interaction/time recording |
|---|---|---|---|---|
| None — empty render fixture matrix | No visible render surface changed | None | None | None; timestamped runtime transcript required below |

## Semantic proof requirements

| ID / named fixture | Exact semantic assertion | Evidence and status |
|---|---|---|
| S1 / BackgroundWakeAfterOriginalResult | An app-owned delegated child has delivered its original result; parent has acknowledged it and completed. A provider background-command notification dispatches queue_after_active into the child, without user/MCP follow-up. The resulting child run has a defined delegatedTaskId. After child completion, its distinct follow-up task completes, completion delivery is claimed, and a new parent continuation references the original owning parent run, with a completion message distinct from the original delivery. | New focused regression implements these assertions. Supplied red commit c9cfae301c fails assert.isDefined(run.delegatedTaskId); supplied head focused result is 27/27. Accepted as reported, not independently rerun. Retain exact commands, commit IDs, failure and passing output with lead's evidence. |
| S2 / RealBeforeBackgroundCommand | Real provider child starts native Bash sleep 60 with run_in_background=true, returns WAITING-21772, later receives background_command completion and produces CANARY-21772-FINAL. Parent receives only WAITING and never receives the final. No parent polling or child follow-up message. | Supplied before-runtime transcript read: demonstrates this failure on base 8d3b061121. It shows parent two runs, child final completed, no final parent notification/third run. |
| S3 / RealAfterBackgroundCommand | Repeat S2 on head a64184c7d3 with real provider and isolated state. Capture original task and child/parent IDs; initial WAITING result and parent completion; actual background_command notification; subsequent child run linked via non-null delegatedTaskId to a distinct follow-up task owned by the parent; child CANARY final; follow-up task completed with final result; parent receives the new completion notification and automatically starts/completes a subsequent turn acknowledging CANARY. Correlate IDs and timestamps across persisted run/task/message records and readable parent/child transcript. Show that parent performs no task polling, child messaging, or manual resume to induce delivery. | MISSING: clean, uninterrupted after-runtime transcript and persisted linkage. Capture head/environment/provider/model and the real command. No tests or watch-triggering source writes during collection; avoid restart/recovery so the proof exercises normal delivery. If restarts occur, repeat the run. Include stable task/child identity or explain redaction consistently; a final parent canary alone is weaker than correlated linkage. |
| S4 / EligibilityAndLockBoundary | Non-monitor notifications may create follow-up tasks; monitor notifications, scheduledTaskId and restartContinuationOfRunId remain excluded. Ordinary user/MCP eligibility and parent-sender guard remain for messages without notifications. Only new runs/attempts qualify, original result must exist, existing delegatedTaskId is preserved, and non-subagent children cannot acquire follow-up ownership. Same predicate selects parent-before-child locking for eligible dispatches. | Source inspection confirms these guards and shared lock predicate. Existing focused suite includes monitor exclusion and follow-up lifecycle cases; supplied 27/27 is supporting evidence, not a new runtime matrix. No additional viewport/provider permutation required for this shared orchestration change. Runtime S3 specifically covers the real provider-to-command normalization boundary (wire background_command versus command notification in the focused test). |

Before evidence: [before-runtime.txt](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/29c3aa3468274d4a/before-runtime.txt).

## FRICTION

The previous after attempt was interrupted by dev-server watch restarts, so it cannot establish uninterrupted end-to-end delivery. No clean after evidence was supplied to this reviewer. Reviewer MERGE recommendations and green tests do not replace S3. The red/green logs are reported by the lead rather than independently inspected here. This audit derives proof requirements only; it does not request additional browser/server work by the review sub-agent.

VERDICT: INSUFFICIENT — missing S3: clean head runtime transcript with correlated child follow-up task/run linkage, completed result, new automatic parent delivery and canary acknowledgement without polling or restart.