FABRIC-3.md: amd64 bare-metal-boot planning decided + punch list

Decisions from conversation: observation is HDMI (interactive) +
serial via the Raspberry Pi's own GPIO UART as the bridge, if the SER5
exposes a UART header (not yet confirmed); genericity is verified by a
code audit against real UEFI/ACPI standards rather than a second
physical machine (none available); Secure Boot is already disabled on
this SER5, so no signed-loader work is needed for this pass.

9-item punch list follows: build+flash the thumbdrive image, physically
inspect for a UART header, connect HDMI, boot, a code-audit pass for
SER5-specific assumptions (the actual genericity bar), capture the
boot (POST/ok>/rdrand backend/serial transcript), mint+re-attach Zuse
on real hardware, then update this section with results before moving
to aarch64.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var

FABRIC-3.md

@@ -162,15 +162,45 @@ what's still genuinely unknown, not assumed.
   `ok>`, document) is the closest thing to an existing plan — but it predates the genericity
   requirement and was written with no hardware in hand yet.
 
-**Genuinely open, not yet decided:**
-- What "generic enough" actually needs to be verified against, beyond the SER5 — is there a
-  second, different machine available to cross-check against, or does genericity get argued
-  from firmware-standards-compliance (real UEFI, no vendor-specific assumptions in the boot
-  code) rather than a second physical test right away?
-- Observation method for a headless/serial-less real machine (no QMP/serial socket the way
-  QEMU gives us) — HDMI + keyboard? A serial console cable if the board exposes UART pins?
-- Whether Secure Boot needs handling, and how, on real UEFI firmware (QEMU/OVMF's own Secure
-  Boot behavior may not match every real vendor's).
+**Decided in conversation, 2026-09-04:**
+- **Observation: HDMI (interactive) + serial (logged transcript), both.** The kernel's own
+  VT100 framebuffer console (`console.c`/`vt100.c`/`framebuffer.c`) already gives a real
+  interactive display over HDMI — no new code needed there. Serial capture, if the SER5
+  exposes a UART header, uses the Raspberry Pi's own GPIO UART as the USB-serial bridge
+  (already available hardware, not a purchase blocker) — this needs the SER5's own UART pins
+  physically identified first (not yet confirmed it has an accessible header at all).
+- **Genericity is verified by standards-compliance, not a second machine** — no second x86_64
+  box is available right now. The bar is: nothing in the boot path may depend on an
+  SER5-specific assumption (a particular ACPI table shape, a specific UEFI implementation's
+  quirk) — argued by code audit against real UEFI/ACPI standards, not by testing on a second
+  board, until one becomes available. This is a real constraint on the punch list below (item
+  6), not a deferred nice-to-have.
+- **Secure Boot: already disabled on this SER5.** No signed-loader work needed for this pass —
+  "Secure Boot disabled in firmware setup" is the supported path, documented as such rather
+  than built around.
+
+**Punch list, this cadence's actual next steps:**
+1. Build the generic thumbdrive image: `make -f Makefile.starkernel ARCH=amd64 thumbdrive`.
+2. Flash it to a USB stick (`dd`, per the target's own existing usage message).
+3. Physically inspect the SER5 for an exposed UART header/pins; if present, wire the
+   Raspberry Pi's GPIO UART to it as the serial bridge. If absent, HDMI-only for this pass —
+   not a blocker, just a scope note for step 7's log.
+4. Connect HDMI + keyboard to the SER5.
+5. Boot the SER5 from the flashed stick (firmware boot-order menu as needed — Secure Boot
+   already disabled, confirmed above, so no signing prompt expected).
+6. **Code audit pass** (can happen before or in parallel with 1–5, doesn't need the hardware
+   in hand): review the amd64 boot path (`src/starkernel/boot/uefi_loader.c`,
+   `arch/amd64/*.c`) for anything that assumes SER5-specific hardware rather than standard
+   UEFI/ACPI — this is what "genericity" actually rests on per the decision above, not the
+   SER5 boot succeeding alone.
+7. Capture the boot: confirm POST reaches the same `1012/0/0` result QEMU shows, confirm
+   `ok>`/`zuse)ok>`, confirm `rng: backend = rdrand` (live entropy, not the QEMU-only
+   `virtio-rng` path), save the serial transcript (if wired) the same way `logs/` already
+   keeps QEMU's.
+8. Mint a Zuse identity on a second thumbdrive on the real SER5, confirm it re-attaches —
+   the same real-hardware round-trip `ROADMAP.md`'s `v2.2.0` gate already names.
+9. Update this section with results — pass/fail per step, any SER5-specific or genuinely
+   generic-UEFI finding either way, before moving to aarch64.
 
 ## IV. aarch64 — Raspberry Pi 5