Module binary 

Find the dev build of the app under test, wherever the build put it.

right-release dev and rightkit cargo build run through the RightKit build broker, which builds into its own target root (<managed root>/rightkit-build-control/ws/<key>/g/<gen>/<leaf>/<triple>/<profile>/) and does not forward app env such as MAILRIGHT_APP_BINARY into a later rightkit cargo test. A journey run there could not find the executable, and every app hand-rolled discovery.

resolve tries, in order, and reports which source won (BinarySource):

1. Env override: RIGHTKIT_QA_APP_BINARY, then RIGHTKIT_QA_UI_BINARY, then the app’s own variable named by ui.binary_env. A set variable that fails validation is an error, never a fall-through.
2. Pointer file: a gitignored file under the app root (.rightkit-qa-app-binary, or ui.pointer_file) whose first non-empty line is the executable path (relative paths resolve against the app root). Same strictness as the env override.
3. Broker target root: the newest dev-profile executable named <bin> under the broker workspace whose identity.json canonicalRoot is the app’s cargo workspace root. See “Broker format” below.
4. App-root relative paths: the existing ui.binaries entry.

Every candidate must also be a QA build: it carries QA_CONTROL_MARKER (Latin-1 or UTF-16LE), the same bytes right-release scans for. A broker or app-root candidate without it is skipped with a reason; an env or pointer value without it is an error. With a single dev profile a plain dev build and the control build both write target/<triple>/debug/<bin>, so the marker is what tells them apart. --build-ui keeps a stable copy (stash_qa_build) and points .rightkit-qa-app-binary at it. Both that pointer file and the <target>/rightkit-qa/ copy are build output: git-ignore them.

One fixed launch path

macOS ties privacy grants to the path an app runs from, and the broker’s target folders change per generation (ws/<hash>/g/<gen>/...). resolve_stashed (what QaConfig::resolve_ui_binary and the suite use) therefore ALWAYS returns the fixed stash copy under the app root, copied in place with no retained copy of the replaced build (D01), whichever source found the build. A QA launch never runs from a broker generation path.

Every candidate must exist, be a regular file, be named <bin> (or <bin>.exe) and must not sit in a release profile directory. A shipping or release-tier artifact is never picked.

Broker format

The broker’s per-job receipts (<broker root>/receipts/<id>.json) carry only freshness counts (compilerArtifacts), no executable path, so they cannot name the last built artifact. What is stable is the workspace state: ws/<key>/identity.json ({"schemaVersion":1,"key","canonicalRoot"}) and the target tree ws/<key>/g/<generation>/<leaf>/... where <leaf> is t or target. Under the leaf sits [<triple>/]<profile>/<bin>[.exe]. Only the dev profiles release-iterate, debug and dev are read; the newest by modification time wins.

Structs

BinaryQuery

Inputs to resolve. env is injectable so tests never read the process environment.

ResolvedBinary

Enums

BinarySource

Which source produced the path.

Constants

APP_BINARY_ENV

Env var: the dev executable, for one app.

DEV_PROFILES

Profile directories the broker lookup reads. release is never in this list.

POINTER_FILE

Default pointer file name, relative to the app root.

QA_CONTROL_MARKER

The embedded control server’s marker; keep identical to embedded::QA_CONTROL_MARKER and packages/release/qa-control-scan.mjs. Not feature-gated here: this module only scans files.

STASH_DIR

Directory (under the cargo target dir) that holds the stable QA copy.

UI_BINARY_ENV

Older env var read by the suite runner; honored second.

Functions

broker_root_of

The broker root under a managed root.

has_qa_marker

True when the file contains QA_CONTROL_MARKER as Latin-1/UTF-8 bytes or as UTF-16LE (Windows wide string). Streamed in chunks, so a large executable is never held in memory.

is_stashed

True when path already sits under the fixed stash <app_root>/<STASH_DIR>.

resolve

resolve_stashed

resolve, then ALWAYS the fixed stash: whichever source wins (env, pointer, broker target or an app-root path), the returned path is the stash copy <app_root>/.rightkit-qa-bin/<triple>/<bin>, copied in place with no retained copy of the replaced build (stash_qa_build, D01). A QA launch therefore never runs from a broker generation path (ws/<hash>/g/<gen>/..., a new folder on every generation) or from target/debug, so macOS privacy grants keep one path. source still names where the build was found. The pointer file is not rewritten (a fresh build is picked up on the next run).

stash_binary

The stash copy itself. pointer is Some(<pointer file override>) to write the pointer file, None to leave it alone; require_marker keeps the QA control-marker check (an explicitly named UI binary skips it, as before, and passes false). The caller has already refused installed apps.

stash_qa_build

After a successful --build-ui: copy the built QA executable (and a sibling .pdb) to <app_root>/<STASH_DIR>/<triple-or-host>/<name> in place (staging copy, then rename, retaining no copy of the replaced build), and point <app_root>/.rightkit-qa-app-binary (or pointer_file) at the copy. A later plain dev build that overwrites debug/<bin> then cannot displace it. The built file must carry the control marker.

validate

Exists, a regular file, named <bin> or <bin>.exe, and not in a release profile directory.