FABRIC-3.md: block-patron admission investigation + Tripod final-shape vision

Investigated whether stadium_admit()'s mass==1 refusal blocks block-patron
Stadium admission -- it doesn't: stadium_word_dispatch()'s real candidate
construction confirms Stadium cells carry identity/heat/bookkeeping only,
never the resident's actual content, so a block patron (identity=LBN,
payload unused) fits the same pattern words already use. The real gap is
just that no LBN->cell_index residency map or touch-on-access hook exists
yet -- real, scoped, buildable work, not a blocker.

Deferred VM-COOL pending the Tripod final-shape vision Captain Bob laid
out (thumbdrive minting, one-time Zuse fuse-blow, messaging-only inter-VM
interaction, polymorphic block-boundary behavior) -- recorded in a new
§D so near-term Stadium work doesn't ignore it, without treating a
one-sentence vision as a ready-to-implement spec.

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

FABRIC-3.md

@@ -283,16 +283,35 @@ other three become honest, explicit punch-list items instead of being touched sp
 
 **Punch list:**
 
+- [x] **Investigated (2026-08-25): block-patron admission does not exist yet, but is
+  architecturally straightforward, not blocked.** Confirmed via `stadium_admit()`'s own doc
+  (`stadium.h`) that it REFUSES any candidate with `mass != 1`, and that a `mass > 1`
+  multi-cell patron would need a continuation chain nothing has ever designed — this looked
+  at first like a hard blocker for a 1024-byte block. It isn't: confirmed via
+  `stadium_word_dispatch()`'s real candidate construction (`stadium_words.c:245-252`) that
+  Stadium cells carry pure identity/heat/bookkeeping only — `candidate.identity = word_id`,
+  `payload[32]` unused — the actual word content stays in the dictionary; Stadium never holds
+  it. By the same pattern, a block patron's cell would carry `identity = LBN`, `mass = 1`,
+  `payload` unused — the actual 1024 bytes of block content stays exactly where it already
+  lives (block cache / disk via `block_subsystem.c`), unmoved. So `mass != 1` is a non-issue;
+  the real gap is just that nothing has ever built the LBN→cell_index residency map (the
+  block-patron analogue of `stadium_word_dispatch()`'s `resolve_resident_cell()`) or the
+  touch-on-access hook (the analogue of `vm_core.c`'s three `stadium_word_dispatch()` call
+  sites). Not yet built — this is real, scoped, buildable work, not a stub-around candidate.
+  **Still open**, plan to be presented before implementation per the no-stubs/no-early-coding
+  conventions.
 - [ ] Wire `STADIUM_BEHAVIOUR_MIGRATE` in `stadium_dispatch()` to call
-  `blk_subsys_relocate_block()` for real. **Needs investigation first**: what LBN pair does a
-  block-patron's cell header actually carry at eviction time, and has anything ever admitted
-  a block patron onto a Stadium cell in the first place? (Item 3.5's admission code in
-  `stadium.c`/`stadium_words.c` needs tracing before wiring — if block-patron *admission*
-  itself doesn't exist yet, that's a bigger prerequisite than just the dispatch stub, and
-  should be reported back rather than built speculatively.)
+  `blk_subsys_relocate_block()` for real, once block-patron admission (above) exists. On
+  reap, `MIGRATE`'s real action may just be `blk_flush(lbn)` (write-back, per `FABRIC.md`
+  §17.2's own wording: "reap event is migration back to Artemis") — `blk_subsys_relocate_block()`
+  is a separate primitive for compudynamics-driven mid-residency relocation to a *different*
+  LBN, not necessarily what fires at ordinary Stadium eviction. Confirm which before wiring.
 - [ ] Scope VM-`COOL`: confirm whether `capsule_vm_kill()`/Tripod's existing VM lifecycle has
   any real hook point equivalent to `stadium_evict()`, or needs the same kind of admission
-  work `MIGRATE` might need. Resolve for real if small; otherwise punch-list explicitly.
+  work `MIGRATE` needs. **Deferred (2026-08-25)** per the user's own "we're going to have to
+  iterate" framing of the final Tripod/Zuse/messaging shape (see §D below) — building VM
+  eviction/cooling machinery ahead of that design risks throwaway or conflicting work. Resolve
+  only after that shape is nailed down, or if it turns out trivially small on its own.
 - [ ] `DELIVER` (Hermes) — scope as its own future item once `MIGRATE`/VM-`COOL` land; do not
   re-decide the `DELIVER`-vs-`EXPIRE` message/channel mapping here, `FABRIC.md`'s own note
   already flags it as genuinely open, not casually assumable.
@@ -315,3 +334,46 @@ Small, honest increments are still fine and encouraged — each increment just h
 complete, real implementation of whatever slice it covers, never a placeholder for a later
 slice. A pre-existing stub found while working nearby (as here) gets flagged and resolved,
 not built on top of or left in place.
+
+---
+
+## D. Tripod final shape — minting, one-time Zuse fuse, messaging-only (vision, not yet scoped)
+
+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`.
+
+- **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.
+- **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.
+- **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`.
+
+**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.
+
+**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.