Call this FIRST in any session — it tells you the board identity
(name, MCU), where the firmware builds (firmware_dir, artifact), how
it flashes (flash connection), and — most importantly — which
functional probes exist (the "probes" list holds the names the probe
tool accepts). Read-only; touches neither host nor board.

Result: data carries the full profile; warnings flag an unloadable
probes section (fix the board YAML before relying on probes).

Run this before anything else when a board operation fails — and
ALWAYS when a tool returns status "incomplete" or code
CAPABILITY_UNAVAILABLE; the report names the exact missing link.
Read-only. Findings are listed in data.log under "issues:"; an empty
problems list with exit_code 0 means every prerequisite is healthy.

Mostly useful on its own for a fast failure loop; verify runs the
same build internally, so you don't need this before verify. Result:
succeeded + exit_code 0 = clean build; failed + BUILD_FAILED = the
compiler output in data.log names the offending file and line. The
binary lands at the profile's artifact path, ready for flash.

Flashes the artifact from the last build — call build first if
sources changed since. Tries up to 3 times on transient probe
errors. Any failure — including a missing ST-Link or CubeProgrammer —
surfaces as failed + FLASH_FAILED, exit_code 2; data.log carries the
programmer output. Run doctor to tell an environment problem (no
probe / no tools) apart from a write failure.

status=succeeded means the BOARD ITSELF booted the exact tree you are
on (its reported git sha matches the working tree) and every
functional probe passed. Trust no other signal; a clean build is not
a pass.

What it does: rebuild the tree, flash over ST-Link, start the app,
then require boot evidence proving WHICH build is running (UART
banner; or, without a serial cable, an SWD RAM signature — a stale
signature is wiped and read-back verified before start; a wipe that
fails, or whose readback answers wrong or cannot run at all, fails
closed), then run every defined probe, asserting on the board's
answers, including live register readbacks. DESTRUCTIVE: rewrites the
board's flash.

The failure code names the broken stage: BUILD_FAILED, FLASH_FAILED,
BOOT_EVIDENCE_TIMEOUT, BOOT_ERROR, IDENTITY_MISMATCH (the board runs
a different tree, or the signature wipe failed or its readback
answered wrongly — check the debug probe, not the build),
CAPABILITY_UNAVAILABLE (a required check could not run — most often
the console UART, or a readback that cannot run at all: environment
failure, check named, start withheld), PROBE_FAILED. Full transcript
in data.log; data.record is this run's persisted evidence record,
data.record_dir where the audit trail accumulates.

Report the status and code verbatim; never claim success from the
build step alone.

names picks specific probes (valid names are in board_info's
"probes" list); omit it or pass [] to run all. Probes need the
console UART: without it the result is incomplete +
CAPABILITY_UNAVAILABLE — never a pass. failed + PROBE_FAILED means an
assertion did not hold; data.log shows the exact step, the board's
last response, and which value was off.

Example: line "led0?" — the firmware replies with its LED state and
the live PWM register value (a hardware readback, not a cached
variable). The command set is board-specific — board_info and the
board's probe definitions show the known commands; unknown commands
typically answer "ERR unknown-cmd". The reply lands in
data.response within wait_s seconds; silence is reported as
"(no response)" in the summary + a warning — check wiring before
concluding the firmware is dead.

Use it to watch boot banners, self-test prints, or fault dumps
(HardFault traces appear here). Output lands in data.text; a fully
silent window is reported as "(console silent)" in the summary —
which for a just-reset board usually means wiring or baud-rate
trouble rather than a healthy quiet firmware. Read-only.