# PASS1 proof audit — issue 22033

Read-only audit of local head ea3642a4872efa089663fff337bd6283c52e17be against 27e0c684c5, 2026-10-24. Worktree: /home/ubuntu/wt/issue-22033. No checkout edits, tests, forge mutations, server, browser, or delegation performed. Only this safe report is written outside the worktree and uploaded.

Context: [#17885](https://github.com/pingdotgg/t3code/pull/17885), [#22033](https://github.com/pingdotgg/t3code/issues/22033). The cached PR metadata reports a different remote head (d0cbecc9); this audit applies to the specified local head, not a claim about current remote state.

## Verdict

PASS1 proof completeness: NOT YET COMPLETE. The narrow server-only/no visual-design-change exemption is defensible. The changed-render-component matrix is empty. The affected behavioral/render-consumer fixture matrix is not empty. Missing current-head runtime-after evidence is the primary proof gap. Green test totals cannot substitute for it.

Codex delivery classification is a real protocol/scheduling semantic change: command completion now requests message_text, causing ProviderContinuationService to dispatch createdBy=agent, creationSource=server instead of provider. It must remain held beside held user work because it needs a fresh prompt. It must not acquire the buffered-wake bypass.

Attribution caveat resolved by tracing the actual path: userMessage.ts maps server to t3code and provider to agent; ordinary user-message rows would switch from folded agent to expanded “Sent by T3 Code” in both web and mobile. However, this Codex request always includes notification metadata; notificationTurnItem removes createdBy/creationSource and converts the input into a notification. Web session-logic renders that as work, and mobile threadActivity handles it as activity rather than a message bubble. getUserQueuedThreadRuns also excludes notification-backed inputs. Thus this patch does not establish a visible attribution-label change in the normal feed or user queue. Do not claim that the generic attribution helper alone proves such a change. A fixture without notification metadata is not representative of this adapter path.

The bug itself is visible (stale Running agent and stalled wake), so “no visible surface” should be described narrowly as no changed visual presentation. Runtime state proof is appropriate for the shared scheduler fix; an empty list of all affected consumers would be misleading. No browser evidence was collected or required by this audit's authorization.

## Changed visual/render implementation matrix

Empty: no web, desktop, mobile, client-runtime, contract, CSS, or render-component files change. The seven changed files are server implementation/tests only.

## Affected behavioral/render-consumer fixture matrix

| Fixture | Inputs / timing | Required result | Consumers / proof |
| --- | --- | --- | --- |
| Claude buffered wake, held queue | Hold user follow-up using Stop or restart recovery; start another root turn; native background command completion offers wake while root still active/settling | Wake queued without queueHeld; root settles; wake starts exactly once; original user run remains queued+held unchanged | Web/local and hosted web, desktop same web feed, mobile activity feed; runtime event/projection transcript is primary |
| Later native agent completion | Following preceding wake, launch native local_agent while idle; discover progress on later turn; deliver final notification | Same native task ID becomes completed with result and completion timestamp; later wake is consumed, not swallowed | Web V2LifecycleRow/subagent presentation and mobile ThreadAgentsSheet, thread-subagent-group/SubagentRow; background-work and working indicators derive same state |
| Stop control | Dispatch Stop while active root and held user work exist; provider wake arrives after Stop commits but before interrupt settles | Wake remains held after worker drain and scheduler resume; no additional provider start; original root interrupted | Composer Stop/queue controls, keybinding/palette/MCP paths reach shared server; BackgroundWorkStop integration covers committed-Stop window |
| Codex fresh text | Real post-settle commandExecution completion produces message_text notification, with another active run and older held user run | Source server, notification metadata intact; continuation queued+held; no fresh turn/prompt before explicit release; after Resume/client release, exactly one real turn receives detail text | Normal notification work/activity row on web/desktop/mobile, not agent/t3code message attribution; runtime adapter/service proof needed |
| Queue release control | Release held work through existing Resume or client send | Held user work and fresh-text continuation become eligible under existing delivery order; no duplicate wake or lost prompt | Web QueuedRunsControl/ComposerPrimaryActions; mobile ThreadRouteScreen Resume; server shared behavior |
| Failed/interrupted worktree setup | Setup fails/interrupted before provider starts; later provider wake | Wake stays queued+held; no provider launch in wrong checkout | ThreadLaunchService test extension; no new visual layout |
| Persistence and blocking | Held only; held+eligible wake; preparing/starting/running/waiting; archived/deleted | Held-only not ready; eligible wake ready only without active work and with live thread; held user run unchanged | SQL and memory ProjectionStore readiness tests; runtimeLayer selects unheld wake |

Local/remote/relay/tunnel transport does not change server eligibility; no client transport/IPC change exists. No separate visual matrix is needed for each transport. Claude buffered and Codex fresh-text are distinct mandatory provider fixtures. Cursor/Grok/OpenCode/Antigravity receive shared scheduling behavior but have no adapter changes; no live verification for them is claimed.

## Evidence assessed

- Supplied [runtime-before transcript](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/f2c8b4b46215655e/runtime-before.txt): main 27e0c684c5, Linux web client, Claude Sonnet 5.5/CLI 2.1.303. Native command and local_agent final notifications occur. Wake ordinal 4 remains queued+held; agent remains running with null result/completedAt after final notification. Good real-application negative evidence. It lacks explicit per-event run/message/provider-turn/native-task correlation and is not an after transcript.
- User reports exact-main red “expected true not equal true” for held wake. This matches runtimeLayer's new assert.notEqual(wake.queueHeld, true). No red command/output artifact was found among the supplied r9 logs; retain exact command, base SHA and failure excerpt before treating red as independently audited. Do not mistake target-test.log for red: it is green (1 passed, 86 skipped).
- Read existing tests.log (257 pass) plus tests-extra.log (52 pass): 309 scoped passes. check-changed.log reports 269 passes plus format/lint/knip/GraphQL/typecheck success. These are overlapping validations, not 578 unique tests. Log says files changed during run; capture command/start/end HEAD or rerun affected verification if provenance cannot establish applicability to ea3642a487.
- Current diff adds wake eligibility, SQL/memory readiness, Stop-window and failed/interrupted-worktree controls. It does not add a focused assertion for the changed Codex commandExecution offer's delivery field. Existing message_text assertion near CodexAdapterV2.test.ts:4955 concerns native child completion, a separate offer path; it does not prove the newly changed command-completion path.

## Exact remaining runtime proof

To be run by the parent only under its own authorized verification scope, with isolated application state and real provider; this audit did not execute these steps.

1. Record exact base/head, app/client, OS, provider model/CLI versions, isolated home, commands and reproduction prompt. Preserve red test command/output at exact base, then green output at exact head. State any stubs, injected frames or service-only harness explicitly.
2. At ea3642a487 repeat the supplied before flow with a genuine held user follow-up, real background command completion during the active/settling root window, and native Agent completion afterward. Record ordered run/attempt/message/provider-turn/native-task IDs, timestamps, source and notification metadata, queueHeld/status before and after each boundary. Await persisted events/worker drain for deterministic service fixtures; no polling sleeps in tests.
3. Show held user run unchanged throughout; wake initially unheld while root blocks it; wake starts after root settlement exactly once. Show authoritative local_agent final notification and persisted completed row for the SAME native ID, non-null completedAt and expected result marker. Show another later wake succeeds, proving the latch is cleared. A scheduler test alone does not establish this issue-level native outcome.
4. Run Stop negative control with native completion after Stop has committed but before active interrupt settles. Show Stop receipt/event, wake held, root interrupted, held follow-up unchanged, and no new provider start after worker drain/resume. Then demonstrate explicit Resume/client release works. Existing integration test establishes the controlled race, but no supplied live transcript does.
5. Codex command completion control: record the actual commandExecution completion offer with delivery=message_text; dispatched message source=server plus notification; held run remains held even beside active work; native turn-start count does not advance until explicit release. After release show exact continuation detail reaches the native fresh turn once. Preserve projected notification item (without attribution fields) to substantiate the no-attribution-UI-change exemption. Do not substitute a native-child completion fixture or synthetic no-notification message.
6. Upload a sanitized runtime-after transcript and red artifact, with ID mapping and explicit observations. No secrets, pairing URLs, credentials or personal conversation content. Link these to the exact tested local commit. A service-only transcript is useful but must not be labeled a full application reproduction. If live Stop/Codex controls are deferred, state that limitation; automated controls cover part of that risk.

No screenshot requirement is inferred solely from server protocol changes. If actual client inspection later reveals a notification rendered as a regular attributed message, withdraw the empty visual matrix and capture before/after on the affected web/desktop and mobile paths with explicit authorization.

FRICTION evidence|Only before runtime supplied; no current-head after or red log in r9|Attach exact-head after transcript and exact-base failing command/output.
FRICTION attribution|Generic source-to-label mapping initially suggested visible change; actual notification conversion strips attribution|Trace the production turn-item route before assigning visual fixtures.
FRICTION provenance|Cached PR head differs and check log reports files changed during run|Bind artifacts to immutable tested SHAs; do not equate cached remote metadata with local audit head.
