FABRIC-2.md Section U addendum: foreign-drive protection, zuse one-way

burn, console/VM key-match attachment -- still brainstorming, nothing
implemented

Three more requirements captured while fresh, same design session:
(7) home-blocks write path must check for a home-blocks signature
before ever writing to an inserted drive, warn and refuse on foreign/
unrecognized/blank media instead of silently claiming it; (8) zuse
credential minting is one-way, asymmetric with an operator drive's
presumed re-provisioning path; (9) console/VM split -- console is
generic and shared, drive insertion spins up a per-identity VM (a
Tripod-birth-mechanism consumer), and console-to-VM attachment is a
key/lock match, structurally similar to ACL-PIN's existing key model
but not yet confirmed to reuse it directly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

FABRIC-2.md

@@ -2611,3 +2611,45 @@ Natural next steps, none begun: (a) settle the hotwords-cache-reuse question fro
 open point, (b) decide on the identity→block-range derivation function (item 3), (c) scope
 the minimal USB xHCI + MSC bulk-only read/write driver as its own milestone, sized against
 virtio-blk's build-out for comparison.
+
+**Addendum, same session, three more requirements while fresh:**
+
+7. **Foreign-drive protection — a hard precondition on the write path, not yet in the design
+   above.** Before any home-blocks write path touches an inserted USB drive, it must check for
+   a signature confirming the drive is already a minted home-blocks drive (analogous to a
+   filesystem superblock magic number, consistent with this project's existing content-
+   addressed-everything approach — e.g. an XXHash64-verified header block, matching the
+   pattern capsules already use for identity). If the signature is absent, or the drive
+   carries a foreign filesystem (Windows, Linux, blank, anything unrecognized), the system
+   must warn and refuse to write rather than silently claiming/overwriting it. Section U's
+   original design (items 1-6 above) implicitly assumed every inserted drive was already a
+   minted home-blocks drive; this closes that gap.
+8. **Zuse minting is one-way — asymmetric with Captain Bob's drive.** Once a drive is burned
+   as the zuse superuser credential, it cannot be re-minted or overwritten, ever — a strictly
+   harder constraint than an operator drive (which presumably can be re-provisioned if lost or
+   replaced). The two physical thumb drives from the Phase 8 PKI context above are *not*
+   symmetric in how their write/re-mint paths should behave, even though both are "thumb
+   drives" in the general sense — the zuse path needs its own one-way-burn guard, distinct
+   from whatever re-provisioning path an ordinary operator drive gets.
+9. **Console/VM split — attach-by-key, not attach-by-identity-check.** The *console* (the
+   physical/session-level interface — what a person actually sits down at) is generic and
+   shared, with no identity bound to the console itself; anyone can attach to a console.
+   Plugging in a USB drive is what spins up a **VM** for that specific identity — a natural
+   consumer of the existing Tripod birth mechanism (Hera already births VM patrons; this would
+   be another trigger for that same mechanism, driven by drive insertion rather than a capsule
+   load). The console then must bind to *exactly one* VM — the one belonging to the identity
+   that just plugged in — via a key/lock match: the console presents a key, the VM (or its
+   home-blocks range) carries a matching lock, and the two only attach on a match. Captain
+   Bob's own framing: "receptors," a lock-and-key/DNA-matching model, structurally the same
+   shape as `ACL-PIN`'s existing key-based permission model, just applied to console→VM
+   binding instead of word-level execution permission — **open question, not yet settled:**
+   whether this literally reuses the `ACL-PIN`/`acl_allow` mechanism (extended to gate console
+   attachment the same way it gates word execution) or needs its own separate key-matching
+   primitive. Confirmed shape (Captain Bob, verbatim confirmation this session): "console
+   attaches to a user's VM... solves just its own VM, that's all it's gonna be" — one console,
+   one VM, exactly, for the duration of that binding. End-to-end flow as currently understood:
+   insert USB drive → drive's credential authenticates and spins up (or re-attaches to) that
+   identity's VM → console presents its key → key matches the VM's lock → console is now
+   attached to that VM and only that VM → "I have permission to use a [thumb drive as a
+   credential] tool. I'm gonna use a console. Simple as that" (Captain Bob, describing the
+   intended user experience end state).