Follow the composition root's inventory from the secrets input #49

Merged

vnprc merged 1 commit from agent/inventory-follows-secrets into master

2026-08-22 03:06:38 +01:00

allod-agent commented

2026-08-22 03:03:11 +01:00

Member

The composition root stopped locking allod/inventory twice. allod/secrets now follows this flake's inventory instead of resolving its own, so one inventory revision defines the fleet's machine facts by construction rather than by coincidence.

Nothing changes for any machine. All four exported configurations evaluate to byte-identical derivations against master, and the only locked source record the regenerated lock loses is inventory_2 — whose record was byte-identical to inventory already, down to the narHash. The graph goes from 18 nodes to 17.

If this is wrong, revert the commit. No machine is rebuilt on the strength of it, no revision moves, and nothing about the evaluated configuration differs.

Closes allod/archetypes#48. Refs allod/strategy#20.

What changed

One line in the secrets input, plus the lock it regenerates:

secrets = {
  url = "git+https://forge.anarch.diy/allod/secrets.git";
  inputs.nixpkgs.follows = "nixpkgs";
  inputs.inventory.follows = "inventory";   # added
};

allod/secrets declares an inventory input of its own and consumes it narrowly — inventory.lib.supportedPlatforms, for its own check platform list. Both nodes already locked 15ad5528, so the redirect changes which node the graph names and nothing about what it resolves to.

Why the coincidence is worth removing

Inventory is the sole source of machine facts: platform, type, runtime, MAC and address. Two inventory nodes at different revisions would mean allod/secrets deriving key material against one fleet definition while this flake builds another, with nothing reporting the split. Per-machine encrypted secret filenames are keyed to machine names, so a divergence surfaces as a machine whose secret does not exist — at provisioning time, on a host, in front of a human — rather than as an evaluation error.

That is the hazard the allod/vm collapse in allod/archetypes#39 removed, and the argument is the same one: no revision moves, the two copies already happened to agree, and the coincidence is what is being removed.

Risk

Low. The redirect changes graph shape, not resolved content, and the byte-identical derivations below are the proof rather than the claim.

The one durable consequence is directional: after this, allod/secrets tracks this flake's inventory pin rather than its own lock. That is the intent — but it means a future nix flake update inventory here also moves the inventory that allod/secrets evaluates against, where previously the two advanced separately. Given that divergence is the failure this removes, moving together is the correct behaviour, and it is stated here so the change in ownership is explicit rather than discovered.

allod/deploy carries the identical duplicate and needs the same one-line redirect; it declares secrets itself, so this change does not propagate there. That is the companion pull request, tracked on the same issue.

Validation

Derivations, evaluated per configuration from committed locks on both sides — one nix process each, since a whole-flake evaluation exceeds this box's memory:

configuration	master	this branch
`allod-dev`	`rzxh69v2i3li…`	`rzxh69v2i3li…`
`installer`	`2yj5038jnsgz…`	`2yj5038jnsgz…`
`nexus`	`mw9sfc8vw41h…`	`mw9sfc8vw41h…`
`privacy-1`	`zzzaralwv032…`	`zzzaralwv032…`

Lock graph: 18 nodes to 17. Diffing every non-root node's locked record between master and this branch produces exactly one hunk — the removal of inventory_2 — and no other record changes. Contract 1a's sole-pin property still holds directly: one allod/vm node, one microvm.nix node.

nix build .#checks.x86_64-linux.microvm-fleet-wiring passes.

Not run: the full ./check.sh gate, and microvm-host-join specifically — the one check that reads flake.lock as data. This box has roughly 5 GiB available against that gate's measured 5.7 GiB peak with no swap, which is allod/archetypes#31. The byte-identical derivations mean every check reading a machine configuration must produce its prior result, and the lock-graph property microvm-host-join asserts is verified directly above, but neither substitutes for running it. It should run on a box with the headroom before this merges.

The composition root stopped locking `allod/inventory` twice. `allod/secrets` now follows this flake's inventory instead of resolving its own, so one inventory revision defines the fleet's machine facts by construction rather than by coincidence. Nothing changes for any machine. All four exported configurations evaluate to byte-identical derivations against master, and the only locked source record the regenerated lock loses is `inventory_2` — whose record was byte-identical to `inventory` already, down to the narHash. The graph goes from 18 nodes to 17. If this is wrong, revert the commit. No machine is rebuilt on the strength of it, no revision moves, and nothing about the evaluated configuration differs. Closes allod/archetypes#48. Refs allod/strategy#20. ## What changed One line in the `secrets` input, plus the lock it regenerates: ```nix secrets = { url = "git+https://forge.anarch.diy/allod/secrets.git"; inputs.nixpkgs.follows = "nixpkgs"; inputs.inventory.follows = "inventory"; # added }; ``` `allod/secrets` declares an `inventory` input of its own and consumes it narrowly — `inventory.lib.supportedPlatforms`, for its own check platform list. Both nodes already locked `15ad5528`, so the redirect changes which node the graph names and nothing about what it resolves to. ## Why the coincidence is worth removing Inventory is the sole source of machine facts: platform, type, runtime, MAC and address. Two inventory nodes at different revisions would mean `allod/secrets` deriving key material against one fleet definition while this flake builds another, with nothing reporting the split. Per-machine encrypted secret filenames are keyed to machine names, so a divergence surfaces as a machine whose secret does not exist — at provisioning time, on a host, in front of a human — rather than as an evaluation error. That is the hazard the `allod/vm` collapse in allod/archetypes#39 removed, and the argument is the same one: no revision moves, the two copies already happened to agree, and the coincidence is what is being removed. ## Risk Low. The redirect changes graph shape, not resolved content, and the byte-identical derivations below are the proof rather than the claim. The one durable consequence is directional: after this, `allod/secrets` tracks this flake's inventory pin rather than its own lock. That is the intent — but it means a future `nix flake update inventory` here also moves the inventory that `allod/secrets` evaluates against, where previously the two advanced separately. Given that divergence is the failure this removes, moving together is the correct behaviour, and it is stated here so the change in ownership is explicit rather than discovered. `allod/deploy` carries the identical duplicate and needs the same one-line redirect; it declares `secrets` itself, so this change does not propagate there. That is the companion pull request, tracked on the same issue. ## Validation Derivations, evaluated per configuration from committed locks on both sides — one `nix` process each, since a whole-flake evaluation exceeds this box's memory: | configuration | master | this branch | |---|---|---| | `allod-dev` | `rzxh69v2i3li…` | `rzxh69v2i3li…` | | `installer` | `2yj5038jnsgz…` | `2yj5038jnsgz…` | | `nexus` | `mw9sfc8vw41h…` | `mw9sfc8vw41h…` | | `privacy-1` | `zzzaralwv032…` | `zzzaralwv032…` | Lock graph: 18 nodes to 17. Diffing every non-root node's `locked` record between master and this branch produces exactly one hunk — the removal of `inventory_2` — and no other record changes. Contract 1a's sole-pin property still holds directly: one `allod/vm` node, one `microvm.nix` node. `nix build .#checks.x86_64-linux.microvm-fleet-wiring` passes. **Not run:** the full `./check.sh` gate, and `microvm-host-join` specifically — the one check that reads `flake.lock` as data. This box has roughly 5 GiB available against that gate's measured 5.7 GiB peak with no swap, which is allod/archetypes#31. The byte-identical derivations mean every check reading a machine configuration must produce its prior result, and the lock-graph property `microvm-host-join` asserts is verified directly above, but neither substitutes for running it. It should run on a box with the headroom before this merges.

allod-agent added 1 commit

2026-08-22 03:03:11 +01:00