The two ordering tests (destructive controls after useful targets, unselected segmented controls before selected) exercise `getRuntimeTargetDisplayPriority` / `isLowPriorityRuntimeTarget` / `isAlreadySelectedRuntimeTarget` sorting logic in `structured-output-envelope.ts` via the full CLI pipeline; move them to `src/utils/__tests__/structured-output-envelope.test.ts` and call `toStructuredEnvelope` directly, as done for all other compact-capture tests in that file.

The replacement `e<TIME>|text|text|<TIME>||` normalizes the element ID (`e\d+`) using the same `<TIME>` placeholder as the time content, so any accessibility tree reordering that shifts a clock-displaying element's ID (e.g. `e42` → `e55`) is silently absorbed and never surfaces as a snapshot contract change.

The replacement `e<TIME>|text|text|<TIME>||` normalizes the element ID (`e\d+`) using the same `<TIME>` placeholder as the time content, so any accessibility tree reordering that shifts a clock-displaying element's ID (e.g. `e42` → `e55`) is silently absorbed and never surfaces as a snapshot contract change.

The touch and long-press success tests call `refreshRuntimeSnapshot()` (which captures a real snapshot) but then pass the hardcoded `elementRef: 'e3'` rather than deriving the ref from the captured output — making the snapshot call meaningless as a ref source and coupling test validity to a brittle positional assumption about Calculator's element tree.

Resetting the `snapshotCaptured` flag at the end of the `swipe > success` test body (not in `afterEach`) creates an ordering dependency: if the success test is skipped, fails early, or runs out of order, `refreshRuntimeSnapshot()` in the subsequent `swipe--error-not-actionable` test will no-op, leaving the Preferences app in the foreground and making `e3` refer to a Preferences element rather than a Calculator element.

When `includeNextSteps` is `false` (e.g. `outputStyle === 'minimal'`), streamed `next-steps` fragments processed via `processItem`'s `case 'next-steps'` are still rendered unconditionally; only the finalize-time `createNextStepsBlock` call is guarded by the new flag.

For each scrollable candidate, `records.filter(isForegroundCandidateForRoot)` iterates all records again, and `findSheetGrabberDescendant` does the same — giving O(n²) total work per UI action in trees with many scrollable elements. Consider pre-grouping records by path prefix so descendant lookups become O(1) amortized.

For each scrollable candidate, `records.filter(isForegroundCandidateForRoot)` iterates all records again, and `findSheetGrabberDescendant` does the same — giving O(n²) total work per UI action in trees with many scrollable elements. Consider pre-grouping records by path prefix so descendant lookups become O(1) amortized.

When ≥2 switches are visible and `batchElements` is replaced with `switchBatchElements`, the `repeatedNoOpAction` exclusion is not applied, so a switch the agent just tapped with no effect can be included in the batch suggestion, directing the model to repeat a known no-op.