From d86b6de9cd56afd108af5f7391a9ec63dbdfa2ba Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Wed, 2 Sep 2026 19:04:48 -0400 Subject: [PATCH] =?UTF-8?q?FABRIC-3.md=20=C2=A7H.11:=20refreshed=20gap=20a?= =?UTF-8?q?nalysis,=20end=20of=20session?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Full sweep across the whole session-refactor design pass -- 7 of the original 10 §H.9 gaps are now closed. Compiles the current accurate picture: one genuinely open design question (more cards beyond the four named?), two small undecided pieces (creator-ceiling enforcement location, Zuse eligibility-list storage), five pure implementation gaps (design fully decided, nothing coded), and two explicitly-deferred non-goals (VM card multi-owner, elevation trigger alternates). Also updates H.10's stale "elevation trigger not yet usable" note now that H.7 confirmed the messaging substrate is already real. Co-Authored-By: Claude Opus 5 --- FABRIC-3.md | 36 +++++++++++++++++++++++++++++++++--- 1 file changed, 33 insertions(+), 3 deletions(-) diff --git a/FABRIC-3.md b/FABRIC-3.md index d234dbc..7520919 100644 --- a/FABRIC-3.md +++ b/FABRIC-3.md @@ -3846,6 +3846,36 @@ Two smaller, lower-risk items flagged in the same pass: functions (e.g. `session_set_pinned()` / `session_is_pinned()`); nothing, including existing Stadium code, reads `STADIUM_FLAG_PIN` directly off the patron header anymore. Session is the sole authority for both write and read, not just the write path. -- **Elevation trigger not yet usable (H.5/H.7).** Rides Hermes messaging, which per this - document's own standing completion criterion (D.1) isn't the real implementation yet. - Correct on paper, not usable until that substrate exists — expected, not a flaw. +- **Elevation trigger, updated 2026-09-02: closer to usable than first thought.** Rides Hermes + messaging — at the time this risk was flagged, assumed to not be the real implementation + yet. §H.7's later verification found the messaging substrate (`CH-REQUEST`/`CH-ACCEPT`/ + `CH-CONFIRM`/ACK-NACK) is already real, working code. What's still missing is only the ACL + gate itself (H.8) and the `ELEVATE-REQUEST` message type/handler — smaller gaps than + originally flagged, not a missing substrate. + +### H.11 — Gap analysis, refreshed (2026-09-02, end of session) + +Full sweep across the whole design pass, not just a re-list of §H.9's original ten items — 7 +of them are now closed (1, 2, 3, 4, 6, 7, 8). New sub-gaps surfaced while closing the old +ones. This supersedes §H.9 as the current accurate picture; §H.9 itself is left intact above +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). + +**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). + +**Pure implementation gaps — design fully decided, nothing coded yet:** +4. `stadium_birth_hermes()`/`_artemis()` don't exist (§H.1). +5. The `Session` struct + its own header don't exist (§H.2). +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. + +**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 + (§H.5).