diff --git a/TODO.md b/TODO.md
index 828e3e9..ae3e737 100644
--- a/TODO.md
+++ b/TODO.md
@@ -309,16 +309,26 @@ each confirmed live against the real VM, not just read off a diff:
   - [ ] ...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).
+        actually being packaged), but nothing was making the components
+        agree -- a real, on-disk mismatch, not a transient VM issue.
+        First fix attempt (`-platform x64` on `heat.exe`'s harvest) was
+        WRONG -- re-verified live, identical ICE80 failures afterward
+        (confirmed the corrected `build.bat` had actually reached the VM
+        this time, ruling out a stale-copy repeat of the earlier watcher
+        bug). WiX v3's `heat.exe -platform` only affects registry-key
+        harvesting, it never stamps `Win64="yes"` on components. Real
+        fix: `-arch x64` on `candle.exe` (the COMPILE step, not the
+        harvest step) -- sets the default Win64/Platform for every
+        component compiled from either source file, hand-authored
+        (`product.wxs`) or harvested (`files.wxs`) alike, the standard
+        WiX v3 way to make a whole package consistently 64-bit. Kept the
+        harmless-but-insufficient `-platform x64` on `heat.exe` too.
+        Applied, NOT YET re-verified live (this session's VM time is
+        long since past reasonable for one sitting -- next run should
+        confirm a real `.msi`, but treat that as still unconfirmed until
+        it actually happens).
         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
diff --git a/packaging/windows/oem/build.bat b/packaging/windows/oem/build.bat
index 262e957..6725726 100644
--- a/packaging/windows/oem/build.bat
+++ b/packaging/windows/oem/build.bat
@@ -49,11 +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%
-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).
+REM -platform x64 alone is NOT enough (confirmed live: still every
+REM component ICE80'd afterward) -- WiX v3 heat.exe's -platform flag
+REM doesn't actually stamp Win64="yes" on harvested components itself,
+REM it only affects registry-key harvesting. Kept anyway (harmless,
+REM correct in spirit), but the real fix is candle.exe's -arch x64
+REM below, see its own comment.
 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%
@@ -65,7 +66,15 @@ if errorlevel 1 (
 copy /y C:\FenigmaBuild\product.wxs C:\build\product.wxs >nul
 
 echo [build.bat] compiling (candle) ... >> %LOG%
-C:\wix\candle.exe -dDistDir=C:\build\dist -dAppVersion=%APPVER% -out C:\build\ C:\build\product.wxs C:\build\files.wxs >> %LOG% 2>&1
+REM -arch x64: the actual fix for the ICE80 "32BitComponent uses
+REM 64BitDirectory" failure (confirmed live -- heat.exe's own -platform
+REM x64 above does NOT set this, only affects registry harvesting).
+REM -arch sets the default Win64/Platform for every component compiled
+REM from EITHER source file, hand-authored (product.wxs) or harvested
+REM (files.wxs) alike, without needing per-component authoring -- the
+REM standard WiX v3 way to make a whole package consistently 64-bit,
+REM matching product.wxs's own ProgramFiles64Folder.
+C:\wix\candle.exe -arch x64 -dDistDir=C:\build\dist -dAppVersion=%APPVER% -out C:\build\ C:\build\product.wxs C:\build\files.wxs >> %LOG% 2>&1
 if errorlevel 1 (
   echo [build.bat] FAILED: candle.exe failed >> %LOG%
   copy %LOG% Z:\build.log.failed >nul