zeno-mobile-runner 0.2.16 → 0.2.17

package/docs/agent-discovery.md

@@ -1,15 +1,15 @@
 # Agent Discovery
 
-ZMR supports agent-led discovery today through its JSON-RPC and MCP interfaces,
-trace events, semantic snapshot artifacts, guarded trace exploration, in-band
-trace discovery, and offline scenario drafting. An external agent can observe
-the app, choose typed actions, inspect trace events, ask ZMR to write a small
-repeatable scenario from the trace, and then edit it as it learns a flow.
+ZMR supports agent-led discovery through JSON-RPC, MCP, trace events, semantic
+snapshots, guarded trace exploration, in-band trace discovery, and offline
+scenario drafting. An external agent can observe the app, choose typed actions,
+inspect trace events, ask ZMR to write a repeatable scenario from the trace, and
+then edit that scenario as it learns the flow.
 
 `zmr explore` is the built-in review-first exploration command. It is
 trace-backed, not an unbounded crawler: it does not launch devices, invent
-missing actions, discover credentials, or commit files. Keep autonomous
-planning in the agent, and keep ZMR as the deterministic mobile control plane.
+missing actions, discover credentials, or commit files. Keep autonomous planning
+in the agent; keep ZMR as the deterministic mobile control plane.
 
 ```mermaid
 flowchart LR
@@ -120,7 +120,7 @@ flowchart LR
    generated replay steps, and `skippedEventCount` is the number of events left
    out.
 
-11. After editing a generated scenario, validate it in-band with JSON-RPC:
+12. After editing a generated scenario, validate it in-band with JSON-RPC:
 
    ```json
    {"jsonrpc":"2.0","id":8,"method":"scenario.validate","params":{"path":".zmr/discovered/replay-smoke.json"}}
@@ -130,7 +130,7 @@ flowchart LR
    result matches `zmr validate --json`, including field paths and source
    locations for invalid files.
 
-12. Use the lower-level draft primitive when you want separate surface and
+13. Use the lower-level draft primitive when you want separate surface and
    replay files. For a conservative surface-smoke scenario:
 
    ```bash
@@ -160,16 +160,16 @@ flowchart LR
    timeout context for successful waits and timeout diagnostics.
    Unsupported events stay out of the scenario and are reported as warnings.
 
-13. Edit the draft, discovery, or exploration output into a candidate flow, for example
-   `.zmr/discovered/login-smoke.json`, by copying only steps that were observed
-   and understood.
-14. Validate the candidate scenario:
+14. Edit the draft, discovery, or exploration output into a candidate flow, for
+   example `.zmr/discovered/login-smoke.json`, by copying only steps that were
+   observed and understood.
+15. Validate the candidate scenario:
 
    ```bash
    zmr validate --json .zmr/discovered/login-smoke.json
    ```
 
-15. Re-run it deterministically:
+16. Re-run it deterministically:
 
    ```bash
    zmr run .zmr/discovered/login-smoke.json \
@@ -179,7 +179,7 @@ flowchart LR
      --json
    ```
 
-16. Export a redacted bundle before sharing artifacts:
+17. Export a redacted bundle before sharing artifacts:
 
     ```bash
     zmr export traces/zmr-login-smoke \

package/docs/ai-agents.md

@@ -1,8 +1,8 @@
 # AI Agent Guide
 
-ZMR is built for external agents. The runner provides device state, typed
-actions, waits, assertions, trace explanation, and trace export; the agent
-decides the next step.
+ZMR gives external agents a mobile control plane. The runner provides device
+state, typed actions, waits, assertions, trace explanation, scenario discovery,
+and redacted export. The agent remains responsible for planning and review.
 
 ```mermaid
 sequenceDiagram
@@ -24,7 +24,8 @@ sequenceDiagram
 
 ## Agent Setup Loop
 
-Start inside the app checkout:
+Start inside the app checkout and gather machine-readable setup state before
+touching a device:
 
 ```bash
 zmr inspect --json --dir .
@@ -34,7 +35,7 @@ zmr validate --json .zmr/ios-smoke.json
 zmr schemas --json
 ```
 
-Use `zmr doctor --strict --json` in CI or setup flows that should fail on any
+Use `zmr doctor --strict --json` in CI or install flows that should fail on any
 warning. Prefer JSON output for automation because it includes stable error
 codes, field paths, and remediation hints.
 
@@ -44,13 +45,14 @@ platform smoke scenario paths, safe next commands, and explicit claim limits.
 
 ## Live JSON-RPC Session
 
-Agents should prefer `zmr serve` for interactive work:
+Use `zmr serve` when an agent needs an interactive session with repeated
+observe-act-assert turns:
 
 ```bash
 zmr serve --transport stdio --config .zmr/config.json --trace-dir traces/zmr-agent
 ```
 
-Recommended flow:
+Recommended loop:
 
 1. Call `runner.capabilities` and check protocol/platform support.
 2. Call `session.create`.
@@ -69,7 +71,7 @@ Recommended flow:
 11. Call `trace.export` with `redact: true` before sharing artifacts.
 12. Call `session.close`.
 
-Do not parse screenshots or terminal text when the same fact is available from
+Do not parse screenshots or terminal prose when the same fact is available from
 snapshot nodes, action results, CLI JSON, or trace events.
 
 If `zmr run --json` returns `status: "partial"`, inspect `partialFailure`.
@@ -109,14 +111,16 @@ The MCP server exposes mobile-specific tools:
 - `trace_events`, `trace_explain`, `trace_explore`, `trace_discover`, and
   `trace_export`
 
-Prefer `semantic_snapshot` for action planning. It avoids forcing an agent to
-infer intent from platform-specific Android/UI Automator or XCTest class names.
+Prefer `semantic_snapshot` for action planning. It prevents the agent from
+inferring product intent from platform-specific Android/UI Automator or XCTest
+class names.
 
 ## Agent-Led Discovery
 
-Agents can use ZMR to discover flows and draft scenarios by looping over
-`observe.semanticSnapshot`, one typed action, trace events, and scenario
-validation. After a session has produced trace artifacts, call JSON-RPC
+Agents can use ZMR to turn an exploratory session into a reviewable scenario.
+The safe loop is: observe with `semantic_snapshot`, take one typed action,
+inspect trace events, generate a candidate, validate it, then rerun it
+deterministically. After a session has produced trace artifacts, call JSON-RPC
 `trace.explain` or MCP `trace_explain` for in-band triage, then call JSON-RPC
 `trace.explore` or MCP `trace_explore` when the generated draft should carry a
 stated goal and guardrails. Use JSON-RPC `trace.discover` or MCP
@@ -169,7 +173,7 @@ then commit only reviewed scenario JSON.
 
 ## Scenario File Workflow
 
-For repeatable tests, generate or edit `.zmr/*.json` scenarios:
+For committed tests, generate or edit `.zmr/*.json` scenarios:
 
 ```bash
 zmr validate --json .zmr/login-smoke.json
@@ -178,21 +182,26 @@ zmr explain --json traces/zmr-login-smoke
 zmr export traces/zmr-login-smoke --out traces/zmr-login-smoke-redacted.zmrtrace --redact
 ```
 
-Use stable selectors in this order when available:
+Use stable selectors in this order:
 
 - app accessibility identifiers or resource ids
 - content descriptions or accessibility labels
 - exact visible text for stable product copy
 - `textContains` only when the visible text legitimately varies
+- `stableId` only as a fallback from the current `semantic_snapshot`
 - coordinate actions only as a last resort
 
 Use `waitAny` for screens with legitimate branches, and `whenVisible` for
 optional platform or dev-client screens. Keep credentials and app-private data
 in the app repository or environment, not in public scenarios.
+Prefer app-owned selectors for committed scenario files. `stableId` is useful
+for immediate live-session actions when a semantic node has no better selector,
+but it is less portable than an accessibility identifier or resource id.
 
 ## Failure Triage
 
-When a run fails, inspect:
+When a run fails, inspect structured evidence before changing app code or
+selectors:
 
 - `zmr run --json` terminal summary
 - `zmr explain --json <trace-dir>`
@@ -202,12 +211,12 @@ When a run fails, inspect:
 - the trace viewer report from `zmr report`
 
 Selector failures include active app context, visible text, disabled/hidden or
-offscreen exact candidates, and nearest text matches when available. Treat
-those diagnostics as the source of truth before changing a selector.
+offscreen exact candidates, and nearest text matches when available. Treat those
+diagnostics as the source of truth before changing a selector.
 
 ## Benchmarking
 
-Use ZMR repeated runs first:
+Use repeated ZMR runs before making reliability claims:
 
 ```bash
 zmr-benchmark --zmr .zmr/android-smoke.json --platform android --device emulator-5554 --app-id com.example.mobiletest --app-build <build-id-or-artifact> --runs 20 --trace-root traces/zmr-android-reliability --results traces/bench-comparison/results.jsonl --replace --min-pass-rate 100 --max-failures 0
@@ -228,7 +237,8 @@ candidate and baseline rows for your team to trust the result.
 
 ## Evidence Summaries
 
-Teams that collect repeated app/device pilot rows can evaluate them with:
+Teams that collect repeated app/device pilot rows can evaluate claim readiness
+with:
 
 ```bash
 zmr-release-readiness --json \

package/docs/app-integration.md

@@ -1,22 +1,33 @@
 # App Integration
 
-ZMR is intentionally a separate runner. A mobile app repo does not need to vendor ZMR, but it should expose a small, stable test surface so agents can drive the app deterministically.
+ZMR is intentionally a separate runner. The app does not vendor ZMR, but it
+should expose a small, stable test surface so agents and CI can drive the app
+deterministically.
 
-Most app teams should install ZMR as a dev dependency:
+Install the native `zmr` binary once, then create app-local `.zmr/` state from
+the app repo:
 
 ```bash
-npm install --save-dev zeno-mobile-runner
-npx zmr-wizard --app-id com.example.mobiletest --package-json
+curl -fsSL https://raw.githubusercontent.com/johnmikel/zeno-mobile-runner/main/install.sh | sh
+export PATH="$HOME/.local/bin:$PATH"
+zmr init --app --app-id com.example.mobiletest
 ```
 
-That keeps scenarios and app scripts in the app repo while the runner remains versioned through npm.
-For Expo development builds, add `--expo-dev-client-scheme <scheme>` to scaffold
-Android and iOS open-link smoke scenarios that load Metro before selector
-assertions run.
+That keeps scenarios and traces in the app repo while the runner stays outside
+the app process. JavaScript teams can use
+`npm install --save-dev zeno-mobile-runner` plus
+`npx zmr-wizard --app-id com.example.mobiletest --package-json` when they want
+generated package scripts and npm helper bins.
+
+For Expo development builds, use
+`npx zmr-wizard --expo-dev-client-scheme <scheme> --package-json` when you want
+generated Android and iOS open-link smoke scenarios that load Metro before
+selector assertions run.
 
 ## React Native, Expo, And Flutter
 
-ZMR works best when the app exposes stable, user-meaningful selectors:
+ZMR works best when the app exposes stable, user-meaningful selectors and direct
+navigation paths:
 
 - React Native apps should use `testID`, `accessibilityLabel`, stable visible
   text, and deep links for direct navigation.
@@ -30,6 +41,8 @@ See [frameworks.md](frameworks.md) for framework-specific examples.
 
 ## What The App Provides
 
+Think of this as the contract between the app repo and the runner.
+
 For Android:
 
 - A debug/test APK.
@@ -40,7 +53,8 @@ For Android:
 - Optional Android instrumentation shim command for faster hierarchy and
   selector-grade actions.
 
-Create the app-local Android shim command from the ZMR package or checkout:
+Create the app-local Android shim command from the ZMR package or checkout when
+you want faster hierarchy capture or selector-grade native actions:
 
 ```bash
 npx zmr-install-android-shim \
@@ -62,7 +76,7 @@ The generated
 `.zmr/android-shim` executable is the value to pass to `--android-shim` or
 `tools.androidShimPath`.
 
-For iOS:
+For iOS/iPadOS:
 
 - A simulator `.app` build.
 - A stable bundle id, for example `com.example.mobiletest`.
@@ -71,7 +85,9 @@ For iOS:
 - Optional simulator XCTest/XCUIAutomation shim command for hierarchy and
   selector-grade actions.
 
-Create the app-local shim command from the ZMR package or checkout:
+Create the app-local XCTest/XCUIAutomation shim command from the ZMR package or
+checkout when selector actions, bounded hierarchy snapshots, or physical-device
+screenshots are required:
 
 ```bash
 npx zmr-install-ios-shim \
@@ -121,10 +137,15 @@ mobile-app/
     ios-smoke.json
 ```
 
-Keep app-owned scenarios and ZMR defaults in `.zmr/` when they are app-specific. Keep generic examples in the ZMR repo. ZMR auto-discovers `.zmr/config.json` from the app repo; explicit CLI flags still override config defaults.
+Keep app-owned scenarios and ZMR defaults in `.zmr/` when they are app-specific.
+Keep generic examples in the ZMR repo. ZMR auto-discovers `.zmr/config.json`
+from the app repo; explicit CLI flags still override config defaults.
 
 ## Android App Pilot Command
 
+Use the pilot wrapper when you want app-local reliability evidence and standard
+trace/report artifacts:
+
 ```bash
 /path/to/zeno-mobile-runner/scripts/run-android-pilot.sh \
   --app-root /path/to/mobile-app \
@@ -146,17 +167,18 @@ Use a saved emulator snapshot for repeatability:
 ```
 
 `--screen-record` writes `screenrecord.mp4` under the pilot trace root. For
-direct traced runs, use `zmr run --android-avd Small_Phone
+direct traced runs, use `zmr run --ensure-device --android-avd Small_Phone
 --create-avd-if-missing --avd-system-image
 'system-images;android-35;google_apis;arm64-v8a' --avd-device pixel_6
 --restore-snapshot zmr-clean --wait-emulator --screen-record`, or set the
 equivalent `android.avdName`, `android.createAvdIfMissing`,
 `android.avdSystemImage`, `android.avdDeviceProfile`,
-`android.restoreSnapshot`, `android.waitReady`, and
+`android.restoreSnapshot`, `android.waitReady`, `android.ensureDevice`, and
 `artifacts.screenRecording` values in `.zmr/config.json`. Treat recordings like
 screenshots: keep them local or share only when the app state is safe.
 
-The Android wrapper expects the default APK path under the app root. Override it when needed:
+The Android wrapper expects the default APK path under the app root. Override it
+when needed:
 
 ```bash
 /path/to/zeno-mobile-runner/scripts/run-android-pilot.sh \
@@ -167,7 +189,9 @@ The Android wrapper expects the default APK path under the app root. Override it
 
 ## Public Android Demo Command
 
-For a generic public Android app:
+Use the public demo before connecting ZMR to a private app. It proves local
+Android install, launch, selector action, typing, snapshot, and trace capture
+with generic artifacts:
 
 ```bash
 npx zmr-demo-android --out /tmp/zmr-android-demo --device emulator-5554 --avd <avd-name>
@@ -186,12 +210,11 @@ adb install -r /tmp/zmr-android-demo/build/app-debug.apk
   --trace-dir /tmp/zmr-android-demo/traces/android-demo
 ```
 
-Use this path to prove local Android install, launch, selector action, typing,
-snapshot, and trace capture before wiring ZMR into a private app.
+Use this path before wiring ZMR into a private app.
 
 ## iOS Demo Command
 
-For a generic public demo app with the shim already installed:
+Use the public iOS demo before connecting ZMR to a private iOS or iPadOS app:
 
 ```bash
 npx zmr-demo-ios --out /tmp/zmr-ios-demo --device booted
@@ -218,7 +241,8 @@ Then boot a simulator and run:
   --ios-shim /tmp/zmr-ios-demo/.zmr/ios-shim
 ```
 
-Build the app for an iOS simulator, boot a simulator, then run:
+For a private app, build the app for an iOS simulator, boot a simulator, then
+run:
 
 ```bash
 /path/to/zeno-mobile-runner/scripts/run-ios-pilot.sh \
@@ -239,17 +263,21 @@ visible labels, hidden/disabled/offscreen candidates, and nearest text matches.
 When the app is already running, ZMR uses the shim `appState` response as an
 idempotent launch confirmation if `simctl launch` itself returns an error.
 
-On iOS simulators, `clearState` means best-effort app uninstall by bundle id.
-For physical iOS devices, lifecycle commands go through `devicectl` and
-selector commands go through the same app-local XCTest shim, subject to signing,
-provisioning, Developer Mode, and local Xcode availability. Screenshot
+On iOS and iPadOS simulators, `clearState` means best-effort app uninstall by
+bundle id. Use the same `--platform ios --ios-device-type simulator` path for
+iPhone and iPad simulators, but collect separate iPad evidence when tablet
+layouts, split views, or size classes can change the UI tree.
+
+For physical iPhone and iPad devices, lifecycle commands go through `devicectl`
+and selector commands go through the same app-local XCTest shim, subject to
+signing, provisioning, Developer Mode, and local Xcode availability. Screenshot
 artifacts use the XCTest shim; log artifact capture is simulator-first in this
 release.
 Use a simulator-built `iphonesimulator` `.app` for simulator runs. A signed
 device `.ipa` must be run with `--ios-device-type physical`; the pilot wrapper
 rejects device IPAs on simulator runs before installing anything.
 Use `--ios-device-type physical` with a concrete device identifier from
-`zmr devices` for physical pilot runs:
+`zmr devices` for physical iPhone or iPad pilot runs:
 
 ```bash
 /path/to/zeno-mobile-runner/scripts/run-ios-pilot.sh \
@@ -268,6 +296,8 @@ Install the simulator `.app` again before launch/open-link steps that need it.
 
 ## Direct CLI Use
 
+Use direct CLI commands when debugging a scenario or wiring custom CI steps.
+
 Android:
 
 ```bash
@@ -291,6 +321,7 @@ xcrun simctl install booted /path/to/Sample.app
 zmr run .zmr/ios-shim-smoke.json \
   --platform ios \
   --device booted \
+  --ensure-device \
   --app-id com.example.mobiletest \
   --ios-shim ./.zmr/ios-shim \
   --trace-dir traces/ios-smoke
@@ -330,5 +361,6 @@ session.
 ## Public Artifact Rules
 
 - Share `*-redacted.zmrtrace` bundles.
-- Do not publish raw Metro logs, simulator logs, or unredacted screenshot bundles from private apps.
+- Do not publish raw Metro logs, simulator logs, or unredacted screenshot
+  bundles from private apps.
 - Run `bash tests/public-safety-test.sh` before publishing this repo.

package/docs/benchmarking.md

@@ -1,8 +1,9 @@
 # Benchmarking
 
-ZMR benchmark output is intentionally simple: each run appends one JSON object
-to `results.jsonl`, and `zmr report` turns that directory into local HTML and
-optional JUnit XML artifacts.
+Benchmarking in ZMR is evidence-first. Each run appends one JSON object to
+`results.jsonl`, and `zmr report` turns the directory into local HTML plus
+optional JUnit XML artifacts. Use repeated runs for reliability claims and
+matched baseline rows for speed claims.
 
 ## Public Evidence
 
@@ -39,6 +40,9 @@ setup, and Android/iOS ZMR workflow scenarios, but no public timing rows yet.
 
 ## Single Tool Benchmark
 
+Use a single-tool benchmark to prove that ZMR can run a scenario repeatedly on a
+target with the required pass rate and latency threshold:
+
 ```bash
 scripts/benchmark.sh \
   --zmr examples/android-app-login-smoke.json \
@@ -71,7 +75,8 @@ zmr report traces/bench-<timestamp> \
 
 ## Pilot Wrapper
 
-The configurable Android pilot script can run both sample scenarios repeatedly:
+Use pilot wrappers when the benchmark should look like a real app release gate.
+The configurable Android pilot script can run sample scenarios repeatedly:
 
 ```bash
 ./scripts/run-android-pilot.sh \
@@ -173,15 +178,18 @@ Benchmark reports include:
 - links to each run's `events.jsonl`
 - optional JUnit XML with one testcase per benchmark row for CI test reports
 
-Before making public performance claims, run the same scenario repeatedly on a clean emulator image and include the raw `results.jsonl` plus the redacted trace bundle for any failure.
+Before making public performance claims, run the same scenario repeatedly on a
+clean emulator or simulator state and retain the raw `results.jsonl` plus the
+redacted trace bundle for any failure.
 
 ![ZMR HTML trace report showing the trace summary and per-event timeline](assets/report-html.png)
 
 ## Compare Against A Baseline
 
-Use `zmr-compare-benchmarks` when a private app repo has benchmark rows from
-ZMR and another local runner. The public ZMR repo keeps this generic: rows are
-grouped by the `tool` field and no external runner is hardcoded.
+Use `zmr-compare-benchmarks` only when a private app repo has benchmark rows
+from ZMR and another local runner for the same app path. The public ZMR repo
+keeps this generic: rows are grouped by the `tool` field and no external runner
+is hardcoded.
 
 Collect ZMR rows into the shared comparison file first:
 

package/docs/benchmarks/README.md

@@ -1,7 +1,8 @@
 # Benchmark Evidence
 
 This directory contains public-safe benchmark evidence collected from
-reproducible ZMR demo apps.
+reproducible ZMR demo apps. Treat each file as fixture-specific evidence, not a
+global performance claim.
 
 Evidence here is intentionally narrow:
 
@@ -11,6 +12,7 @@ Evidence here is intentionally narrow:
   baseline was collected on the same app build, device state, and scenario.
 - Raw local traces are not committed because generated reports and JUnit files
   can include absolute local paths. Public rows are sanitized before commit.
+- Product claims should point to the matching evidence pack and its scope.
 
 ## Evidence Packs
 

package/docs/benchmarks/benchmark-lab-v1.md

@@ -21,7 +21,7 @@ React Native, Expo, Flutter, native Android, and native iOS. The lab is not a
 generic benchmark scoreboard. Each fixture must represent an app workflow a
 developer can inspect, build, run, and adapt.
 
-The near-term wedge is agent-native mobile testing: structured observation,
+The near-term wedge is agent-first mobile testing: structured observation,
 selector-grade actions, trace-first debugging, and reviewable scenario
 generation. Benchmarks should prove the local runner path is fast and reliable
 without overstating what one fixture demonstrates.

package/docs/client-installation.md

@@ -1,25 +1,27 @@
 # Client Installation
 
-ZMR has two layers:
+ZMR has two layers. Install the binary first; add a language client only when
+your agent or harness needs idiomatic host-side calls.
 
 1. The `zmr` binary controls devices, runs scenarios, serves JSON-RPC, and writes traces.
 2. Language clients are optional wrappers around `zmr serve --transport stdio`.
 
-For fastest adoption, install the binary once with npm or Homebrew. Then use a
-language client only when you want tests or agents written in that language.
+For fastest adoption, install the native binary once with the curl installer.
+Then use a language client only when tests or agents are written in that
+language.
 
 ## Binary First
 
-Install from npm inside the app repo:
+Install the release binary and scaffold app-local ZMR state:
 
 ```bash
-npm install --save-dev zeno-mobile-runner
-npx zmr-wizard --app-id com.example.mobiletest --package-json
-npx zmr version
+curl -fsSL https://raw.githubusercontent.com/johnmikel/zeno-mobile-runner/main/install.sh | sh
+export PATH="$HOME/.local/bin:$PATH"
+zmr init --app --app-id com.example.mobiletest
+zmr version
 ```
 
-Homebrew is the best install path for non-JavaScript teams because it gives any
-language the same `zmr` executable:
+Homebrew is a secondary native install path when you use a generated formula:
 
 ```bash
 brew install --build-from-source ./dist/homebrew/zmr.rb
@@ -29,6 +31,13 @@ brew tap johnmikel/zmr
 brew install zmr
 ```
 
+JavaScript teams can instead pin ZMR in the app repo and use npm helper bins:
+
+```bash
+npm install --save-dev zeno-mobile-runner
+npx zmr-wizard --app-id com.example.mobiletest --package-json
+```
+
 ## TypeScript
 
 ```bash

package/docs/clients.md

@@ -1,14 +1,15 @@
 # Client Guide
 
 ZMR clients are reference implementations for the JSON-RPC protocol used by
-`zmr serve`. They are intentionally small and dependency-light.
+`zmr serve`. They are intentionally small, dependency-light, and host-side.
+They do not replace the `zmr` binary and they do not run inside the app under
+test.
 
 TypeScript and Python are the most common starting points for app teams and
-agent harnesses. Go, Rust, Swift, and Kotlin clients are reference integrations
-for teams that want to embed the protocol from those ecosystems. Go and Rust
-include typed trace discovery and scenario validation helpers for host-side
-agent loops; Swift and Kotlin include lightweight discovery and validation
-helpers for host-side automation.
+agent harnesses. Go, Rust, Swift, and Kotlin are reference integrations for
+teams that want host-side orchestration in those ecosystems. Go and Rust include
+typed trace discovery and scenario validation helpers; Swift and Kotlin include
+lightweight discovery and validation helpers for native mobile teams.
 
 | Language | Entry point | Example |
 | --- | --- | --- |