diff --git a/docs/superpowers/work-log-2026-05-12.md b/docs/superpowers/work-log-2026-05-12.md index 59138c1..10e0823 100644 --- a/docs/superpowers/work-log-2026-05-12.md +++ b/docs/superpowers/work-log-2026-05-12.md @@ -4,31 +4,50 @@ The redesign brief was approved with one edit (add dark + light theming), the WinUI 3 replatform was green-lit explicitly, and you said don't stop until told to. This log is what happened. -## TL;DR +## TL;DR — overnight result -**Read me first when you wake up:** +**The WinUI 3 redesigned host runs.** It launches, renders, and respects +dark / light theme. See `docs/preview/winui3-mainwindow-light.png` and +`docs/preview/winui3-mainwindow-dark.png` for proof shots captured from +the live .exe. -1. **Twelve commits landed on origin/main** (`94b0a71` through `6b45c39`). - `git fetch` if you want to see them; they're already pushed. Credentials - refreshed at some point so the push worked. -2. **The WPF host (the running build) is fine.** I didn't touch it. Your - May 2026 batch still works exactly as it did. -3. **The new WinUI 3 project builds clean** (`dotnet build TeamsISO.Windows.slnf - -c Debug` → 0 warnings, 0 errors). The redesigned MainWindow, ThemeManager, - Settings drawer (with slide-in animation), Help/About/Onboarding dialogs, - theme toggle in the title bar — all in place. -4. **The .exe still doesn't activate.** It shows "TeamsISO.exe - This - application could not be started" before Main() runs. I tried five - things; details in the migration plan's Phase 3 section. The .NET host - loads CoreCLR fine, so the failure is in the WinUI 3 / WindowsAppSDK - activation path. Strong candidate: the assembly references something - that fails during managed-assembly load before any user code runs. -5. **You can see the redesign visually NOW** via the interactive HTML - preview I built: open - `docs/preview/redesigned-mainwindow.html` in any browser. Theme toggle - works, settings drawer slides in from the right when you click the gear - icon or the banner "Open settings" button, accent peek in the - Appearance tab shows both palette modes. Faithful to the WinUI 3 XAML. +**Eighteen commits landed on origin/main.** Already pushed (credentials +refreshed during the session). + +**The WPF host is untouched.** Your May 2026 batch still works exactly +as it did — the WinUI 3 host is a parallel project at +`src/TeamsISO.App.WinUI/`. + +**Two activation blockers — both diagnosed:** + +1. WindowsAppSDK 1.6 DDLM wasn't installed on this machine + (Get-AppxPackage shows Main.1.5 and Main.1.8 but no Main.1.6). Bootstrap + returned `MDD_E_BOOTSTRAP_INITIALIZE_DDLM_NOT_FOUND` (HR 0x80670016). + **Fix:** switched to WindowsAppSDK 1.8 — its DDLM is present. +2. The SettingsDrawer's RenderTransform + named Storyboard binding + triggered a XAML parser fault (HR 0x802b000a) post-bootstrap. + **Fix:** stubbed the drawer host inline; the drawer XAML itself is + intact for re-hosting in Phase 4 once the right transform pattern is + confirmed (likely `Translation` via composition API instead of + `TranslateTransform` via Storyboard). + +**What I left in mostly-ready state:** + +* `src/TeamsISO.App.WinUI/Views/MainWindow.xaml` — redesigned IA, runs. + Participants list is a stub message until view-model wires up + (Phase 4 of the migration plan). +* `src/TeamsISO.App.WinUI/Views/SettingsDrawer.xaml` + .cs — builds + clean; not hosted yet. +* `src/TeamsISO.App.WinUI/Views/HelpDialog.xaml`, AboutDialog, + OnboardingDialog — built clean; nothing in MainWindow opens them yet. +* `src/TeamsISO.App.WinUI/Services/ThemeManager.cs` — System / Dark / + Light tri-state with OS app-mode auto-follow and Themed event so the + title-bar buttons stay in sync. +* `src/TeamsISO.App.WinUI.Probe/` — diagnostic console for activation + triage. Run if a deployment target ever shows the same activation + dialog. +* `docs/preview/redesigned-mainwindow.html` — interactive HTML preview + for non-Windows stakeholders. ## Commit list @@ -48,8 +67,14 @@ In chronological order on `main`: | `2f9f709` | build(winui3): post-build target to strip WindowsDesktop.App from runtimeconfig | | `46b1ca5` | fix(preview): clip drawer behind .content with position:relative+overflow:hidden | | `6b45c39` | fix(preview): drawer uses display:none + animation when opened | +| `19072b4` | docs(work-log): refresh with complete commit list + push confirmation | +| `1687e0c` | docs: CHANGELOG + README cover the in-flight WinUI 3 redesign | +| `166e7d6` | build(winui3): switch to WindowsAppSDK 1.8 + add diagnostic probe | +| `07f4a1b` | docs(work-log): add root-cause finding for activation blocker | +| `a33f80d` | feat(winui3): WinUI 3 host LAUNCHES — verified rendering on Windows | +| `eee307d` | docs(preview): proof-of-running WinUI 3 screenshots (dark + light) | -Plus whatever lands after this log is updated. +All eighteen pushed to origin/main. ## What you'll find in the tree @@ -182,29 +207,52 @@ To reproduce the diagnosis from scratch: ## Suggested first session tomorrow -1. **Look at the preview first**: open - `docs/preview/redesigned-mainwindow.html` and toggle dark/light. If - you're happy with the design, the rest is execution. -2. **Diagnose the activation blocker**: see "What's blocked" above. The - most likely path forward is reinstalling/upgrading the WindowsAppRuntime - 1.6 redistributable or moving to packaged mode. -3. Once activation works: Phase 4 (view-model wiring) → Phase 5 (DataGrid) - → Phase 6 (remaining secondary windows) → Phase 7 (hardening: single - instance, crash, tray, REST/OSC) → Phase 8 (tests + real-meeting - verification) → Phase 9 (retire WPF host). +1. **Look at the screenshots**: `docs/preview/winui3-mainwindow-light.png` + and `docs/preview/winui3-mainwindow-dark.png` — proof shots of the + live .exe. If the design is right, the rest is execution. +2. **Run it yourself**: from a fresh shell, + `dotnet build src/TeamsISO.App.WinUI` then run the .exe at + `src/TeamsISO.App.WinUI/bin/Debug/net8.0-windows10.0.19041.0/win-x64/TeamsISO.exe`. + The redesigned shell should appear at 1280×780. +3. **Then Phase 4** (view-model wiring): the existing `MainViewModel`, + `ParticipantViewModel`, etc. in `src/TeamsISO.App/ViewModels/` use + WPF's `System.Windows.Threading.Dispatcher`. Either substitute with + `DispatcherQueue` in-place (probably the right move long-term), or + add a thin `IDispatcherAdapter` interface so both hosts share the + view models verbatim. +4. **Phase 5** (DataGrid): swap the stub message in the MainWindow + content area for `CommunityToolkit.WinUI.UI.Controls.DataGrid` + bound to `MainViewModel.Participants`. The DataTemplate from the + git history (the version in commit `9e176d8`) has the active-speaker + accent + audio meter + signal lock visuals — restore those. +5. **Phase 6 cont** (re-host SettingsDrawer): the drawer XAML builds + clean; what crashes is using `RenderTransform` + named + `TranslateTransform` + Storyboard.TargetName binding. Try + `Translation` via `ElementCompositionPreview.GetElementVisual` or + use the `XamlIslands` translation animation pattern instead. +6. **Phase 7** (hardening): port single-instance mutex, crash dialog, + REST + OSC + tray icon from the WPF App.xaml.cs. ## Honest assessment -The design work is done. The system tokens are real, the XAML matches the -shape brief faithfully, the theme infrastructure is correct and tested via -the HTML preview, the secondary surfaces (Help / About / Onboarding / -Settings drawer) all build cleanly. The activation issue is annoying but -isolated — it's a build/runtime configuration problem, not a design or -architecture problem. +The redesign is real, on-disk, building cleanly, AND RUNNING. The +WinUI 3 host opens at 1280×780, paints the new IA correctly, respects +the theme system end-to-end, and is sitting on `main` waiting for the +view-model wiring. The diagnostic probe (`TeamsISO.App.WinUI.Probe`) is +a permanent addition that'll pay back the next time anyone hits a +WindowsAppSDK activation issue on a different machine. -The biggest risk to the v1.0 timeline isn't tonight's work; it's the -WinUI 3 view-model wiring (Phase 4) and the engine-side regressions that -might surface during the binding migration. Those need real-meeting -testing time once the build runs. +What still needs real work: Phase 4 (view-model wiring — the +engine's `Dispatcher` use needs to flex to `DispatcherQueue`), Phase 5 +(real DataGrid), Phase 6 cont (re-host SettingsDrawer with the right +transform pattern), Phase 7 (hardening: single instance, crash, REST, +OSC, tray). None of these are blocked anymore — they're all execution +work. + +The biggest risk to the v1.0 timeline is the same as it was yesterday: +real-meeting smoke test against a live Teams call. That's the +gate that determines whether the WPF host retires or stays as a +fallback for a release or two. — end of log +— Claude, 2026-05-13 ~12:45am