# issue14699 — read-only proof audit, pass 1

Scope: actual iOS Swift native client, [head 2b0311a07a](https://git.cafe/pingdotgg/t3code/commit/2b0311a07aea2866fb8cf452118d8495669c89f1) versus [base 4619c0bca6](https://git.cafe/pingdotgg/t3code/commit/4619c0bca6a385e53f3479e4e52a9cdf2d12ff62) (`origin/t3code/rebuild-mobile-app-swift`). Local HEAD and base ref matched. Only NativeFeatureClient.swift changes: 41 additions, 5 deletions. No repository edits or native execution performed.

## Smallest meaningful fixtures

Use enabled active A and passive B, distinct labeled projects and stopped threads on each, plus one archived A thread and saved B history. Keep A healthy except for the route-recovery step. Use isolated native cache: empty or preseeded, with recognizable stale rows and newer server rows. TCP refusal means closed port, not rejected credentials. A single route per host suffices except the route-recovery fixture, which needs a working fallback for A. Do not infer a native six-second completion bound from the host transcript: shell loading also awaits auth/config and may try alternate routes.

Every row below requires a timestamped **native screen recording**; no row is satisfied by a still image or host log. Status in every row is **UNVERIFIED — cannot-verify ios-swift; cannot capture here**.

| Row | Cache / passive condition | Native execution must establish | Required recording | Status |
|---|---|---|---|---|
| E1 | Empty / B answers | A home becomes usable after A loads; B projects/threads arrive eventually without replacing A connection/selection. Open A thread before B completion, then B thread after arrival; archive list eventually loads. | Launch → first usable A home → A interaction → B arrival/open. Run base and head. | UNVERIFIED — cannot-verify ios-swift; cannot capture here |
| E2 | Empty / B accepts TCP, never HTTP | A first render and thread interaction precede B timeout; later B failure does not clear A or show global failure. | Launch → A thread open/back → B timeout/failure. Run base and head. | UNVERIFIED — cannot-verify ios-swift; cannot capture here |
| E3 | Empty / B refused | A remains usable; B failure is scoped to B and does not become A pairing/global error. | Launch → A interaction → B failure shown in connection management. | UNVERIFIED — cannot-verify ios-swift; cannot capture here |
| C1 | Cached A+B / B answers | Saved lists appear first; live A refresh and connected state precede passive completion; B stale rows become live without duplicates or selection reset. | Launch → saved state → live A → A interaction → live B/open. Run base and head. | UNVERIFIED — cannot-verify ios-swift; cannot capture here |
| C2 | Cached A+B / B hangs | Saved B lists/history remain available and honestly offline; live A becomes connected/usable before B completes, remains so after failure. | Launch → saved state → live A/thread interaction → B timeout → saved B history. Run base and head. | UNVERIFIED — cannot-verify ios-swift; cannot capture here |
| C3 | Cached A+B / B refused | Live A is unaffected; saved B rows/history survive refusal with B-scoped failure. | Launch → live A interaction → B failure → saved B history. | UNVERIFIED — cannot-verify ios-swift; cannot capture here |
| P1 | B-only cache / B hangs | Any restored shell triggers cached branch even without A cache. B saved rows must not imply A is live; A then populates independently and becomes usable. | Launch → B-only saved state → live A/open → B failure. | UNVERIFIED — cannot-verify ios-swift; cannot capture here |
| R1 | Empty AND cached (two runs) / B held pending | After live A load completes, break its selected route; A fallback/reconnect and thread interaction must work while B remains pending. Verify routeSnapshotLoads no longer gates recovery; later B publish must preserve latest A connection/detail. | A ready → route break → fallback recovery/open → release B response/failure. | UNVERIFIED — cannot-verify ios-swift; cannot capture here |
| S1 | Empty AND cached (two runs) / B response held | Switch active session to healthy C while old B work is pending, then release B. No stale A selection/connection, old shell resurrection, or wrong thread routing; C remains usable. Session generation guard is affected. | A ready → switch C → C thread open → release old B → C still usable. | UNVERIFIED — cannot-verify ios-swift; cannot capture here |
| X1 | Empty AND cached (two runs) / B response held | Disconnect while passive work is pending, then release it: no stale publish/repopulation. Repeat initialSnapshot/reload to cancel superseded startup work. Cached variant also cancel while active refresh is held; subsequent session route recovery must not remain blocked by load-counter imbalance. | Pending phase → disconnect/reload → release old work → reconnect/use current session; include cached active-refresh cancellation phase. | UNVERIFIED — cannot-verify ios-swift; cannot capture here |

## Affected render and interaction paths

- FeatureRootModel.start awaits initialSnapshot before clearing isLoading and consuming client events. Prove both first install and buffered later snapshot application in the actual native UI.
- Home aggregate project/thread lists, active computer connection/detail, passive computer status, cached history and later live replacement; opening A/B threads and preserving their environment routing.
- Active polling and archived refresh start after active load (or after cached initial install); detail/archived interactions must remain functional during passive loading.
- Connection management, pairing/reloadAfterConnection, reload, enable/disable/remove computer, and addProject call initialSnapshot or reload it. Cover representative reload, switch and disconnect in S1/X1; these share the changed service path rather than requiring a full Cartesian UI matrix. Removal/disable must not resurrect late results (load-generation/revoked-cache guards remain relevant).
- Route recovery checks routeSnapshotLoads == 0. R1 specifically exercises the changed exclusion of passive work, rather than merely observing home paint.
- backgroundSnapshot still loads all enabled environments; this patch alone does not prove foreground/resume/manual background refresh has the same latency behavior. Web, Electron and React Native are not proof surfaces for this Swift change. No provider-specific adapter changes.

## Minimum capture set

One continuous recording per row/run above; a recording may contain labeled sequential runs, but each run needs visible launch/cache condition, interactions and completion/failure. Compare base/head for E1/E2/C1/C2 to establish regression and healthy baseline behavior. Capture the remaining rows on head. Record monotonic launch, first saved render, first live A render, first successful interaction, and B completion/failure times in companion native logs keyed to the video. Screen recordings must span the pending interval and the late completion; stills cannot prove timing or responsiveness. Extra standalone screenshots are unnecessary. No recordings or screenshots exist from this pass.

## Available host-only evidence

Supplied `/tmp/14699-runtime/transcript.txt`, described as real main servers on ports 47621/47622, reports:

| Host setup | A | B | Evidentiary limit |
|---|---|---|---|
| Both answer; isolated empty server state | HTTP 200, 38 ms | HTTP 200, 35 ms | Hosts respond; zero projects/threads cannot prove native lists. |
| B accepts TCP, sends no HTTP | HTTP 200, 8 ms | TimeoutError, 6008 ms | Establishes independent host response/failure setup only. |
| B closed/refused | HTTP 200, 6 ms | URLError, 1 ms | Establishes refusal setup only. |

These are supplied transcript observations, not rerun here, not Swift requests or native reproduction, not UI timing, and not captures. The transcript itself does not identify ports or record a native build/device. No host evidence is promoted to a passing native row.

## FRICTION

Linux VM has no Xcode, iOS simulator or attached native execution surface. Actual Swift build/test and screen recording cannot be performed here. Existing source guards support the intended design but cannot establish cancellation timing, event/render ordering, route recovery, cache correctness or interaction responsiveness. No browser/server started, no fabricated captures, no repository changes. Next executor needs macOS/Xcode with an actual Swift iOS client on simulator/device and isolated cache plus controlled host responses; execute and record the rows above.

## VERDICT: INSUFFICIENT cannot-verify ios-swift

All native rows remain unverified. Source inspection and host-only transcript are insufficient to approve the native behavior or claim issue resolution.