diff --git a/TODO.md b/TODO.md
index 229f89b..828e3e9 100644
--- a/TODO.md
+++ b/TODO.md
@@ -300,17 +300,29 @@ each confirmed live against the real VM, not just read off a diff:
         not `build_windows.sh`'s real default) fails `candle.exe` with
         CNDL0108/CNDL0010. Not a real bug, just don't pass a version with
         a suffix.
-  - [ ] `light.exe` (final MSI linking) did not finish within 15 minutes
-        on this VM (4 CPU / 8GB RAM) before the RAM-conscious auto-
-        shutdown killed it -- process was genuinely active (343MB
-        working set, not hung on a dialog), just slow, likely from the
-        ~1GB+ bulk-copied mingw64 runtime (see README's own "dist tree is
-        fat, not lean" note) combined with this VM's disk/CPU being
-        shared with the host. Needs either a longer timeout on a retry,
-        or the dist-tree-trimming work the README already flags as a
-        known follow-up (tracing the real DLL/typelib closure instead of
-        bulk-copying all of mingw64) to make `light.exe` have less to
-        compress in the first place.
+  - [x] `light.exe` (final MSI linking) did not finish within 15 minutes
+        on a first retry (4 CPU / 8GB RAM VM) before the RAM-conscious
+        auto-shutdown killed it -- turned out to be genuinely just slow
+        (process was active, 343MB working set, not hung on a dialog),
+        not a real bug: retried with a 40-minute budget and it finished
+        `light.exe` itself in a few more minutes.
+  - [ ] ...and then failed for a REAL reason right at the very end:
+        `light.exe`'s ICE80 validation rejected essentially every
+        harvested file -- "This 32BitComponent ... uses 64BitDirectory".
+        `heat.exe`'s harvest command had no `-platform x64`, so every
+        component it generated defaulted to 32-bit, while
+        `product.wxs`'s own `INSTALLFOLDER` is correctly under
+        `ProgramFiles64Folder` (a 64-bit mingw64 toolchain is what's
+        actually being packaged) -- a real, on-disk mismatch, not a
+        transient VM issue. Fixed: added `-platform x64` to `build.bat`'s
+        `heat.exe` invocation. NOT YET re-verified against a live build
+        (found right as this session's VM time/cycles were already
+        heavily spent -- next run should get all the way to a real
+        `.msi`, but that's still a claim, not yet a confirmed result).
+        Once confirmed, revisit the still-slow `light.exe` step itself
+        (the ~1GB+ bulk-copied mingw64 dist tree, see README's own "not
+        lean" note) as a separate, real perf follow-up -- 40 minutes for
+        one MSI link is a lot, even once it stops failing outright.
 
 ## OCR: new fire-support-request grammar gaps (from real user-pasted messages)
 
diff --git a/packaging/windows/oem/build.bat b/packaging/windows/oem/build.bat
index ce0c1c9..262e957 100644
--- a/packaging/windows/oem/build.bat
+++ b/packaging/windows/oem/build.bat
@@ -49,7 +49,12 @@ REM here (see this file's top-of-file note).
 robocopy C:\msys64\mingw64 C:\build\dist\mingw64 /e /xd include share\doc share\man share\gtk-doc /nfl /ndl /njh /njs >> %LOG% 2>&1
 
 echo [build.bat] harvesting WiX components ... >> %LOG%
-C:\wix\heat.exe dir C:\build\dist -cg AppFiles -gg -scom -sreg -sfrag -srd -sw5150 -dr INSTALLFOLDER -var var.DistDir -out C:\build\files.wxs >> %LOG% 2>&1
+REM -platform x64: confirmed live (real light.exe run, not guessed) --
+REM without it heat.exe defaults every harvested component to 32-bit,
+REM which light.exe's ICE80 validation then rejects wholesale (~every
+REM single harvested file) once it's placed under INSTALLFOLDER, a
+REM 64-bit directory (this is a 64-bit mingw64 toolchain being packaged).
+C:\wix\heat.exe dir C:\build\dist -platform x64 -cg AppFiles -gg -scom -sreg -sfrag -srd -sw5150 -dr INSTALLFOLDER -var var.DistDir -out C:\build\files.wxs >> %LOG% 2>&1
 if errorlevel 1 (
   echo [build.bat] FAILED: heat.exe harvest failed >> %LOG%
   copy %LOG% Z:\build.log.failed >nul