FABRIC-2.md Sections W/X: correct execution order -- validate Artemis

in QEMU first, defer real-hardware USB boot to last; add UEFI-only
boot-path constraint

Captain Bob's explicit correction: real-hardware boot is "difficult
and lots of blind guesswork" (no serial log, unknown firmware quirks)
and isn't worth attempting until there's a working Artemis subsystem
to actually demonstrate, not just an empty kernel proving UEFI boot
works. QEMU's own USB hotplug emulation is sufficient to build and
validate the entire home-blocks subsystem without touching real
hardware at all.

Milestone IDs in Section X kept stable (not renumbered, to avoid
breaking cross-references between milestones) with an explicit
execution-order note instead: 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> 1,
networking (9) still deferred past all of them.

New scope constraint captured for whenever Milestone 1 resumes: UEFI-
only boot path, no legacy BIOS/MBR, no GRUB2 -- starkernel_loader.efi
is meant to be the entire boot path, not one stage in a longer chain.

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

FABRIC-2.md

@@ -2945,23 +2945,29 @@ overwritten; the zuse credential, once minted, can never be re-minted.
 | Install path ("install it") | area H | ❌ not started, explicitly deferred — "not that risky yet" |
 | QEMU monitor socket (dev iteration) | area B | ❌ one-line gap, not blocking |
 
-**Sequencing, as currently stated across the whole conversation, nearest-term first:**
+**Sequencing — corrected 2026-08-22, real-hardware boot moved to last, not first.**
+Captain Bob's explicit call, reversing this section's original draft order: get Artemis (the
+actual home-blocks/USB subsystem) working and validated **inside QEMU first** — real-hardware
+boot is "difficult and lots of blind guesswork" (no serial log, unknown firmware quirks,
+Secure Boot variance — the exact caveats this section already listed as real, now treated as
+reason to defer rather than a footnote) and isn't worth attempting until there's something
+real to boot *into*, not just an empty kernel proving UEFI boot works at all.
 
-1. **Bare-metal boot from a physical USB stick, demo/"try it" mode only — the actual next
+1. **USB hardware stack (Milestone 3) and the rest of the Artemis subsystem (Milestones
-   milestone**, confirmed this session as *not* gated on the USB-hardware-driver gap above.
+   4-8), built and validated entirely in QEMU** — QEMU's own USB hotplug emulation
-   Booting *from* USB is a UEFI firmware responsibility, not a kernel one — the same
+   (`device_add`/`device_del` via the QMP socket, Milestone 2) is sufficient to build and test
-   `starkernel.iso` (amd64/aarch64, El Torito) or raw disk image (riscv64) already rebuilt on
+   all of it without touching real hardware at all. This is now the actual near-term work.
-   every QEMU launch this session is, mechanically, the artifact to `dd` onto a physical drive.
+2. Contributor capsules/trust tiers, still explicitly sequenced after the ACL/PKI work closes.
-   Two 64GB SanDisk drives are on hand and available right now for this; one currently carries
+3. Networking (capsule distribution server, WiFi), still sequenced after that.
-   a Kubuntu 26.04-era live ISO, re-flashable without loss (re-downloadable). Real-hardware
+4. **Bare-metal boot from a physical USB stick (demo/"try it" mode) — moved to last, not
-   UEFI firmware varies from QEMU's OVMF, so the first real boot is a genuine test, not a
+   first.** Still confirmed not *technically* gated on the USB-hardware-driver work (booting
-   formality — noted, not treated as a blocker.
+   *from* USB is UEFI's job, not the kernel's), but no longer worth doing until there's a
-2. Everything in this section's component table below the live-boot-ISO row — the actual
+   working Artemis subsystem to actually demonstrate. **Added scope constraint for whenever
-   home-blocks/thumbdrive-as-persistent-identity-storage subsystem — waits on the USB
+   this does happen: the boot path must be UEFI-only — no legacy BIOS/MBR support, no GRUB2
-   hardware driver (area B), which is the honest, singular hard prerequisite once milestone 1
+   or any other bootloader in the chain.** The existing `starkernel_loader.efi` is meant to be
-   is done.
+   the entire boot path, generic and minimal, not one stage in a longer chain. Two 64GB
-3. Contributor capsules/trust tiers, explicitly sequenced after the ACL/PKI work closes.
+   SanDisk drives remain on hand and available whenever this gets picked back up; one
-4. Networking (capsule distribution server, WiFi), explicitly sequenced after that.
+   currently carries a Kubuntu 26.04-era live ISO, re-flashable without loss.
 
 Not started: no code, no capsule work, no hardware testing yet. This section exists so a
 future session (or Captain Bob re-reading cold) gets the whole shape in one read, rather than
@@ -2972,17 +2978,28 @@ needing to reconstruct it by reading U, V, and this section's own cross-referenc
 ## X. Artemis punch list — deep detail, one task at a time, 2026-08-22
 
 Requested explicitly: deep, function-level granularity, no code written yet — this is the
-task breakdown only. Organized by milestone, in the sequence Section W established. Each
+task breakdown only. Each milestone is independently checkable off; sub-items within a
-milestone is independently checkable off; sub-items within a milestone are ordered (later
+milestone are ordered (later items generally depend on earlier ones in the same milestone
-items generally depend on earlier ones in the same milestone unless noted). `[ ]` = not
+unless noted). `[ ]` = not started, matching this file's existing convention (Section F).
-started, matching this file's existing convention (Section F). Where a task genuinely needs
+Where a task genuinely needs spec research before it can even be scoped precisely (mostly in
-spec research before it can even be scoped precisely (mostly in Milestone 3, USB hardware),
+Milestone 3, USB hardware), the research step is its own punch-list item rather than skipped.
-the research step is its own punch-list item rather than skipped.
+
+**Execution order — corrected same day, see Section W's sequencing update.** Milestone
+numbers below are stable IDs (kept as originally assigned so cross-references between
+milestones stay valid), *not* execution order. Real-hardware boot (Milestone 1) moved to
+**last** — build and validate Artemis entirely in QEMU first. Actual order to work through:
+**2 → 3 → 4 → 5 → 6 → 7 → 8 → 1**, with Milestone 9 (networking) deferred past all of them per
+its own section below.
 
 ### Milestone 1 — Bare-metal boot from physical USB (demo/"try it" mode)
 
-Confirmed not gated on any other milestone below (Section W). Smallest, nearest-term,
+**Deferred to last, not first — see the execution-order note above.** Technically not gated
-actionable now.
+on any milestone below (booting from USB is UEFI's job, not the kernel's), but deliberately
+not attempted until Milestones 2-8 give it something real to demonstrate; real-hardware boot
+is "difficult and lots of blind guesswork" and not worth the detour yet. **Scope constraint
+for whenever this resumes: UEFI-only boot path, no legacy BIOS/MBR support, no GRUB2 or any
+other bootloader in the chain** — `starkernel_loader.efi` is meant to be the entire boot path,
+generic and minimal, not one stage in a longer one.
 
 - [ ] Confirm which physical machine will receive the first real-hardware boot test (CPU
       arch — amd64 assumed given the SanDisk drives on hand, but confirm)