hardware-in-the-loop-test

# Hardware-in-the-Loop Test > **Reading results:** a non-zero exit means look at BOTH streams. An operation > that ran but failed (a build with errors) puts `success: false` on **stdout**; > one that could not run (bad arguments, policy, a busy port) puts `errorType` on > **stderr** with stdout empty. Capture both (`--json 2>&1`). See the > `pio-manager` skill for the full contract. ## Purpose Use this skill to validate firmware behavior on a real device, not just through compilation. ## Safety Rules - Ask before flashing. - Do not assume physical wiring is safe. - Do not activate motors, heaters, lasers, relays, pumps, or high-power outputs without explicit user approval. - Keep tests bounded by timeout. - Save logs and artifacts. ## Workflow 1. Define finite expected markers, rejected patterns, timeout, stability window, and safe physical behavior. 2. Resolve one project, environment, board, and stable device binding with `pio-agent target-resolve`; stop on ambiguity or replacement. 3. Validate and build with `pio-agent agent-build-diagnose`. 4. Ask for an approval scoped to the exact flash workflow and target binding. 5. Run `pio-agent agent-flash-monitor-verify` after approval. 6. Check bounded serial markers, timing, or telemetry and retain task/log/artifact references. 7. Mark build, flash, monitor, and assertions independently as pass, fail, or inconclusive. 8. Cancel runaway tracked tasks with `pio-agent task-cancel <id>`; confirm cleanup with `pio-agent task-history --project-dir <dir>`, `pio-agent monitor-status`, and `pio-agent lock status`. 9. Save redacted evidence and summarize the result. Scheduled HIL writes require a pre-existing, exact, expiring `lab_runner` policy. A saved prompt cannot create, approve, or broaden that policy, and default scheduled monitoring must remain read/build/monitor-only. ## Example Test Definition ```yaml name: esp32_boot_marker board: esp32dev expected: serial_contains: BOOT_OK timeout_seconds: 15 ```