Add the machine-coverage check to the framework so every deployment's gate runs it #149

Merged

vnprc merged 1 commit from agent/machine-coverage-framework into master

2026-10-22 00:41:28 +01:00

allod-agent commented

2026-10-22 00:35:07 +01:00

Member

Nothing changes on any running machine. The framework gains one check, machine-coverage, that every deployment's gate now runs against that deployment's own data: its inventory machines, its host-key table and its four identity sets must name one set of machines, each identity under its machine type's set. The same check landed last week in the secrets template (allod/secrets#48), where it protected only the template, since every deployment builds from a private fork of that repo and pins this one; a second pull request removes that copy. What stays identical: every machine derivation, every other check, the existing identity assertion in machineConfigurations and the host-key guard in vm-facts.nix. Proof: the gate on this branch is green with the new check built; the check is green against the fork fixture with all three data inputs overridden, so it names nothing from the template; four sabotaged copies of the template's data are each refused by name; and a rule disabled inside the check turns its own fixture assertion red. If it is wrong, revert the one commit; a deployment whose legal layout it refuses sees which name and which file, and the fix is a data edit.

Refs allod/archetypes#148

Risk

R1. One new check; flake.nix passes four more values into the check index and nothing else moves. The worst credible failure after validation is a fork with a layout the fixtures did not anticipate going red on its next archetypes bump, with a message naming the offender. Rollback is a revert.

Validation

allod check . on the branch: All 47 steps passed (checks: 31 built), machine-coverage built.
Fork safety for this check: nix build .#checks.x86_64-linux.machine-coverage with secrets, profiles and inventory overridden to checks/fork-fixture/ (the path: form fork-safety.sh uses): green. The fixture's secrets export no serviceIdentities, and the existing or {} default carries it.
Sabotage on copies of the template's secrets, each run with --override-input secrets: a guest deleted from machine-host-keys.json with its ciphertext; an entry for a machine the inventory never declares; a guest removed from identity.nix; a service machine moved under privacyVMs. Each refused with its own message naming the offender.
One rule disabled inside the check (guestsWithoutHostKey forced empty): the fixture assertion fails, so the fixtures are load-bearing. Restored, the output path matches the healthy run.
A null machineHostKeys (a secrets input predating the export) is refused with the message vm-facts.nix already uses, covered by its own fixture.
Not run: the whole-suite fork-safety.sh, which is a lock-bump-path witness and peaks near this box's memory ceiling; the single-check form above is its mechanism applied to the one check this change adds.

Nothing changes on any running machine. The framework gains one check, `machine-coverage`, that every deployment's gate now runs against that deployment's own data: its inventory machines, its host-key table and its four identity sets must name one set of machines, each identity under its machine type's set. The same check landed last week in the secrets template (allod/secrets#48), where it protected only the template, since every deployment builds from a private fork of that repo and pins this one; a second pull request removes that copy. What stays identical: every machine derivation, every other check, the existing identity assertion in `machineConfigurations` and the host-key guard in `vm-facts.nix`. Proof: the gate on this branch is green with the new check built; the check is green against the fork fixture with all three data inputs overridden, so it names nothing from the template; four sabotaged copies of the template's data are each refused by name; and a rule disabled inside the check turns its own fixture assertion red. If it is wrong, revert the one commit; a deployment whose legal layout it refuses sees which name and which file, and the fix is a data edit. Refs allod/archetypes#148 ## Risk R1. One new check; `flake.nix` passes four more values into the check index and nothing else moves. The worst credible failure after validation is a fork with a layout the fixtures did not anticipate going red on its next archetypes bump, with a message naming the offender. Rollback is a revert. ## Validation - `allod check .` on the branch: `All 47 steps passed (checks: 31 built)`, `machine-coverage` built. - Fork safety for this check: `nix build .#checks.x86_64-linux.machine-coverage` with `secrets`, `profiles` and `inventory` overridden to `checks/fork-fixture/` (the `path:` form `fork-safety.sh` uses): green. The fixture's secrets export no `serviceIdentities`, and the existing `or {}` default carries it. - Sabotage on copies of the template's secrets, each run with `--override-input secrets`: a guest deleted from `machine-host-keys.json` with its ciphertext; an entry for a machine the inventory never declares; a guest removed from `identity.nix`; a service machine moved under `privacyVMs`. Each refused with its own message naming the offender. - One rule disabled inside the check (`guestsWithoutHostKey` forced empty): the fixture assertion fails, so the fixtures are load-bearing. Restored, the output path matches the healthy run. - A null `machineHostKeys` (a secrets input predating the export) is refused with the message `vm-facts.nix` already uses, covered by its own fixture. - Not run: the whole-suite `fork-safety.sh`, which is a lock-bump-path witness and peaks near this box's memory ceiling; the single-check form above is its mechanism applied to the one check this change adds.

allod-agent added 1 commit

2026-10-22 00:35:07 +01:00

Add machine-coverage check to the framework checks suite 7cf69589a5

Ports checks/machine-coverage.nix from the secrets template so every
deployment's gate asserts it, not only the template's own. The
primary-hypervisor rule (hostKeysForPrimary) is dropped: this
repository's identity surface carries no notion of "primary", so the
diagnostics function instead places every machine's identity, guests
and hypervisors alike, into one of four type-keyed sets (devIdentities,
privacyIdentities, serviceIdentities, hypervisorIdentities) and refuses
a mismatch. The duplicate-name rule is unchanged. A null
machineHostKeys (a secrets input predating the export) refuses with
the same message nix/vm-facts.nix uses for that case.

checks/default.nix gains the entry and the new arguments; flake.nix
passes privacyIdentities, serviceIdentities, hypervisorIdentities and
machineHostKeys into the check index. README notes machine-coverage as
the standing example under Fork-safe checks.

Refs allod/archetypes#148