docs(v4.0.0): step 6a withdrawn -- drives that come and go are built as v3 has them

Captain Bob, 2026-10-07.  Rulings 6 and 8 of MESH.md 8.1 (a device
identity in the block header, a returning device's old numbers, release
by moving its blocks off, holes) were given without v3's design having
been shown.  MESH.md 8.7 sets v3's design beside them: a removable drive
is a person's, known by its signature; WIREBIND; it joins at the tail and
only the tail leaves; EJECT flushes to the drive and kills the user's VM.

ENGINE.md steps 7 and 8 now say that is where it is built.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/v4.0.0/ENGINE.md

@@ -409,7 +409,14 @@ its logs.
 6. **Hera as v3 has her.** `init.4th` runs on the node; v3's whole POST
    passes; v3's parity lines.
 7. **The fleet.** Hestia and Artemis; message delivery; who runs next.
+   With Artemis: she is the owner of the disk, who says it may be
+   formatted, so that the disk is written as well as read (`MESH.md` step
+   6); and a drive that arrives is registered by her, at the chain's tail.
 8. **Identity and the prompt.** Zuse; `[zuse@Hera] ok>`.
+   With identity: drives that come and go, as v3 has them — the
+   home-blocks signature, `WIREBIND`, the user's VM born from the drive,
+   `EJECT`, and a surprise pull (`MESH.md` 8.7, which says why the storage
+   step that was to build them another way was withdrawn).
 
 Moving words from the assembled nucleus to `forth79.4th` goes on beside
 these, a group at a time, with POST after each.

docs/v4.0.0/MESH.md

@@ -298,20 +298,14 @@ in 8.6, so that it is not proposed again.
    It is v3's (`v3/include/block_subsystem.h`): the `STFR` version 2 header,
    the allocation map, the relocation table, and a card for every block
    (`blk_meta_t`). A disk v3 formatted reads in v4.
-6. **Plus an identity.** *(step 6a)* Two fields are added in the header's
+6. ~~Plus an identity: a device's and its chain's, in the header's spare
-   spare space, as v3 added its relocation and fence fields: the device's
+   space.~~ **Withdrawn 2026-10-07**, 8.7.
-   identity, and the identity of the chain it belongs to. A v3 disk reads
-   zero there: not yet given one. With them a device is known when it
-   returns, wherever it is plugged in.
 7. **The mapper is the kernel's**: the device chain, the metadata,
    first-touch claim, ACL, migration and the Stadium touch stay in the
    kernel's block subsystem, which is v3's C code.
-8. **A device leaves by being asked for.** *(step 6a)* Asked to release a
+8. ~~A device leaves by being asked for, its blocks moved onto the
-   device, the mapper moves its blocks onto the devices that remain and
+   others; one pulled without asking leaves holes; a returning device has
-   then says it may be pulled; if there is no room, the release is refused
+   its old numbers.~~ **Withdrawn 2026-10-07**, 8.7.
-   with a message. A device pulled without asking leaves holes: its
-   logical numbers stay claimed and answer "no storage" until it returns,
-   is known by its identity, and its blocks are at the same numbers again.
 
 ### 8.2 What a node does *(step 6)*
 
@@ -395,8 +389,9 @@ block number not to exist, and on the real chain it does.
   card's ACL and the Stadium touch need the node's identity
   (`V3-PARITY.md` 1d). Blocks are read and written through v3's subsystem
   with nobody's claim on them. Not as intended yet.
-- **Chains of more than one device, identities, release and holes** are
+- **Drives that come and go.** Step 6a, which was to build them, is
-  step 6a.
+  withdrawn (8.7). They are built as v3 has them, when v4 has identity
+  and the fleet (`ENGINE.md` steps 7 and 8).
 - **Cloud stores and real USB drives** wait for their drivers.
 
 ### 8.5 Ruled 2026-10-07, after the review of step 6
@@ -414,6 +409,46 @@ overwrite the node's code**, and **v3's way in full** — the block words
 are the kernel's, by number only, with the kernel keeping the record of
 the window and doing the copying. Both are built: 8.2 and 8.3.
 
+### 8.7 Step 6a withdrawn 2026-10-07: drives that come and go
+
+Rulings 6 and 8 of 8.1 were given on 2026-10-06 in answer to questions put
+without first saying how v3 does it. On 2026-10-07, shown v3's design,
+Captain Bob withdrew step 6a as written. None of the four things it was to
+build is v3's:
+
+| Ruled 2026-10-06 | v3 |
+|---|---|
+| A device identity and a chain identity in the block header | Identity is the signature and the keypair on the drive; the header has none |
+| A returning device has its old block numbers | It joins at the tail again; its numbers depend on what else is attached |
+| Release by asking: the mapper moves the device's blocks onto the others | `EJECT` flushes to the drive itself and kills the user's VM; nothing is moved off it |
+| A surprise pull leaves holes that answer "no storage" | Only the tail can go; the user's VM is killed; there are no holes |
+
+**v3, as built** (`kernel/src/repl.c`, `v3/src/block_subsystem.c`,
+`v3/src/word_source/block_words.c`; `FABRIC-2.md` Phase 8, D.3 and F.10):
+
+- A removable drive is a person's. It carries an identity, the home-blocks
+  signature and a keypair Zuse mints onto it. Plugged in, its signature is
+  checked and the user's VM is born from the drive (`WIREBIND`); the
+  user's blocks are on their own drive.
+- The kernel polls USB; Hera asks Artemis to register the drive
+  (`HERA-BLK-ATTACH-REQ`), and Artemis adds it to the chain.
+- A drive joins at the tail, and only the tail can leave
+  (`blk_subsys_detach_device`): taking one out of the middle would
+  renumber every device after it.
+- Leaving by asking is `EJECT`, a word of Hera's alone: the user's blocks
+  are flushed to their drive and the user's VM is killed.
+- A surprise pull kills the user's VM with no flush, and the kernel drops
+  the device and whatever was not written.
+- Coming back, the drive is known by its signature and the user's VM is
+  born again; the data is there because it never left the drive.
+- Every VM's block window is emptied when the chain changes. (v4 has this
+  already: `v4/system/blocks.c`.)
+
+v4 has none of what that rests on yet: Zuse and identities, `WIREBIND`,
+user VMs born from a drive, Artemis, USB in the v4 boot. They are
+`ENGINE.md` steps 7 and 8, and drives that come and go are built there,
+as v3 has them.
+
 ### 8.6 Withdrawn 2026-10-07
 
 Each of these was ruled on 2026-10-06 or stood in this document, and each
@@ -699,11 +734,11 @@ Each is tested, committed and pushed before the next.
      from `kmalloc` and is not cleared (`kernel_main.c`, where the chain is
      set up); only the ramdrive is. The v4 path clears its own.
 
-   **6a. Storage that changes while running.** Rulings 6 and 8 of
+   **6a. Storage that changes while running.** **Withdrawn 2026-10-07**
-   section 8.1: chains of several devices, the device and chain
+   (section 8.7): what it was to build is not how v3 does it. Drives that
-   identities, a device joining at the end and known when it returns,
+   come and go are built as v3 has them, with identity and the fleet
-   release by asking, holes. Its acceptance is to be approved before it is
+   (`ENGINE.md` steps 7 and 8).
-   built.
+
    **6b. POST is the kernel's.** Ruled 2026-10-07 (section 9); design
    approved 2026-10-07, `NUCLEUS.md` 6.3 and section 7.
    **Done 2026-10-07.**