diff --git a/FABRIC-3.md b/FABRIC-3.md
index b4f7c7b..ef8152f 100644
--- a/FABRIC-3.md
+++ b/FABRIC-3.md
@@ -1431,7 +1431,7 @@ graph TD
 
     EXPIRE["✅ EXPIRE reframed: session end<br/>= VM detach via COOL (§B + D.2)"]
     RUNCAP["❌ Runtime capsule construction<br/>from thumbdrive content — SCOPED 2026-08-27 (§F.6)"]
-    MINT["❌ Ongoing MINT word (Phase 8 + D.3)"]
+    MINT["❌ Ongoing MINT word (Phase 8 + D.3)<br/>SCOPED 2026-08-27 (§F.8) — GPT dropped, single-device confirmed OK"]
     PENTAGON["📍 Pentagon: Hera/Hermes/Artemis/<br/>User-VM/Console, K5 (D.2b)"]
     MSGSHAPE["✅ Hermes message shape known<br/>(MSG-CELLS, MSG-ALLOC/DELIVER)"]
     MSGMIGRATE["❓ Message-bus migration of<br/>attach/verify/bind (D.4)"]
@@ -1514,6 +1514,11 @@ finished). Dashed arrows = softer "gates/informs" relationships.
   on-device key while capsules are signed by the offline root CA's snakeoil intermediate.
   Neither chain validates the other; a future audit pass should keep this distinction explicit
   rather than let "PKI" get treated as one undifferentiated mechanism.
+- **`MINT` closed out the GPT question for the whole arc, not just itself** (§F.8) — GPT was
+  never actually load-bearing anywhere in this design; every node that referenced it
+  (`CERTVERIFY`, `WIREBIND`, `RUNCAP`, `HOTPLUG`) was already treating raw devblock-0 as the
+  working format. Dropping GPT converts all of those from "interim, revisit later" to simply
+  "the design," retroactively.
 
 **Not yet done:** an ordered plan (which node to attack first, given the graph). Per Captain
 Bob's own framing, that's the next pass — "start asking and answering questions iteratively
@@ -1757,7 +1762,10 @@ Two things, read directly from the code, changed the shape of this node:
 the metadata partition, how `identity_src_devblocks` bounds a variable-length FORTH source);
 whether the source is plain FORTH text authored once at mint time or something a user can edit
 and have re-read on next attach; the interaction with `CERTVERIFY` (does verification gate
-reading this content, or only gate the resulting birth).
+reading this content, or only gate the resulting birth). **Partially settled by `MINT`'s own
+scoping pass (§F.8, decision 2):** this region's first devblock holds a new
+`user_identity_seed_t` record, and the FORTH source itself occupies the remaining devblocks —
+narrows "the exact read path" question above, though the read-side code is still unwritten.
 
 ### F.7 — `CERTVERIFY` (Zuse-signed user-cert verification)
 
@@ -1806,6 +1814,68 @@ function's design (this pass decided *what* it must extract, not its implementat
 shares this exact cert format on the signing side) constructs the DER bytes in the first place
 — DER *encoding* has never been needed in this kernel before, only decoding.
 
+### F.8 — `MINT` (the last piece of the original Tripod vision)
+
+Two real dependencies surfaced while scoping this node that weren't in the §E graph, both
+resolved before any design decision was needed:
+
+1. **GPT.** The earlier-decided drive layout (`project_usb_thumbdrive_gpt_layout`:
+   ~1GB GPT metadata partition + remainder) has no parser or writer anywhere in kernel code.
+   **Dropped entirely, per direct instruction (2026-08-27) — not deferred, decided against.**
+   The raw `homeblocks_sig_t`-at-devblock-0 layout every other node in this arc (`CERTVERIFY`,
+   `WIREBIND`, `RUNCAP`, `HOTPLUG`'s own `sig_start_fblock=0`) already treats as an interim
+   stand-in is now the **permanent** format. The "small metadata region + remainder is user
+   storage" *proportion* from the old GPT design still holds — it's just a plain devblock-count
+   convention within one raw device now (metadata = devblocks `0..N` covering the sig header +
+   cert + identity-source regions; everything past that is the user's own general block-storage
+   pool directly, consistent with `FIRSTTOUCH`'s pool clarification in §F.6). No GPT-parser
+   node needed in the graph at all — this closes that thread rather than deferring it.
+2. **Single-device USB driver.** `xhci_dev_t`'s BOT/MSC state (`device_ctx`, `bulk_in_ring`,
+   `bulk_out_ring`, `bot_data_buf`) are singular fields, not per-slot arrays — only one USB MSC
+   device is usable at a time today. This looked like it might conflict with the vision's
+   "while Zuse is active, mint a second blank thumb" (implying two drives attached at once).
+   **Confirmed no conflict**: Zuse's own identity is system-resident, loaded from Artemis's own
+   top-of-device block-fence at boot (`kernel_main.c:634-687`), never from a removable thumb.
+   `MINT` only ever needs the one target blank drive attached — today's single-device path is
+   sufficient, no driver work needed for this node.
+
+**Decisions made 2026-08-27:**
+
+1. **The minted identity gets a real keypair**, not just a pubkey badge. `virtio_rng` +
+   `ed25519_keygen()` generate a fresh seed/pubkey pair for the new identity, stored on *their*
+   thumbdrive (never system-resident — matches `SSDSCOPE`'s "regular users stay
+   thumbdrive-resident" read). Keeps the door open for a user VM to sign something itself
+   later, per `D.5`'s "identity is common to every VM" direction, without redesigning the cert
+   format again.
+2. **Storage layout** (direct extension of `RUNCAP`'s already-decided `identity_src_offset`/
+   `identity_src_devblocks` region, §F.6 — no further header growth needed): that region's
+   *first* devblock holds a new `user_identity_seed_t` record (`magic`/`version`/`seed[32]`/
+   `pubkey[32]`/`crc` — same shape as `zuse_cert_devblock_t`, a new type rather than reusing
+   that Zuse-specific one, per this project's own "dedicated header per real-shaped feature"
+   convention); the *remaining* devblocks in that region hold the raw FORTH personality/init
+   source `RUNCAP` reads at birth.
+3. **`drive_uuid`**: a fresh, independent 16 random bytes from `virtio_rng` at mint time (not
+   derived from the identity seed — two separate random draws, matching `homeblocks_sig_t`'s
+   own field being logically "which physical drive," not "whose identity").
+4. **Cert construction**: builds the exact `CERTVERIFY` (§F.7) format — `SubjectPublicKeyInfo`
+   = the new pubkey, `serialNumber` = `drive_uuid`, signed with **Zuse's own seed** via
+   `ed25519_sign()` (real signing capability already exists, Phase 8). This is the first
+   confirmed caller that needs DER *encoding*, not just the decoding `x509_ed25519.c` already
+   has — flagged in `F.7` already, restated here since `MINT` is where it's actually needed.
+5. **Header assembly**: `hdr_crc` via the existing `homeblocks_sig_compute_crc()` — no new
+   checksum logic, this function already does exactly what's needed.
+
+**Not yet scoped (deferred within this node):** the default personality/init FORTH content a
+freshly minted identity starts with (shared open question with `RUNCAP`, §F.6: mint-time-fixed
+vs. user-editable); a monotonic-ns source for `minted_time_ns` — checked, and there is no
+working precedent anywhere in this codebase today (`CapsuleDesc.created_ns` is hardcoded to `0`
+at generation time, not a real example to follow); the `S" name" MINT` FORTH word's own
+stack/argument shape; whether `MINT` refuses to overwrite a drive that already reads as a
+recognized home-blocks drive (`HOMEBLOCKS_SIG_OK`), mirroring `WRITE(10)`'s
+refuse-on-non-blank-media posture — reasonable by analogy, not decided here. The hard blocker
+is unchanged and already modeled in the graph: `WRITE(10)` still doesn't exist, so `MINT`
+cannot write anything to real or QEMU-emulated USB media yet regardless of the above.
+
 ### D.5 — Scope expansion (2026-08-27): identity is common to every VM, not just users
 
 Surfaced while scoping `ACLKEY`, stated directly: *"the whole object is to deliver a