CUA Driver Test Matrix

This is the source map for the Rust test suites in packages/cua-driver. It uses two top-level test classes:

1. Unit and deterministic protocol tests. These do not depend on a repo-local application or an interactive desktop.
2. Harness E2E tests. These build and launch a repo-local application, drive it through the Rust driver, and verify an external application or desktop oracle.

A test is E2E because it crosses the driver, OS, window system, and application boundary. The Rust harness catalog and its external oracles are the source of truth.

Matrix Dimensions

Every harness E2E result should identify these dimensions:

Focus preservation is a cross-cutting oracle, not a separate matrix family. When a background action is tested, the row should attach the platform focus observer in addition to checking the target application's external state.

AX and PX describe how an action addresses a target. They are not capture modes. get_window_state returns the tree and screenshot together; the action uses an element index or coordinates.

Unit And Deterministic Tests

These run without the repo-local GUI applications:

Some protocol tests spawn the driver process. They remain deterministic because they do not launch a real target application or require a desktop. They should be reported with the unit gate, separately from Harness E2E.

The ordinary unit gate must not run #[ignore] GUI tests and must not turn missing desktop fixtures into silent skips.

Harness E2E: Shared Web Applications

Electron and Tauri are separate repo-local applications that load the shared web harness. The fixture exposes action-specific controls and external state markers rather than an application task that duplicates those same actions.

Source:

• tests/fixtures/shared/web/index.html
• tests/fixtures/apps/cross-platform/electron/
• tests/fixtures/apps/cross-platform/tauri/
• rust/crates/cua-driver/tests/cross_platform_behavior_test.rs

The shared harness exposes deterministic external markers for these actions:

The Rust shared catalog declares 40 evidence-bearing cells per harness application. Windows and Linux run 80 shared cells across Electron and Tauri; macOS also runs the native WKWebView host for 120 shared cells. Each host covers the full AX/PX and foreground/background cross-product for click, text, keyboard, sequential type-then-Return, scroll, and child-window actions, plus both delivery modes for PX drag and AX editor-save. A background capability refusal is a valid result only when the test verifies the declared structured refusal and the no-focus/no-z-order/no-input-leak side effect. Background posture requires one foreground window to contain the target geometry, not merely overlap it. The lane preflight also injects deliberate focus and input violations and requires the sentinel to detect both before its results are trusted. A refusal fails a cell whose contract requires delivery. Canonical reporting rejects skips and enforces the complete shared catalog size for unfiltered runs. Diagnostic filters are allowed, but matching zero cells is always an error.

Harness E2E: Native Windows

Windows native harnesses are repo-local applications built from source:

Native controls use AX/UIA state as their oracle. Pointer actions also use PX where the tool contract requires coordinates. Current set_value rows declare background delivery and attach desktop-side-effect oracles.

Harness E2E: macOS

macOS uses the installed ScreenCaptureKit/AX permissions for GUI runs. Its maintainer acceptance gate runs in a disposable clone of the stopped Lume SIP-off golden image described in the macOS Lume runner guide. Maintainers build that private seed from the sanitized public base macos-tahoe-cua:26.5.2. The repo-local harnesses are canonical; Calculator and TextEdit are supporting real-app checks. SwiftUI's popover trigger is proven independently from the remaining transient-panel AX discovery gap.

Harness E2E: Linux

Nix provides the Linux build and desktop environment. X11 and Wayland are separate matrix dimensions because their capture and input contracts differ. Linux runs do not produce GIF output. Every canonical GUI cell retains an MP4 and trajectory alongside screenshots, AX trees, structured results, and driver logs for E2E evidence.

Action Delivery Matrix

The current per-OS delivery/refusal ledger is maintained in action-support.md. This section defines the coverage policy; the ledger records empirical status.

For each OS and harness where the action is supported, the canonical E2E suite should cover both delivery modes:

N/A means the API has no delivery mode for that operation. A refusal is a passing observation only when the Rust case expects refusal, the exact code is allowed, and the desktop-side-effect oracles pass.

CI And Local Entry Points

Workflows select private execution lanes. Rust source owns scenario definitions, fixture oracles, and result records. OS runners only build the driver, stage the local harnesses, establish the desktop session, collect evidence, and publish the shared report.

Evidence And Ownership

Every Harness E2E cell should produce:

recordings/<cell-label>-pid<pid>-<sequence>/recording.mp4
recordings/<cell-label>-pid<pid>-<sequence>/trajectory.json
results.jsonl
<rust-target>.log

The GitHub summary links the exact recording path from the corresponding row to its lane archive. Target logs remain lane-level diagnostics. Unit tests need logs and test-result output, but do not need desktop video.

When a new action or modality is added, update this document, the shared fixture oracle, the Rust test, and the OS-specific runner selection together. This is the cross-OS checklist that prevents a Windows-only test from being mistaken for cross-platform coverage.