diff --git a/FABRIC-3.md b/FABRIC-3.md index 1f277c1..dcdfac1 100644 --- a/FABRIC-3.md +++ b/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)
SCOPED 2026-08-27 (§F.8) — GPT dropped, single-device confirmed OK"] PENTAGON["📍 Pentagon: Hera/Hermes/Artemis/
User-VM/Console, K5 (D.2b)"] MSGSHAPE["✅ Hermes message shape known
(MSG-CELLS, MSG-ALLOC/DELIVER)"] - MSGMIGRATE["❓ Message-bus migration of
attach/verify/bind (D.4)"] + MSGMIGRATE["❌ Message-bus migration of
attach/verify/bind (D.4) — SCOPED 2026-08-27 (§F.15)"] SSDSCOPE["❓ SSD identity-store scope
for regular users (D.4)"] ROUNDTRIP["❓ Session state round-trip
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. + +