Validate real-store profiles on FreeBSD

docs/PROGRESS.md

@@ -1791,3 +1791,79 @@ Current assessment:
 
 - Phase 6.2 is now satisfied on the current FreeBSD prototype track
 - the next step is to validate a minimal user-facing profile installation flow on top of these real store outputs
+
+## 2026-04-01 — Phase 6.3 completed: minimal profile installation validated on real store outputs
+
+Completed work:
+
+- added a runnable real-store profile harness:
+  - `tests/packages/run-phase6-real-store-profile-prototype.sh`
+- wrote the Phase 6.3 report:
+  - `docs/reports/phase6-real-store-profile-freebsd.md`
+- updated the Phase 6 package-build harnesses so they can recover derivation paths even when the requested outputs are already present in `/frx/store`
+- ran the real-store profile harness successfully and captured metadata under:
+  - `/tmp/phase6-real-store-profile-metadata.txt`
+
+Important findings:
+
+- the current FreeBSD track now has a minimal user-facing profile installation flow built on top of real Phase 6 store outputs rather than the earlier Phase 3 package/profile prototype inputs
+- the validated transaction semantics are intentionally small but real:
+  - generation 1 is created from the Phase 6.1 host-built store item
+  - generation 2 is created from the Phase 6.2 jail-built store item
+  - the `profile` symlink switches to generation 2
+  - both generations remain addressable
+- observed metadata confirmed:
+  - `profile_target=profile-2-link`
+  - `generation1_store_path=/frx/store/...-hello-2.12.3`
+  - `generation2_store_path=/frx/store/...-hello-2.12.3`
+  - `current_store_path=/frx/store/...-hello-2.12.3`
+  - `profile_hello_output=Hello, world!`
+  - `clean_env_hello_output=Hello, world!`
+- the upstream-derived profile layer is still not fully usable on this FreeBSD track because the current `guix profiles` / `fruix package` path still reaches the unresolved bootstrap-platform blocker:
+  - `dynamic linker name not known for this system "x86_64-freebsd15.0"`
+- despite that blocker, the minimal Fruix-owned profile path is now validated on top of real daemon-built store items
+
+Current assessment:
+
+- Phase 6.3 is now satisfied on the current FreeBSD prototype track
+- Phase 6 as a whole is now complete on the active FreeBSD amd64 prototype path
+
+## 2026-04-01 — Phase 6 completed on the current FreeBSD prototype track
+
+Phase 6 is now considered complete for the active FreeBSD amd64 prototype path.
+
+Why this milestone is satisfied:
+
+- **Phase 6.1** success criteria were met on the prototype track:
+  - a real package definition derived from Guix's `hello` package now builds through `fruix build`
+  - the output lands in `/frx/store`
+  - the package runs from the store and preserves a declared source reference
+- **Phase 6.2** success criteria were met on the prototype track:
+  - a real package build now executes inside a FreeBSD jail
+  - the build work runs under dropped numeric build credentials
+  - the jailed build succeeds into `/frx/store`
+- **Phase 6.3** success criteria were met on the prototype track:
+  - real Phase 6 store outputs can be installed into a minimal profile environment
+  - generation switching works in a concrete form
+  - package execution through the profile succeeds for the current user
+
+Important scope note:
+
+- this completes the **real FreeBSD-backed store-build milestone** on the current prototype track, not full upstream-package-graph support or full upstream profile-layer parity yet
+- the current package path still relies on a prefetched local source tarball for GNU Hello because the built-in downloader/root-daemon path remains a separate FreeBSD issue
+- the current profile-installation path is a Fruix-owned minimal layer over real store outputs because the upstream-derived profile code still hits the unresolved FreeBSD bootstrap-platform mapping blocker
+- nevertheless, the core Phase 6 question has now been answered positively:
+  - real package definitions can be built into `/frx/store`
+  - those builds can run under integrated jail/build-user isolation
+  - and the resulting store items can be exposed through a minimal user-facing profile flow
+
+Next recommended step:
+
+1. begin Phase 7.1 by defining a minimal Fruix operating-system model for FreeBSD
+2. carry forward the selective Fruix naming policy:
+  - Fruix at the product boundary
+  - `/frx` as the canonical store root
+  - stable upstream-derived internal names unless there is strong architectural value in renaming them
+3. keep the two remaining Phase 6 follow-up blockers visible but scoped:
+  - built-in downloader/root-daemon integration for real package origins
+  - upstream-derived profile/bootstrap-platform support for `x86_64-freebsd15.0`