Validate Shepherd PID 1 boot on XCP-ng

docs/PROGRESS.md

@@ -2486,3 +2486,58 @@ Next recommended step:
 1. try the `shepherd-pid1` image on the real XCP-ng VM
 2. if it boots there too, decide whether to keep `shepherd-pid1` as an experimental selectable boot mode or advance it further toward the main Fruix boot path
 3. continue reducing the remaining Guile / Shepherd compatibility-prefix shims now that the broader `rc.d` boot-manager dependency has been locally bypassed
+
+## 2026-04-02 — Post-Phase-10: Shepherd-as-PID-1 boot also passed on the real XCP-ng VM
+
+Completed work:
+
+- took the locally validated `shepherd-pid1` boot mode and tested it on the real XCP-ng deployment path
+- wrote the follow-up report:
+  - `docs/reports/postphase10-shepherd-pid1-xcpng-freebsd.md`
+- expanded the Shepherd-PID-1 operating-system template so the generated guest remains compatible with both local virtio and the real Xen NIC path:
+  - `tests/system/phase11-shepherd-pid1-operating-system.scm.in`
+  - now includes:
+    - `ifconfig_xn0=SYNCDHCP`
+    - `ifconfig_em0=SYNCDHCP`
+    - `ifconfig_vtnet0=SYNCDHCP`
+- added a dedicated real-VM Shepherd-PID-1 deployment/validation harness:
+  - `tests/system/run-phase11-shepherd-pid1-xcpng.sh`
+
+Validation:
+
+- `tests/system/run-phase11-shepherd-pid1-xcpng.sh` now passes on the operator-approved VM and existing VDI:
+  - VM `90490f2e-e8fc-4b7a-388e-5c26f0157289`
+  - VDI `0f1f90d3-48ca-4fa2-91d8-fc6339b95743`
+- passing run workdir:
+  - `/tmp/pid1-xcpng-1775129768`
+- passing real-guest metadata confirmed:
+  - `ready_marker=ready`
+  - `run_current_system_target=/frx/store/2940c952e9d35e47f98fe62f296be2b6ab4fceb3eee8248d6a7823decd42a305-fruix-system-fruix-freebsd`
+  - `pid1_command=[guile]`
+  - `shepherd_pid=1`
+  - `shepherd_socket=present`
+  - `shepherd_status=running`
+  - `sshd_status=running`
+  - `init_mode=shepherd-pid1`
+
+Important findings:
+
+- the local QEMU PID 1 prototype was not a simulator-only artifact; the same general boot design also works on the real XCP-ng/Xen guest
+- as expected for a Guile-script entry point, the PID 1 process image shows up as Guile, but the meaningful architectural check is that:
+  - `/var/run/shepherd.pid` contains `1`
+- this means Fruix has now validated two distinct real-VM boot architectures on FreeBSD:
+  - `freebsd-init+rc.d-shepherd`
+  - `shepherd-pid1`
+- however, this still does not remove the current Guile / Shepherd compatibility-prefix shims; those remain a separate runtime-artifact issue rather than an init-manager issue
+
+Current assessment:
+
+- Shepherd-as-PID-1 is now no longer merely a local prototype; it is validated on the real XCP-ng VM as well
+- this significantly strengthens the path toward a more Guix-like Fruix system architecture on FreeBSD
+- the main remaining native-runtime gap is now the baked-prefix / compatibility-shim problem, not whether Fruix can boot with Shepherd as PID 1
+
+Next recommended step:
+
+1. focus directly on eliminating the remaining Guile / Shepherd compatibility-prefix shims from the guest runtime
+2. preserve `shepherd-pid1` as an experimental selectable boot mode while that cleanup proceeds
+3. once the runtime-prefix issue is reduced, reassess whether `shepherd-pid1` should replace the older `freebsd-init+rc.d-shepherd` path as the preferred Fruix boot architecture