FABRIC-3.md: scope MSGMIGRATE, capture Console-driven interactive mint onboarding vision

Traced the actual Hermes mechanism before scoping: MSG-DELIVER already executes arbitrary FORTH source text on the destination VM via VM-EXEC, not a structured RPC -- migrating an interaction needs no new dispatch machinery, only a routing decision. Noted that every "VM" lives in one kernel address space, not a separate process, so messaging WIREBIND/BINDSTEP/CERTVERIFY is an architectural-discipline choice (uniform heat/audit participation in Compudynamics via Hermes), not a correctness requirement.

Decisions: real target is the Console VM (already real hardware: serial+framebuffer+PS2, not waiting on D.2b), a two-hop flow (Hera->Console reports attach outcome, Console->Hera requests the privileged operation), payload arguments encoded as literals directly in the FORTH text.

Captured a substantial new vision detail surfaced live while scoping this (D.6): blank-media minting is meant to be an interactive Console-driven onboarding form (Full Name/Address/City/State/Country/Metadata), not a bare programmatic MINT call -- connects forward into RUNCAP's deferred "default personality content" question and MINT's own scope. Capture only, not designed in detail, per this arc's own capture-first discipline.

FABRIC-3.md

@@ -1377,7 +1377,12 @@ can't"):**
 - **Message-bus migration scope.** Which specific interactions (attach detection, cert
   verify, console bind) move to Hermes messages, and what do those message shapes look like?
   Entirely unscoped, explicitly deferred until after a hardwired version exists to migrate
-  *from*.
+  *from*. **SCOPED 2026-08-27 (`FABRIC-3.md` §F.15)**: `MSG-DELIVER` already executes arbitrary
+  FORTH text on the target VM (`VM-EXEC`), so no new dispatch mechanism is needed. Real target
+  is a genuine Console VM (already real: serial+framebuffer+PS2), two-hop flow (Hera→Console
+  reports attach; Console→Hera requests the privileged operation with literal arguments).
+  Surfaced a substantial new vision detail along the way: blank-media minting is a Console-
+  driven interactive onboarding form, not a bare word call (§D.6).
 - **Polymorphic block-boundary behavior for user VMs** — still just the one original sentence
   from 2026-08-25, never elaborated.
 - **SSD identity-store scope** — does the system-resident store (the block-fence built in
@@ -1464,7 +1469,7 @@ graph TD
     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)"]
+    MSGMIGRATE["❌ Message-bus migration of<br/>attach/verify/bind (D.4) — SCOPED 2026-08-27 (§F.15)"]
 
     SSDSCOPE["❓ SSD identity-store scope<br/>for regular users (D.4)"]
     ROUNDTRIP["❓ Session state round-trip<br/>across attaches (D.4)"]
@@ -1509,8 +1514,8 @@ graph TD
     classDef open fill:#666,stroke:#333,color:#fff
     classDef partial fill:#883,stroke:#333,color:#fff
     class M6,PH8,EXPIRE,MSGSHAPE,HOTPLUG,BMAPWRITE,BMAPREAD done
-    class W10,STALL,FIRSTTOUCH,WIREBIND,BINDSTEP,DETACH,MINT,BMAPFMT,CERTVERIFY,RUNCAP,UNCLEAN blocked
-    class ACLKEY,MSGMIGRATE,SSDSCOPE,ROUNDTRIP,POLYBLOCK open
+    class W10,STALL,FIRSTTOUCH,WIREBIND,BINDSTEP,DETACH,MINT,BMAPFMT,CERTVERIFY,RUNCAP,UNCLEAN,MSGMIGRATE blocked
+    class ACLKEY,SSDSCOPE,ROUNDTRIP,POLYBLOCK open
     class MIGSM partial
 ```
 
@@ -1583,6 +1588,11 @@ finished). Dashed arrows = softer "gates/informs" relationships.
   Unlike most nodes this session, this one designs genuinely new protocol machinery rather than
   finding existing infrastructure already covers it: no completion-code distinction and no
   recovery of any kind existed before this pass, only a bounded-timeout safety net.
+- **`MSGMIGRATE` needed no new mechanism, only a routing decision** (§F.15) — `MSG-DELIVER`
+  already executes arbitrary FORTH text on the target VM. Scoping it also surfaced a real,
+  substantial vision expansion (§D.6): blank-media minting is meant to be an interactive,
+  Console-driven onboarding form, connecting forward into both `RUNCAP`'s deferred
+  "default personality content" question and `MINT`'s own scope.
 
 **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
@@ -2275,3 +2285,97 @@ current iterative pass, recorded so they aren't lost):**
   mechanism, and the codebase/documentation are clean per the above audit, tag a v2.0.0
   release. Stated as the destination this whole planning arc is walking toward, not an
   immediate next step.
+
+### D.6 — Console-driven interactive mint onboarding (vision capture, 2026-08-27)
+
+Surfaced live while scoping `MSGMIGRATE`'s message-target question (§F.15) — capture only, per
+this arc's own "capture first, plan second" discipline; not designed in detail here.
+
+**Stated directly:** the Console VM (real hardware ownership: serial + framebuffer + PS2
+keyboard) is where blank-media minting actually happens interactively, not a bare programmatic
+`MINT` call. Zuse's own thumbdrive becoming physically present is itself what starts
+authentication (no separate manual step). For **blank** media specifically, the system pulls
+up an interactive "user StarshipOS (LithosAnanke+StarForth) Mint" onboarding form on the
+Console:
+
+```
+Full Name:
+Address 1:
+Address 2:
+City:
+State/Province:
+Country:
+Metadata: (hexdump of some encrypted metadata OR QR code later)
+```
+
+**Why this matters beyond `MSGMIGRATE` itself:** this directly informs two already-open
+questions elsewhere rather than sitting alone —
+- **`RUNCAP`'s deferred "default personality content" question (§F.6)**: this onboarding data
+  is very likely *part of* what a freshly minted identity's personality/init source encodes,
+  not a separate concern. Not confirmed as a final answer — flagged as the likely connection.
+- **`MINT`'s own scope (§F.8)**: minting a new identity now has a real interactive-collection
+  step in front of the cert/keypair/header-writing mechanics already scoped there. The Console
+  becomes an active participant in `MINT`, not just Zuse triggering it standalone.
+
+**Not designed here, explicitly deferred (per the user's own "later" on the metadata field):**
+the "hexdump of some encrypted metadata OR QR code" field's actual mechanism, encoding, and
+purpose; the exact validation/editing UX for the form itself (can a field be corrected before
+submit? what happens on a blank/skipped field?); how collected form data actually reaches
+`MINT`'s execution (addressed at the mechanism level only, in `MSGMIGRATE` below — the message
+carries the values, the *encoding* of the metadata field itself is separate and unaddressed).
+
+### F.15 — `MSGMIGRATE` (the last real design question)
+
+Traced the actual Hermes mechanism before designing anything, rather than treating "message"
+as an abstract placeholder. **Real finding: `MSG-DELIVER` (`capsules/hermes/init.4th:200-203`)
+does `MSG-TO@ IDX>NAME VM-EXEC`** — a message's out-of-line payload (`PADDR`/`PLEN`) is
+**arbitrary FORTH source text, executed on the destination VM via the ordinary interpreter**,
+not a structured/typed RPC call. Migrating an interaction to Hermes needs no new dispatch
+machinery at all — only a decision about what FORTH text goes where.
+
+Also worth being explicit about, since it reframes why this migration is even worth doing:
+every "VM" in this system is a Forth VM instance living inside **one kernel address space**,
+not a separate OS process. There is no correctness reason `WIREBIND`/`BINDSTEP`/`CERTVERIFY`
+*must* become messages — Hera's REPL can already call their C functions directly, today, once
+built. The stated reason to migrate anyway is architectural discipline: routing through Hermes
+gives uniform heat-tracking/`STADIUM-CELL` participation in Compudynamics and an audit trail
+via `MSG-SEQ`, matching the standing "nothing is done until it's messaging" completion
+criterion — not solving an isolation problem that doesn't exist here.
+
+**Decisions made 2026-08-27:**
+
+1. **Real target: the Console VM**, not a self-addressed message to Hera. There is a real
+   Console VM today (serial + framebuffer + PS2 keyboard) — this isn't waiting on D.2b's
+   pentagon to become real, it already is. Corrects this pass's own first framing (a
+   self-addressed-to-Hera fallback was floated and explicitly rejected in favor of this).
+2. **The flow is two hops, not one:**
+   - **Hop 1 (Hera → Console):** Hera's existing hardwired attach detection
+     (`homeblocks_sig_check()`, unchanged — this is Milestone 2 hardware-driver work, not
+     something that itself becomes a message; nothing exists to receive a message before
+     detection happens) results in a message to the Console VM reporting the outcome —
+     recognized identity, or blank/foreign media.
+   - **Console-side behavior (not itself a message):** for a recognized identity, the Console
+     proceeds toward the existing cert-verify/bind flow; for blank media, the Console runs the
+     interactive mint-onboarding form (§D.6) using its own owned hardware (framebuffer/PS2).
+   - **Hop 2 (Console → Hera):** once the Console has what it needs — either confirmation to
+     proceed with a recognized identity, or the completed onboarding fields for a new one — it
+     sends a message *back* to Hera to actually execute the privileged operation
+     (`MINT`/`WIREBIND`/`BINDSTEP`), since Hera owns the VM registry these operations mutate.
+3. **Payload shape: arguments encoded as literals directly in the payload text**, not a
+   dedicated no-argument word reading global state. E.g. the Console's hop-2 message to Hera
+   for a mint would look like a human-typed command line with the collected fields pushed as
+   string literals ahead of the word call (`S" Robert James" S" 123 Main St" ... MINT`) — more
+   flexible than a fixed no-argument word, at the cost of the Console needing to build that
+   text safely (not addressed here — see deferred list).
+
+**Not yet scoped (deferred within this node):** the exact literal-encoding/escaping mechanism
+for building a multi-field FORTH command string safely on the Console side (a real concern —
+untrusted-ish human-typed onboarding text landing in FORTH source text merits care, not
+assumed away); the precise message `TYPE` values for each of the three migrated interactions
+(this pass decided the mechanism and direction, not the constant catalog); whether
+`CERTVERIFY`'s own re-verify-live behavior (`BINDSTEP`, §F.9) changes shape once it's Console-
+mediated rather than a direct Hera-side check; how this reconciles with `PENTAGON`'s still-open
+"which of the 10 edges are real today" question (`D.4`) — this node answers it for exactly the
+Hera↔Console edge, not the other nine.
+
+