diff --git a/FABRIC-3.md b/FABRIC-3.md index b8846316..18367e57 100644 --- a/FABRIC-3.md +++ b/FABRIC-3.md @@ -5341,9 +5341,9 @@ current 30 MiB image is short of one single trial's worth (516 MB / 8 ≈ 64.5 M than 2x. **This has to be fixed before any writer design matters**, and it is a two-part fix, not one: -1. **Grow `disk/artemis.img` itself.** Recommend resizing to **256 MiB** -- a real SSD/USB drive +1. **Grow `disk/artemis.img` itself.** Recommend resizing to **1 GiB** -- a real SSD/USB drive on actual bare-metal hardware will dwarf this trivially, so there is no reason to size the dev - image tightly; 256 MiB gives comfortable headroom over the summary-only budget computed below + image tightly; 1 GiB gives comfortable headroom over the summary-only budget computed below (§XXXV.4) even before any tick-sampling extension, without gambling on a number that turns out short mid-campaign. **Not done yet -- flagging the concrete risk found while scoping this, not fixing it, per this session's own instruction not to apply unrequested fixes:** growing the @@ -5356,9 +5356,9 @@ one: already-minted thumbdrive identities and everything else live on this image (`project_thumbdrive_identities_minted_20260906.md`). Two real options, genuinely open, not decided here: (a) write a proper migration -- read the fence's live content at the current - 30 MiB geometry, then rewrite it at the correct offsets for the new 256 MiB geometry, before + 30 MiB geometry, then rewrite it at the correct offsets for the new 1 GiB geometry, before ever letting anything else touch the grown file; or (b) accept identity loss and re-mint fresh - on a newly-created blank 256 MiB image, since this is presently a dev/QEMU test artifact, not + on a newly-created blank 1 GiB image, since this is presently a dev/QEMU test artifact, not a production one -- Captain Bob's call, not assumed here either way. 2. **Confirm `disk/artemis.img` is genuinely shared across all three ISAs' sequential QEMU invocations** (same `$(ARTDISK)` path referenced identically for the amd64/aarch64/riscv64 @@ -5407,7 +5407,7 @@ base, living in the same top-of-device system-metadata fence Zuse's genesis mark ### XXXV.4 -- What actually gets persisted: trial summaries, not a raw tick mirror -Given the 30 MiB (soon 256 MiB) device is 2-3 orders of magnitude smaller than raw per-tick data +Given the 30 MiB (soon 1 GiB) device is 2-3 orders of magnitude smaller than raw per-tick data at any realistic campaign size, raw per-tick mirroring to block storage is ruled out entirely, not just decimated: @@ -5416,13 +5416,13 @@ just decimated: of trial-end aggregate physics reads already available at that point (e.g. final `fleet_k_q48`/`fleet_conserved`, cumulative `switch_count`). At 18 trials/ISA x 3 ISAs = 54 records total, this is trivially small (well under 1 MiB even generously sized per record) -- - no tuning, no risk of overrunning even the current 30 MiB device, let alone 256 MiB. This alone + no tuning, no risk of overrunning even the current 30 MiB device, let alone 1 GiB. This alone is enough to reconstruct the whole campaign's pass/fail and top-line physics-conservation picture with zero dependency on any live serial capture. - **v2, optional, explicitly deferred:** decimated sub-trial sampling (e.g. one row every N heartbeat ticks instead of every tick) for anyone who wants intra-trial resolution later. Sized against whatever's left of the device budget after v1 and whatever migration/resize path - (§XXXV.2) is chosen -- rough order of magnitude, at 256 MiB total and reserving generous + (§XXXV.2) is chosen -- rough order of magnitude, at 1 GiB total and reserving generous headroom for existing fence consumers, a decimation factor in the range of several dozen ticks per sample would be needed to fit an 18-trial/ISA x 3-ISA campaign at anything like the §XXXIV.5-measured per-trial tick volume; **not sized precisely here, left for whoever @@ -5444,10 +5444,10 @@ 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 -- Drive-resize path RATIFIED: fresh 256 MiB image, full re-mint, no migration +### XXXV.6 -- Drive-resize path RATIFIED: fresh 1 GiB 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 +Captain Bob resolved §XXXV.2's option (a)-vs-(b) fork directly: **build a brand-new 1 GiB `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 @@ -5460,7 +5460,7 @@ over even if the bytes were migrated correctly, since the signing material itsel device it was minted on. **Ratified shape:** -- Build a **new, blank 256 MiB `disk/artemis.img`** from scratch -- not a resize of the current +- Build a **new, blank 1 GiB `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 @@ -5482,7 +5482,7 @@ device it was minted on. 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. -- Whether the old 30 MiB `disk/artemis.img` gets deleted/archived once the new 256 MiB image is +- Whether the old 30 MiB `disk/artemis.img` gets deleted/archived once the new 1 GiB 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