Link Tripod vision to Stadium foundation theory + capture the pentagon

No code changes -- continued design capture, per direct request to
link today's vision into the existing FABRIC.md/FABRIC-2.md material
("the existing pile of dirt") before planning.

Mined FABRIC.md's original Stadium theory (§17.1, §20, §24) and found
the EXPIRE-as-TTL correction wasn't just cleaner once "session=VM"
landed -- it was required from the start: the foundational
patron/departure table already says VMs depart via heat decay (COOL),
never TTL (TTL only ever governed messages/ACLs). §20's outer/inner
Stadium nesting already anticipated "attach = admit a VM" as a case,
so no new Stadium theory is needed, only a new admission trigger.
§24's identity-stability rules don't block session-state round-
tripping across separate attaches either way.

Mined FABRIC-2.md and found real grounding for two more decisions: the
acl_pinned one-way-ratchet was already identified as the right shape
for both Zuse's "burn" and console-session ownership, just never built
past word-execution gating -- and the real Hermes message shape
(MSG-CELLS, 9 fields, out-of-line payload, MSG-ALLOC/CH-ALLOC/
MSG-DELIVER) gives message-bus migration a concrete target instead of
an abstract goal. Confirmed empirically that today's xHCI hotplug
attach chain is 100% hardwired, zero messaging anywhere in it -- the
real baseline to migrate from.

Captured the pentagon topology: "just to get a user, 5 VMs are needed"
-- Hera, Hermes, Artemis, the user's own VM, and the Console, fully
interconnected (K5, a pentagon with every diagonal drawn). Flagged the
Console as a full peer node, not the passive relay D.3's flow
description implied -- reconciling that phrasing against the five-node
picture is new open work.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U14ET9CWAtbQMbYqomKgXd

FABRIC-3.md

@@ -1202,6 +1202,51 @@ timeout on a flag.
 When Hera has no VM attached beyond fleet-servicing strata, she idles, watching services and
 maintaining a serviced fleet foundation — her normal steady state, not a special case.
 
+**Validated against the original Stadium foundation, not just today's intuition (mined
+2026-08-27 from `FABRIC.md` §17.1/§20, the oldest, most foundational layer of this whole
+design — see D.2b below for the full mining pass).** `FABRIC.md` §17.1's own patron/departure
+table already says VMs depart via heat decay (`COOL`) and only messages/ACLs ever used TTL —
+meaning the `EXPIRE`-as-TTL-on-a-flag plan this session had started scoping didn't just become
+inconvenient once "session = VM" landed, **it contradicted the original design from the
+start**: a VM was never one of the two patron kinds TTL governs. §20's outer/inner Stadium
+nesting (VMs as outer-Stadium patrons; words/blocks/ACLs/messages as inner-per-VM patrons)
+already anticipated exactly "attach = admit a VM patron" as the outer-Stadium case — no new
+Stadium theory is needed for this, only a new *admission trigger* (thumbdrive attach) feeding
+the existing admit/evict machinery.
+
+### D.2b — The pentagon: five VMs, minimum, to service one attached user (2026-08-27)
+
+Stated directly: **"Just to get a user, 5 VMs are needed — if we draw every connection to
+every node they can make a pentagon."** The five: **Hera, Hermes, Artemis, the user's own VM,
+and the Console.** Drawing every pairwise connection among five nodes (a complete graph, K5)
+draws a pentagon with all its diagonals — visually a pentagram. Noted in passing, and worth
+keeping since this project's naming is already steeped in Greek mythology (Hera, Hermes,
+Artemis, Ananke/Lithos, Zuse for Zeus): a pentagram at the foundation of a "pagan" system fits
+the theme, not an accident to explain away.
+
+**The Console is a full peer node, not a passive terminal that merely "attaches to" a user
+VM** — D.3 step 4 undersells this; the Console is architecturally one of the five, with (at
+minimum) its own binding relationship to the user's VM and, per the messaging end-state,
+eventually its own message traffic to Hera/Hermes/Artemis too, not just a one-way relay.
+Reconciling D.3's "console attaches to the new user VM" phrasing against this five-node,
+fully-connected picture is real remaining work, not done here — captured as a gap in D.4.
+
+Why each of the five is load-bearing, best understanding as of this capture (not all edges
+independently confirmed — see D.4's gaps):
+- **Hera** — governs the fleet, births/kills the user VM (existing `capsule_birth_baby()`/
+  `capsule_vm_kill()` path), holds the outer-Stadium quota the new VM draws from.
+- **Hermes** — the messaging fabric itself; per the standing "nothing is done until it's
+  messaging" criterion, every other edge in this pentagon is ultimately meant to route through
+  Hermes, making Hermes both a node in the graph and (eventually) the medium connecting every
+  other edge — worth being explicit that this is a two-level relationship (Hermes as a peer VM
+  *and* as the substrate other peers communicate over), not a design tension to smooth over
+  by treating it as an ordinary fifth node.
+- **Artemis** — persistent block storage; the identity/system-metadata store (Phase 8's
+  block-fence) and, per D.3, wherever a user's own working data actually lives during a
+  session, live here.
+- **The user's own VM** — where the user plays (D.3 step 5).
+- **Console** — the human-facing binding point (D.3 step 4, Milestone 5).
+
 ### D.3 — The attach/mint flow, end to end
 
 1. **Idle loop watches for thumbdrive connects** (`sk_repl_idle()`, already the right hook —
@@ -1239,12 +1284,32 @@ maintaining a serviced fleet foundation — her normal steady state, not a speci
 
 **Answered (resolved during capture, not deferred):**
 - Milestone 5's "reuse `ACL-PIN` vs. build a new key-match primitive" question — reuse ACL.
-- `EXPIRE`'s framing — superseded by "session end = VM detach," see D.2.
+  **Now grounded, not just intuited** (mined 2026-08-27 from `FABRIC-2.md` §C/§D,
+  lines ~2884-2918): `acl_pinned`'s one-way-ratchet (`include/vm.h:346`, C-only mutation, no
+  FORTH clear path) was *already* identified as the right-shaped precedent for exactly two
+  things — Zuse's own one-way "burn" and console-session ownership — but in both cases only
+  the *pattern* was precedented, never actually built past word-execution gating. The
+  "still genuinely open" framing in `FABRIC-2.md` is accurate as of that writing; today's
+  decision closes it, the comparison *semantics* remain the real gap (below).
+- `EXPIRE`'s framing — superseded by "session end = VM detach," see D.2. **Now shown to be
+  required, not just cleaner**, by `FABRIC.md` §17.1's own patron/departure table (see D.2's
+  addendum above) — TTL was never a valid mechanism for a VM patron in the first place.
 - Regular-user cert chain-of-trust mechanism — signed by Zuse's own key, verified with
   already-built, already-proven Ed25519/X.509 primitives (Milestone 6). No new crypto work
   needed, only a new verification *call site* using existing functions.
 - Whether the system needs a central user directory — no, by design; each thumbdrive is
   self-contained (reinforces D.3 point 2, was implicit, now explicit).
+- **The concrete target shape for message-bus migration** (mined 2026-08-27 from
+  `FABRIC-2.md`, cross-checked against live `capsules/hermes/init.4th`): a message is
+  `MSG-CELLS` = 9 cells (`TYPE, FROM, TO, PADDR, PLEN, STADIUM-CELL, SEQ, CH, ORIG-TYPE`), 72
+  bytes, payload **out-of-line** (a pointer+length to caller-owned bytes — there was never a
+  fixed inline payload field, an earlier open question in `FABRIC-2.md` §23.4 that its own
+  design already closed as moot). Live API: `MSG-ALLOC ( heat -- addr|0 )`,
+  `CH-ALLOC ( heat -- addr|0 )`, `MSG-DELIVER ( m -- )`, `MSG-DELIVER-ALL ( -- )`. A future
+  "thumbdrive attach event" or "cert verify request" message type follows this exact shape —
+  allocate, fill `TYPE`/`FROM`/`TO`/`CH`, point `PADDR`/`PLEN` at an out-of-line event struct,
+  send. Not built, but no longer an abstract "use messaging someday" — there's a real API to
+  target.
 
 **Real, unanswered gaps — deferred on purpose (per "answer what we can, defer what we
 can't"):**
@@ -1267,7 +1332,25 @@ can't"):**
   latter, but not stated explicitly enough to treat as settled.
 - **Does a user's VM/session state round-trip across multiple attaches** (unplug, come back
   later, resume exactly where you left off), given detach explicitly copies state back to the
-  drive? Implied yes by the detach description, not confirmed directly.
+  drive? Implied yes by the detach description, not confirmed directly. **Checked against
+  `FABRIC.md` §24's mutation/identity-stability rules (mined 2026-08-27) — no conflict either
+  way**: identity is only pinned stable *within one residency*, so a thumbdrive re-attaching
+  later and being admitted as a fresh VM patron (possibly reusing an identity value derived
+  from its cert/pubkey) is simply a new residency each time. Nothing in the foundational
+  theory blocks or answers round-tripping; it stays a pure implementation decision.
+- **Reconcile D.2b's five-node, fully-connected pentagon against D.3 step 4's "console
+  attaches to the user VM" phrasing.** The Console is a full peer node (Hera/Hermes/Artemis/
+  User-VM/Console, K5), not just a passive relay that binds to one other node — D.3's
+  wording undersells this. Which of the ten pentagon edges are real *today* versus aspirational
+  once messaging lands is not worked out; only Hera↔UserVM (birth/kill) and
+  UserVM↔Artemis-via-Hera's-quota (existing Stadium quota mechanics) are clearly already
+  real in some form.
+- **Confirmed baseline before any message-bus migration can start** (mined 2026-08-27,
+  `FABRIC-2.md` cross-checked against live `src/starkernel/repl.c` and the xHCI/USB driver):
+  today's hotplug→MSC-attach→`homeblocks_sig_check()`→`blk_subsys_attach_device()` chain is
+  **100% hardwired, direct C calls, zero messaging at any point** — confirmed empirically, not
+  assumed. This is the exact, real starting point "hardwire now, message later" describes;
+  there is no partial messaging implementation anywhere in this path to build on yet.
 - **The single biggest hard blocker underneath all of it: SCSI `WRITE(10)` still doesn't
   exist** (`blkio_usb.c` is read-only — Milestone 2's biggest open item, unchanged). Minting
   a blank thumb, and flushing state back on detach, both need real writes to physical USB