Proof audit, pass 1, for [#25754](https://git.cafe/pingdotgg/t3code/pull/25754).

Reviewed [db41c18dc6](https://git.cafe/pingdotgg/t3code/commit/db41c18dc69938e7196e221cc7e79982d82e5815) against merge-base [5808469018](https://git.cafe/pingdotgg/t3code/commit/5808469018fb95676af148e7a7662c23665c67a3), in `/home/ubuntu/wt/pr-25754`. Forge metadata agreed with the requested head. The checkout was clean on entry. This is a proof-design audit, not a new performance measurement or merge-readiness verdict. No tests, capture drivers, browsers, devices, dev servers, edits to the checkout, pushes, or comments were run/made.

**Findings, before the matrix**

1. The lead's scope description is correct: seven changed files, with production changes only in server thread replay, the shared client history queue key, and authorization/resolution descriptor propagation. There are no render-path changes. Runtime transcripts and request/byte/order measurements fit the diff; screenshots would not establish these claims. Web and desktop share the web state binding; mobile binds the same client-runtime functions. Provider adapters and wire schemas do not change.
2. The replay improvement applies only after the existing raw guards pass: at most 128 stored events and at most 1,048,576 stored payload bytes. Coalescing cannot rescue a raw-over-budget reconnect. Encoded replay sizing happens after coalescing. The proof must use the actual server subscription, retain completion/boundary events, and show replay -> optional synchronized marker -> live tail, including sequence gaps. A helper-only byte comparison misses the changed call site and fallback decisions.
3. Descriptor reuse is per successful authorization attempt, not a new cross-attempt cache. The old 10-second direct descriptor cache is removed for both bearer and direct DPoP. Cold bearer preparation goes from descriptor -> ticket -> descriptor to descriptor -> ticket. Warm preparation within the old TTL still has two requests, but descriptor validation moves before credential transmission. Direct DPoP has the same direct-origin saving, with any relay bootstrap/exchange requests counted separately. Pure relay and primary-without-bearer still need the resolver's fallback descriptor fetch. SSH also uses bearer authorization after its gateway prepares the endpoint.
4. Reusing the pre-ticket descriptor changes which metadata `prepare` and `prepareForUpdate` observe if the same host changes protocol/capabilities during ticket creation. Capture this ordering explicitly; do not claim the post-ticket descriptor check remains. This is a documented tradeoff in the current PR body, not a newly demonstrated defect. A warm identity mismatch test alone does not prove the ordering: log whether the credential-bearing ticket request was sent.
5. The scratch benchmark at `/tmp/lead-25754-r1/tests/remotePerformance.bench.ts` is useful for actual resolver preparation and actual command scheduling. Its “remote message replay” section applies projection events in memory; it does not call the changed server subscription or measure RPC replay bytes. Its imports are relative to client-runtime `src`, and the package test config includes `*.test.ts`, so passing the external `*.bench.ts` unchanged to `vp test run` is not a runnable capture recipe. Adapt its imports/runner in scratch. Existing PR numbers and test assertions are leads for captures, not new before/after evidence from this pass.

Four fixture families collapse orthogonal dimensions without taking their Cartesian product. Each named variant below is a subcase in the same driver/artifact. All four artifacts are the minimum capture set: three changed behavior families plus the descriptor-fallback control. All are **timed transcripts** because they depend on interaction ordering or time. No video is needed for these nonvisual paths.

| Fixture and status | Diff affected; data and branch variants | Minimum before/after proof and acceptance | Produce on this Linux VM |
| --- | --- | --- | --- |
| **R1 — bounded reconnect replay** — **PENDING CAPTURE**, timed transcript | **Changed:** `afterSequence` resume with coalescible persisted `message.updated` and `turn-item.updated`. Seed one thread with 64 assistant streaming full-text replacements, text length `256 * i`, same message/run; optionally append completed text and one post-high-water live event. Use a smaller paired message/turn-item sequence for the paired-family variant so raw bytes remain under budget. Vary: assistant streaming versus completed/non-assistant messages; running streaming `assistant_message`/`reasoning`; running `command_execution`, `file_change`, `file_search`, `web_search`, `dynamic_tool`; non-running, non-streaming, other item types and unrelated event boundaries; same-family identity/run changes and interleaved message/item families. **Controls:** cursor absent, equal to high-water, ahead of high-water; 128 versus 129 raw events; raw payload at/beyond 1 MiB; projected encoding beyond 1 MiB if constructible under raw limits; retained `thread.created` with existing shell versus deleted/missing shell; unknown stored event types; completion marker on/off. Snapshot controls use bounded/full and body-dedupe/compact flags as negotiated. | One paired base/head transcript reports raw count/bytes, emitted item count, projected item JSON bytes, and (if quoting RPC sizes) actual RPC-serialized chunk bytes separately. The simple 64-update variant emits 64 replay events before and 1 after; latest full text and completed text match. Log survivor sequence/id/text/status, synchronized marker, live source cursor and live event. Show boundary/identity changes survive in insertion order; applying the survivors gives the same final projection, also when reconnecting at each survivor cursor. Fallback controls must still snapshot, with history cursor/flags intact, rather than evade raw guards. Unknown rows must not prevent the live tail from resuming at high-water. Shell-only subscription is an unchanged control. Do not require every subcase to get faster. | Make a scratch `R1.test.ts` from the in-memory SQLite `ReplayTestLayer` and `subscribeOrchestrationV2Thread` harness in `apps/server/src/ws.test.ts`; run through `vp test run` from `apps/server` with a scratch config including that external test. Import production code from each pinned checkout, never copy the new coalescer call into the driver. Insert deterministic rows, use Deferred/Queue or a finite live stream for the marker/tail handshake, and log the actual subscription output. Reuse item constructors and survivor-cursor assertions from `ThreadLiveEventCoalescer.test.ts`. The original benchmark's projection loop is not a substitute. |
| **R2 — fresh direct authorization** — **PENDING CAPTURE**, timed transcript | **Changed:** saved bearer; primary with bearer; SSH gateway -> bearer; learned direct `t3-connect` DPoP. Use one environment descriptor with current protocol and self-update capabilities, ticket response, saved profile/credential, and a fake gateway for SSH. For DPoP provide a matching account/key-bound unexpired token; add cold/expired/rejected token variants with bootstrap and exchange responses. Run cold, warm under 10 seconds, and after the old TTL; swap environment identity between attempts; fail descriptor before ticket; reject ticket. **Metadata interaction:** keep identity stable but change protocol/serverVersion/self-update capabilities while ticket response is held. Include current, missing/old, and newer protocol; compare ordinary `prepare` with `prepareForUpdate`. | One paired transcript logs method/origin/path, authorization **kind only**, descriptor identity/protocol/capabilities, ticket freshness, result/error and phase order. Cold direct bearer: two descriptor GETs -> one, total HTTP requests 3 -> 2. Warm under TTL: total remains 2 -> 2; correct head order is descriptor then fresh ticket. An identity-swapped warm head attempt fails before sending a ticket/token; base may fail only after sending the ticket. Fresh descriptor per attempt remains after TTL. For direct DPoP count only the learned direct origin for the one-GET saving and list relay bootstrap/exchange separately. Verify all four broker paths actually carry the descriptor into resolution; SSH gateway setup is outside the 3 -> 2 claim. `prepare` still gates incompatible protocol, while `prepareForUpdate` returns descriptor/prepared data without that gate. Log the intentional pre-ticket metadata observation versus base post-ticket observation. No network-latency claim follows from request counts. | Adapt `prepareSample` plus the real authorization harness in `authorization/layer.test.ts`, using the real authorization service **and** real resolver; existing resolver-only tests mock authorization without descriptors and cannot prove propagation. Extend target/profile selection for the four brokers and mock only HTTP, credential stores, cloud signer/bootstrap and SSH gateway. Use a virtual clock for TTL variants and Deferred gates for the metadata swap. Run a scratch test from `packages/client-runtime` for each revision. No real SSH, cloud credentials, or phone is required. |
| **R3 — no supplied descriptor and route fallback** — **PENDING CAPTURE**, timed transcript | **Unchanged observable controls through changed resolver:** primary with no bearer; pure relay DPoP with no `directEndpoint` (cached token success and renewal/expiry/auth-invalid/transient endpoint failure). Descriptor is absent from authorization, so the resolver must fetch it. Include a mismatched/unsupported fallback descriptor and an unavailable/mismatched learned direct route with relay alternate. Add preflight -> connect to show those are distinct preparation attempts. Preserve cached DPoP token on transient direct failure; auth-invalid renewal and pure-relay refresh follow their existing paths. | One paired transcript shows no-bearer primary performs exactly one fallback descriptor fetch and no ticket; warm pure relay does ticket -> one fallback descriptor GET; cold pure relay additionally does its existing bootstrap descriptor/exchange, with no claimed saving. Wrong identity and unsupported protocol remain blocked; update preparation keeps its documented bypass. Direct-route failure still reaches the relay route where appropriate, without discarding the reusable token on a transient direct failure. Distinguish driver route probes and preflight preparation from resolver counts so an end-to-end connect is not mislabeled “2 HTTP requests”. | Extend R2's HTTP recorder with no-token primary and `RelayConnectionTarget`; drive the real `ConnectionResolver`. For the alternate-route/preflight subcase use `ConnectionDriver`/`connectOverRoutes` with fake RPC-session ready gates and deterministic route checks, adapting `connection/driver.test.ts`. Record route/attempt ids and each prepare separately. Run from `packages/client-runtime` against both revisions. Session/sign-in/key-ownership guards are unchanged; do not add a separate exhaustive authentication campaign. |
| **R4 — history versus thread commands and live state** — **PENDING CAPTURE**, timed transcript | **Changed:** one shared AtomRegistry/scheduler, environment E/thread T, history HTTP page held pending; invoke `startTurn` and, in a separate sample with an active run, `interruptTurn`. Compare idle history. Also hold an ordinary same-thread command first, then request history (reverse ordering). Two history requests for E/T must remain serial; ordinary commands remain serial; another thread/environment stays independent. Load ordinary older history and `throughEntryId` progressive conversation -> full history. Let a streaming/completed update arrive while the page waits; then release older overlapping rows. Variant: replace bounded snapshot/cursor or delete/close thread before release; history error/noop/busy/cancel must release the history queue. | One paired transcript records history-start, command invocation, dispatch, receipt, history release/completion, reconciliation and final projection/meta. With controlled 250 ms history delay and 50 ms reply, base dispatch waits for history, head dispatch precedes history release; idle has no history penalty. Separate dispatch latency from receipt/provider termination; Stop does not measure provider shutdown. Prefer a Deferred gate/event-order assertion as the deterministic claim and report repeated raw timing samples only as fixture latency. Show final latest/completed text is retained, older pages merge without losing live state, stale-cursor replies no-op, Stop's detached pending-work reconciliation still happens, and both queue types keep their own ordering after success/failure. | Adapt `commandSample` and `state/threadCommands.test.ts` with explicit phase logs, plus the real state/history harness from `state/threads-sync.test.ts` for the overlap variant. The command-only benchmark stubs `loadEarlier`; it proves scheduling but cannot alone prove merge correctness. Run each action and pending/idle pair separately from `packages/client-runtime` at both revisions; use Deferred/Queue acknowledgements instead of polling. A wall-clock scratch benchmark can retain the controlled delays, but do not transplant sleeps or timing deltas into committed tests. |

**Changed-path inventory and why these rows cover it**

- Server: [ws.ts](https://git.cafe/pingdotgg/t3code/blob/db41c18dc69938e7196e221cc7e79982d82e5815/apps/server/src/ws.ts#L789) exposes the subscription through the `ORCHESTRATION_V2_WS_METHODS.subscribeThread` RPC handler. The clients call it from [threads.ts](https://git.cafe/pingdotgg/t3code/blob/db41c18dc69938e7196e221cc7e79982d82e5815/packages/client-runtime/src/state/threads.ts#L883) for initial/resumed/foreground subscriptions and the generic [orchestration.ts](https://git.cafe/pingdotgg/t3code/blob/db41c18dc69938e7196e221cc7e79982d82e5815/packages/client-runtime/src/state/orchestration.ts#L82) subscription family. R1 covers its only changed branch: loaded replay is coalesced before encoded sizing/initial emission. The live 50 ms coalescer, full/bounded snapshots, wire body dedupe, shell replay, raw limits, legacy hydration and unknown-type handling are existing behavior; the listed controls guard their boundaries. Each provider reaches the same normalized event stream; fixtures vary normalized event types rather than launch every provider.
- Coalescing shapes: [ThreadLiveEventCoalescer.ts](https://git.cafe/pingdotgg/t3code/blob/db41c18dc69938e7196e221cc7e79982d82e5815/apps/server/src/orchestration-v2/ThreadLiveEventCoalescer.ts#L23) coalesces assistant streaming messages and the seven listed running item variants; assistant_message/reasoning also require streaming. Everything else is a flush boundary. Keys include thread, event run, event type, item type and id; same-family identity changes clear the update run while paired message/item families may coalesce. Survivors keep original positions/sequences. This affects tool/reasoning replay as well as message text.
- Authorization/resolution: [resolver.ts](https://git.cafe/pingdotgg/t3code/blob/db41c18dc69938e7196e221cc7e79982d82e5815/packages/client-runtime/src/connection/resolver.ts#L89) has primary token/no-token, saved bearer versus `authorization: t3-connect`, relay and SSH brokers. R2 covers returned descriptors from bearer and direct DPoP; R3 covers their absence for unauthenticated primary and pure relay. Missing/wrong profile, profile environment mismatch and missing/wrong credential fail before the changed authorization work; these are unchanged prerequisites, not independent performance fixtures. SSH saved/repaired-token persistence and profile updates also precede authorization and remain unchanged.
- Resolver callers: [driver.ts](https://git.cafe/pingdotgg/t3code/blob/db41c18dc69938e7196e221cc7e79982d82e5815/packages/client-runtime/src/connection/driver.ts#L181) calls `prepare` for connection attempts and preflight. [outdatedHostUpdate.ts](https://git.cafe/pingdotgg/t3code/blob/db41c18dc69938e7196e221cc7e79982d82e5815/packages/client-runtime/src/connection/outdatedHostUpdate.ts#L50) calls `prepareForUpdate` for describe/update. Those two methods share authorization; only ordinary prepare applies the protocol gate. The public HTTP-only `authorizeDpopHttp` path does not call changed direct verification, does not return a descriptor and has no new performance behavior. DPoP token-cache success, refresh and rejection select different HTTP sequences; R2/R3 keep them visible without claiming new retry behavior. Local, LAN/tailnet, remote and relay routes all enter these same branches; driver probe traffic remains additional.
- History entry points: [web ChatView](https://git.cafe/pingdotgg/t3code/blob/db41c18dc69938e7196e221cc7e79982d82e5815/apps/web/src/components/ChatView.tsx#L443), [web citation reveal](https://git.cafe/pingdotgg/t3code/blob/db41c18dc69938e7196e221cc7e79982d82e5815/apps/web/src/components/chat/citationProcedure.ts#L203), and [mobile ThreadRouteScreen](https://git.cafe/pingdotgg/t3code/blob/db41c18dc69938e7196e221cc7e79982d82e5815/apps/mobile/src/features/threads/ThreadRouteScreen.tsx#L366) call the shared command, including `throughEntryId`. Desktop wraps the web client. The queue key uses only environment/thread, so both history forms separate from mutations and still serialize with each other. Missing controller/handler yields noop. No additional Settings/palette/keybinding history implementation was found.
- The queue-key change releases **every** command sharing the old environment/thread key in [threadCommands.ts](https://git.cafe/pingdotgg/t3code/blob/db41c18dc69938e7196e221cc7e79982d82e5815/packages/client-runtime/src/state/threadCommands.ts#L143): create/delete; closeGuestShare/resolveGuestMessage; archive/unarchive, settle/unsettle, snooze/unsnooze; pin/unpin wrappers; reorderPin/reorderActive; setAutoSettle; visit/markUnread; updateMetadata; link/unlink/watchPullRequest; setRuntimeMode/setInteractionMode; startTurn/interruptTurn; respondToApproval/respondToUserInput/dismissUserInput; revertCheckpoint/stopSession; resumeThreadQueue/promoteQueuedRun/cancelQueuedRun/retryWorkspacePreparation/editQueuedRun; uploadFeedback; and forkFromRun using the source thread. `mergeBack` has a three-element key already and never shared history's two-element key. R4 samples Send and Stop as the observable representatives and checks serial ordering once; duplicating the same scheduler proof for each command would add no distinct behavior. Direct server/MCP/scheduled-task command dispatch does not use this client Atom scheduler and has no queue change.
- Interactions: R1 checks replay -> marker -> live and reducer equivalence; R2 checks descriptor -> credential request -> compatibility/update metadata; R3 checks direct -> relay and preflight -> connect; R4 checks pending history <-> commands, live updates and stale snapshots. A full auth x replay x command Cartesian product is unnecessary: none of these changes branches on another one's implementation. One optional combined scripted session may reuse these fixtures, but is not a substitute for their branch outputs.

**Capture handling and review limits**

Keep driver/config/output files under `/tmp/lead-25754-r1/proof-audit-1/`. The capture operator needs an independent checkout/source tree for the pinned base; the existing main checkout is at a different revision and must not be called “before”. Do not reset either checkout. Configure the scratch runner to select only the scratch tests and resolve dependencies from the owning package; do not write/copy a benchmark into tracked `src`. Run base/head in fresh processes with equivalent data/options, record full revision ids and raw samples, and redact tokens/tickets/proofs. Upload driver and paired transcripts with ghdrop for a later proof pass. No dev server is necessary; if used instead, give it an explicit isolated scratch home with `T3CODE_DEV_SEED=0` and never point it at live T3 home.

Coverage completed in this pass: complete seven-file diff, changed production code in context, immediate callers, replay/coalescer guards, descriptor broker/fallback/protocol/update paths, command scheduler and history merge guards, relevant existing test harnesses, supplied scratch benchmark, and live GitCafe PR metadata. Existing tests were inspected, not rerun. All four before/after artifacts remain to capture; no performance numbers in the PR description were independently verified.

FRICTION: none

VERDICT: INSUFFICIENT R1, R2, R3, R4 paired before/after transcripts still to capture