Automate Native SDK apps

Every Native SDK app embeds an automation server — native-rendered apps and WebView-shell apps alike. It works through file-based IPC in .zig-cache/native-sdk-automation/ and is intended for smoke tests, CI checks with a GUI session, and quick runtime inspection: accessibility snapshots, widget driving through the real input paths, deterministic reference-renderer screenshots, readiness/state assertions, and bridge round-trips.

Automation is not browser DOM automation. It reports runtime/window/widget state, drives retained-canvas widgets, and can ask the runtime to reload or dispatch bridge requests. For DOM testing of the optional WebView path, use the frontend framework's tests or a browser automation tool against the dev server.

What automation can verify

• An automation-enabled app started and published ready=true.
• The runtime loaded the expected app name, source kind, and window metadata.
• The main window exists and is focused/open.
• The JavaScript-to-Zig bridge can round-trip a request through native automate bridge.
• Builtin window/WebView commands work when exercised by a smoke test.
• Reload requests are accepted by the runtime.
• Real pixels of retained-canvas (gpu_surface) views: native automate screenshot <view-label> renders the view's current canvas frame through the deterministic CPU reference renderer and writes a PNG artifact. Two captures of an unchanged scene are byte-identical, so screenshots can back golden-image or "did the UI change" checks.

What automation cannot verify