From c19b6febc2d8466d67cf2b18507a83d7e078ecbe Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Thu, 17 Sep 2026 11:29:34 -0400 Subject: [PATCH] =?UTF-8?q?FABRIC-3.md=20=C2=A7XXXV.6:=20ratify=20fresh=20?= =?UTF-8?q?256=20MiB=20artemis.img=20+=20full=20re-mint,=20no=20fence=20mi?= =?UTF-8?q?gration?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Captain Bob resolved the drive-resize fork from §XXXV.2: build a new blank 256 MiB disk/artemis.img and re-mint Zuse + all 8 thumbdrive identities fresh, rather than attempt to migrate the top-of-device fence on the existing 30 MiB image. Skips migration complexity since a re-mint invalidates prior identities either way. Decision only -- no new image built, no re-mint performed yet. Co-Authored-By: Claude Sonnet 5 --- FABRIC-3.md | 41 +++++++++++++++++++++++++++++++++++------ 1 file changed, 35 insertions(+), 6 deletions(-) diff --git a/FABRIC-3.md b/FABRIC-3.md index db6d02b6..b8846316 100644 --- a/FABRIC-3.md +++ b/FABRIC-3.md @@ -5444,10 +5444,37 @@ leaving more margin against both unknowns landing on the expensive side at once. available as a documented follow-up top-up pass later if N=2's data looks clean and time allows, rather than committing to the larger N up front. -### XXXV.6 -- Genuinely open, not decided here +### XXXV.6 -- Drive-resize path RATIFIED: fresh 256 MiB image, full re-mint, no migration +attempted (2026-09-17) + +Captain Bob resolved §XXXV.2's option (a)-vs-(b) fork directly: **build a brand-new 256 MiB +`disk/artemis.img` rather than migrate the existing 30 MiB one**, on the reasoning that +re-minting will invalidate the existing identities regardless of whether a fence migration is +attempted -- i.e. option (a)'s extra complexity (careful top-of-device fence migration to +preserve identity state across a resize) buys nothing if a re-mint happens anyway, so skip +straight to (b). Confirmed against how identity actually gets established here: genesis/ +eligibility/`artemis_sig_t` are all written fresh at first-attach time +(`project_thumbdrive_identities_minted_20260906.md`, `project_phase8_milestone6_complete.md`'s +entropy-to-signing-to-block-fence chain) -- there is no cross-image identity that could carry +over even if the bytes were migrated correctly, since the signing material itself is tied to the +device it was minted on. + +**Ratified shape:** +- Build a **new, blank 256 MiB `disk/artemis.img`** from scratch -- not a resize of the current + file. No migration code written or needed. +- **Zuse re-minted fresh** on the new image (genesis marker, root CA placement, per + `docs/03-architecture/word-acl/DESIGN.md`'s Phase 8 design and + `project_phase8_milestone6_complete.md`'s already-verified entropy/signing/block-fence chain -- + same mechanism, new device, not new code). +- **All 8 thumbdrive identities re-minted** (`project_thumbdrive_identities_minted_20260906.md`: + zuse/bob/00-06) against the new image, using the same live-verified mint path + (`project_identity_verification_bugs_20260906.md` confirms that path is already correct end to + end -- this is a re-run of a working procedure, not new development). +- The **old 30 MiB `disk/artemis.img`** is left alone / superseded, not deleted here -- disposal + of the old file is a separate, later call once the new one is confirmed live and correct. + +### XXXV.7 -- Genuinely open, not decided here -- **Which drive-resize path** (§XXXV.2: proper fence migration vs. accept identity loss and - re-mint fresh) -- Captain Bob's call before any code is written. - **Exact v2 decimation factor**, if/when v2 is built at all (§XXXV.4). - Whether `THRU`'s own line-swallowing defect (§XXXIV.1, still un-root-caused at the C level) gets fixed before or after this work -- it blocks true single-command `SK_STARTUP_FORTH` autolaunch @@ -5455,7 +5482,9 @@ rather than committing to the larger N up front. applies either way. - Disposal of the two stale partial amd64 runs' data (§XXXIV.5's own still-open item) is unrelated to this pivot and remains undecided. -- **Nothing built yet** -- this section is design only, ratified in conversation, no capsule/C - code written or committed for either the drive resize, the persistence region, or the N=2 - campaign shape. +- Whether the old 30 MiB `disk/artemis.img` gets deleted/archived once the new 256 MiB image is + confirmed live (§XXXV.6). +- **Nothing built yet** -- this section (including §XXXV.6's ratified drive-resize decision) is + design/decision only, no capsule/C code, no new disk image, and no re-mint actually performed + or committed for the drive resize, the persistence region, or the N=2 campaign shape.