Investigate Guix derivation generation on FreeBSD

docs/PROGRESS.md

@@ -366,3 +366,68 @@ 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
+
+## 2026-04-01 — Phase 1.2 follow-up: derivation-generation investigation identified the first real checkout blockers
+
+Completed work:
+
+- added a reproducible checkout/bootstrap/configure investigation harness:
+  - `tests/guix/run-derivation-generation-investigation.sh`
+- used the previously validated fixed local Guile build for the investigation:
+  - `/tmp/guile-freebsd-validate-install/bin/guile`
+- followed the operator instruction for future store setup by parameterizing the checkout attempts to use:
+  - store directory: `/frx/store`
+  - local state directory: `/frx/var`
+  - sysconf directory: `/frx/etc`
+- created a disposable shared clone of `~/repos/guix`
+- successfully ran `./bootstrap` from that disposable checkout on FreeBSD
+- attempted `configure` without `--with-courage`
+- attempted `configure` again with `--with-courage`
+- confirmed directly that the local fixed Guile build currently cannot load:
+  - `(gnutls)`
+- wrote the results to:
+  - `docs/reports/phase1-guix-derivation-generation-investigation.md`
+
+Important findings:
+
+- a stock Guix checkout currently fails configuration on FreeBSD before any derivation/store/daemon work is reached, due to the explicit unsupported-platform gate:
+  - ``configure: error: `x86_64-freebsd15.0' is not a supported platform.``
+- re-running `configure` with `--with-courage` gets past that gate, but then stops on a second blocker:
+  - `configure: error: The Guile bindings of GnuTLS are missing; please install them.`
+- a direct module-load test with the same local Guile confirms the problem more concretely:
+  - `(use-modules (gnutls))` fails with `no code for module (gnutls)`
+- this means the current effort is still blocked before reaching:
+  - usable `pre-inst-env` generation for Guix commands
+  - package -> bag lowering in a live checkout
+  - bag -> derivation lowering
+  - daemon connectivity
+  - actual `/frx/store` population
+
+Current assessment:
+
+- the first practical boundary between the earlier FreeBSD builder-phase prototypes and a real Guix checkout has now been located more precisely
+- the project is no longer blocked by vague uncertainty at this stage; it is blocked by two concrete checkout-preparation issues:
+  1. unsupported-platform configure gating
+  2. missing Guile `(gnutls)` bindings
+- importantly, the derivation-generation investigation has not yet reached the store/daemon boundary, so the next step must first clear the `(gnutls)` dependency issue
+
+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`
+
+Next recommended step:
+
+1. obtain working Guile `(gnutls)` bindings compatible with the fixed local Guile build and re-run the derivation-generation investigation
+2. once configuration succeeds, continue until the next failure boundary is identified among:
+  - `pre-inst-env` usability
+  - derivation emission
+  - daemon connectivity
+  - daemon-side `/frx/store` assumptions
+3. continue keeping `~/repos/bdwgc` in reserve if later FreeBSD-specific GC/thread issues appear