# Native evidence capture index — issue 14691 Result: cannot-verify ios-swift. All 15 rows UNVERIFIED; zero native captures; zero passing runtime claims. Target: base 4619c0bca6; HEAD 6b0ce9b0bc70939c7cd1a81a009b0af70077fed5. HEAD identity checked read-only. ## Capture-route check Prior-pass route check (not repeated in this refresh): local OS Linux. command -v xcrun, xcodebuild, and swift returned no paths. Bounded device_list(hostId="local") returned: "Agent device access is turned off for this environment." No device opened. No fleet hosts contacted; no browsers/servers launched; no Swift installation attempted. ## Shared prerequisite P0 An authorized native iOS runtime on a macOS/Xcode host with iOS SDK and Simulator or physical iOS device, the actual apps/swift-ios SwiftUI app built/installed at BOTH base and HEAD, isolated app storage and disposable real A/B/C host fixtures, production-clock continuous app video plus sanitized correlated request/cancel/auth/catalog/socket logs. A native fixture driver and deterministic endpoint/fault control must be provided or implemented there. No native driver is demonstrated here. Record build SHA, device/iOS, logical width, appearance/cache state and host SHA. Cover compact iPhone/light R1–R8, regular iPad/dark long-title R1, pending-response rotation R10/R11; identify iOS 17/current-runtime coverage gaps. No RN/Expo/EAS substitution. ## Every affected row ### R1 — UNVERIFIED / cannot-verify ios-swift Scenario: Foreground merged home; warm catalog/cache; B rename while C shell is held 4.5 s; repeat with B/C labels and response order swapped Required proof: On head, changed healthy row appears before held peer completes; next healthy shell begins after its completion plus fast 5 s without waiting for C. Base/head video and timestamps; include a second healthy mutation on the next poll. Hold C across a later tick using an ancillary-stage delay for R3 if the 6 s shell limit prevents it. Exact prerequisite: P0, plus Real B/C delayed-response control, swapped response order, next-poll mutation. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R2 — UNVERIFIED / cannot-verify ios-swift Scenario: Same home, B/C both unchanged and quiescent; then mutate B immediately after an idle poll Required proof: Initial timer is 5 s; unchanged success selects idle 10 s; change selects fast 5 s for next poll. Show at least two unchanged cycles then changed cycle. Do not claim mutations during idle arrive within 5 s: idle wait plus endpoint work applies. Exact prerequisite: P0, plus Production-clock recording covering two unchanged cycles and an idle-period mutation. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R3 — UNVERIFIED / cannot-verify ios-swift Scenario: B fast, C pending across multiple ticks (hold authSession/catalog or route fallback as well as shell); mutate B twice Required proof: Healthy rows/cadence continue; at most one aggregate load for C at a time; C request is not restarted at each B tick. Record pending request ownership, two B updates, C release and its eventual row. R1 alone does not cover an outstanding request spanning two ticks. Exact prerequisite: P0, plus Auth/catalog/route delay control spanning multiple ticks; per-request ownership logs. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R4 — UNVERIFIED / cannot-verify ios-swift Scenario: B unchanged succeeds first (arms 10 s); C then returns changed shell or unchanged-but-busy shell before that timer fires Required proof: Late C publishes immediately; the next tick uses the earlier of the existing pending deadline and late completion + 5 s. Shorten only when the latter is strictly earlier; preserve the pending deadline near expiry. Record early-shortening and near-expiry preservation, stale tick rejection/no duplicate scheduling, separately for changed and unchanged-busy answers. Exact prerequisite: P0, plus Precisely released changed and busy-only late answers both early and near idle timer expiry; correlated pending deadlines. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R5 — UNVERIFIED / cannot-verify ios-swift Scenario: One passive remains busy while the other answers first; then busy-to-idle transition. Variants: session starting/running, latestTurn running, pending approval, pending input, background working/monitoring Required proof: Seven predicate variants must be visibly/semantically seeded. Each keeps 5 s cadence even when shell payload is unchanged; clear the predicate and demonstrate return to 10 s when all quiescent. Include a busy C load spanning later B-only cycles to test whether cached C work remains represented in cadence. These variants share the scheduling branch but not their source data requirements. Exact prerequisite: P0, plus All seven real work-state predicates, clearing each, and cached busy C across B-only cycles. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R6 — UNVERIFIED / cannot-verify ios-swift Scenario: C timeout/unreachable with saved rows, B changes or remains busy; then C recovers Required proof: B publishes without waiting for C failure; C retains last-known rows with disconnected indication. Transient failure records an absolute ContinuousClock deadline at failure handling + 20 s, not a decrementing tick budget. C is eligible only on a later tick at or after that deadline; an early/pulled-forward tick must not retry it. B stays fast; recovery clears the deadline and publishes. Record >20 s from failure, timestamps and all request counts, including a failure arriving mid-wait and multiple earlier ticks. Repeat all-passive-failure/recovery; eligibility is not an exact 20 s dispatch guarantee. Exact prerequisite: P0, plus Transient/timeout injection including mid-wait failure, absolute failure/retry timestamps, early-tick request counts, last-known rows, >20-second retry/recovery observation, all-failure variant. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R7 — UNVERIFIED / cannot-verify ios-swift Scenario: Passive C credential rejected; B healthy; then re-pair C Required proof: C does not retry each 5/10 s; absolute retry deadline at failure handling + 24 h, evaluated on subsequent ticks; re-pair replaces runtime/restarts refresh and permits recovery. A short clip plus request log proves only the observed suppression window, not 24 h. Exact full-duration suppression remains unverified without a real-duration capture or separately labelled scheduler test. Single-route/direct and managed/multi-route reachability distinctions require labelled segments. Exact prerequisite: P0, plus 401/re-pair fixtures for direct and managed routes; full real-duration evidence for 24-hour suppression (short capture cannot establish it). Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R8 — UNVERIFIED / cannot-verify ios-swift Scenario: B genuinely empty shell (no projects/threads), then project/thread creation, rename, archive/removal; C delayed; raw IDs collide across B/C Required proof: Successful empty shell counts as success, removes stale B rows only, and can arm idle cadence. Each subsequent real change appears without cross-environment overwrite. Pair same-ID seed with R1 rather than duplicate a whole platform matrix. Include at least one project-only shell change and thread removal, not title-only evidence. Exact prerequisite: P0, plus Empty shell and real project/thread creation, rename, archive/removal with colliding B/C IDs. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R9 — UNVERIFIED / cannot-verify ios-swift Scenario: Settings disable/re-enable C or remove C while its read is pending; release old answer; add/re-pair same environment as applicable Required proof: Removed/disabled rows and permissions must not revive from old answer; healthy B continues and re-enable/re-pair can refresh. Disable and removal have different invalidation paths; both need segments. Capture catalog update before/after tick and after old response release. Exact prerequisite: P0, plus Settings disable and removal as separate segments; release stale reads and re-enable/re-pair. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R10 — UNVERIFIED / cannot-verify ios-swift Scenario: Switch active A→B while C pending; disconnect/sign out during a second pending read; separately replace active route/re-pair Required proof: Old session cannot publish a late snapshot, steal active selection, revive stale permission or schedule more ticks. New active has correct stream and passive set; cancellation terminates owned work. Release old reads after switch/disconnect, observe >10 s. R9 cannot substitute: generation/session ownership differs. Exact prerequisite: P0, plus Active switch, disconnect/sign-out, route replacement/re-pair; stale-read release and >10-second observation. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R11 — UNVERIFIED / cannot-verify ios-swift Scenario: Home start/reload with warm read cache vs cold storage; return foreground after <10 s and ≥10 s background Required proof: Record startup snapshot, first aggregate publication, and resumed updates without stale replay. Cold initialSnapshot and cacheStartupRefreshTask still batch all enabled loads; label any wait there separately, not a failed proof of the narrower passive-loop fix. Resume does not itself start aggregate refresh, so demonstrate continuity/replacement through actual lifecycle. Exact prerequisite: P0, plus Independent cold/warm native storage; background intervals below and at least 10 seconds; lifecycle capture. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R12 — UNVERIFIED / cannot-verify ios-swift Scenario: No passive environments (only A, disabled B/C); then enable B Required proof: No passive shell requests; loop selects idle 10 s and discovers newly enabled B on a later tick. Record enable action through discovery and next publication. Include all-passives-in-backoff observation with R6/R7 to distinguish it from empty passive set. Exact prerequisite: P0, plus Only-active/disabled-passive seed, enable action, no-request observation through discovery. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R13 — UNVERIFIED / cannot-verify ios-swift Scenario: Environment document load transient failure while existing load completions are pending, then recovery Required proof: Persistence failure uses 20 s retry; queued completions must not strand refresh or republish removed rows. This requires an isolated storage-fault seam on the native host; real UI recording plus fault log. If no reliable seam exists, explicitly retain UNVERIFIED, do not fabricate a UI repro. A slow persistence read can also block the event consumer; the diff does not remove that await. Exact prerequisite: P0, plus Reliable isolated native environment-document storage-fault seam and correlated fault logs; no seam is currently demonstrated. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R14 — UNVERIFIED / cannot-verify ios-swift Scenario: C primary route unavailable with working alternate route; B healthy; repeat over remote/relay/tunnel if available Required proof: B independent while C resolves; C recovers on selected route without disconnecting newly active shared client. Capture real route labels/status and requests, not a mock server catalog. Local-host-only evidence cannot establish managed relay/tunnel behavior; unavailable credentials/routes remain unverified. Exact prerequisite: P0, plus Real alternate-route and remote/relay/tunnel access with test-only credentials; route/status/request capture. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ### R15 — UNVERIFIED / cannot-verify ios-swift Scenario: Selected passive B thread detail while home aggregate updates; return to merged home; compare background snapshot path Required proof: Detail selection must keep owning-environment routing/live stream; aggregate publications update shared rows without wrong connection/detail identity. Bounded backgroundSnapshot still batch-awaits and must not create long-lived subscriptions/timers. Record interaction/lifecycle and traffic; separate path from recurring refresh. Exact prerequisite: P0, plus Real passive detail/live-stream navigation and separately observed bounded backgroundSnapshot traffic. Captures: 0. Blocker: no available native runtime/capture route; scenario not executed. ## Existing transcript — HOST ONLY [HOST ONLY runtime transcript](https://gh-file-drop-api-prod-mi5fy3sowv63ufte.pinglabs.workers.dev/f/b6158405819336ba/host-runtime-transcript.txt). Existing host-main measurements demonstrate independent host responses/data availability only. They are not native app captures, not base/HEAD before/after evidence, and satisfy none of R1–R15. ## FRICTION - Linux lacks Xcode/iOS SDK and local Swift tooling; device access explicitly disabled. No native compilation, tests or capture performed. - Native fixture driver, scenario seeds, fault seams and synchronized video/request logs are prerequisites, not completed artifacts. - R7 full-duration suppression, R13 storage-fault seam and R14 real route access need their own proof; short/local-only evidence cannot replace them. - The explicit task-brief exception permits the parent to open the Swift base PR with cannot-verify ios-swift in body/terminal. No independent runbook compliance claim is made. This evidence-only subtask creates no PR or public comments. - No code edits, commits, pushes, or repository cleanup. Scratch output only under /tmp/issue-14691; pre-existing untracked .t3-b/ and .t3-c/ were left alone. - Captures: 0. Verified rows: 0/15. No success proof claimed. ## Final-head refresh — 2026-10-22 Target HEAD `6b0ce9b0bc70939c7cd1a81a009b0af70077fed5`, base `4619c0bca6`. Read-only source inspection only; no build, tests, native capture, browser, server or device access attempted. All 15 rows remain UNVERIFIED / cannot-verify ios-swift; captures 0; verified 0/15. The task-brief exception permits a Swift PR with that disclosure but does not establish passing proof. **VERDICT: INSUFFICIENT.** Exact missing rows: R1, R2, R3, R4, R5, R6, R7, R8, R9, R10, R11, R12, R13, R14, R15, with every variant above still required.