services/orchestrator: split api crate into capabilities and config

services/orchestrator/api/BUILD.bazel → services/orchestrator/capabilities/BUILD.bazel

@@ -4,11 +4,10 @@
 load("@rules_rust//rust:defs.bzl", "rust_library", "rust_test")
 
 rust_library(
-    name = "orchestrator_api",
+    name = "orchestrator_capabilities",
     srcs = [
         "src/boot_control.rs",
         "src/boot_monitor.rs",
-        "src/config.rs",
         "src/lib.rs",
     ],
     edition = "2024",
@@ -17,6 +16,6 @@ rust_library(
 
 # Host tests: build on the host platform, no kernel/QEMU.
 rust_test(
-    name = "orchestrator_api_test",
-    crate = ":orchestrator_api",
+    name = "orchestrator_capabilities_test",
+    crate = ":orchestrator_capabilities",
 )

services/orchestrator/capabilities/README.md

@@ -0,0 +1,8 @@
+<!-- Licensed under the Apache-2.0 license -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# orchestrator-capabilities
+
+Device-facing capability traits for the Boot Orchestrator: `BootControl`
+(actuation — hold/release reset) and `BootMonitor` (observation — read boot
+liveness). A dependency-free leaf; adapters implement them elsewhere.

services/orchestrator/api/src/lib.rs → services/orchestrator/capabilities/src/lib.rs

@@ -10,21 +10,20 @@
 //! `BootMonitor` is the observation capability: the orchestrator reads a
 //! device's boot liveness.
 //!
-//! This crate is a dependency-free leaf: it holds the capability contracts
-//! and the schema for the per-board device table, and everything depends
-//! downward on it. Concrete adapters bind a trait to a signal source and
-//! live in their own crates, so naming a capability never drags in the stack
-//! behind it — the HAL-backed `HalBootControl` and `GpioBootMonitor` are in
-//! `orchestrator-hal-adapters`; other backends (for example an MCTP-ready
-//! `BootMonitor`) implement the same traits from their own transport crate.
-//! Config values live in the board device tables
-//! (`target/<board>/devices.rs`).
+//! This crate is a dependency-free leaf: it holds the capability contracts,
+//! and everything depends downward on it. Concrete adapters bind a trait to a
+//! signal source and live in their own crates, so naming a capability never
+//! drags in the stack behind it — the HAL-backed `HalBootControl` and
+//! `GpioBootMonitor` are in `orchestrator-hal-adapters`; other backends (for
+//! example an MCTP-ready `BootMonitor`) implement the same traits from their
+//! own transport crate. The per-board device table schema lives in the
+//! separate `orchestrator-config` crate; board tables
+//! (`target/<board>/devices.rs`) declare the values.
 
 #![cfg_attr(not(test), no_std)]
 
 mod boot_control;
 mod boot_monitor;
-pub mod config;
 
 pub use boot_control::BootControl;
 pub use boot_monitor::{BootMonitor, BootStatus};

services/orchestrator/config/BUILD.bazel

@@ -0,0 +1,17 @@
+# Licensed under the Apache-2.0 license
+# SPDX-License-Identifier: Apache-2.0
+
+load("@rules_rust//rust:defs.bzl", "rust_library", "rust_test")
+
+rust_library(
+    name = "orchestrator_config",
+    srcs = ["src/lib.rs"],
+    edition = "2024",
+    visibility = ["//visibility:public"],
+)
+
+# Host tests: build on the host platform, no kernel/QEMU.
+rust_test(
+    name = "orchestrator_config_test",
+    crate = ":orchestrator_config",
+)

services/orchestrator/config/README.md

@@ -0,0 +1,8 @@
+<!-- Licensed under the Apache-2.0 license -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# orchestrator-config
+
+Schema for the per-board device table: `DeviceConfig`, `BootCheckpoint`,
+`BootSignal`, `CommitPolicy`, and a compile-time `validate`. Board tables in
+`target/<board>/devices.rs` supply the values.

services/orchestrator/api/src/config.rs → services/orchestrator/config/src/lib.rs

@@ -5,6 +5,8 @@
 //! (`target/<board>/devices.rs`) declare the values; no concrete line or
 //! device is named here.
 
+#![cfg_attr(not(test), no_std)]
+
 /// What the orchestrator requires before it commits a staged image.
 ///
 /// Intentionally exhaustive (not `#[non_exhaustive]`): adding a variant is

services/orchestrator/hal-adapters/BUILD.bazel

@@ -14,7 +14,7 @@ rust_library(
     visibility = ["//visibility:public"],
     deps = [
         "//hal/blocking",
-        "//services/orchestrator/api:orchestrator_api",
+        "//services/orchestrator/capabilities:orchestrator_capabilities",
     ],
 )
 

services/orchestrator/hal-adapters/README.md

@@ -0,0 +1,8 @@
+<!-- Licensed under the Apache-2.0 license -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# orchestrator-hal-adapters
+
+HAL-backed adapters for the capability traits: `HalBootControl` drives
+`BootControl` over a `ResetControl` line, `GpioBootMonitor` reads `BootMonitor`
+off a `GpioPort`. Kept separate so contracts never pull in the HAL.

services/orchestrator/hal-adapters/src/gpio_boot_monitor.rs

@@ -7,7 +7,7 @@
 use openprot_hal_blocking::gpio_port::{
     ActivePolarity, GpioError, GpioErrorKind, GpioPort, PinMask,
 };
-use orchestrator_api::{BootMonitor, BootStatus};
+use orchestrator_capabilities::{BootMonitor, BootStatus};
 
 /// Adapts any HAL GPIO error into a [`core::error::Error`].
 ///

services/orchestrator/hal-adapters/src/hal_boot_control.rs

@@ -4,7 +4,7 @@
 //! HAL-backed [`BootControl`]: bind one reset-controller line to a device.
 
 use openprot_hal_blocking::system_control::{Error as HalError, ErrorKind, ResetControl};
-use orchestrator_api::BootControl;
+use orchestrator_capabilities::BootControl;
 
 /// Adapts any HAL system-control error into a [`core::error::Error`].
 ///

services/orchestrator/hal-adapters/src/lib.rs

@@ -3,13 +3,13 @@
 
 //! HAL-backed adapters for the Boot Orchestrator capability traits.
 //!
-//! Each type here implements a capability trait from `orchestrator-api` against
-//! a HAL-blocking trait: [`HalBootControl`] drives `BootControl` over a
+//! Each type here implements a capability trait from `orchestrator-capabilities`
+//! against a HAL-blocking trait: [`HalBootControl`] drives `BootControl` over a
 //! `ResetControl` line, and [`GpioBootMonitor`] reads `BootMonitor` off a
 //! `GpioPort` input line. Adapters live in this crate — not in the leaf
-//! `orchestrator-api` — so that depending on a capability contract never pulls
-//! in the HAL. A transport-backed adapter belongs in its own crate depending
-//! on its own stack, by the same rule.
+//! `orchestrator-capabilities` — so that depending on a capability contract
+//! never pulls in the HAL. A transport-backed adapter belongs in its own crate
+//! depending on its own stack, by the same rule.
 
 #![cfg_attr(not(test), no_std)]
 

services/orchestrator/sm/src/lib.rs

@@ -134,7 +134,8 @@ enum Gating {
 /// gated out. The walk-phase payloads (`AwaitingReady`/`Recovering`) stay on the
 /// global [`State`] rather than here — those phases are properties of the whole
 /// machine, not of one component. Named for the *component service* axis to keep
-/// it distinct from orchestrator-api's trial-boot/commit (update-slot) lifecycle, which
+/// it distinct from orchestrator-capabilities's trial-boot/commit (update-slot)
+/// lifecycle, which
 /// is a separate concern.
 #[derive(Clone, Copy, PartialEq, Eq, Debug)]
 enum ComponentLifecycle {

services/orchestrator/sm/src/model.rs

@@ -194,7 +194,7 @@ pub enum Event {
     /// up. The passive-tier counterpart to [`Event::ComponentReady`]: a passive
     /// component has no iRoT to self-verify, so "it booted" is the only
     /// post-release signal it can produce. Clears that component's boot-progress
-    /// watchdog. Mirrors orchestrator-api's `BootProgress::Booted`.
+    /// watchdog. Mirrors orchestrator-capabilities's `BootProgress::Booted`.
     Booted(ComponentId),
     /// A challenger has requested a signed attestation.
     AttestationChallenge,

target/mock/BUILD.bazel

@@ -10,5 +10,5 @@ rust_library(
     srcs = ["devices.rs"],
     crate_name = "board_devices",
     edition = "2024",
-    deps = ["//services/orchestrator/api:orchestrator_api"],
+    deps = ["//services/orchestrator/config:orchestrator_config"],
 )

target/mock/devices.rs

@@ -9,7 +9,7 @@
 
 use core::time::Duration;
 
-use orchestrator_api::config::{BootCheckpoint, BootSignal, CommitPolicy, DeviceConfig};
+use orchestrator_config::{BootCheckpoint, BootSignal, CommitPolicy, DeviceConfig};
 
 /// Declaration order is the boot order: the orchestrator releases devices
 /// top to bottom, one at a time.
@@ -50,4 +50,4 @@ pub const MANAGED_DEVICES: &[DeviceConfig<u8, u8>] = &[
     },
 ];
 
-const _: () = orchestrator_api::config::validate(MANAGED_DEVICES);
+const _: () = orchestrator_config::validate(MANAGED_DEVICES);