FABRIC-3.md: close SSDSCOPE, ROUNDTRIP, POLYBLOCK, PROMPTBUG -- last four §E nodes

SSDSCOPE and ROUNDTRIP close by cross-referencing decisions already made this session (D.3's "no central registry" statement, and the pool-ownership/EJECT-flush model from F.6/F.10) rather than new tracing -- both turn out to have zero remaining work of their own. POLYBLOCK needed the user's own clarification first (never elaborated beyond one sentence since 2026-08-25): reframes as an architectural principle (the block layer shouldn't know what backs it), confirmed already true of blk_get_buffer()'s live RAM/raw/disk-cache abstraction. PROMPTBUG traced for the literal string and found to be less than described -- no live code prints "zuse)ok>" today, only a doc comment describing not-yet-implemented behavior; correct intended form recorded, comment itself not touched per standing instruction against unrequested code changes.

Also corrects two stale graph classifications noticed while cleaning up: ACLKEY's own node had never been updated despite being fully scoped back in F.2, and the empty "open" classDef bucket is now removed since every §E node is closed or scoped except WRITE(10) itself.

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)<br/>partially answered: ACL decides *when*"]
     UNCLEAN["❌ Unclean-removal handling (M3)<br/>DESIGN CLOSED 2026-08-27 (§F.10), code not yet written"]
 
-    ACLKEY["❓ ACL 'bumps and holes' comparison<br/>semantics — SAME GAP in M5 and D.4"]
+    ACLKEY["❌ ACL 'bumps and holes' comparison<br/>semantics — SCOPED 2026-08-27 (§F.2)"]
     WIREBIND["❌ Wire hotplug → capsule_birth_baby() (M5)"]
     BINDSTEP["❌ Extend sk_repl_set_active_vm()<br/>with key-match (M5) — SCOPED 2026-08-27 (§F.9)"]
     DETACH["❌ Detach behavior / new EJECT word (M5)<br/>SCOPED 2026-08-27 (§F.10)"]
@@ -1471,10 +1486,10 @@ graph TD
     MSGSHAPE["✅ Hermes message shape known<br/>(MSG-CELLS, MSG-ALLOC/DELIVER)"]
     MSGMIGRATE["❌ Message-bus migration of<br/>attach/verify/bind (D.4) — SCOPED 2026-08-27 (§F.15)"]
 
-    SSDSCOPE["❓ SSD identity-store scope<br/>for regular users (D.4)"]
+    SSDSCOPE["✅ SSD identity-store scope<br/>for regular users — CLOSED 2026-08-27 (§F.16)"]
-    ROUNDTRIP["❓ Session state round-trip<br/>across attaches (D.4)"]
+    ROUNDTRIP["✅ Session state round-trip<br/>across attaches — CLOSED 2026-08-27 (§F.16)"]
-    POLYBLOCK["❓ Polymorphic block-boundary<br/>behavior (D.1, since 2026-08-25)"]
+    POLYBLOCK["✅ Polymorphic block-boundary<br/>behavior — CLOSED 2026-08-27 (§F.16), already true"]
-    PROMPTBUG["🐛 (Zuse)ok> prompt typo<br/>trivial, independent"]
+    PROMPTBUG["🐛 (Zuse)ok> prompt typo<br/>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 M6,PH8,EXPIRE,MSGSHAPE,HOTPLUG,BMAPWRITE,BMAPREAD,SSDSCOPE,ROUNDTRIP,POLYBLOCK done
-    class W10,STALL,FIRSTTOUCH,WIREBIND,BINDSTEP,DETACH,MINT,BMAPFMT,CERTVERIFY,RUNCAP,UNCLEAN,MSGMIGRATE blocked
+    class W10,STALL,FIRSTTOUCH,WIREBIND,BINDSTEP,DETACH,MINT,BMAPFMT,CERTVERIFY,RUNCAP,UNCLEAN,MSGMIGRATE,ACLKEY blocked
-    class ACLKEY,SSDSCOPE,ROUNDTRIP,POLYBLOCK open
     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