diff --git a/FABRIC-3.md b/FABRIC-3.md index dcdfac1..05f00bb 100644 --- a/FABRIC-3.md +++ b/FABRIC-3.md @@ -1220,6 +1220,8 @@ then we'll build a plan"). Full detail also in memory `project_tripod_final_shap 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. + **CLOSED 2026-08-27, see `D.4`/§F.16** — that follow-up happened; already true of the live + block-subsystem code. - **`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`. @@ -1384,14 +1386,23 @@ can't"):** Surfaced a substantial new vision detail along the way: blank-media minting is a Console- driven interactive onboarding form, not a bare word call (§D.6). - **Polymorphic block-boundary behavior for user VMs** — still just the one original sentence - from 2026-08-25, never elaborated. + from 2026-08-25, never elaborated. **CLOSED 2026-08-27 (`FABRIC-3.md` §F.16)**: clarified by + the user as an architectural principle (the block layer should have no idea what backs it), + then confirmed already true of `blk_get_buffer()`'s live RAM/raw/disk-cache abstraction — + not a missing feature. - **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. + latter, but not stated explicitly enough to treat as settled. **CLOSED 2026-08-27 + (`FABRIC-3.md` §F.16)**: confirmed the latter, both by D.3's own explicit "no central + registry" statement and structurally by where this session's own scoping put every piece of + user identity data (§F.6-F.8, all on the user's own drive). - **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. **Checked against + drive? Implied yes by the detach description, not confirmed directly. **CLOSED 2026-08-27 + (`FABRIC-3.md` §F.16)**: confirmed as a structural consequence of decisions already made — + the user's pool being their own drive plus `EJECT`'s flush-before-kill means the data simply + never leaves; no separate resume mechanism needed. **Checked against `FABRIC.md` §24's mutation/identity-stability rules (mined 2026-08-27) — no conflict either way**: identity is only pinned stable *within one residency*, so a thumbdrive re-attaching later and being admitted as a fresh VM patron (possibly reusing an identity value derived @@ -1420,7 +1431,11 @@ can't"):** **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. +everything else in this section; safe to fix any time. **CLOSED 2026-08-27 (`FABRIC-3.md` +§F.16)**: traced for the literal string — it doesn't exist in any live code path today +(`SK_PROMPT_TEXT` is unconditionally `"ok> "`); the typo lives only in a doc comment +describing not-yet-implemented behavior. Correct intended form recorded for whenever it's +actually built. **Why this affects §B:** VM-`COOL` (and any inter-VM Stadium wiring) sits close to this design — see D.2's `EXPIRE` supersession above, the concrete example of exactly this risk @@ -1459,7 +1474,7 @@ graph TD MIGSM["🟡 Migration state machine (M3)
partially answered: ACL decides *when*"] UNCLEAN["❌ Unclean-removal handling (M3)
DESIGN CLOSED 2026-08-27 (§F.10), code not yet written"] - ACLKEY["❓ ACL 'bumps and holes' comparison
semantics — SAME GAP in M5 and D.4"] + ACLKEY["❌ ACL 'bumps and holes' comparison
semantics — SCOPED 2026-08-27 (§F.2)"] WIREBIND["❌ Wire hotplug → capsule_birth_baby() (M5)"] BINDSTEP["❌ Extend sk_repl_set_active_vm()
with key-match (M5) — SCOPED 2026-08-27 (§F.9)"] DETACH["❌ Detach behavior / new EJECT word (M5)
SCOPED 2026-08-27 (§F.10)"] @@ -1471,10 +1486,10 @@ graph TD MSGSHAPE["✅ Hermes message shape known
(MSG-CELLS, MSG-ALLOC/DELIVER)"] MSGMIGRATE["❌ Message-bus migration of
attach/verify/bind (D.4) — SCOPED 2026-08-27 (§F.15)"] - SSDSCOPE["❓ SSD identity-store scope
for regular users (D.4)"] - ROUNDTRIP["❓ Session state round-trip
across attaches (D.4)"] - POLYBLOCK["❓ Polymorphic block-boundary
behavior (D.1, since 2026-08-25)"] - PROMPTBUG["🐛 (Zuse)ok> prompt typo
trivial, independent"] + SSDSCOPE["✅ SSD identity-store scope
for regular users — CLOSED 2026-08-27 (§F.16)"] + ROUNDTRIP["✅ Session state round-trip
across attaches — CLOSED 2026-08-27 (§F.16)"] + POLYBLOCK["✅ Polymorphic block-boundary
behavior — CLOSED 2026-08-27 (§F.16), already true"] + PROMPTBUG["🐛 (Zuse)ok> prompt typo
CLOSED 2026-08-27 (§F.16) — doc-comment only, not live code"] W10 -->|blocks| BMAPWRITE W10 -->|blocks| MINT @@ -1513,9 +1528,8 @@ graph TD classDef unblocked fill:#a83,stroke:#333,color:#fff classDef open fill:#666,stroke:#333,color:#fff classDef partial fill:#883,stroke:#333,color:#fff - class M6,PH8,EXPIRE,MSGSHAPE,HOTPLUG,BMAPWRITE,BMAPREAD done - class W10,STALL,FIRSTTOUCH,WIREBIND,BINDSTEP,DETACH,MINT,BMAPFMT,CERTVERIFY,RUNCAP,UNCLEAN,MSGMIGRATE blocked - class ACLKEY,SSDSCOPE,ROUNDTRIP,POLYBLOCK open + class M6,PH8,EXPIRE,MSGSHAPE,HOTPLUG,BMAPWRITE,BMAPREAD,SSDSCOPE,ROUNDTRIP,POLYBLOCK done + class W10,STALL,FIRSTTOUCH,WIREBIND,BINDSTEP,DETACH,MINT,BMAPFMT,CERTVERIFY,RUNCAP,UNCLEAN,MSGMIGRATE,ACLKEY blocked class MIGSM partial ``` @@ -2286,6 +2300,61 @@ current iterative pass, recorded so they aren't lost):** release. Stated as the destination this whole planning arc is walking toward, not an immediate next step. +### F.16 — The last four standalone nodes: `SSDSCOPE`, `ROUNDTRIP`, `POLYBLOCK`, `PROMPTBUG` + +Closes out every node in §E's graph except `WRITE(10)` itself. Three of the four close by +cross-referencing decisions already made this session, not new tracing; `POLYBLOCK` needed the +user's own clarification first, since it had never been elaborated beyond one sentence. + +**`SSDSCOPE` — closed.** "Does the system-resident store (Phase 8's block-fence) ever hold +anything about *regular* users, or is it purely Zuse/system bookkeeping?" This was already +answered, just not cross-referenced: D.3 states directly — *"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."* This session's own later +scoping confirms it structurally rather than just by assertion: `CERTVERIFY`/`RUNCAP`/`MINT` +(§F.6-F.8) all put a user's cert, keypair, and personality source *on their own thumbdrive*, +never on Artemis's system-resident fence. `FIRSTTOUCH` (§F.11) does let a user's claim extend +onto system-resident devblocks, but that's anonymous per-block ownership (`blk_meta_t.owner_fp`, +a pubkey fingerprint) written directly on the claimed blocks themselves — not a lookup-by-name +directory entry anywhere. The system-resident fence holds exactly one identity record type: +Zuse's own (`zuse_cert_devblock_t`). + +**`ROUNDTRIP` — closed.** "Does a user's session state round-trip across multiple attaches?" +Implied yes by D.3's detach description, now confirmed structurally rather than left implicit: +since a user's pool *is* their own thumbdrive by default (§F.6, decision 3) and `EJECT` +(§F.10) flushes working state back to wherever those blocks physically live before killing the +VM, the data simply never leaves the drive between attaches. Reattaching the same drive and +re-birthing via `WIREBIND`+`RUNCAP` naturally resumes from wherever the blocks were left — no +separate "session resume" mechanism needs building; the drive's own persistence *is* the +round-trip mechanism, a consequence of decisions already made rather than a new one. + +**`POLYBLOCK` — closed, reframed as an existing principle, not a missing feature.** Clarified +directly by the user: the block abstraction at this level should have no idea what backs it — +"a re-usable, polymorphic definition of a storage device." Traced against `blk_get_buffer()` +(`block_subsystem.c:866-900`) before concluding anything: it already returns a uniform `uint8_t*` +regardless of whether the backing LBN resolves to RAM, a raw in-memory device +(`blk_subsys_add_raw_device()`), or a real disk-cache-backed device — callers (every FORTH +block word, `LOAD`, etc.) never know or care which. The one backend-specific behavior found +(`BLK_FMT_PROVISIONAL` write-refusal, disk-backed slots only) doesn't violate this — it's +encapsulated *within* the uniform interface (an ordinary failed `blk_get_buffer()` call), not +leaked as caller-visible backend-awareness. **This principle is already true of the live code**, +confirmed rather than assumed. + +**`PROMPTBUG` — closed, and found to be less than originally described.** Traced for the +literal string before closing: no runtime code anywhere prints `"zuse)ok> "` today — +`SK_PROMPT_TEXT` (`repl.c:50`) is unconditionally `"ok> "`; there is no `zuse_session`-gated +prompt-text branch in the live REPL at all yet (only `emergency_console` gating exists, +`repl.c:412,459`). The typo lives in a **doc comment** describing not-yet-implemented intended +behavior (`repl.c:372`), not in running code. Closed as: whenever a Zuse-specific prompt is +actually implemented, use `"(Zuse)ok> "` (both parens, generalizing to any attached identity — +`"(CaptBob)ok> "`), matching the already-corrected form recorded in `D.4`. The comment itself +is a trivial one-line fix whenever code in this file is next touched — not applied here, +per standing instruction against unrequested code changes. + +**Every node in the §E graph is now scoped or closed except `WRITE(10)` itself** — the one +remaining hard blocker gating real execution of nearly everything captured across this entire +`§F` pass. + ### D.6 — Console-driven interactive mint onboarding (vision capture, 2026-08-27) Surfaced live while scoping `MSGMIGRATE`'s message-target question (§F.15) — capture only, per