From a67a7015bf1440c544f6226880eb685a7c193db3 Mon Sep 17 00:00:00 2001
From: Daniel Samson <12231216+daniel-samson@users.noreply.github.com>
Date: Sun, 9 Aug 2026 18:30:16 +0100
Subject: [PATCH] =?UTF-8?q?docs:=20record=20the=20V3c=20resequencing=20?=
 =?UTF-8?q?=E2=80=94=20removal=20lifecycle=20first,=20multi-volume=20follo?=
 =?UTF-8?q?ws?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 docs/volume-manager-plan.md | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/docs/volume-manager-plan.md b/docs/volume-manager-plan.md
index 92dd5e4..cd9d8d0 100644
--- a/docs/volume-manager-plan.md
+++ b/docs/volume-manager-plan.md
@@ -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)`