FABRIC-3.md §XXXV.6: ratify fresh 256 MiB artemis.img + full re-mint, no fence migration
Build / build-amd64-iso (push) Waiting to run
Build / build-aarch64-iso (push) Waiting to run
Build / build-riscv64-img (push) Waiting to run

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 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-09-17 11:29:34 -04:00
co-authored by Claude Sonnet 5
parent a83cbe016f
commit c19b6febc2
+35 -6
View File
@@ -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.