docs: record the V3c resequencing — removal lifecycle first, multi-volume follows

2026-08-09 18:30:16 +01:00
parent 301bdcaf5b
commit a67a7015bf
1 changed files with 9 additions and 0 deletions
@@ -79,6 +79,15 @@ fat sheds `acquireVolume` and its device-manager grant; filesystem binaries
 get `open volume-manager` only — a filesystem cannot acquire, only be given.
 Grants move with the code in the same commits.

+**Sequencing (as executed).** V3a (discovery+probe) and V3b (the flip: spawn +
+confine + hand over the channel, single volume) landed the core. The V3c items —
+the `volumes.csv` mount map, the fuller identity ladder (FAT serial, GPT GUID),
+and multi-volume spawning — mainly serve the MULTI-volume drills (two-partitions,
+clone-policy). The user's goal is the single-volume boot-stick removal lifecycle,
+so V4's removal lifecycle runs next on the single volume, and the multi-volume
+work + its drills become a documented follow-on (V3c/multi-volume). fat keeps its
+hardcoded mount prefixes until the mount map lands.
+
 ## V4 — the removal lifecycle, end to end

 Two triggers, one path: storage-channel death and `medium_changed(absent)`