diff --git a/docs/superpowers/work-log-2026-05-12.md b/docs/superpowers/work-log-2026-05-12.md
index deb59b4..59138c1 100644
--- a/docs/superpowers/work-log-2026-05-12.md
+++ b/docs/superpowers/work-log-2026-05-12.md
@@ -122,18 +122,47 @@ Teams ISO/
 * The UndockedRegFreeWinRT auto-init ModuleInitializer was disabled —
   still fails
 
-**Top suspect**: the managed assembly's static dependencies include
-`Microsoft.WinUI.dll` which itself has DllImport-style native dependencies
-that the .NET host probes during managed-assembly load. Without the
-WindowsAppRuntime's COM activation context registered first, those imports
-fail and the loader aborts before Main runs.
+**ROOT CAUSE IDENTIFIED (post-log-update):**
 
-**Recommended first action when you're up**: open the WinUI project in
-Visual Studio if you have it installed; the F5 launch path will show the
-actual activation error in a way the command-line launch doesn't. If no
-VS, try installing the `Microsoft.WindowsAppRuntime.1.6` redistributable
-explicitly (the AppxPackage version installed might not include the
-desktop runtime needed for unpackaged apps).
+I built a tiny diagnostic console probe
+(`src/TeamsISO.App.WinUI.Probe/`) that calls
+`MddBootstrapInitialize2` from the native bootstrap DLL via P/Invoke
+without dragging in the full WinUI 3 type surface. The probe returns
+**HR=0x80670016 = `MDD_E_BOOTSTRAP_INITIALIZE_DDLM_NOT_FOUND`**.
+
+Translation: the framework package (Microsoft.WindowsAppRuntime.1.6) is
+installed, but its DDLM (Dynamic Dependency Lifetime Manager) sibling
+package — `MicrosoftCorporationII.WinAppRuntime.Main.1.6` — is NOT.
+Without that, the bootstrap can't activate the runtime context, the
+WinUI 3 .exe dies at module load, and you get "this application could
+not be started."
+
+Looking at `Get-AppxPackage`, this machine has Main.1.5 (5001.373) and
+Main.1.8 (8000.836) installed, but NO Main.1.6.
+
+**Three fixes, pick one:**
+
+1. **Install the 1.6 DDLM** redistributable. Download
+   `Microsoft.WindowsAppRuntime.1.6` from
+   https://aka.ms/windowsappsdk/1.6/latest/windowsappruntimeinstall-x64.exe
+   and run it. After it installs, `Get-AppxPackage MicrosoftCorporationII.WinAppRuntime.Main.1.6`
+   should return a row.
+2. **Switch the .csproj to WindowsAppSDK 1.8** (the package version
+   would be `Microsoft.WindowsAppSDK` 1.8.260508005, and the major.minor
+   in `Program.cs` becomes `0x00010008`). 1.8 IS fully installed on
+   this machine.
+3. **Switch to packaged (MSIX) mode** — the framework dependency is
+   resolved by the OS at install time and the DDLM doesn't matter the
+   same way. Means giving up the existing MSI installer path for now.
+
+Option 2 is the fastest. Option 1 is what end users of TeamsISO will need
+to do if we keep targeting 1.6 LTS.
+
+To reproduce the diagnosis from scratch:
+
+    cd src/TeamsISO.App.WinUI.Probe
+    dotnet build
+    dotnet bin/Debug/net8.0-windows/win-x64/TeamsISO.App.WinUI.Probe.dll
 
 ## What I did NOT do