Architecture

Two thin clients — the GPUI app (wrec-app) and the wrec CLI — talk to a local daemon over a Unix socket. The daemon owns all recording state and drives a native Swift capture engine that does the actual pixel work: ScreenCaptureKit hands frames straight to AVAssetWriter, which writes the hardware-encoded .mov. Rust never touches frames.

wrec architecture diagram: wrec-app and the wrec CLI share core types and talk through an IPC client over a Unix socket to the daemon, which drives the macOS recorder and the capture engine (ScreenCaptureKit → AVAssetWriter → .mov)
Clients stay thin The app and CLI own user interaction only. They do not import backend, macOS recorder, or capture-engine code.
Control is the contract The control crate owns IPC request/response types, daemon discovery, daemon startup, job snapshots, errors, and protocol version checks.
Daemon owns recording state The daemon is the source of truth for target listing, Screen Recording permission requests, one active job, queued jobs, pause/resume/stop, and persisted events.
Platform code stays below daemon The macOS recorder and Swift capture engine are runtime internals. Agents should observe them only through daemon job events and errors.
Separate packages share one runtime shape The app package carries wrec-app, daemon, and capture-engine. The standalone CLI package carries wrec, daemon, and capture-engine.
Agent rule Use the CLI with --json, trust daemon job state, refresh target ids per task, and follow error.next for recoverable failures.