Execute FABRIC-3.md §XXXV.6: format new artemis.img, re-mint all 9 identities live

Boots amd64 with Zuse's bleached thumbdrive, confirms live: fresh 1 GiB
disk/artemis.img formats ("Artemis: blank disk -- formatting"), Zuse
genesis-mints onto it ("Zuse: genesis minted onto attached thumbdrive",
root CA written to the new fence's devblock 0), session authenticates
(zuse@Hera ok>). With Zuse live, mints the other 8 identities (bob, 00-06)
one at a time via QMP-driven xHCI hotplug + MINT at the console, each
confirmed by its own "MINT: identity minted" log line before detaching
and moving to the next. Clean BYE shutdown, zero leaked qemu/socat
processes, all 9 images verified nonzero.

Root cause confirmed live before executing: Zuse's genesis marker lives
on artemis.img's own fence (devblock_from_top=0), not on her thumbdrive
-- with the marker gone, her old drive could not have re-authenticated
regardless of its own content, confirming re-mint was genuinely required.

FABRIC-3.md §XXXV.7/.8, disk/README.md updated with the full account.
Serial log preserved: logs/20260917-114652/amd64/.

Still open: the block-backed DoE persistence writer itself is unbuilt
(design only); ZUSE-ELIGIBILITY-ADD (elevation eligibility, narrower
than baseline auth) not re-populated for any of the 8; old 30 MiB
artemis.img backup disposal undecided.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

FABRIC-3.md

@@ -5473,7 +5473,54 @@ device it was minted on.
 - 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
+### XXXV.7 -- §XXXV.6 EXECUTED live: fresh `artemis.img` formatted, all 9 identities re-minted,
+verified end to end (2026-09-17)
+
+Before executing, confirmed the root cause that made re-mint (not just re-registration)
+mandatory, not merely likely: `capsule_zuse_boot.c`'s `genesis_marker_read()` reads Zuse's
+`zuse_pubkey` root-CA marker from **Artemis's own disk fence** (`devblock_from_top=0`), not from
+her thumbdrive -- her thumbdrive only carries her seed/cert, checked *against* that marker.
+With the marker gone (fresh `artemis.img`), `capsule_zuse_boot_try_attach()`'s own logic
+silently no-ops for a non-blank, already-minted drive (the `!have_marker` branch only proceeds
+if the attaching drive is *also* blank) -- her old thumbdrive genuinely could not have
+re-authenticated against the new disk, confirming the user's original instinct
+("reminting will invalidate the existing identities too") was correct, not merely cautious.
+Also confirmed `capsule_mint_identity()` refuses to write over an already-recognized drive
+(`MINT_ERR_ALREADY_MINTED`), so bleaching all 9 thumbdrive images to blank first was mandatory,
+not optional, before any of them could be re-minted.
+
+**Executed, in order:**
+1. Bleached all 9 `disk/thumbdrives/*.img` (zuse, bob, 00-06) to all-zero, 64 MiB each,
+   verified zero nonzero bytes and size intact. Committed (`e56974e`).
+2. Booted amd64 (`make -f Makefile.starkernel ARCH=amd64 qemu QEMU_DISPLAY=none`, orchestrated
+   headless via a bash+socat+QMP driver script, not `-display gtk` this time since this session
+   has no visual terminal) with Zuse's now-blank drive attached at launch (the Makefile's own
+   default `ZUSEDISK`). Confirmed live in the serial log: `Artemis: blank disk -- formatting`
+   (fresh 1 GiB image formatted), `Zuse: genesis minted onto attached thumbdrive` (root CA
+   written fresh to the new fence), prompt reached `zuse@Hera ok>` (session authenticated).
+3. With Zuse authenticated, minted the other 8 identities one at a time against the **same
+   still-running instance** -- hot-attached each blanked thumbdrive over QMP
+   (`human-monitor-command` wrapping `drive_add`/`device_add` against `xhci0.0`, mirroring the
+   2026-09-06 session's HMP-not-QMP-JSON approach but reached through the QMP socket the current
+   `Makefile.starkernel` actually wires up, since no separate HMP monitor socket exists in the
+   current target), minted via the live console (`MINT-NUM`, a thin `MINT` wrapper defined
+   at the console for the 6 numeric identities exactly as in the original 2026-09-06 procedure;
+   full `full_name`/`username`/`email` `MINT` call for `bob`), then hot-detached
+   (`device_del`/`drive_del`) before the next. All 9 `MINT: identity minted` confirmations
+   present in the log (the 9th being the "00" identity, validated first as a single-device
+   dry run before looping the remaining 7 -- caught and fixed a false-negative bug in this
+   session's own verification helper, a classic `grep -c ... || echo 0` double-output bug, before
+   trusting the result on the other 7).
+4. Clean `BYE` shutdown, confirmed zero leaked `qemu-system-x86_64`/`socat` processes afterward.
+   All 9 thumbdrive images confirmed nonzero in their first 6 devblocks (same verification
+   convention as the original mint); `disk/artemis.img` confirmed no longer blank
+   (27,618 nonzero bytes of real fence/format data). Full log preserved:
+   `logs/20260917-114652/amd64/qemu-amd64-20260917-114652.log`.
+
+Committed and pushed (image/log commit follows this one). `disk/README.md` updated with the
+same account.
+
+### XXXV.8 -- Genuinely open, not decided here
 
 - **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
@@ -5482,9 +5529,13 @@ 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 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
-  or committed for the drive resize, the persistence region, or the N=2 campaign shape.
+- Whether the old 30 MiB `disk/artemis.img` gets deleted/archived now that the new 1 GiB image is
+  confirmed live and re-minted (§XXXV.7).
+- The block-backed DoE persistence writer itself (§XXXV.3/§XXXV.4) is still design-only -- no
+  capsule/C code written for it. Only the drive-resize/re-mint prerequisite (§XXXV.6) is done.
+- The `ZUSE-ELIGIBILITY-ADD` elevation-eligibility list (narrower than baseline identity auth --
+  only gates the `ELEVATE` flow in `capsules/zuse-eligibility.4th`, confirmed by reading its only
+  call site) was **not** re-populated for any of the 8 re-minted identities during this pass --
+  their baseline identity/auth works (confirmed live), but elevation eligibility, if any of them
+  had it before, was not restored. Left open; re-add via `ZUSE-ELIGIBILITY-ADD` later if needed.
 

disk/README.md

@@ -18,9 +18,21 @@ VM's `--disk-img=` flag instead.
   ratified building a brand-new blank image and re-minting Zuse + all
   thumbdrive identities fresh against it, since re-minting invalidates the
   prior identities regardless of whether a migration is attempted. Blank
-  (all zero) at creation, same as every other fresh-format fixture below —
-  not yet formatted or re-minted; that is a separate, later live-boot step.
-  The superseded 30 MiB image is preserved, not deleted, as
+  (all zero) at creation, same as every other fresh-format fixture below.
+  **Formatted and re-minted live, same day**: booted amd64 with Zuse's
+  (freshly bleached) thumbdrive attached at launch — `Artemis: blank disk --
+  formatting` confirmed the fresh format, `Zuse: genesis minted onto
+  attached thumbdrive` confirmed her genesis mint (root CA — her
+  `zuse_pubkey` — written to this image's own devblock 0, per
+  `capsule_zuse_boot.c`'s `genesis_marker_read()`/`install_and_activate()`),
+  and the `zuse@Hera ok>` prompt confirmed her session authenticated. The
+  other 8 identities (`bob`, `00`–`06`) were then minted one at a time via
+  QMP-driven xHCI hotplug (`drive_add`/`device_add` per drive, `MINT` or a
+  `MINT-NUM` helper word at the live console, `device_del`/`drive_del` to
+  detach before the next) — all 9 `MINT: identity minted` confirmations
+  present in `logs/20260917-114652/amd64/qemu-amd64-20260917-114652.log`,
+  clean `BYE` shutdown, no leaked qemu/socat processes. The superseded
+  30 MiB image is preserved, not deleted, as
   `artemis-30mb-pre-1gib-backup.img` (below).
 - `artemis-30mb-pre-1gib-backup.img` — the pre-2026-09-17 `artemis.img`
   (30 MiB), preserved rather than deleted when `artemis.img` was rebuilt
@@ -123,6 +135,19 @@ carrying timestamp noise in git history.
   default via zeroed former padding, not corruption) rather than crashing
   or misreading adjacent fields.
 
+- `thumbdrives/` — the 9 **real** identity thumbdrive images (`zuse-thumb-
+  ident.img`, `bob-thumb-ident.img`, `00-thumb-ident.img`–`06-thumb-
+  ident.img`), 64 MiB each, minted via the actual kernel `MINT` word (not
+  blank placeholders). **Bleached and re-minted fresh, 2026-09-17**
+  (FABRIC-3.md §XXXV.6/§XXXV.8): required alongside the `artemis.img`
+  rebuild above, since Zuse's own genesis marker lives on `artemis.img`,
+  not on any thumbdrive — with that marker gone, none of these 9 images'
+  prior certs could authenticate against the new disk regardless of their
+  own on-drive content, and `capsule_mint_identity()` refuses to mint over
+  an already-recognized drive, so all 9 had to be blanked first. Same
+  verification convention as the original 2026-09-06 mint
+  (`project_thumbdrive_identities_minted_20260906.md`): nonzero-byte count
+  in each image's first 6 devblocks confirms real identity data present.
 - `zuse.img` — 64MB raw image simulating the physical Zuse superuser
   thumbdrive for QEMU testing (FABRIC-2.md, Phase 8: `zuse.img` "bleach"
   mechanism, added 2026-08-26). **64MB is only this fixture's size, not a