Capture full Tripod/Zuse identity vision (§D), supersede EXPIRE-as-TTL plan

No code changes -- pure design capture, per direct request ("capture
EVERYTHING first then we'll build a plan").

Core correction: a session IS a VM (Zuse is a player in the Stadium
fabric like any other, not a special boolean flag on Hera). This
supersedes an in-progress plan this session to implement EXPIRE as a
Stadium-TTL sweep on the zuse_session boolean -- caught mid-research,
before any code was written. Session end = VM detach, much closer to
the existing COOL/capsule_vm_kill() path than a new TTL mechanism.

Captured the full attach/mint flow: idle-loop thumbdrive watch,
cert-only auth (no password/username, no central user directory),
runtime capsule construction from drive content, ACL-based console/VM
binding (resolves Milestone 5's "reuse ACL-PIN vs. new primitive"
question in favor of reuse), ongoing MINT, and deferred detach/flush-
back. Standing completion criterion: nothing here is done until
hardwired calls are replaced by real Hermes messages.

Sorted the resulting gaps into answered (chain-of-trust mechanism,
ACL-reuse decision, no-central-directory) vs. genuinely deferred
(runtime capsule construction, exact ACL comparison semantics,
message-bus migration scope, polymorphic block-boundary behavior,
SSD-store scope, session state round-tripping, and the underlying
WRITE(10) hard blocker). Also flagged a small unrelated bug: the
prompt should read (Zuse)ok>, not zuse)ok>.

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

FABRIC-3.md

@@ -1144,43 +1144,146 @@ not built on top of or left in place.
 
 ---
 
-## D. Tripod final shape — minting, one-time Zuse fuse, messaging-only (vision, not yet scoped)
+## D. Tripod final shape — minting, one-time Zuse fuse, messaging-only (vision, substantially expanded 2026-08-27)
 
 Stated directly by Captain Bob, 2026-08-25: "we're going to have to iterate because I know
-what the final shape of the tripod will be." Recorded here as a forward-looking vision, not
-yet broken into implementable items — captured so near-term Stadium/VM work (§B above) is
-made against the right end-state rather than in ignorance of it. Full detail also saved as
-memory `project_tripod_final_shape_vision.md`.
+what the final shape of the tripod will be." Originally captured as a forward-looking vision,
+not yet broken into implementable items. **2026-08-27: expanded into a much fuller picture**
+after Phase 8/Milestone 6 closed and unblocked this design pass — captured here in full before
+any of it gets scoped into implementable items, per direct request ("capture EVERYTHING first
+then we'll build a plan"). Full detail also in memory `project_tripod_final_shape_vision.md`.
+
+### D.1 — Original vision (2026-08-25), still accurate
 
 - **Thumbdrive presentation → legality check → mint.** A newly presented thumbdrive is
-  checked for legality (against the CA-root-derived identity/certificate scheme already
-  decided earlier this session, `FABRIC-2.md`). If not legal, it is "minted" — formatted for
-  system use — which (1) spins a new user VM and (2) attaches the console VM to it.
+  checked for legality (against the CA-root-derived identity/certificate scheme). If not
+  legal, it is "minted" — formatted for system use — which (1) spins a new user VM and (2)
+  attaches the console VM to it.
 - **One-time Zuse mint + fuse-blow on first install.** A brand-new system instance
   ("Install"/"Try It") mints exactly one Zuse superuser, then irreversibly "blows a fuse":
   direct quote, "we mint one and only one Zuse user and blow a fuse. The only way around is a
   new system." Post-fuse, no further Zuse can ever be minted on that instance — but the
   system is NOT bricked: the existing Zuse superuser keeps working, and ordinary users can
-  still "thumb in" via regular thumbdrives.
+  still "thumb in" via regular thumbdrives. **This half is now actually built** — Phase 8's
+  entropy→signing→block-fence persistence work (2026-08-26, `project_phase8_milestone6_complete.md`)
+  implements exactly this, minus the physical thumbdrive itself (see D.4, WRITE(10) gap).
 - **Messaging-only once Tripod is fully live.** All inter-VM interaction becomes Hermes
   messaging, not direct calls/shared state — a stated end-state, not the current
-  implementation.
-- **Polymorphic block-boundary behavior for user VMs.** Stated in one sentence, not yet
-  elaborated: a user VM needs to behave polymorphically when crossing block boundaries.
-  Needs a dedicated follow-up conversation before this is actionable.
-- **`ClaudeEXPORT/`** (repo root, new as of 2026-08-25) — a prior Claude data export the user
-  pointed at for "concepts and thoughts as guidelines" on this vision, explicitly flagged as
-  possibly containing superseded/conflicting ideas, not authoritative. `conversations.json` is
-  ~66MB; mine selectively (grep or a subagent) rather than reading wholesale. See memory
-  `project_claude_export_archive.md`.
+  implementation. **Reaffirmed and sharpened 2026-08-27: hardwired/direct-call
+  implementations are acceptable *during development only* — no piece of this design is
+  considered actually finished until its hardwired calls are replaced with real Hermes
+  messages.** This is a standing completion criterion for everything in this section, not a
+  separate future milestone.
+- **Polymorphic block-boundary behavior for user VMs.** Still just one sentence, still not
+  elaborated — genuinely unresolved since 2026-08-25, needs its own follow-up conversation.
+- **`ClaudeEXPORT/`** — a prior Claude data export, "concepts and thoughts as guidelines,"
+  explicitly flagged as possibly containing superseded/conflicting ideas, not authoritative.
+  See memory `project_claude_export_archive.md`.
+
+### D.2 — The session model (2026-08-27): a session IS a VM
+
+Direct correction to how this document and the earlier `EXPIRE` framing (§B) had been
+thinking about "sessions": **a session is any VM client running in the Stadium fabric — Zuse
+is no different from any other VM.** The Stadium/FABRIC metaphor restated by Captain Bob:
+the fabric floats inside the Stadium; VMs actually doing work are "players on the field"
+(system perturbances); user interaction is "fans in the stands" providing patron-driven noise.
+Zuse is a player like any other, not a special boolean flag on Hera.
+
+**This directly invalidates the `EXPIRE`-as-TTL-on-`zuse_session`-boolean plan this session
+had started scoping (§B's `EXPIRE` decision, and the implementation research begun
+2026-08-27 before this correction landed).** Today's `zuse_session` field on the VM struct is
+not what a "session" actually is in this model — a session ending is a **VM detaching**, far
+closer to the existing, real, working `COOL`/`capsule_vm_kill()` path than to a new
+Stadium-behaviour-tag TTL sweep. **`EXPIRE` as originally scoped is superseded, not merely
+deferred** — when Stadium/ACL session-lifetime work is picked up again, it should be framed
+as "what happens when a user-VM's owning thumbdrive detaches," reusing `COOL`, not as a
+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.
+
+### D.3 — The attach/mint flow, end to end
+
+1. **Idle loop watches for thumbdrive connects** (`sk_repl_idle()`, already the right hook —
+   confirmed 2026-08-27 during the (superseded) `EXPIRE` research: ~1s cadence, already used
+   for `xhci_poll_events()`/MSC attach).
+2. **Cert-only authentication — no password, no username.** A presented thumbdrive's identity
+   is *entirely* the cert on it. Verification means checking the cert's fields directly (chain
+   of trust, most likely signed by *Zuse's own key* — the same `x509_ed25519.c`/
+   `ed25519_verify()` primitives Milestone 6 already built and proved work end to end, just
+   verifying against Zuse's pubkey instead of the snakeoil intermediate's). **The system has
+   no requirement to maintain any single identity itself** — no user directory, no central
+   registry of who exists. Each thumbdrive is a fully self-contained, portable identity
+   record.
+3. **A dedicated user VM is born** from the identity's own data — "the users/agents/services
+   metadata can reside in their capsule and [get] encoded directly into their dictionary when
+   they attach and their init.4th executes." This is a *runtime*-constructed capsule from
+   drive content, not a build-time-embedded one like `pki:snakeoil-intermediate.der` — a
+   materially different mechanism from anything `mkcapsule` does today (gap, see D.4).
+4. **The console VM attaches to the new user VM** — this is exactly Milestone 5's still-open
+   "Console/VM key-match binding" item, now with its open question *resolved*: "the bumps on
+   a thumbdrive have to fit the holes on the VM... (ACL territory)" — **reuse the existing
+   ACL primitive (`acl_mode`/`acl_allow`/`acl_pinned`) for the key-match check, don't build a
+   separate mechanism.** Exact comparison semantics still undesigned (see D.4).
+5. **The user plays entirely inside their own VM** — all their FORTH activity happens in
+   their own isolated VM context, never Hera's or anyone else's.
+6. **Ongoing minting**: while Zuse is attached/active, a second blank thumb presented can be
+   minted with a new named identity (worked example given: `S" CaptBob" MINT`-shaped flow)
+   and ejected — this is the still-open `MINT` word from Phase 8's own punch list, now with a
+   concrete attach-flow context to design it against.
+7. **Detach**: working state is copied back to the user's own thumb and flushed before eject.
+   **Explicitly deferred — stated directly as "going to be a maintenance operation later,"
+   not needed now.**
+
+### D.4 — Gaps identified 2026-08-27, sorted by whether they're answered
+
+**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.
+- 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).
+
+**Real, unanswered gaps — deferred on purpose (per "answer what we can, defer what we
+can't"):**
+- **How does thumbdrive content actually become a capsule at runtime?** `mkcapsule` only
+  ever builds capsules at build time, baked into `capsule_generated.c` — nothing today
+  constructs a capsule from data read off a live-attached device. This is new mechanism, not
+  a variation on anything that exists.
+- **Exact ACL "bumps and holes" comparison semantics.** Which specific ACL fields, compared
+  how, constitute a console-to-VM match? Direction is settled (reuse ACL), the actual
+  comparison logic is not designed.
+- **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*.
+- **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
+  Phase 8) ever hold anything about *regular* users, or is it purely Zuse/system bookkeeping
+  with regular users staying purely thumbdrive-resident? Best read of what was said: the
+  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.
+- **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
+  media. None of D.3's flow can run on real hardware until this lands; QEMU testing would need
+  to proxy through a writable virtio-blk stand-in the same way Phase 8's cert persistence did
+  for Zuse's own identity.
+
+**Small, unrelated, real bug found along the way:** the prompt shows `zuse)ok>` (a stray
+trailing paren, "never corrected typo") — should be `(Zuse)ok>`, both parens around the
+identity name, generalizing to any attached identity (e.g. `(CaptBob)ok>`). Independent of
+everything else in this section; safe to fix any time.
 
 **Why this affects §B:** VM-`COOL` (and any inter-VM Stadium wiring) sits close to this
-still-iterating design. Building it now risks conflicting with or being thrown away by the
-Zuse/messaging shape once that gets its own pass — hence §B's punch list defers VM-`COOL`
-explicitly rather than resolving it in this pass. Block-patron `MIGRATE` work does not
-obviously depend on this vision and is not deferred for this reason.
+design — see D.2's `EXPIRE` supersession above, the concrete example of exactly this risk
+materializing.
 
-**Next step:** no implementation here yet. When this gets its own design pass, start by
-clarifying "polymorphic block-boundary behavior" and the exact legality-check mechanism
-(presumably the CA-root certificate scheme), then scope minting as its own capsule-birth-style
-protocol (mirroring the existing capsule birth writeup's rigor) before writing any code.
+**Next step:** no implementation yet — this section is capture only, per direct request. Next
+session should turn D.3/D.4 into an actual scoped, ordered plan (the user's own framing:
+"identify gaps, answer what we can, defer what we can't... push the pile out in front of us").