system: record explicit generation layout

docs/system-deployment-workflow.md

@@ -255,6 +255,43 @@ Therefore the canonical workflow is:
 
 Do not assume that a device name validated in one harness is portable to another.
 
+## Installed-system generation layout
+
+Installed Fruix systems now record an explicit first-generation deployment layout under:
+
+- `/var/lib/fruix/system`
+
+Current validated shape:
+
+```text
+/var/lib/fruix/system/
+  current -> generations/1
+  current-generation
+  generations/
+    1/
+      closure -> /frx/store/...-fruix-system-...
+      metadata.scm
+      provenance.scm
+      install.scm   # present on installed targets
+```
+
+Installed systems also now create explicit GC-root-style deployment links under:
+
+- `/frx/var/fruix/gcroots`
+
+Current validated shape:
+
+```text
+/frx/var/fruix/gcroots/
+  current-system -> /frx/store/...-fruix-system-...
+  system-1 -> /frx/store/...-fruix-system-...
+```
+
+Important detail:
+
+- `/run/current-system` still points directly at the active closure path in `/frx/store`
+- the explicit generation layout therefore adds deployment metadata and retention roots without changing the already-validated runtime contract used by activation, rc.d wiring, and tests
+
 ## Roll-forward workflow
 
 The current Fruix roll-forward model is declaration-driven.
@@ -310,13 +347,14 @@ Current rollback is:
 
 - **redeploy the earlier declaration again**
 
-Future Phase 19 work is expected to make these more explicit:
+What still remains for later Phase 19 work is making rollback itself operator-driven at the installed-system layer, rather than only declaration/redeploy driven.
 
-- current generation
-- previous generation
-- rollback target
-- installed-system roots and generation links
+Still pending:
+
+- previous-generation tracking beyond the initial explicit generation-1 layout
+- an explicit rollback target link distinct from `current`
 - an operator-facing installed-system rollback workflow
+- generation switching without full redeploy
 
 ## Provenance and deployment identity
 
@@ -341,12 +379,12 @@ The deployment workflow is now coherent, but it is not yet the final generation-
 
 Not yet first-class:
 
-- installed-system generation directories and symlink model
 - a dedicated `switch` or `reconfigure` command
 - an installed-system rollback command that moves between generations in place
-- explicit GC-root management for installed systems
+- multi-generation retention and previous-generation tracking beyond generation 1
+- generation switching policy independent of full redeploy
 
-Those are the next logical steps after Phase 19.1.
+Those are the next logical steps after the current explicit-generation layout.
 
 ## Summary
 
@@ -359,4 +397,4 @@ The current canonical Fruix deployment model is:
 - **identify deployments by closure path and provenance metadata**
 - **roll back by rebuilding/redeploying the earlier declaration**, not by mutating the current closure in place
 
-That is the operator-facing workflow Fruix should document and use until explicit installed-system generation management is added.
+That is the operator-facing workflow Fruix should document and use while installed-system generation switching remains more limited than Guix's mature in-place system-generation workflow.