#3948·tinyusb

HIL: dispatched escalation for wedges beyond rung 1 (chief, hil-operator, contract)

Author: hathachCreated Sep 21, 2026Updated Sep 21, 2026
LabelsPrio 📌followup

Recovery beyond rung 1 (a wedged probe needing root-cycle, a dead controller needing pci-rebind, a driver-owned lock needing sysrq) is rig-wide and stays a dispatched action, never automatic. Today no role is named for it: agentrc chief.md:69 makes host-side USB recovery task scope without an actor, and the HIL contract's wedge rule says "consult usb-kernel-recover".

Remaining work

  • agentrc agents/chief.md:69: a still-wedged board (the admission marker of #3944, or wedged from hil-validate) dispatches one hil-operator for one named recovery action with explicit target busport and board, rung ceiling, budget and required cleanup result. pci-rebind only on the dead-controller signature (usb-kernel-recover/SKILL.md 3b), never for a live device-lock convoy. The sysrq and hypervisor rungs are needs-user in a headless session.
  • HIL contract (.claude/skills/hil/SKILL.md, wedge rule): a delegated run reports wedges and recovers only through its own in-run and post-pool paths; anything beyond is a separately dispatched action. The wording must describe what exists at the time it lands and report unresolved cleanup explicitly.
  • For CI: a marked board is a rig-side verdict for pr-ci-watcher; the recovery dispatch happens at chief's next launch. This is not a scheduling barrier; the barrier is the admission refusal of #3944.
  • After recovery, the operator clears the marker under lock (#3944's subcommand) and chief re-runs hil-validate for that board.

Verification

agentrc tests/test_agents.py phrase checks for the chief and contract text. Rig: one dispatched root-cycle on ci.lan against a deliberately wedged probe, marker cleared, following hil-validate run green.

Why deferred

Agreed in the 2026-09-21 HIL review with Codex as the last of five steps. The text-only parts can land earlier as a separate commit, provided they describe currently executable recovery and do not imply the post-pool phase (#3947) exists before it does.