diff --git a/apps/kubevirt-vms/ci1.yaml b/apps/kubevirt-vms/ci1.yaml
index 7058f72..3f9e459 100644
--- a/apps/kubevirt-vms/ci1.yaml
+++ b/apps/kubevirt-vms/ci1.yaml
@@ -411,24 +411,22 @@ spec:
             # Confirmed via debug pod: PVC content IS a real bootable ISO9660
             # (file: "ISO 9660 CD-ROM filesystem data ... (bootable)"), so the
             # only bug was boot priority.
-            # 2026-05-08 PM: ISO presented as a virtio-blk DISK (not cdrom).
-            # Both SATA and SCSI cdrom buses hit OVMF BdsDxe "starting Boot0001
-            # ... Time out" regardless of storage backend (NFS, Longhorn PVC,
-            # containerDisk tmpfs — all rule out IO speed). The qemu cdrom
-            # emulation path appears to have a deep-seated read window issue
-            # under KubeVirt v1.4.0's OVMF firmware.
-            #
-            # Workaround: present the ISO bytes as a regular virtio-blk disk
-            # (model="virtio-non-transitional"). UEFI/OVMF still recognizes
-            # ISO9660 + El Torito boot records on a regular disk, so it can
-            # boot the EFI bootloader the same way it would from a USB stick.
-            # This is also closer to the FlowerCore.Distribution USB-key
-            # pattern: the ISO bytes live on a block device, UEFI boots from
-            # the GPT/El Torito boot record, Windows installer runs.
+            # 2026-05-08 PM: cdrom bus SCSI + containerDisk delivery. This
+            # combination boots qemu cleanly and reaches OVMF, but OVMF
+            # BdsDxe still hits "starting Boot0001 ... Time out" on the
+            # cdrom — see HANDOFF.md / CODEX-STATUS.md "OPEN — ci1" for the
+            # full diagnostic chain. virtio-blk disk swap was attempted as a
+            # workaround but introduced a separate QEMU rootdisk flock issue
+            # without fixing the underlying OVMF cdrom problem; reverted.
+            # Operator decision needed for next architectural step (OVMF
+            # custom build with extended timeout, KubeVirt version bump,
+            # Hyper-V/VirtualBox-and-export, or BIOS legacy boot). The
+            # containerDisk distribution pipeline (build/save/scp/ctr import)
+            # is proven and ready to reuse for any of those.
             - name: windows-iso
               bootOrder: 1
-              disk:
-                bus: virtio
+              cdrom:
+                bus: scsi
             - name: rootdisk
               bootOrder: 2
               disk: