orchestrator: gate Isolable/Cascading immediately on DeviceFatal boot failure A DeviceFatal BootFailed means the device itself reported its image as bad. For Isolable/Cascading components, going through recovery first is wasted work: gate them immediately via the same policy path as CorruptionDetected, so isolation and cascade happen without a recovery attempt. Required components still enter Recovering. The split is about what gating costs, not about whether a retry could work: recovery can try a different source each attempt, so a golden image may fix any component, but gating an Isolable component only holds it in reset while gating a Required one locks the platform down. The halt-on-exhaustion path applies normally. Also adds Effect::ReportBootFailed (and Report::BootFailed in the driver) so the checkpoint name and failure kind reach management software. The report is emitted before the transition for every non-stale BootFailed, regardless of kind or policy. Closes #477. Assisted-by: Claude (Anthropic)
The OpenPRoT Technical Charter can be found at https://github.com/OpenPRoT/.github/blob/main/GOVERNANCE.md
NOTE: We are converting our build system to bazel. We recommend installing bazelisk to automatically manage bazel versions.
You can run tasks using the Pigweed workflow launcher pw or bazel.
./pw presubmit - Run presubmit checks: formatting, license checks, C/C++ header checks and clippy../pw format - Run the code formatters.bazel test //... - Run all tests.bazel build //docs - Build documentation.The project is structured as a bazel module.
No additional tools are required - all dependencies are managed by bazel.