Bridge Shepherd to FreeBSD services

docs/PROGRESS.md

@@ -1425,3 +1425,114 @@ Next recommended step:
 2. use that bridge layer in a runnable integration harness that validates both activation and cleanup of those FreeBSD concepts
 3. continue carrying the separate real-checkout runtime blocker for later integration work:
   - investigate the `leave-on-EPIPE` failure in `./pre-inst-env guix --version`
+
+## 2026-04-01 — Phase 4.3 completed: FreeBSD Shepherd bridge layer validated across rc.d, network, filesystem, and account management
+
+Completed work:
+
+- added a reusable FreeBSD Shepherd bridge module:
+  - `modules/fruix/shepherd/freebsd.scm`
+- added a runnable integration harness exercising that bridge layer:
+  - `tests/shepherd/run-freebsd-shepherd-bridge-prototype.sh`
+- wrote the Phase 4.3 report:
+  - `docs/reports/phase4-freebsd-shepherd-bridge.md`
+- ran the bridge prototype successfully and captured metadata under:
+  - `/tmp/freebsd-shepherd-bridge-metadata.txt`
+
+Important findings:
+
+- the new module now exports concrete helper constructors for four FreeBSD integration categories:
+  - `freebsd-rc-service`
+  - `freebsd-loopback-alias-service`
+  - `freebsd-tmpfs-service`
+  - `freebsd-user-group-service`
+- the integration harness used those helpers to manage a real chained host-side service graph under Shepherd covering:
+  - a temporary rc.d script in `/usr/local/etc/rc.d/`
+  - loopback alias configuration on `lo0`
+  - tmpfs mount/unmount with mode validation
+  - temporary user/group creation and removal via `pw`
+- observed activation metadata confirmed all of those operations succeeded under Shepherd control:
+  - `target_running=yes`
+  - `rc_started=yes`
+  - `alias_present=yes`
+  - `tmpfs_mounted=yes`
+  - `tmpfs_mode=drwxr-x---`
+  - `user_present=yes`
+  - `group_present=yes`
+- observed cleanup metadata confirmed that `stop root` also reversed all of those host-side effects successfully:
+  - `rc_stopped=yes`
+  - `alias_removed=yes`
+  - `tmpfs_unmounted=yes`
+  - `user_removed=yes`
+  - `group_removed=yes`
+- the same expected FreeBSD runtime note remained true here as well:
+  - `System lacks support for 'signalfd'; using fallback mechanism.`
+  and again it did not prevent the prototype from working correctly
+
+Current assessment:
+
+- Phase 4.3 is now satisfied on the current prototype track
+- Shepherd now has a concrete FreeBSD bridge layer in-repo rather than only ad hoc validation scripts
+- with service supervision, rc.d integration, and FreeBSD host-concept bridging now all validated, Phase 4 is complete on the current FreeBSD amd64 prototype path
+
+## 2026-04-01 — Phase 4 completed on the current FreeBSD prototype track
+
+Phase 4 is now considered complete for the active FreeBSD amd64 prototype path.
+
+Why this milestone is satisfied:
+
+- **Phase 4.1** success criteria were met on the prototype track:
+  - Shepherd built successfully on FreeBSD with the fixed local Guile stack
+  - regular multi-service supervision worked
+  - dependency handling, status monitoring, privilege-aware execution, and respawn behavior were all validated
+- **Phase 4.2** success criteria were met in init-integration prototype form:
+  - a real FreeBSD `rc.d` wrapper launched Shepherd successfully
+  - a minimal essential-service graph started automatically in correct dependency order
+  - orderly reverse shutdown through native FreeBSD service entry points was validated
+- **Phase 4.3** success criteria were met on the prototype track:
+  - a reusable FreeBSD Shepherd bridge layer was added
+  - Shepherd services successfully bridged to rc.d service control, loopback/network configuration, filesystem mounting/permissions, and temporary user/group administration
+  - both activation and cleanup were validated
+
+Important scope note:
+
+- this completes the **Shepherd porting milestone** on the current prototype track, not a literal replacement of `/sbin/init` on the live host
+- however, the core Shepherd questions have now been answered positively on FreeBSD:
+  - it builds
+  - it runs
+  - it supervises services
+  - it integrates with FreeBSD service-management conventions
+  - it can express concrete FreeBSD host-management tasks through Shepherd services
+- the separate real-Guix-checkout runtime blocker still exists for later integration work:
+  - `./pre-inst-env guix --version` fails with `Wrong type to apply: #<syntax-transformer leave-on-EPIPE>`
+  but that is now clearly outside the scope of the completed Phase 4 Shepherd milestone
+
+Recent commits:
+
+- `e380e88` — `Add FreeBSD Guile verification harness`
+- `cd721b1` — `Update progress after Guile verification`
+- `27916cb` — `Diagnose Guile subprocess crash on FreeBSD`
+- `02f7a7f` — `Validate local Guile fix on FreeBSD`
+- `4aebea4` — `Add native GNU Hello FreeBSD build harness`
+- `c944cdb` — `Validate Guix builder phases on FreeBSD`
+- `0a2e48e` — `Validate GNU which builder phases on FreeBSD`
+- `245a47d` — `Document gaps to real Guix FreeBSD builds`
+- `d62e9b0` — `Investigate Guix derivation generation on FreeBSD`
+- `c0a85ed` — `Build local Guile-GnuTLS on FreeBSD`
+- `15b9037` — `Build local Guile-Git on FreeBSD`
+- `47d31e8` — `Build local Guile-JSON on FreeBSD`
+- `d82195b` — `Advance Guix checkout on FreeBSD`
+- `9bf3d30` — `Document FreeBSD syscall mapping`
+- `7621798` — `Prototype FreeBSD jail build isolation`
+- `d65b2af` — `Prototype FreeBSD build user isolation`
+- `e404e2e` — `Prototype FreeBSD store management`
+- `eb0d77c` — `Adapt GNU build phases for FreeBSD`
+- `d47dc9b` — `Prototype FreeBSD package definitions`
+- `b36746f` — `Validate Shepherd services on FreeBSD`
+- `83715f0` — `Prototype Shepherd rc.d integration`
+
+Next recommended step:
+
+1. return to the remaining real Guix checkout/runtime blocker and investigate the `leave-on-EPIPE` failure in `./pre-inst-env guix --version`
+2. begin the next post-Phase-4 integration milestone by connecting the now-validated daemon/build/store/Shepherd prototypes more directly to real Guix checkout behavior on FreeBSD
+3. continue using `/frx/store` rather than `/gnu/store` whenever future integration experiments need a persistent store root