Document gaps to real Guix FreeBSD builds

docs/PROGRESS.md

@@ -302,3 +302,67 @@ Next recommended step:
 1. document the concrete remaining gap between these Scheme-driven phase-runner prototypes and a true Guix package/derivation/store-daemon build on FreeBSD, especially around store management, implicit inputs, and build isolation
 2. or choose a somewhat more demanding GNU package with non-trivial declared inputs to identify the first builder-side FreeBSD adaptation points
 3. continue keeping `~/repos/bdwgc` in reserve if later FreeBSD-specific GC/thread issues appear
+
+## 2026-04-01 — Phase 1.2 follow-up: documented the gap to a real Guix package build
+
+Completed work:
+
+- analyzed the concrete remaining gap between the current FreeBSD validation harnesses and a real Guix package/derivation/store-daemon build
+- wrote the analysis to:
+  - `docs/reports/phase1-guix-build-gap-analysis.md`
+- based the analysis on the current local Guix source tree, including the relevant host-side and daemon-side code paths in:
+  - `guix/packages.scm`
+  - `guix/build-system/gnu.scm`
+  - `guix/gexp.scm`
+  - `guix/store.scm`
+  - `guix/derivations.scm`
+  - `gnu/packages/commencement.scm`
+  - `doc/guix.texi`
+  - `nix/libstore/build.cc`
+- compared those real Guix layers against the currently validated FreeBSD prototypes:
+  - shell-driven native GNU Hello harness
+  - Scheme-driven GNU Hello builder-phase runner
+  - Scheme-driven GNU which builder-phase runner
+
+Main conclusions recorded:
+
+- the current FreeBSD work has validated a narrow but real builder-side slice of Guix execution:
+  - Guile can run the needed Scheme code when using the fixed local build
+  - `(guix build gnu-build-system)` phases can build small GNU packages on FreeBSD
+- however, the current prototypes still bypass several critical layers of a real Guix build:
+  - package -> bag lowering
+  - bag -> derivation lowering
+  - imported module closure/store materialization
+  - real daemon RPC and build submission
+  - canonical `/gnu/store` management and metadata
+  - build users, chroot/container or jail-style isolation
+  - substitute/graft/offload handling
+- documented that the current phase runners rely on host tools already present on FreeBSD, whereas real `gnu-build-system` uses implicit inputs drawn from `%final-inputs`
+- identified the most actionable next milestone as a derivation-generation investigation for a tiny package, to locate the first failure boundary among:
+  - host-side lowering
+  - store interaction
+  - derivation emission
+  - daemon availability
+  - daemon-side execution
+
+Current assessment:
+
+- Phase 1.2 now has both practical build validation and a clearer architectural map of what remains before a true Guix package build can work on FreeBSD
+- the project has reduced uncertainty around builder-side GNU phase portability
+- the next uncertainty is now specifically the host-side lowering/store/daemon boundary, not the builder-phase boundary
+
+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`
+
+Next recommended step:
+
+1. investigate whether a tiny package can be lowered far enough on FreeBSD to produce a real derivation, and capture the exact first failure point
+2. if derivation generation proves immediately blocked, document whether the blocker is generated Guix modules/configuration, store connectivity, or daemon assumptions
+3. continue keeping `~/repos/bdwgc` in reserve if later FreeBSD-specific GC/thread issues appear