system: validate installed rollback workflow

docs/GUIX_DIFFERENCES.md

@@ -48,13 +48,12 @@ That path remains the active runtime boundary used by activation and service wir
 
 Fruix avoids in-place mutation of an older deployed closure.
 
-The validated rollback story today is:
+The validated rollback story now has two layers:
 
-- keep the earlier declaration
-- rebuild or rematerialize it
-- boot or redeploy that earlier closure again
+- declaration-level rollback by rebuilding/redeploying an earlier declaration
+- installed-system rollback between already-recorded generations on the target itself
 
-That is Guix-like in spirit even though Fruix does not yet expose the same installed-system rollback command surface.
+That is Guix-like in spirit, although Fruix still exposes a smaller installed-system workflow than Guix's more mature `reconfigure` model.
 
 ### Generation-style metadata and roots
 
@@ -78,7 +77,7 @@ Guix heavily reuses its profile-generation model and represents a lot of meaning
 
 Fruix keeps the **semantics** but uses a more explicit metadata-oriented layout for installed systems.
 
-Current Fruix layout:
+Current Fruix layout starts as:
 
 ```text
 /var/lib/fruix/system/
@@ -92,6 +91,20 @@ Current Fruix layout:
       install.scm
 ```
 
+After a validated installed-system switch, Fruix also records:
+
+```text
+/var/lib/fruix/system/
+  rollback -> generations/1
+  rollback-generation
+  generations/
+    2/
+      closure -> /frx/store/...-fruix-system-...
+      metadata.scm
+      provenance.scm
+      install.scm
+```
+
 Why Fruix does this:
 
 - it makes deployment state easier to inspect directly
@@ -154,27 +167,35 @@ Validated examples:
 
 So compared with Guix-on-Linux intuition, Fruix operators should be more explicit about target-device selection during installation and installer-media validation.
 
-## 6. Fruix does not yet have Guix-equivalent installed-system generation commands
+## 6. Fruix now has a minimal installed-system generation command surface, but it is still smaller than Guix's
 
-This is the biggest current operational gap.
+This remains the biggest operational gap, but it is no longer a complete gap.
 
-Fruix does **not** yet provide a mature equivalent of the familiar Guix System operator flow around in-place generation switching and rollback commands.
+Installed Fruix systems now provide a small in-guest helper:
 
-Today, Fruix rollback is mostly:
+- `fruix system status`
+- `fruix system switch /frx/store/...-fruix-system-...`
+- `fruix system rollback`
 
-- declaration-driven
-- rebuild/redeploy based
+What this gives you today:
 
-rather than:
+- explicit current-generation tracking
+- explicit rollback-generation tracking
+- in-place switching between already-staged closures on the installed target
+- rollback without reinstalling the whole system image again
 
-- switch current system generation in place through a dedicated command
+What it still does **not** give you yet compared with Guix:
 
-So if you come from Guix, assume that Fruix currently has:
+- a mature `reconfigure`-style workflow that builds and stages the new closure from inside the target system
+- automatic closure transfer/fetch as part of `switch`
+- the broader generation-management UX Guix operators expect
+
+So if you come from Guix, assume that Fruix now has:
 
 - strong closure/store semantics
 - explicit install artifacts
 - explicit generation metadata roots
-- but a less mature installed-system generation UX
+- a real but still modest installed-system switch/rollback UX
 
 ## Where Fruix is intentionally trying to improve on Guix's representation
 
@@ -202,10 +223,11 @@ If you are already comfortable with Guix, the safest Fruix mental model today is
    - closure path
    - source provenance metadata
    - install metadata
-5. think of rollback today as:
-   - “redeploy the earlier declaration again”
-   rather than:
-   - “switch to an already-managed previous generation in place”
+5. think of rollback in two layers:
+   - if the target already has the desired closure staged locally:
+     - use `fruix system rollback`
+   - otherwise:
+     - redeploy the earlier declaration again
 
 ## Status summary
 
@@ -222,4 +244,4 @@ It differs most from Guix in:
 - source-provenance emphasis
 - installer-medium-oriented workflows
 - generation-layout representation
-- and the still-maturing installed-system generation command surface
+- and an installed-system generation command surface that now exists, but is still much smaller than Guix's