test(ios-smoke): answer deep-link prompt after readiness exhaustion

[thymikee]

Summary

Keep the iOS smoke deep-link confirmation probe active when the destination wait ends during typed target discovery readiness (wait_readiness_exhausted). The helper previously returned before alert get, leaving iOS's “Open in Agent Device Tester?” confirmation unanswered. A runner startup readiness failure still returns after one wait without prompt probes. Two test-harness files changed; production behavior is unchanged.

Failure on #3006 and failure on #3032 both show a successful deep-link open, a failed first 15-second destination wait, no alert probe, then APP_NOT_RUNNING on the following wait. Final error details report wait_capture_stalled, readinessPhase: target-discovery, and zero readable captures; screenshots show the unanswered system confirmation. The first wait's exact reason is absent from uploaded artifacts, so the missing branch is inferred from control flow and verified by regression.

Validation

At 1fd5e01362f168d0ae545a44072337b8da4da6ea, rebased onto main 3fe2e6929: frozen install, build, repository-wide pnpm format, focused Node test (12 passed), and exact-head pnpm check:affected --run passed, including Node integration (119 passed, 12 skipped), lint, typecheck, and fallow. Removing the target discovery branch makes the confirmation test fail with only the first wait recorded; the branch was restored. Live iOS smoke on the rebased head is pending.

[github-actions]

Size Report

Metric	Base	Current	Diff
Installed (including dependencies)	4.88 MB	4.88 MB	0 B
Package (unpacked)	4.87 MB	4.87 MB	0 B
Package (download)	1.46 MB	1.46 MB	+4 B

Startup median (7 runs, lower is better):

Scenario	Base	Current	Diff
CLI --version	28.0 ms	27.3 ms	-0.6 ms
CLI --help	81.8 ms	80.1 ms	-1.7 ms

[cubic-dev-ai]

All reported issues were addressed across 2 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[thymikee]

Reviewed at cb7f1a6. The harness now answers the deep-link confirmation when the first wait ends with readiness exhausted, instead of returning early and leaving the prompt open. The new regression covers that branch.

Not blocking: test/integration/ios-simulator-e2e/live-deep-link-confirmation.ts#L74 checks a local list of wait reasons. A retriable reason added later would fall through to the early return again. Keying on the typed retriable detail would avoid that.

The link to the #3041 and #3032 failures comes from the PR description; I did not read those CI artifacts. Both Smoke Tests jobs are still queued. The iOS smoke calls this helper at its deep-link step, so a failure there would be related to this change. A green run may not hit the readiness-exhausted case, so the regression test is the main proof.

[thymikee]

Reviewed at b93c2eb. The new commit limits the prompt retry to target-discovery exhaustion, and the regression test covers that condition. Not blocking: the raw 'target-discovery' comparison at live-deep-link-confirmation.ts:77 could use the existing readinessPhaseOf(details) helper, as the production wait path does.

The regression test uses a mocked device, so the live iOS smoke run on this head is still the real check. Both Smoke Tests jobs are still queued; if one fails, please check whether it fails at the deep-link confirmation step. Ready for human review.

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-09-28 17:56 UTC