Module userdata 

QA runs never touch real user data.

A test run may not start an app on the user’s real data or on a location that can raise a system dialog (macOS file-access prompts for Documents, Desktop, Downloads, iCloud Drive and removable or network volumes; the same cloud-sync folders on Windows). Guard is evaluated by control::launch (and by the engine launch paths) before anything is started, with no opt-out for apps: a violation is a typed UserDataViolation naming the path and the rule, and nothing is launched. An engine launch must also name an isolated data directory (check_engine_launch); the one exception is a probe of the engine’s own refusal, available on Unix only and only with HOME redirected.

The rule for an app launched with a workspace:

• the workspace home must be a QA root this runner created (it sits directly under a rightkit-qa directory inside a system temp root on the internal disk and carries the .rightkit-app.json binding), and must itself break none of the forbidden-location rules;
• every directory passed to the app (the launch working directory and each absolute path in the environment) must resolve, symlinks followed, inside that home.

Forbidden anywhere: the user’s Documents, Desktop, Downloads, Pictures, Music and Movies; iCloud Drive (~/Library/Mobile Documents, ~/Library/CloudStorage), OneDrive, Dropbox and Google Drive folders; the user’s real application-support / AppData / .config directory for the app under test; any /Volumes/* volume; any Windows UNC (network) path.

Scenarios that need existing state build it with generated fixtures (the default) or with seed_from, which refuses to read the real per-user data of the app under test unless the scenario declares the copy scrubbed and a verification callback returns true before launch.

Structs

EngineLaunch

Everything the guard judges about one engine, sidecar or app-engine launch, before the process starts. env is the environment the launcher will set on the child (target values, the data directory variable, then the caller’s values, in that order: the last value of a key wins, as with Command::env).

Guard

What decides whether a launch may proceed. Build one with Guard::for_workspace (apps) or Guard::for_temp_roots (engines without a workspace).

ScrubDeclaration

How a seed copy proves it holds no user data.

UserDataViolation

A launch refused before anything started. From<UserDataViolation> for Error keeps ? working in code that returns crate::Result; match on rule where the reason matters.

Enums

DialogCheck

Outcome of a permission-dialog check.

Rule

Why a path was refused.

Functions

check_app_data_dir

App launches get their data directory from the workspace: the launch environment must carry RIGHTKIT_QA_DATA_DIR, pointing inside the QA root guard was built for. A workspace whose environment lost it is refused rather than launched on the app’s own default folder.

check_engine_dirs

Engine launches have no workspace: judge the data directory and the environment values that name data, home, profile or config directories.

check_engine_launch

Judge one engine launch. A launch is refused, before anything starts, when:

is_system_dialog_owner

True when name is a macOS process that owns permission prompts.

live_permission_dialog_check

TODO: observe live TCC prompts. rightkit_qa_driver::mac::windows(pid) lists windows of one pid only; there is no enumeration of windows by owner name (UserNotificationCenter, CoreServicesUIAgent), so no reliable detector exists in this crate yet. This hook reports DialogCheck::Unsupported instead of guessing. Replace the body once the automation layer can list windows by owner without clicking them.

permission_dialog_in

Positive evidence only: the first sampled foreground name that belongs to a system dialog agent, from StopReport::frontmost_states. An empty answer proves nothing, because these agents rarely become frontmost.

resolve

Resolve symlinks in the longest existing prefix and append the rest, so a path that does not exist yet is still judged by where its existing parents really are.

seed_from

Seed <data_dir>/<dest_rel> from source through the caller’s transform(source, dest).

seed_from_guarded

seed_from with an explicit guard (tests use a fake user home).