Add fruix system command for FreeBSD

docs/PROGRESS.md

@@ -2291,3 +2291,65 @@ Next recommended step:
   - login-class warnings around `daemon`
   - the `gpart: Unknown command: show` rc noise
   - residual syslog/cron/runtime polish issues where they still matter
+
+## 2026-04-02 — Phase 10.1: added a real `fruix system` command
+
+Completed work:
+
+- started Optional Phase 10 with the first user-facing Fruix system-management command surface
+- wrote the subphase report:
+  - `docs/reports/phase10-fruix-system-command-freebsd.md`
+- added a real CLI wrapper:
+  - `bin/fruix`
+- added the corresponding Guile entry point:
+  - `scripts/fruix.scm`
+- added a dedicated validation harness:
+  - `tests/system/run-phase10-fruix-system-command.sh`
+
+What the new command does:
+
+- exposes declarative FreeBSD system artifact generation through a Fruix CLI instead of only phase-specific harness scripts
+- currently supports:
+  - `fruix system build OS-FILE`
+  - `fruix system image OS-FILE`
+  - `fruix system rootfs OS-FILE ROOTFS-DIR`
+- currently supports options:
+  - `--system NAME`
+  - `--store DIR`
+  - `--disk-capacity SIZE`
+  - `--rootfs DIR`
+  - `--help`
+- loads an operating-system object from a Scheme file, validates it, and dispatches to:
+  - `materialize-operating-system`
+  - `materialize-rootfs`
+  - `materialize-bhyve-image`
+- emits machine-readable `key=value` metadata for the produced artifacts
+
+Important findings:
+
+- the project already had the core declarative system machinery by the end of Phase 9; the missing piece here was a direct Fruix operator interface to that machinery
+- a small dedicated wrapper in this repo is currently the most practical way to expose that functionality without waiting for deeper upstream command-framework integration
+- keeping the command aligned with the already validated local FreeBSD Guile / Fibers / Shepherd toolchain avoids introducing a second, divergent runtime path
+
+Validation:
+
+- `tests/system/run-phase10-fruix-system-command.sh` passes
+- passing run workdir:
+  - `/tmp/phase10-fruix-cmd-1775117490`
+- the test validated that:
+  - `fruix system build` materializes a closure under `/frx/store/*-fruix-system-fruix-freebsd`
+  - the produced closure contains the activation path
+  - `fruix system image` materializes a disk image under `/frx/store/*-fruix-bhyve-image-fruix-freebsd/disk.img`
+  - the command returns expected metadata fields for both actions
+
+Current assessment:
+
+- Fruix now has a real user-facing system command in this repo, which is a concrete step from “prototype scripts” toward “OS tooling”
+- this does not replace all earlier harnesses yet, but it establishes `fruix system` as the new canonical interface for system closure/rootfs/image materialization work
+- system/image creation still typically requires `sudo` because the command writes into `/frx/store` and uses privileged image-building operations
+
+Next recommended step:
+
+1. continue Phase 10 by making more of the existing system workflows call `bin/fruix` directly instead of bespoke phase scripts
+2. reduce the current runtime compatibility shims for locally built Guile / Shepherd prefixes and move toward a more native store-path-aware Fruix runtime arrangement
+3. consider adding the next operator-facing subcommand on top of the now-working image path, such as a `vm`/deploy-oriented flow for the active XCP-ng workflow