Decide board-by-board hardware rollout: v2.2.0 (SER5 amd64) / v2.4.0 (RasPi5 aarch64) / v2.5.0 (all three)

Real silicon arrives incrementally (Beelink SER5 in hand now; RasPi 5 + Milk-V
orderable around Mon 2026-08-31), so the hardware release is split per board
in hand, each an even-minor LTS point-in-time cut on the same line:

  - v2.2.0  amd64 bare metal  — Beelink SER5 (two 16GB sticks: one boots the
                                thumbdrive image, one mints a real Zuse user)
  - v2.4.0  aarch64 bare metal — Raspberry Pi 5
  - v2.5.0  all three bare     — adds Milk-V (riscv64)

Each closes only when its board's items are proven live (boot to ok>, block-
fence Zuse true, backend entropy non-deterministic), never build-only.

Records the decision in the authoritative Release Versioning Policy
(docs/lithosananke/ROADMAP.md, "Board-by-board hardware rollout, decided
2026-08-29") and re-maps G.4/G.5 in FABRIC-3.md onto the new cadence, noting
v2.0.0 was cut (tag v2.0.0).

FABRIC-3.md

@@ -3292,6 +3292,14 @@ author expects to have money for the SBCs — RasPi 6, Milk-V — within about a
 v2.0.0 cut). Nothing
 is deferred that QEMU alone could already prove out; only what genuinely needs real silicon.
 
+**v2.0.0 was CUT 2026-08-29 (annotated tag `v2.0.0`, the three-arch QEMU release).** With
+real boards arriving incrementally (Beelink SER5 in hand now; RasPi 5 + Milk-V orderable
+around Mon 2026-08-31), the hardware rollout is split per board in hand into **v2.2.0
+(amd64/SER5), v2.4.0 (aarch64/RasPi 5), v2.5.0 (all three, adds Milk-V riscv64)** — each an
+even-minor LTS point-in-time cut on the same line. Authoritative form in `ROADMAP.md`
+"Release Versioning Policy": **Board-by-board hardware rollout, decided 2026-08-29**. The
+G.2/G.4/G.5 items below are re-mapped onto that cadence in each section's completion notes.
+
 Everything about the state being shipped by v2.0.0 is unchanged by this versioning: the
 current tree is a complete, deterministic, three-architecture OS that boots UEFI under QEMU
 (M0–M9 core milestones complete, M7.1 Capsules live, M9 Block I/O live, terminal/REPL I/O
@@ -3425,22 +3433,25 @@ there.
   confirmed. `rdrand_fill()`'s exact logic host-proven to fill 32-byte/16-byte buffers and
   produce differing draws run-to-run (non-deterministic). aarch64/riscv64 builds unaffected
   (guarded off). Still parked for their real boards: riscv64 Zkr (RNDR), aarch64 peripheral
-  RNG. Full "two distinct certs per bleached boot" proof remains v2.5.0/real-board.
+  RNG. Next: prove RDRAND live on the real SER5 (v2.2.0), then add Zkr (v2.5.0/Milk-V) and the
+  aarch64 peripheral RNG (v2.4.0/RasPi 5) as those boards reach v2.2.0-level closure.
 
-#### G.5 [v2.5.0] Real-machine boot validation (SER5 / RasPi 6 / Milk-V)
+#### G.5 [v2.2.0 / v2.4.0 / v2.5.0] Real-machine boot validation (SER5 / RasPi 5 / Milk-V)
 
-Flash `starkernel.iso` to real media and boot each real board in hand, confirming the same
-acceptance story QEMU keeps green: POST `1012/0/0` + `ok>`, block-fence Zuse load true to the
-already-minted Artemis image, and the G.4 RNG backend working live. The board pool is
-SER5 (if still in hand), RasPi 6 (aarch64), Milk-V (riscv64) — the goal is at least one
-board per architecture, but each board that boots is a separate, recorded data point.
-This is the genuine transfer proof that the zero-degradation QEMU claim holds on real
-silicon — the thing v2.0.0 cannot honestly claim.
+Boot the generic thumbdrive image (`make -f Makefile.starkernel ARCH=<arch> thumbdrive`) on
+each real board in hand, confirming the same acceptance story QEMU keeps green: POST
+`1012/0/0` + `ok>`, block-fence Zuse load true to the already-minted Artemis image, and the
+corresponding G.4 RNG backend working live. **Mapping onto the board-by-board cadence
+(decided 2026-08-29):** v2.2.0 = SER5 (amd64, in hand now — two 16 GB sticks available, one
+to boot the image, one to mint a real Zuse identity on real hardware); v2.4.0 = RasPi 5
+(aarch64, orderable around Mon 2026-08-31); v2.5.0 = adds Milk-V (riscv64), the full
+three-arch bare-metal cut. Each board that boots is a separate, recorded data point, and
+each milestone closes only when its board's items are proven live (not build-only).
 
-- **Exit criterion:** each board in hand cold-boots to `ok>` with Arena conservation
+- **Exit criterion (per milestone):** the board cold-boots to `ok>` with Arena conservation
   (43691/21845/65536), Zuse cert loads from the fence (or mints fresh on bleached media),
-  and its G.4 RNG backend returns non-deterministic bytes live. v2.5.0 does not close on any
-  board's G.4/G.x item being build-only.
+  and its G.4 RNG backend returns non-deterministic bytes live. A milestone does not close on
+  any of its board's G.4/G.x items being build-only.
 
 #### G.6 [v2.0.1] Generic UEFI-bootable thumbdrive image (SER5 path — **BUILT + VERIFIED 2026-08-29**)