Module harness_check 

Whether a transport: process capsule’s harness is installed, at a tested version, and logged in for this user, asked without launching a session.

mur doctor asks it. Every answer comes from what mur run uses: the same driver checks at staging, the same binary resolution, the same probe environment and bound as the version probe a run makes. Only the driver knows how its harness reports a login, so the login question is the driver’s login-check and read-login, never a guess made here.

Structs

HarnessCheck

What check_process_harness found about a process capsule’s harness.

Enums

HarnessBinary

Where the harness binary resolved to.

HarnessLogin

Whether the harness is logged in, as the driver reads its login check.

HarnessVersion

What the version probe read, judged against the driver’s tested-versions.

Constants

LOGIN_REASON_MAX_CHARS

The longest reason, in characters, a HarnessLogin carries.

Functions

check_process_harness

Checks the process driver in driver_bytes (an artifact’s .mur.zip bytes) and the harness it drives on this host.

harness_needs_report

The harness report mur run --explain-scope prints and session_start.effective_grants carries: the harness’s needs resolved against the manifest and this host, read-only, with every need’s status. A need the manifest does not allow is refused in the report rather than raising — explain-scope exits 0. A driver that cannot be read (missing, unloadable, wrong WIT level) is an crate::harness_needs::HarnessReport with unresolved naming why and every list empty.