admin/LithosAnanake
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

FABRIC-3.md §H.11: refreshed gap analysis, end of session

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-09-02 19:04:48 -04:00
co-authored by Claude Opus 5
parent 91dfb0a079
commit d86b6de9cd
1 changed files with 33 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
FABRIC-3.md
+33 -3
View File
@@ -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 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 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. 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 - **Elevation trigger, updated 2026-09-02: closer to usable than first thought.** Rides Hermes
document's own standing completion criterion (D.1) isn't the real implementation yet. messaging — at the time this risk was flagged, assumed to not be the real implementation
Correct on paper, not usable until that substrate exists — expected, not a flaw. 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).