clan inventory carries per-host hardware facts instead of pure role assignment

[fosskar]

From architecture review 2026-07-10.

Problem

machines/flake-module.nix should answer "which machines run what", but several instance settings embed per-host hardware facts:

• beszel client (nixbox, :398-403): drive device list (/dev/nvme0,...,/dev/sdg), sensor blocklist, ~230-char extraFilesystems mount map
• monitoring server (:384): the monitored openwrt target
• snapshot-backup (:505-524): per-host zfs/btrfs folder lists
• borgbackup (:526-569): 44 lines of per-host repo paths, excludes, schedules

Consequences: changing nixbox's disks means editing the global 570-line inventory, not machines/nixbox/; reading machines/nixbox/ says nothing about its backups or monitored filesystems; a reader scanning the inventory for role topology wades through per-host strings.

Direction (open — needs design discussion)

These are clan role settings, so they cannot simply move to host modules. Candidate shapes:

1. Inventory keeps the instance but imports per-host settings from the host dir: client.machines."nixbox".settings = import ../nixbox/beszel-settings.nix;
2. Hardware facts (drive lists, filesystems) move into the flake.hosts facts file (modules/flake-parts/hosts.nix) and the inventory references them.
3. Status quo where the setting is genuinely about the service relationship (borg schedule), moving only hardware enumerations.

Decide which settings are role wiring (stay central) vs hardware facts (move next to the hardware).

Wins

• locality: hardware facts beside the hardware
• inventory becomes a readable topology index