diff --git a/FABRIC-3.md b/FABRIC-3.md
index 78ec99a..d0db8fa 100644
--- a/FABRIC-3.md
+++ b/FABRIC-3.md
@@ -3429,6 +3429,27 @@ silicon — the thing v2.0.0 cannot honestly claim.
   and its G.4 RNG backend returns non-deterministic bytes live. v2.5.0 does not close on any
   board's G.4/G.x item being build-only.
 
+#### G.6 [v2.0.1] Generic UEFI-bootable thumbdrive image (SER5 path — **BUILT + VERIFIED 2026-08-29**)
+
+First concrete v2.0.1/SER5 work item, taken up because the Beelink SER5 is in hand and a
+"generic thumbdrive bootable OS" is the target. The new `make -f Makefile.starkernel
+thumbdrive` goal builds a generic GPT/FAT32 disk image (one "STARKERNEL" EFI System
+partition with `EFI/BOOT/BOOT<ARCH>.EFI` + `startup.nsh`) writable to a USB stick with
+`dd` and bootable on any real amd64 UEFI firmware as well as under QEMU. The monolithic
+loader embeds the entire kernel, so the ESP needs only the UEFI fallback boot path —
+this is what makes the image "as generic as possible."
+
+- **Verified** by attaching the image to QEMU as a **USB mass-storage device** (not cdrom):
+  OVMF BDS auto-selected `Boot0002 "UEFI QEMU QEMU USB HARDDRIVE"`, then the kernel booted
+  normally — v2.0.0 banner, POST `1012/0/0` + `ok>`, `rng: backend = virtio-rng` +
+  `entropy: ready`, Artemis ready, and the USB BOT/xHCI storage path enumerated
+  (READ CAPACITY10 → MSC device ready → READ10 CSW PASS). This mirrors the real SER5 flow:
+  firmware boots the thumbdrive's ESP, and the OS's own storage rides the same USB BOT/xHCI
+  path. Works for all three arches via the arch-mapped EFI boot name.
+- **Next (v2.0.1):** G.4 requires real entropy on the SER5 — amd64 **RDRAND** backend behind
+  `rng_get_bytes()` (QEMU-verifiable: `qemu64` exposes RDRAND), then flashing this image to
+  a physical stick and the G.5 real-board boot attempt.
+
 ---
 
 ### Post-release tracking (not gating either milestone)