Validate GNU which builder phases on FreeBSD

docs/PROGRESS.md

@@ -236,3 +236,69 @@ Next recommended step:
 1. run the Scheme-driven phase-runner pattern against at least one more small GNU/autotools package on FreeBSD, or
 2. document the concrete gaps between this prototype and a real Guix package/derivation build, especially around store management and build isolation
 3. continue keeping `~/repos/bdwgc` in reserve if later FreeBSD-specific GC/thread issues appear
+
+## 2026-04-01 — Phase 1.2 follow-up: second Scheme-driven GNU package build validated with GNU which
+
+Completed work:
+
+- added a second Scheme-driven GNU package harness:
+  - `tests/native-build/gnu-which-guix-phase-runner.scm`
+  - `tests/native-build/run-gnu-which-guix-phase-runner.sh`
+- again used the previously validated fixed local Guile build because this harness depends on subprocess-heavy Guix/Scheme builder logic
+- used the current Guix package definition in `~/repos/guix/gnu/packages/base.scm` as the source of truth for:
+  - GNU which version `2.21`
+  - expected Guix nix-base32 source hash `1bgafvy3ypbhhfznwjv1lxmd6mci3x1byilnnkc7gcr486wlb8pl`
+- verified the downloaded tarball against the translated SHA256:
+  - `f4a245b94124b377d8b49646bf421f9155d36aa7614b6ebf83705d3ffc76eaad`
+- successfully executed the same subset of Guix builder-side `%standard-phases` on FreeBSD as used for GNU Hello:
+  - `set-SOURCE-DATE-EPOCH`
+  - `unpack`
+  - `configure`
+  - `build`
+  - `check`
+  - `install`
+- executed the resulting `which` binary successfully with a deterministic command:
+  - `PATH=/bin:/usr/bin ./which sh`
+- confirmed output:
+  - `/bin/sh`
+- captured metadata including:
+  - host triplet
+  - phase list
+  - runtime dependencies
+  - check-phase success status
+  - executed command output
+- wrote the results to `docs/reports/phase1-guix-which-phase-runner.md`
+
+Important findings:
+
+- this confirms the Scheme-driven Guix builder-side phase-runner pattern is not limited to GNU Hello; a second small GNU/autotools package also succeeds on FreeBSD
+- GNU which's `check` phase passed, but it did not leave behind an Automake-style `test-suite.log` or `testsuite.log`
+- GNU which emitted a non-fatal `configure` warning about Guix's standard `--enable-fast-install` flag being unrecognized
+- the source also emitted several clang warnings about deprecated non-prototype C declarations/definitions, but the build still completed successfully
+- the resulting `which` binary again showed a minimal store-like runtime linkage profile:
+  - `libc.so.7`
+  - `libsys.so.7`
+- unlike GNU Hello, the source tree did not present an obvious shipped `config.guess`, so the harness used `cc -dumpmachine` as a fallback for host-triplet metadata
+
+Current assessment:
+
+- Phase 1.2 now has two successful Scheme-driven Guix builder-side GNU package validations on FreeBSD:
+  - GNU Hello
+  - GNU which
+- this increases confidence that a narrow but real subset of `gnu-build-system` builder-side execution already works on FreeBSD when paired with the fixed local Guile build
+- the next uncertainty is now less about whether basic builder phases run at all, and more about where real Guix package/derivation/store integration and isolation will first require FreeBSD-specific adaptation
+
+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`
+
+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