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

Reviewed branch `fix/issue-26775`, head [4ecd25f](https://github.com/pingdotgg/t3code/commit/4ecd25f21cf8f3755fff58967daad1fae22a74fd), against the requested merge-base [fe219c4](https://github.com/pingdotgg/t3code/commit/fe219c4de18f5ee37c28cbd3914a5569b1579156). All eight changed files are under `apps/server`: five production files and three existing test files. No changed component renders UI; viewport, theme, account counts, text lengths and responsive layout do not branch in this diff.

## Findings first

1. **The boot-read exception is real; evidence must not describe every connect as grace-bounded.** In [TailscaleStatusReader.ts:84](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/environment/TailscaleStatusReader.ts#L84), `previous === undefined` awaits the shared read without the 250 ms grace. A request overlapping that boot read can wait its remaining 3.5 s status timeout plus process cleanup. This is a residual limitation, rather than a newly introduced delay relative to the baseline. R01 must measure it or explicitly label a deterministic service/RPC harness when real startup finishes outside that window. A client's first connection after the server has warmed is not this fixture. This corroborates the open CodeRabbit finding; no change is requested in this proof pass.
2. **One UI timing recording is justified.** [session.ts:419](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/packages/client-runtime/src/rpc/session.ts#L419) makes `ready` await the first config snapshot; [driver.ts:196](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/packages/client-runtime/src/connection/driver.ts#L196) waits for it before returning a connection lease. [SavedEnvironmentRows.tsx:80](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/web/src/components/settings/SavedEnvironmentRows.tsx#L80) displays Connecting/Connected. W01 shows this transition in a real web client, at one viewport/theme. No static screenshot proves this delay. Desktop uses the same web code, and mobile uses the shared readiness path; native layouts and provider adapters did not change, so neither gets another visual matrix.
3. **The supplied prior artifact cannot establish this head or baseline.** The downloaded transcript identifies [fdf8e89](https://github.com/pingdotgg/t3code/commit/fdf8e89b6b) and [7b87466](https://github.com/pingdotgg/t3code/commit/7b87466731), rather than the pinned pair above. It covers warm failure, healthy status and immediate recovery, but not a recovery after grace, loss, rename, deduplication, cancellation or boot overlap. Its "no-cli" variant actually found a real CLI; it is not a missing-executable fixture. The reporter's current-head PR comment is useful corroboration, not the requested raw, reproducible proof set.
4. **The prior drivers need revision before use.** They hard-code another scratch root and port, poll readiness with sleeps, clear the status log, and lack reliable cleanup on error. The recovery driver changes mode before connecting and returns status immediately, so it does not exercise the late-snapshot path. `connect.mjs` treats an RPC Exit as a timed result; the new capturer must fail unless the first config item is a valid snapshot. `subscribe-hold.mjs` omits direct endpoints and updated config fields. All seven supplied files were downloaded to separate new directories and read, not executed.
5. **The 250 ms figure bounds only the reader's warm wait.** The unchanged Serve self-probe can add up to 2.5 s (the resolver has a 3 s envelope), and without local sshd the unchanged `debug prefs` call can take 3.5 s. Editor discovery and other config loading also contribute. Record total handshake timing and the isolated status timeline; do not impose a 250 ms upper bound on end-to-end connect time. A fake DNS name cannot prove a positive HTTPS endpoint: that needs trusted HTTPS or an explicitly labelled harness.

This is fixture derivation, not an execution pass or merge-readiness verdict. Code, tests, live PR metadata, comments and check status were inspected. No tests, downloaded drivers, servers or browsers were run. No edits, pushes or comments were made to the repository. The forge reported the requested head and 40 successful checks; that does not substitute for the captures below.

## Minimum capture matrix

**Status** describes whether the diff changes this behavior; every required row is currently **uncaptured**. **Transcript** means a chronological protocol recording, including timestamps, requests, ACKs, snapshot contents and CLI start/finish records. This is the requested server-only equivalent of a temporal recording; no server timing row may be replaced by a still. **Recording** means screen video. There are no still-only rows.

Notation: `F` = settled status failure; `A`/`B` = successful status with `a.tail0000.ts.net`/`b.tail0000.ts.net`; `B0` = unchanged bound-interface endpoints; `M` = mDNS target when sshd and a usable hostname exist; `T(A)` = Tailscale remote-open target for A; `H(A)` = HTTPS tailnet direct endpoint for A, only after successful probe. Fix hostname/user, sshd result and bound interfaces per run, and log them. An initial failure means targets `M` (or empty without sshd), and direct endpoints `B0`, not necessarily empty arrays. JSON and secrets in published logs must be synthetic/redacted.

| ID / fixture | Status | Data, sequence and expected head behavior | Capture kind | Seeding / route / harness | Minimum evidence |
|---|---|---|---|---|---|
| **R01 — Connect during boot read** | affected; uncaptured | Fresh reader; status has started and has **not settled**; connect before its 3.5 s timeout. Slow failing CLI, Serve on, no unrelated slow probes. First snapshot waits the remainder of boot status, not 250 ms. Show final `M`/`B0`; a buffered identical re-resolve must not create a distinct network snapshot. | transcript | Real `t3 serve` plus early bearer request, with boot status spawn and request timestamps proving overlap. Make fake `serve` commands return promptly. If app readiness misses the whole window, label this row **service/RPC harness** with immediate layer build/read, a Deferred-held process and TestClock; report real attempt's lack of overlap. Do not extend the production status timeout to manufacture the case. | Before/after pinned revisions. Baseline has no eager shared boot read: show the same early-connect workload and its uncached reads. Head must explicitly prove `previous` was still unknown, not merely call its first client "cold". |
| **R02 — Warm failure, Serve on, connect/reconnect burst** | affected; uncaptured | Boot failure settled; next status hangs past grace and eventually times out. Repeated and overlapping clients, including a reconnect while the same read is pending. Head answers from `F` after one grace per overlapping reader call; first snapshots `M`/`B0`. No network follow-up for failure→failure. Overlapping callers share a status process. | transcript | Isolated real server, `--tailscale-serve`; PATH fake handles `status --json` with >3.5 s delay/failure, other subcommands immediately. Establish boot settlement from raw trace/process events; retain boot log. Bearer ticket→WS→`subscribeServerConfig {}`; ACK valid chunks. Include one `server.getConfig` unary request while a subscription is open to cover the second `loadServerConfig` caller. | Before/after timings and `status` spawn counts, not all CLI commands. Baseline expected sequential ~3.5 s + ~3 s status waits; head's total includes transport/config overhead. Hold beyond settlement to show failure→failure silence, then a client fence request/ACK. |
| **R03 — Warm failure, Serve off** | affected; uncaptured | Same settled failure and slow refresh as R02, with Serve disabled. First snapshots omit only unavailable Tailscale discoveries; the mDNS/bound results stay intact. No repeated 3.5 s wait for warm head requests. | transcript | Same real server setup in a separate timestamped run without `--tailscale-serve`. No Serve process/probe expected; `RemoteOpenTargets` still reads status. | One matched before/after connect and reconnect; baseline ~3.5 s versus warm grace at head. This is the one necessary Serve-off contrast, not a viewport multiplier. |
| **R04 — Fresh success fits grace** | affected; uncaptured | (a) Fast successful boot/read; (b) settled `F`→fast `A`; (c) settled `A`→fast `B`. Each refresh settles comfortably below 250 ms. Initial snapshot must contain the fresh `T(A)`/`T(B)`, and `H` only if self-probe succeeds, rather than stale failure/name. No extra network-only snapshot once the same targets are already initial. | transcript | Real server with switchable fake status returning valid `Self.DNSName`/`TailscaleIPs`; use sshd already present or a labelled NetService harness. Keep one older subscription open and trigger one refresh with `server.getConfig` to prove it also drives subscriber updates. Use status spawn/settle markers, not an assumed fast machine. | Before/after, can share one staged server run with R05–R09. Include status outcomes and first payload; report actual CLI overlap rather than claiming every fast connect can spawn only one process. |
| **R05 — Fresh failure fits grace** | affected; uncaptured | Settled `A`→fast failing read: must drop Tailscale targets in the initial snapshot, not retain `A`. Then change failure cause, e.g. malformed JSON exit 0→nonzero exit; failures compare equal. A third true spawn-error variant belongs to the same failure class, without another visual row. | transcript | Real switchable fake outputs invalid JSON/nonzero status immediately. A controlled missing executable is optional: isolate PATH so the real installed CLI cannot be found. No-sshd prefs must be fast, or use sshd control. | Before/after snapshot and failure markers. Hold old subscriber: first success→failure changes its target projection; failure→different failure must cause no further network snapshot. Do not report RPC Exit as successful connection. |
| **R06 — Late recovery, ACK buffer, shared refresh survives cancel** | affected; uncaptured | Settled `F`; next read captures `A` but is gated >250 ms and <status timeout. Start two subscribers together; cancel one while refresh is pending. Survivor gets stale `M`/`B0`; withhold its first ACK, then release status and ACK. Survivor must receive recovered `T(A)` (and `H(A)` only with verified probe). Configure a hypothetical next status call to fail, and show no extra call is started by re-resolution. | transcript | Real server plus revised gated fake; release via per-run control file/FIFO. Mode must latch at process start. Keep all status records. If exact ACK/release ordering is hard, use the existing production-RPC test style as a **labelled RPC harness**, not a mocked snapshot stream. | Before/after sequence, timestamps, cancellation, ACK boundary, both target arrays and process count. Baseline normally includes recovery in its delayed first snapshot; head stale-first→fresh-follow-up. This also proves `SettledReadOnly` success and no recursive refresh loop. |
| **R07 — Late loss removes previously advertised targets** | affected; uncaptured | Settled `A` with successful HTTPS probe; next read is gated >grace then fails. Head first answers stale `T(A)`+`H(A)`, then follow-up removes both while retaining `M`/`B0`. Repeat failure must not churn snapshots. | transcript | **Labelled service/RPC harness** with real reader/resolver code, controlled sshd/interfaces and HttpClient returning 200. Alternatively a real server with a controlled trusted HTTPS host routed to its well-known endpoint. A fake name plus an unreachable probe does not seed `H(A)`. | Before/after or clearly paired baseline resolver/RPC workload. Required positive→negative proof for both changed fields. Settled-read-only failure must not spawn another read. |
| **R08 — Late success changes name** | affected; uncaptured | Settled `A`; >grace refresh succeeds as `B`. Head first uses A, later snapshot replaces A with B, with no accumulated duplicate host. Test same-field success equality by repeating B and observing no further network snapshot. | transcript | Real staged server is sufficient for remote-open name. To prove HTTPS replacement too, share R07's labelled harness/trusted endpoint setup for A and B. | Before/after; record `magicDnsName`, target hosts/URLs and snapshot count. Exercises previous-success fallback followed by success→different-success publication. |
| **R09 — Status changed, target projection unchanged** | affected; uncaptured | Keep DNS A and all discovery probes fixed; change only parsed `tailnetIpv4Addresses` or HTTPS capability. Reader outcome changes and triggers re-resolution, but target arrays stay equal, so `withLateConfig` emits no network snapshot. Also replay identical status: no reader publication. A successful no-DNS status→failure has the same empty-Tailscale projection and is the corresponding empty variant. | transcript | Real fake changes status-only fields; reliable inner-publication/resolve evidence and negative output count may use a **labelled reader/RPC harness**. Hold the subscriber through settlement and use a driven milestone/fence; a brief screenshot or arbitrary silence does not prove suppression. | Before/after payload/control, plus head's settle/re-resolve marker and network-snapshot count. Explicitly distinguish reader-level equality from target-level equality. |
| **R10 — Network snapshot preserves newer config** | affected; uncaptured | Deliver settings, keybindings/issues and providers updates before a late network resolution. New snapshot must keep all updates. Interleave late editor resolution before and after network resolution, including newly discovered file manager/reveal kind. Environment-theme and usage-source events remain independent and survive client projection. | transcript | **Labelled deterministic production-RPC/`withLateConfig` harness**: drive Deferred/Queue sources, use production accumulator and projection, not hand-written emitted configs. Existing examples are in `ws.test.ts`. Run default capability input and a capability-enabled/on-demand variant; no real providers/paid turns needed. | Before/after where the baseline has no network-follow-up path: document that absence, do not call it a baseline failure. At head, emit current-field digest before/after both interleavings. Existing editor tests alone do not cover a network-triggered full snapshot. |
| **U01 — SSH/mDNS projection controls** | unaffected semantics; no separate new capture required | sshd IPv4 or IPv6-only→Tailscale+M when DNS exists, M without DNS; no sshd→only Tailscale when `RunSSH=true` and `WantRunning!=false`; prefs off/down/failure→none. Null username omits field; blank hostname omits M; FQDN becomes first-label `.local`. | transcript if executed | Existing `RemoteOpenTargets.test.ts`, or labelled NetService/HostProcess/spawner harness. No settings route changes these OS facts. Never stop or reconfigure the host's real sshd for proof. | Code inventory/control, not 2×theme×width repetitions. Use an sshd-present variant for core timing to avoid unrelated `debug prefs` latency. Empty/no-DNS projection is exercised by R09. |
| **U02 — Bound endpoints / Serve guards** | unaffected semantics; no separate new capture required | Loopback/public/hostnames→no bound endpoint; wildcard/specific private IPv4→deduped LAN/tailnet; virtual interfaces omitted; private-network-only cloud filter retains tailnet. Serve off skips read/probe. DNS null, probe error/non-2xx/timeout→omit HTTPS; 200→append H; custom Serve port formats URL. Existing 2.5 s probe/3 s resolver and 5 s config envelopes remain. | transcript if executed | Existing `DirectEndpoints.test.ts`; fake HttpClient/NodeOS/config in a labelled harness for exact interfaces/cloud/probe outcomes. R07 supplies required positive probe evidence; core real-server rows naturally supply failed fake-DNS probes. | Code inventory/control. Do not advertise a fake HTTPS endpoint merely because status returns DNS. No full host/network/platform cross-product. |
| **W01 — Visible reconnect readiness** | affected timing; uncaptured | Same warm failing CLI/Serve-on state as R02; saved environment disabled then enabled. Show Connecting→Connected duration. Exactly one before/after pair, **1440×900, dark**; no layout or light-theme variants. | recording | Real web client at `/settings/connections` connected to a healthy primary, with one saved direct bearer/pairing route to the isolated target; enable its switch. Target's boot read must already be settled. Use the same web bundle/state, label target revision before/after and record from before click until connected. Could also show shell data arriving; not required. | Before/after videos or one clearly labelled paired video plus R02 transcript. Browser/computer use belongs to the authorized capturer, not this read-only pass. No real tokens or pairing URLs in recording. |

**Minimum required set:** R01–R10 protocol transcripts at both pinned revisions, using the row-specific labelled harness fallbacks where necessary, and W01 before/after video at 1440×900 dark. U01/U02 are unchanged branch inventories, not additional mandatory captures. For server rows viewport/theme = N/A. No stills. A single staged transcript may cover several rows if it has explicit row boundaries and input/state markers; do not restart/build a server per table row. R01 requires an actual fresh layer/server; R02 versus R03 requires Serve-on/off runs. Shared healthy/failure transitions can cover R04–R09. R07/R08 can share one controlled service/RPC harness, and R10 needs only one deterministic harness session with the two interleavings.

## Complete path/branch inventory and fixture mapping

- [server.ts:705](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/server.ts#L705) provides one reader to both resolvers and the WS runtime. Its boot refresh starts unconditionally, including Serve-off and CLI-absent environments. Scope lifetime owns it (R01–R03, R06). Startup `ensureTailscaleServe` also runs separate CLI commands; these are not reader status processes and must be identified separately in logs.
- [TailscaleStatusReader.ts:50](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/environment/TailscaleStatusReader.ts#L50): `inFlight` exists→join (R01/R02/R06), absent→claim and fork (R02–R09); caller disconnect must not kill shared refresh (R06). First settled outcome always publishes (R01/R04). Later success keys compare all three parsed fields; identical success suppresses publication (R08/R09), unequal success publishes (R08/R09), success↔failure publishes (R04–R07), failure↔failure suppresses regardless of error (R02/R05). Status output parsing is unchanged in `packages/tailscale`; no additional parsing-layout matrix is introduced.
- [TailscaleStatusReader.ts:80](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/environment/TailscaleStatusReader.ts#L80): unknown previous→unbounded caller wait on pending with underlying CLI timeout (R01 plus fast boot R04); known previous + `SettledReadOnly`→return cached success/failure without refresh (R06–R09); ordinary known previous→fresh success/failure inside grace (R04/R05), or previous failure/success after grace (R02/R03/R06 versus R07/R08). No timer/TTL/polling refresh exists after boot: changing a fake mode alone does nothing until a normal reader caller triggers refresh.
- The only production reader callers are [RemoteOpenTargets.ts:36](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/environment/RemoteOpenTargets.ts#L36) (always) and [DirectEndpoints.ts:129](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/environment/DirectEndpoints.ts#L129) (Serve on). Both are called through [ws.resolveNetworkTargets:1742](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/ws.ts#L1742). All unchanged sshd/username/hostname/prefs branches are U01; all unchanged interface/cloud/DNS/probe/port branches are U02. In-flight coalescing is not a promise that arbitrarily staggered fast reads always use exactly one CLI process.
- `resolveNetworkTargets` runs both resolvers concurrently with separate existing 5 s discovery fallbacks (R02/R03, U01/U02). [loadServerConfig:1752](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/ws.ts#L1752) has two production callers: unary [server.getConfig:2201](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/ws.ts#L2201) and streaming [subscribeServerConfig:3101](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/ws.ts#L3101). Unary has no own follow-up stream but its read can update existing subscriptions (R02/R04). Usage-command and workspace-on-demand options alter provider payloads, not target discovery; theme/source feature flags gate existing events (R10).
- The streaming RPC acquires Tailscale subscription before initial discovery, buffers through discovery/first ACK, then re-resolves every queued settled change with `SettledReadOnly=true` (R01/R04/R06). Each open subscriber re-resolves, without initiating a new status read; flap/cancel case R06 proves the important shared lifetime and no-loop properties. Empty targets are valid snapshots, not protocol errors.
- [withLateConfig:320](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/ws.ts#L320) has one production caller, in that streaming RPC. Equal target arrays suppress output (R04/R05/R08/R09); differing arrays merge into current config and emit a full snapshot (R06–R08/R10). Ordering and full-array JSON equality matter, not just counts. Late editor filters compare editor list and optional reveal kind; reveal only probes for `file-manager`; resolved editor config replaces old editor fields. Settings, keybindings/issues and providers update accumulator state; themes/usage-source events pass through (R10). There is no added loading/error UI branch.
- The changed tests are [DirectEndpoints.test.ts](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/environment/DirectEndpoints.test.ts), [RemoteOpenTargets.test.ts](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/environment/RemoteOpenTargets.test.ts), and [ws.test.ts](https://github.com/pingdotgg/t3code/blob/4ecd25f21cf8f3755fff58967daad1fae22a74fd/apps/server/src/ws.test.ts). Existing new cases cover a hung shared read, warm failed reuse, fast recovery, late remote-target recovery and no recursive refresh. The WS helper settles startup failure before opening its subscription and mocks direct endpoints empty, so those cases do not prove R01 or positive HTTPS loss/rename. Tests were read, not run here.
- Client follow-through: web Settings, command-palette environment status and chat synchronization share readiness; desktop wraps web; mobile uses the same runtime. Direct endpoints are also used for learned routes/link requests; remote-open targets feed web editor-link resolution, with desktop-local/loopback execution and SSH-alias precedence unchanged. Current route learning reads `initialConfig`, so a late endpoint snapshot proves config delivery, not automatically learned-route persistence; no proof should claim otherwise. No providers, MCP tools, scheduled task paths or wire schemas change. Local, remote/direct and relay connects use the same server RPC discovery; no theme, viewport, provider or transport multiplier is needed for this server-only change.

## Capturer run contract

- Everything goes under a new timestamped child of `/tmp/lead-26794-r2/proof-audit-1/` (or the lead's separately assigned scratch root). Keep server data isolated with an explicit base directory; do not touch live T3 state. Use the lead's existing revision checkouts; this audit did not create/change any checkout.
- Record full revision, process PID, flags, non-secret environment, CLI script hash/content, platform, fixture ID and actual startup/read timeline. Retain raw CLI logs including startup; count only `status --json` separately from `serve` and `debug prefs`. A fake status invocation must latch its planned result at spawn so a mode switch does not rewrite an already-running read.
- Fake `serve` should complete immediately, and fake `debug prefs` should be immediate controlled JSON, except when explicitly demonstrating unchanged outer-probe behavior. Do not let the old fake's blanket 5 s sleep turn startup/probe time into alleged reader timing. Prefer gates for the >250 ms/<3.5 s success cases, with observed markers, rather than a fragile exact 250 ms boundary.
- Time ticket request→WS open→RPC request→first **snapshot**, and all follow-up snapshots. Print both arrays and relevant config digests, ACK every expected chunk except the intentional R06 hold. Handle Ping/Pong, RPC Exit/error, missing snapshot and connection close as explicit outcomes. Validate first snapshot before counting success. Record connection termination and process cleanup.
- On head, verify settlement through trace/process markers before calling a fixture warm. On a loaded machine, report measured residual boot wait and observed durations, not hard wall-clock test assertions. For negative emission cases, use driven completion/resolve markers and a fence, not an arbitrary short sleep. Deterministic harnesses should use Deferred/Queue/TestClock.
- No arbitrary server/build restart per row. Batch staged scenarios and keep run labels. Before/after means the exact pinned revisions, with equivalent fake behavior and host state. A baseline lacking the new follow-up mechanism is an expected difference to document, not an excuse to invent baseline events.
- Stop only tracked spawned PIDs; retain evidence and raw logs until uploaded. Never delete another lead's files. Record free space and stop if available disk drops below 5 GB.

FRICTION:
- tool | Python urllib received HTTP 403 on the first artifact download; curl with a browser User-Agent succeeded, and all seven files were then read | use curl with an accepted User-Agent for these public artifact URLs.

VERDICT: INSUFFICIENT R01–R10 protocol transcripts at the pinned before/after revisions; W01 before/after recording at 1440×900 dark