The existing published `2.schema.json` is being modified to add new `$defs` (including `compactRuntimeSnapshot`, `recoverableUiError`) and corresponding `capture`/`uiError` properties to `data`; any consumer that cached the old v2 schema definition under its stable `$id` URL will now reject new payloads that include those fields, since the old schema had `additionalProperties: false` on `data` without those properties. New features should only appear in the newly created v3 schema.

New fields `capture` and `uiError`, plus new action types `type-text` and `batch`, were added directly to the already-published v2 schema instead of being exclusive to the new v3 schema; consumers that validated or cached the old v2 definition will encounter unexpected fields without a version signal.

The `ignores unrelated project session defaults` test uses `handler as unknown as (args, executor) => Promise<void>` to force-inject a `CommandExecutor`; use `batchLogic` with the mock executor directly instead, which is already tested and available in this file.

The `ignores unrelated project session defaults` test uses `handler as unknown as (args, executor) => Promise<void>` to force-inject a `CommandExecutor`; use `batchLogic` with the mock executor directly instead, which is already tested and available in this file.

The `ignores unrelated project session defaults` test uses `handler as unknown as (args, executor) => Promise<void>` to force-inject a `CommandExecutor`; use `batchLogic` with the mock executor directly instead, which is already tested and available in this file.

The `long-press--success` test uses the same `refreshRuntimeSnapshot()` + hardcoded `'e3'` pattern, adding assumed positional state rather than resolving a verified element ref from the live snapshot.

The `type-text--success` snapshot fixture is dropped with no replacement success-path test; the positive contract for `type-text` now has zero snapshot coverage.

The two deleted tests were the sole unit-level coverage for the empty-array omission guard and the error-envelope suppression guard inside `toStructuredEnvelope`; both guards are still active in the implementation and should remain tested.

When `shouldShowBatch` is true and `tapElement` is a non-content-rich, non-screen-changing, non-low-priority element, the same `elementRef` is emitted twice: once inside the `batch` step params and again as the standalone `tap` step, causing an agent to be given redundant or conflicting instructions to tap the same control twice.

In `createTypeTextExecutor` (src/mcp/tools/ui-automation/type_text.ts), the success path calls `createUiActionSuccessResult` without `previousRuntimeSnapshot`. As a result, `uiActionNextStepContexts` is never populated for type_text successes, so `actionTarget` and `previousScreenHash` are absent from the structured output — defeating the PR's goal of giving agents reusable next-action context after a type-text. All sibling handlers (tap, touch, swipe, drag, long_press, batch) pass `resolution.snapshot.payload` here.

`uiError.candidates` is capped with `.slice(0, COMPACT_RUNTIME_TARGET_LIMIT)` (64) before serialisation, but `waitMatch.matches` uses an unbounded `.map()`, so a wait predicate matching many elements (e.g. `exists` or `settled` on a large list) can produce arbitrarily large output.

`uiError.candidates` is capped with `.slice(0, COMPACT_RUNTIME_TARGET_LIMIT)` (64) before serialisation, but `waitMatch.matches` uses an unbounded `.map()`, so a wait predicate matching many elements (e.g. `exists` or `settled` on a large list) can produce arbitrarily large output.

Each call to `foregroundScore` does a full `records.filter` pass (plus a separate `findSheetGrabberDescendant` scan) over all snapshot elements; with `n` scrollable candidates this is O(n²) total. Have you considered pre-building an ancestor-lookup map keyed by path prefix so each candidate's descendants can be found in O(1) amortised time?

Each call to `foregroundScore` does a full `records.filter` pass (plus a separate `findSheetGrabberDescendant` scan) over all snapshot elements; with `n` scrollable candidates this is O(n²) total. Have you considered pre-building an ancestor-lookup map keyed by path prefix so each candidate's descendants can be found in O(1) amortised time?

The constants `HIDDEN_RUNTIME_TARGET_LABELS` / `LOW_PRIORITY_RUNTIME_TARGET_LABELS` and helper functions (`compactRuntimeSnapshotText`, `normalizedRuntimeSnapshotText`, `isHiddenRuntimeTarget`, `isLowPriorityRuntimeTarget`, `isContentRichTapTarget`, `isAlreadySelectedRuntimeTarget`, `getRuntimeTargetDisplayPriority`, `sortRuntimeTargetsForDisplay`) are copy-pasted verbatim from `src/utils/structured-output-envelope.ts` — future edits to label sets or priority logic in one file won't automatically propagate to the other, causing the text renderer and structured-output envelope to silently diverge.