native-build: promote results into store objects

docs/PROGRESS.md

@@ -46,6 +46,13 @@ Fruix currently has:
   - `/usr/local/bin/fruix-self-hosted-native-build`
   - result roots under `/var/lib/fruix/native-builds`
   - in-guest source recovery from current-system metadata
+- a validated promotion path that turns native-build result roots into first-class Fruix store objects via:
+  - `fruix native-build promote`
+  - `/frx/store/...-fruix-native-world-...`
+  - `/frx/store/...-fruix-native-kernel-...`
+  - `/frx/store/...-fruix-native-headers-...`
+  - `/frx/store/...-fruix-native-bootloader-...`
+  - `/frx/store/...-fruix-native-build-result-...`
 
 Validated boot modes still are:
 
@@ -58,32 +65,39 @@ The validated Phase 18 installation work currently uses:
 
 ## Latest completed achievement
 
-### 2026-04-05 — Phase 20.3 completed
+### 2026-04-05 — Native base builds promoted into first-class Fruix store objects
 
-Fruix now has a validated first controlled guest self-hosted native base-build prototype, on top of the already validated host-initiated in-guest build path.
+Fruix now has a validated end-to-end path that treats guest native base-build results as **staged mutable results first**, and then promotes them into **immutable Fruix store identities**.
 
 Highlights:
 
-- development-enabled systems now ship an in-guest helper at:
-  - `/usr/local/bin/fruix-self-hosted-native-build`
-- the helper recovers the declared materialized FreeBSD source store from:
-  - `/run/current-system/metadata/store-layout.scm`
-- the helper records self-hosted build results under:
+- guest self-hosted runs still record staged results under:
   - `/var/lib/fruix/native-builds/<run-id>`
   - `/var/lib/fruix/native-builds/latest`
-- heavy object/stage work remains under:
-  - `/var/tmp/fruix-self-hosted-native-builds/<run-id>`
-- the prototype exposed an important contract detail:
-  - a naive reuse of the development-shell exports polluted `buildworld`
-  - the validated helper therefore sanitizes development-oriented variables such as `MAKEFLAGS`, `CPPFLAGS`, `CFLAGS`, `CXXFLAGS`, and `LDFLAGS` before world/kernel bootstrap
-- the validated result includes guest-recorded native artifact outputs for:
-  - kernel
-  - bootloader slice
-  - headers / `usr/share/mk`
+- those result roots now carry promotion metadata describing:
+  - executor / executor-version
+  - closure path
+  - source store provenance
+  - build policy
+  - artifact entries for:
+    - `world`
+    - `kernel`
+    - `headers`
+    - `bootloader`
+- the host can now run:
+  - `fruix native-build promote RESULT_ROOT`
+- promotion creates immutable `/frx/store` objects for:
+  - `world`
+  - `kernel`
+  - `headers`
+  - `bootloader`
+- promotion also creates a result-bundle store object that references those artifact stores
+- the validated promotion metadata now makes Fruix-native native-build identity explicit instead of leaving results only as ad hoc files under `/var/lib/fruix/native-builds/...`
 
 Validation:
 
 - `PASS phase20-self-hosted-native-build-xcpng`
+- `PASS phase20-native-build-store-promotion-xcpng`
 
 Reports:
 
@@ -92,6 +106,7 @@ Reports:
 - `docs/reports/phase20-development-environment-freebsd.md`
 - `docs/reports/phase20-host-initiated-native-builds-freebsd.md`
 - `docs/reports/phase20-self-hosted-native-builds-freebsd.md`
+- `docs/reports/phase20-native-build-store-promotion-freebsd.md`
 
 ## Recent major milestones
 
@@ -117,9 +132,14 @@ Reports:
 
 `docs/PLAN_4.md` currently ends at Phase 20.3, and that milestone sequence is now complete.
 
-The next practical follow-up is therefore no longer another planned `PLAN_4` phase, but a product decision:
+The next practical follow-up is now clearer:
 
-- whether to keep the new guest self-hosted helper as a narrow prototype while Phase 20.2 remains the default operator path
-- or whether to invest in a broader guest-driven Fruix-native native-build workflow
+- unify host-initiated and self-hosted native-build execution behind a shared Fruix executor/result model
+- make the same first-class promotion story available regardless of whether the outer loop is host-driven or guest-driven
+- decide how much of result import/promotion should remain host-side versus become a more integrated Fruix deployment action
 
-Phase 20.3 is now complete: Fruix validates a first controlled guest self-hosted native FreeBSD base-build prototype on the approved real XCP-ng path.
+The immediate architectural direction is no longer just “can guest self-hosting work?”
+
+It is now:
+
+- how should Fruix represent native base builds as real first-class objects and workflows across different executors?