# Proof audit pass 1: issue 23191

Scope: /home/ubuntu/wt/issue-23191; complete diff 8acbefefc5..ec336f235f (3 files, 4 insertions, 3 deletions). No repository edits, server launches, browser launches, or delegated tasks. Audit artifact only.

## Visual fixture matrix

Empty (0 rows). The complete diff changes orchestration instructions, delegate_task tool description, and the mode schema description. No UI render path, layout, client mutation, transport behavior, or runtime scheduling changes. Under the supplied server-only exception, runtime transcript proof replaces screenshots. Web/desktop/mobile, viewport, theme, connection, and UI entry-point permutations add no proof for this change.

## Nonvisual proof matrix

| Fixture | Required observation | Current evidence / status |
| --- | --- | --- |
| Baseline provider MCP client, two batched wait calls | Second call begins only after first wait response; explain client serialization without claiming server scheduling is broken | runtime.json: first wait completes 01:26:36.243Z; second starts 01:26:36.317Z (74 ms later). Both time out with status running and distinct task IDs. Observed. |
| Same provider/client, two async launches before any blocking wait | Both responses confirm running, retain distinct task IDs, no intervening blocking wait | runtime.json: first starts 01:29:57.136Z; second confirmation 01:29:57.931Z: 795 ms total. Both status running, waitTimedOut false, distinct task IDs. Observed. This establishes launch acceptance, not parallel CPU execution or completed child work. |
| Fixed current-main dev build, fresh provider turn with T3 MCP | Actual provider-bound orchestration context exposes async-first rule, retains task IDs, warns about client serialization, and forbids claiming running before launch confirmation | Not present in runtime.json; required before calling proof complete. Source inspection alone is insufficient. |
| Same fixed build, actual MCP tools/list | delegate_task description exposes async-first/confirmed-launch guidance; mode property's schema description exposes async-first/client-serialization guidance | Not present in runtime.json; required before calling proof complete. Inspect advertised description and inputSchema.properties.mode (including any optional-schema wrapper), not source strings. |
| Codex context delivery guard | Every context entry fits 4,000 UTF-8 bytes; authored orchestration sections arrive in sorted key order without omissions | Existing CodexDeveloperInstructions.test.ts is directly relevant; execution result recorded separately in audit reply. Metadata flattening case is unrelated to this fix. |

## Exact minimum outstanding proof

1. On an already prepared fixed current-main development build, record main/build SHA plus applied fix SHA or equivalent diff and provider/client identity. The transcript currently contains no build revision or provider/client version, so do not label it post-fix/current-main evidence.
2. Capture one fresh T3-enabled provider turn's actual outbound instruction context (for Codex, t3_code_orchestration_* additionalContext entries) and the same build's MCP tools/list delegate_task description plus mode input schema description. Confirm all three changed exposure surfaces. Redact credentials and unrelated conversation content. A model paraphrase is weaker than the actual payload.
3. Attach the existing runtime.json baseline/async transcript with the exact observations above. If its provider/build provenance cannot be established, repeat only the two async launches on the fixed build using independent harmless tasks long enough to remain active, distinct stable clientRequestIds, and no waits before both confirmations. Preserve task IDs and responses. An additional baseline replay is unnecessary unless baseline provenance is disputed. Child completion is not required to prove launch acceptance; make no claim of completed work.
4. Run the existing focused CodexDeveloperInstructions test on the fixed source. Its byte-cap and section-delivery checks protect this guidance from truncation/omission. It is not a behavioral test for provider MCP client serialization and does not establish live-build exposure.

No new string-match unit test is required: such a test would restate authored guidance and cannot reproduce serialization inside an external provider MCP client. No new server concurrency test is justified by a diff that changes no concurrency implementation. No screenshots or browser launch are required. The minimum is runtime evidence plus all three live guidance exposure surfaces and the existing delivery guard.

## Disposition

The evidence supports the workaround's launch-acceptance behavior. Proof remains incomplete until fixed-current-main guidance exposure and build provenance are supplied. This audit does not perform those runtime actions because the request forbids server/browser launch and is read-only.

FRICTION
- Existing runtime evidence lacks build/provider provenance and guidance exposure payloads.
- No UI fixture is applicable; manufacturing screenshots would add no evidence.
- No behavioral unit test can express the external MCP client's serialization; use the existing delivery guards and runtime transcript.