fix(swift-ios): retain Stop feedback until the session is inactive

[saphid]

Review this layer

GitHub shows this PR against t3code/rebuild-mobile-app-swift, so its diff includes every earlier PR in the chain. Review only this layer's change:

This layer's diff: +4060 / −25 lines across 11 files; app code +238 / −16, the rest is tests and docs.

An accepted Stop request is not a terminal session outcome. Retain Stopping feedback across thread navigation, expose an unconfirmed state when the outcome cannot be verified, and check current status before Retry stop dispatches again. Keep repeated taps from duplicating an outstanding stop. Disable pending question controls while Stop is active, and resume other queued submissions even when Stop fails.

Verification: current-head CI passes, including contract fixtures and native tests. The final bootstrap/environment run passed 38 tests, covering environment switching, error visibility and archive hydration; separate focused checks cover passive-worker lifetime. The Stop regression run passed 119 tests; native before/after captures verify pending question controls are disabled until Stop completes. Skipped checks are not claimed as executed proof.

Delivery: stacked. This branch contains #10758, #10759, #10761, #10762, #10763, #10764; merge the chain in order (#10758 → #10759 → #10761 → #10762 → #10763 → #10764 → #10765 → #10766 → #14021 → #10767). Each PR's own change is its top commit(s).

Base: Theo’s t3code/rebuild-mobile-app-swift, 157476f1fb.

Visual verification: Baseline a361b2212 and candidate 9bcc08bea use actual ThreadDetailView. Both captures passed and assert one Stop dispatch. The candidate retains unconfirmed feedback after acknowledgement and clears it after completed status. The fixture supplies no scoped connection, so it correctly does not claim a confirmed remote outcome. Native model tests separately cover connected acknowledgement, close/reopen retention, duplicate taps and status reconciliation before retry.

Actual before/after stills, held for 3.5 seconds each; not a motion or latency measurement.

Before screenshot · After screenshot

Before (base), full recorded sequence at 12 fps and real-time playback:

After (candidate), full recorded sequence at 12 fps and real-time playback:

Before video · Clean candidate video · Annotated candidate video · Evidence receipt

Additional Stop regression proof: baseline faa5574e6 leaves Submit actionable during an outstanding Stop. Candidate 58ad6fe56 disables the answer panel until completion. Both native captures passed; semantic snapshots confirm controls become available again after completion, and no answer was sent. The fixture invokes the actual model Stop method after selecting Continue; it does not depict a Stop-button tap. A separate regression verifies failed Stop resumes other queued submissions.

Actual before/after stills, held for 3.5 seconds each; not a motion or latency measurement.

Before screenshot · After screenshot

Before (base), full recorded sequence at 12 fps and real-time playback:

After (candidate), full recorded sequence at 12 fps and real-time playback:

Before video · Clean candidate video · Annotated video · Evidence receipt

Capture currency: checked against 5e0055bdc. The original Stop scenario contains no pending question or queued creation, so later changes to those paths do not alter that demonstration. The separate pending-question capture at 58ad6fe56 includes the final control fix; only environment lookup error propagation and its test changed afterward.

Visual review: inspected the before/after images and recorded interaction states at 390 px width against current head 5e0055bdc. The demonstrated UI is unchanged from the labeled capture revisions; retained content, recovery controls, spacing, and text are legible. This is the author’s visual assessment, not maintainer approval.

Independent cross-provider review was unavailable: claude auth status returned exit 1 with loggedIn: false. No Claude review or maintainer approval is claimed.

Refresh onto 157476f1fb (2026-09-27)

Rebased with the thread-sync chain onto the current t3code/rebuild-mobile-app-swift (157476f1fb). Head 33c35dd32f.

• Focused tests at this layer, measured before the review fixes below (NativeMultiEnvironmentTests, NativeThreadCatchUpTests, NativeRetryIdentityTests, FeatureRootModelTests, iOS Simulator, per-test time limits): 117 passed.
• Full T3CodeTests at the chain top (68d92c2752): 343 XCTest cases passed (1 skipped). Swift Testing ran 892 tests; the only 2 failures are UsageModelsTests currency formatting, which fail identically on unmodified 157476f1fb.
• Independent review: devin -p --sandbox --permission-mode smart --model swe-2-max over the whole chain diff, exit 0. No blocker, high or medium findings. A dead-state finding was fixed. A report that Stop state outlives a vanished thread was not changed, because stopSurvivesCloseReopenAndMissingReconnectSeed requires that behaviour.

Review fixes (round 7: Macroscope and Astra)

• Stop could not be confirmed while a turn was streaming. Stop status refreshes the shell cache and reads it back, but a refresh superseded by a newer stream update threw a cancellation, so the check failed and Stop could not be confirmed or retried. While the environment's stream is authoritative on the current socket, the cache it keeps current now answers instead; after a disconnect or lost authority the check still fails. This works for peer environments as well as the active one. Test: stopStatusDuringLiveUpdates(environmentID:authorityLost:) (cases active superseded, active authority lost, peer superseded). The original code fails the superseded cases.
• GPT-6 Astra (codex exec -m gpt-6-astra -c model_reasoning_effort="xhigh" --sandbox read-only) reviewed this fix across rounds 8–12. It rejected two broader versions: one that trusted the cache after a reconnect, and one that answered from the HTTP read alone, which could overwrite newer visible state and leave cancelTurn validating a stale cache. The final version returned ready with no medium or higher findings.

Follow-ups (minor, not blocking)

• After a failed hydration, a later HTTP-only hydration can leave the root connection state at disconnected until a socket snapshot arrives (Macroscope).

Model and harness: GPT-6 / Codex. Rebase onto 157476f1fb: Claude Opus 5.5 / Claude Code.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR introduces a substantial cross-cutting rewrite of Swift iOS synchronization, lifecycle, thread reconciliation, and Stop behavior across production paths, rather than a narrowly isolated fix. Unresolved correctness risks remain in Stop completion handling and shell hydration/connection-state recovery.

Not approved because:

• 3 blocking correctness issues found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.

[saphid]

@t3dotgg Alex has approved this PR for your review. Stop feedback persists until the session settles, including pending-question controls. The current description contains the verification evidence.

[macroscopeapp]

🟠 High Root/FeatureRootModel.swift:1532

An idle snapshot leaves a successful Stop request in .awaitingOutcome, so the thread remains non-actionable and its Stop-related controls stay disabled indefinitely. install now calls reconcileStop for every snapshot, but that reconciliation rejects the valid inactive idle status even though the native mapper represents it as a completed latest turn; update reconcileStop to finalize the request for idle snapshots as well.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/swift-ios/Features/Root/FeatureRootModel.swift around line 1532:

An `idle` snapshot leaves a successful Stop request in `.awaitingOutcome`, so the thread remains non-actionable and its Stop-related controls stay disabled indefinitely. `install` now calls `reconcileStop` for every snapshot, but that reconciliation rejects the valid inactive `idle` status even though the native mapper represents it as a completed latest turn; update `reconcileStop` to finalize the request for `idle` snapshots as well.

[macroscopeapp]

🟠 High App/NativeFeatureClient.swift:1202

The same-client fast path preserves the previous shell epoch, so after a stream restart acceptActiveShell rejects the lower-sequence HTTP hydration and the UI remains on stale projects and threads. Update activeShellConnectionID and activeShellEpochHasSnapshot before returning from this path, as in the replacement-client path.

-            return true
+            activeShellConnectionID = adoptedConnectionID
+            activeShellEpochHasSnapshot = adoptedConnectionID != nil
+                && shellConnectionIDsByEnvironmentID[environment.id] == adoptedConnectionID
+            return true

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/swift-ios/App/NativeFeatureClient.swift around line 1202:

The same-client fast path preserves the previous shell epoch, so after a stream restart `acceptActiveShell` rejects the lower-sequence HTTP hydration and the UI remains on stale projects and threads. Update `activeShellConnectionID` and `activeShellEpochHasSnapshot` before returning from this path, as in the replacement-client path.

[macroscopeapp]

🟡 Medium App/NativeFeatureClient.swift:454

A successful fallback HTTP hydration applies the shell but leaves the published root snapshot in .disconnected when the previous hydration failed and no WebSocket snapshot has arrived. This preserves latestSnapshot.connection.state because connectHeader is false, so consumers continue to treat the reachable session as offline; publish the successful shell with a connected state instead.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/swift-ios/App/NativeFeatureClient.swift around line 454:

A successful fallback HTTP hydration applies the shell but leaves the published root snapshot in `.disconnected` when the previous hydration failed and no WebSocket snapshot has arrived. This preserves `latestSnapshot.connection.state` because `connectHeader` is false, so consumers continue to treat the reachable session as offline; publish the successful shell with a connected state instead.

[saphid]

Acknowledged: after a failed hydration, a later HTTP-only hydration applies the shell but can leave the root connection state at disconnected until the socket snapshot arrives. Listed as a follow-up.

[macroscopeapp]

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

[saphid]

@t3dotgg this is ready for your review and merge.

Merge order: stacked chain, merge in order: #10758 → #10759 → #10761 → #10762 → #10763 → #10764 → #10765 → #10766 → #10767. #12655 (composer focus freeze) is independent and can merge at any time.

Evidence at head 33c35dd32f:

• CI: all checks pass on this head.
• Full T3CodeTests at the chain top (70258b6a6b, iOS Simulator): 343 XCTest cases passed (1 skipped). Swift Testing ran 892 tests; the only 2 failures are UsageModelsTests currency formatting, which fail identically on unmodified 157476f1fb.
• Each review fix has a focused regression test that fails without the fix, except where the description says why not.
• An earlier build of this chain (before the review rounds) fixed the stuck-send behaviour on a physical iPhone, as confirmed by the user. The current heads have not been re-verified on a device.

Independent review: GPT-6 Astra xhigh (read-only) reviewed the Stop-status fix in this layer across rounds 8–12. It rejected two broader versions; the final version returned ready with no medium or higher findings. The rest of the layer was covered by the SWE-2 Max review of the whole chain.

Macroscope findings on the latest heads have been verified against the source: real ones are fixed, and the rest have a written reason and are listed under Follow-ups in the description.

[juliusmarminge]

Note

This comment is posted by Julius' dot

The new Stop unconfirmed and Retry stop workflow changes cancellation behavior across navigation and reconnects. That scope requires prior approval. The comment mentioning Alex’s approval does not link maintainer direction. Please link that approval or agree on the Stop workflow with maintainers, then request reconsideration.