.nornir/build-thing-design.md · mikronova/draupnir

draupnir's build thing — what the recipe declares, and why

The code is the source (lane AG, 2026-08-30). crates/draupnir-build-thing is draupnir's impl BuildThing; .nornir/build-variants.toml is emitted from it and read back as authority by nothing:

cargo run -p draupnir-build-thing -- emit      # regenerate the file
cargo run -p draupnir-build-thing -- toml      # the emission, on stdout
cargo run -p draupnir-build-thing -- --list    # the roster and its cargo argv

Editing the toml changes nothing; the next emit deletes the edit. tests/toml_parity.rs fails for any reason the file and the code differ.

What it declares

Three rows, and all three are the same artifact: draupnir ships no executable. It is one crate with one [lib] and no [[bin]] — the boot/provisioning library (BootSpec/Machine, validation, the three backend seams, the fleet fan-out) that jera and Skidbladnir link in-process.

variant	features	what it is
`draupnir` ⭐	—	PURE std: trait surface, types, validation, fleet fan-out, zero dependencies
`draupnir-seed`	`seed`	plus the pure-Rust `fatfs` NoCloud seed-image authoring (the file-set render and seed-dir output are always compiled)
`draupnir-tunnr`	`backend-tunnr`	plus the live KVM wire over tunnr's `boot_test`; pulls `seed`, because the KVM adapter authors the seed image it attaches

Every row says linkage = "not-applicable". That is a declaration, not an omission: a library is linked by whoever consumes it and composes nothing, so the fat/thin axis has no answer — and an omitted key reads as the fat default, i.e. a self-containment claim nobody checked.

Why the recipe is this small

Because the build is. The 2026-07-30 suite inventory listed draupnir (CLI/server) and fleet_boot (daemon) as binaries; measured against the crate, neither exists. Those names are recorded in recipe.rs's doc comment rather than invented as phantom [[bin]] targets — an over-declared recipe is worse than none, because it lies with more detail. recipe.rs's own test no_row_declares_a_binary_because_this_repository_has_none holds that.

The four features nothing here builds

backend-oci, backend-youki, backend-redfish and redfish-server are real and no row turns them on. They are in [build.allow_unbuilt] with the reason, so the gap is a written decision rather than a silence. The reason is the same for the three backends — a backend is a consumer's choice about which wire it compiles in, and draupnir ships no artifact per backend to choose between. backend-tunnr has a row only because it is the one backend whose dependency is a PATH dep (tunnr-vm, not yet published), so whether it still compiles is a question about this repository. redfish-server is excused separately: it is a listening socket, deliberately not implied by backend-redfish, and a client-only build must not grow a server.

recipe.rs::every_offer_is_either_built_or_excused_by_name makes an unexcused gap impossible.