Document FreeBSD base self-hosting decision

docs/reports/phase15-self-hosting-decision-freebsd.md

@@ -0,0 +1,120 @@
+# Phase 15.3: decision on self-hosted FreeBSD base builds
+
+Date: 2026-04-03
+
+## Question
+
+After Phases 13 through 15, should Fruix immediately pursue self-hosted FreeBSD base builds inside a Fruix-managed guest, or should it continue using the host builder while tightening source/reproducibility boundaries?
+
+## Current evidence
+
+What is now already true:
+
+- Fruix builds native FreeBSD base artifacts from `/usr/src` into `/frx/store`
+- Fruix has validated a host-base-free boot/runtime path composed from:
+  - `freebsd-native-kernel`
+  - `freebsd-native-bootloader`
+  - `freebsd-native-runtime`
+- that path boots locally under QEMU/UEFI and on the approved real XCP-ng VM/VDI
+- the FreeBSD base is now an explicit declarative system input through `freebsd-base`
+- Fruix can keep distinct declared base versions side by side in `/frx/store`
+- Fruix can roll forward to a candidate base declaration and roll back to the earlier closure without mutating it in place
+
+So the main Guix-inspired value proposition is already present at the system-deployment layer:
+
+- declarative system descriptions
+- content-addressed outputs
+- side-by-side versions
+- rollback-friendly closures
+
+## What is still not strong enough for self-hosting to be the best next step
+
+### 1. Source acquisition is still too host-local
+
+The native base path still depends on the host's local `/usr/src` tree as the source of truth.
+
+That means the next reproducibility win is not "build inside the guest" first; it is "make the source tree selection/acquisition more explicit and reproducible" first.
+
+### 2. The host-built path is already validated and useful
+
+The current host-built native base flow is not hypothetical anymore.  It has already proven:
+
+- native artifacts in `/frx/store`
+- host-base-free boot/runtime composition
+- side-by-side closures
+- rollback behavior
+
+That makes it the productive path to continue refining.
+
+### 3. Self-hosting would currently mix several problems at once
+
+Jumping to guest self-hosting now would combine:
+
+- source acquisition/reproducibility questions
+- toolchain/profile maturity questions
+- build-environment modeling questions
+- large build-resource/runtime questions inside the guest
+- deployment/debugging questions
+
+That would make failure analysis worse just after the project finally obtained a clean validated deployment path.
+
+### 4. Platform constraints still argue for caution
+
+Current operator/environment constraints still matter:
+
+- local bhyve remains blocked under Xen due to missing nested VT-x exposure
+- real VM validation still reuses a single approved XCP-ng VM/VDI pair
+- XCP-ng storage permissions still prevent creating fresh VDIs on demand
+
+Those constraints do not block the current host-built native-base path, but they do make an early self-hosting pivot less attractive.
+
+## Decision
+
+**Decision:** do **not** pursue self-hosted FreeBSD base builds as the next immediate milestone.
+
+The near-term direction should remain:
+
+1. continue building native FreeBSD base artifacts on the host
+2. keep storing them in `/frx/store`
+3. improve declarative source-tree/version selection and provenance
+4. tighten reproducibility around source inputs and build parameters
+5. only revisit self-hosting after those pieces are stronger
+
+## Why this is the right decision now
+
+This preserves the important architectural win already achieved:
+
+- Fruix, not ad hoc host copying, now defines the deployed FreeBSD base through declared store artifacts
+
+It also follows the same spirit as Guix generation/rollback semantics: the crucial user-facing property is not where the build happened first, but that the result is declarative, content-addressed, side-by-side, and rollback-friendly.
+
+At this point Fruix already has those properties for the FreeBSD base path.
+
+## Conditions for revisiting self-hosting later
+
+Self-hosted base builds should be reconsidered only after at least most of the following are true:
+
+- Fruix can select or acquire distinct FreeBSD source trees more reproducibly than a single ambient `/usr/src`
+- the native development/toolchain side is modeled cleanly enough for a Fruix-managed build environment
+- operator/deployment tooling can handle larger iterative validation loops without excessive friction
+- there is a concrete benefit to guest-side base builds beyond what host-built store artifacts already provide
+
+## Recommended next focus after Phase 15
+
+The next work should likely focus on improving the declared source/reproducibility boundary around the now-working native base path, rather than on guest self-hosting.
+
+A good next phase would be centered on things like:
+
+- declarative source-tree selection/acquisition for the FreeBSD base
+- stronger provenance for declared source inputs
+- cleaner rebuilds across multiple source trees or revisions
+- continued refinement of deployment/generation management around the existing store-based base artifacts
+
+## Result
+
+Phase 15.3 is complete.
+
+The project now has an evidence-based decision:
+
+- **near-term path:** host-built native FreeBSD base artifacts in `/frx/store`
+- **not yet:** self-hosted FreeBSD base builds inside the Fruix guest