FABRIC-3.md §H: close all three remaining design gaps

Gap #1: closed set of four cards (VM/word/block/message), no new cards
for now. Gap #2: creator-ceiling enforcement is a birth-time snapshot
copy, not a live ACL-RECHECK-time check -- reversed mid-conversation once
the live-check approach's cross-VM dictionary-lookup problem surfaced;
final rationale is child program stability (a program developed against
one ACL set must not have it silently changed by later parent changes).
Gap #3: Zuse's eligibility list persists in the existing growable
metadata-fence mechanism as a simple owner_pubkey[32] list, no extra
per-entry metadata.

Every design-level question in this refactor is now closed. What remains
is pure implementation (5 items) and two intentional deferrals.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

FABRIC-3.md

@@ -3630,11 +3630,17 @@ pinholes drop all the way down through and give the permission for whatever we'r
 work[ing on]... a set of graduated sieves." Confirmed accurate by the user.
 
 **Each card is one permission dimension**, not a redundant extra layer of the same check —
-named dimensions so far: VM, word, block, message. A compound action (e.g. "execute word X,
-which touches block Z and sends message M") passes through the word card, the block card, and
-the message card at once — one card per relevant axis. **Confirmed: an action only consults
-the cards for the dimensions it actually touches** — a pure VM-level operation only checks the
-VM card, not the full stack every time.
+named dimensions: VM, word, block, message. A compound action (e.g. "execute word X, which
+touches block Z and sends message M") passes through the word card, the block card, and the
+message card at once — one card per relevant axis. **Confirmed: an action only consults the
+cards for the dimensions it actually touches** — a pure VM-level operation only checks the VM
+card, not the full stack every time.
+
+**Closed set, resolved 2026-09-03**: VM, word, block, and message are the complete set — "closed
+set, no new cards, naturally, subject to change." Not permanently frozen, but not open-ended
+by default either — a fifth card (e.g. a "console" dimension, given the D.2b pentagon names
+Console as a full peer node) would be a deliberate future decision, not something implicitly
+already on the table.
 
 **Word-ACL reconciliation resolved 2026-09-02.** Checked `capsules/ACL.4th` directly: both
 existing modes (`STRICT` — "always allow, TTL stays 0 (recheck always)"; `TTL` — "compute TTL
@@ -3647,10 +3653,24 @@ reused as-is.** The stack-of-cards framing is new vocabulary for what already ex
 new mechanism.
 
 **The one genuinely new piece, not present in today's system at all**: creator-ceiling
-enforcement. Nothing today caps a newly-birthed VM's word-ACL state against its parent's —
-this needs to happen somewhere in capsule birth (copying/capping the child dictionary's
-`acl_allow`/`acl_mode`/`acl_pinned` against the parent's own values at birth time). Where
-exactly this lands in the birth flow is not yet designed.
+enforcement. Nothing today caps a newly-birthed VM's word-ACL state against its parent's.
+
+**Mechanism decided 2026-09-03, after a mid-conversation reversal.** First proposed: hook the
+ceiling check into the existing `ACL-RECHECK` cold path (checked later, no birth-time copy) —
+initially agreed, but this runs into a real problem: each VM has an entirely separate
+`DictEntry` dictionary (H.10), so `ACL-RECHECK` running inside a child would need a live
+cross-VM lookup back to the parent's own dictionary state, never designed. On seeing this, the
+user reconsidered: **"perhaps a fast copy might be cheaper and just as effective."**
+
+**Final: birth-time snapshot, no live sync, ever.** The child's `acl_allow`/`acl_mode`/
+`acl_pinned`/`acl_ttl` are copied from the parent once, at birth — no ongoing reference back
+to the parent afterward, which solves the cross-VM lookup problem outright. The child's own
+ACL state can still grow/shrink dynamically after birth (the word card's "additive/subtractive"
+framing still holds); it just starts from the snapshot rather than staying synced to the
+parent's *current* state. **Explicit rationale, user's own words**: "if something was
+developed with a particular set of ACLs, it should remain at that — otherwise parent changes
+break the child's program." Program stability for the child, not administrative convenience,
+is why live-sync was rejected.
 
 ### H.4 — VM card
 
@@ -3699,9 +3719,16 @@ retarget, quota grant, etc.) — those are finer-grained checks built elsewhere.
   path only.
 - **Eligibility gate on top of the trigger, user-proposed**: "maybe zuse keeps a list of users
   that can be granted zuse caps?" — confirmed as a gating layer, not a replacement for the
-  trigger. Zuse checks this list (presumably keyed by `owner_pubkey`, matching H.4's
-  single-owner VM-card shape) before honoring any elevation request. Exact list
-  representation/storage not yet designed.
+  trigger. Zuse checks this list (keyed by `owner_pubkey`, matching H.4's single-owner
+  VM-card shape) before honoring any elevation request.
+- **Storage decided 2026-09-03**: persists across reboots, living in Zuse's already-built
+  growable metadata fence at the top of Artemis's block device (the same mechanism that
+  already persists Zuse's own `zuse_cert_devblock_t` identity — see Phase 8/Milestone 6).
+  Shape: a simple growable list of `owner_pubkey[32]` entries, no extra per-entry metadata —
+  "simple list, no extra metadata, unless we find a reason this won't work" (provisional
+  lean-by-default, not a permanent ban on adding fields later). Not yet designed: the actual
+  record format added to the metadata fence; how entries get added (presumably a Zuse-only
+  FORTH word, unbuilt); exact relationship to the still-unbuilt `MINT`-a-second-identity flow.
 
 ### H.6 — Block card
 
@@ -3861,11 +3888,15 @@ ones. This supersedes §H.9 as the current accurate picture; §H.9 itself is lef
 as historical record (each item already carries its own closure annotation inline).
 
 **Genuinely open design question (never asked):**
-1. Whether more cards exist beyond the four named (VM, word, block, message).
+1. **CLOSED 2026-09-03.** Closed set — VM, word, block, message are the complete four, no new
+   cards for now (see H.3).
 
-**Small design pieces still undecided:**
-2. Where exactly creator-ceiling enforcement (§H.3) lands in the capsule birth flow.
-3. Zuse's eligibility-list exact representation/storage (§H.5).
+**Small design pieces, now resolved 2026-09-03:**
+2. **CLOSED.** Creator-ceiling enforcement (§H.3) is a birth-time snapshot copy, not a live
+   `ACL-RECHECK`-time check — decided after a mid-conversation reversal once the live-check
+   approach's cross-VM lookup problem surfaced.
+3. **CLOSED.** Zuse's eligibility list persists in the existing metadata-fence mechanism, as a
+   simple `owner_pubkey[32]` list, no extra metadata (§H.5).
 
 **Pure implementation gaps — design fully decided, nothing coded yet:**
 4. `stadium_birth_hermes()`/`_artemis()` don't exist (§H.1).
@@ -3873,9 +3904,17 @@ as historical record (each item already carries its own closure annotation inlin
 6. `BMAPFMT`'s code edit to `block_subsystem.h`/`.c` (§F.4/§H.6 — field/API design fully
    closed).
 7. The message card's ACL gate isn't wired onto the real `CH-REQUEST` (§H.8).
-8. Creator-ceiling enforcement itself, once item 2 above is answered.
+8. Creator-ceiling enforcement itself — the birth-time copy logic (§H.3, design now fully
+   decided as of item 2's closure above, code not written).
+9. The eligibility-list's actual metadata-fence record format + the Zuse-only FORTH word to
+   add entries (§H.5, design now fully decided as of item 3's closure above, code not
+   written).
 
 **Explicitly deferred, not rejected (intentional non-goals for now):**
-9. VM card multi-owner support (§H.4).
-10. Elevation trigger alternates — live-console `sudo` path, pre-signed capability tickets
+10. VM card multi-owner support (§H.4).
+11. Elevation trigger alternates — live-console `sudo` path, pre-signed capability tickets
     (§H.5).
+
+**Remaining genuinely open design question, after this pass**: none — every design-level
+question from this list is now closed. What's left is implementation (items 4–9) and
+intentional deferrals (10–11).