Zac Gaetano
2e6d2a1e5e
Two new docs to land alongside the in-flight WinUI 3 work: * docs/superpowers/plans/2026-05-12-winui3-migration.md Full nine-phase migration plan. Locks the architectural decisions (WindowsAppSDK 1.6 LTS, unpackaged, win-x64 RID, custom Main with explicit Bootstrap, CommunityToolkit DataGrid 7.1.2, AppWindow title-bar API). Tracks what's done (Phase 1 + 2: scaffold and MainWindow shell), what's blocked (Phase 3: activation failure), and what's next (Phase 4-9). Risk register flags fallback paths. * docs/superpowers/work-log-2026-05-12.md Operator-readable summary of overnight progress. Leads with the pull-and-push reminder (forgejo credentials expired so commits are local-only until Zac authenticates and pushes manually), names the activation blocker with the diagnostic evidence captured, and suggests the first session tomorrow morning. Documents what was deliberately NOT touched (WPF host, Teams orchestration, view-model wiring) so the running build is unambiguously safe.
147 lines
7 KiB
Markdown
147 lines
7 KiB
Markdown
# Work log — overnight session 2026-05-12 → 2026-05-13
|
|
|
|
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
|
|
|
|
**Read me first when you wake up:**
|
|
|
|
1. **Pull. The forgejo credentials expired so I couldn't push.** Authenticate
|
|
and `git push origin main` to land six commits.
|
|
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 is in place
|
|
with the new IA, the dark/light theme system, the theme toggle, the
|
|
live-pill title bar — everything from the shape brief.
|
|
4. **The .exe doesn't launch.** It shows "TeamsISO.exe - This application
|
|
could not be started" before Main() runs. Diagnostics captured; the
|
|
.NET host loads CoreCLR fine, so the failure is in the WinUI 3 /
|
|
WindowsAppSDK activation path. Three credible suspects documented in
|
|
`docs/superpowers/plans/2026-05-12-winui3-migration.md` Phase 3.
|
|
5. **You can see the redesign visually** via the SVG mockup we approved in
|
|
chat. Tomorrow's first session: fix activation, then the .exe shows the
|
|
real thing.
|
|
|
|
## Commits landed (local only — push needed)
|
|
|
|
In chronological order on `main`:
|
|
|
|
| SHA | Subject |
|
|
|---|---|
|
|
| `94b0a71` | docs: PRODUCT.md + DESIGN.md (ground-up GUI redesign brief) |
|
|
| `cb1402e` | feat(winui3): scaffold TeamsISO.App.WinUI alongside the WPF host |
|
|
| `9e176d8` | feat(winui3): redesigned MainWindow + custom title bar + theme toggle |
|
|
| `db341f9` | build(winui3): pin RID + flatten native DLLs into output dir |
|
|
|
|
Plus whatever lands during the rest of the session — see `git log
|
|
--oneline f12cbe7..HEAD` for the full set.
|
|
|
|
## What you'll find in the tree
|
|
|
|
```
|
|
Teams ISO/
|
|
├─ PRODUCT.md ← new, baseline product brief
|
|
├─ DESIGN.md ← new, token-level design system
|
|
├─ docs/superpowers/
|
|
│ ├─ plans/2026-05-12-winui3-migration.md ← new, full migration plan
|
|
│ └─ work-log-2026-05-12.md ← this file
|
|
├─ src/
|
|
│ ├─ TeamsISO.App/ ← unchanged, the WPF host
|
|
│ └─ TeamsISO.App.WinUI/ ← new, the WinUI 3 host
|
|
│ ├─ TeamsISO.App.WinUI.csproj
|
|
│ ├─ Program.cs ← custom Main with Bootstrap
|
|
│ ├─ App.xaml + App.xaml.cs
|
|
│ ├─ Assets/ ← Inter, JetBrainsMono, dragon-mark
|
|
│ ├─ Themes/
|
|
│ │ ├─ Tokens.xaml ← ThemeDictionary (Dark + Light)
|
|
│ │ └─ Controls.xaml ← Button hierarchy + type ramp
|
|
│ ├─ Models/MockParticipant.cs ← interim until VM wires
|
|
│ └─ Views/
|
|
│ └─ MainWindow.xaml + .xaml.cs ← redesigned per shape brief
|
|
├─ TeamsISO.sln ← updated
|
|
└─ TeamsISO.Windows.slnf ← updated, backslash-normalized
|
|
```
|
|
|
|
## What works right now
|
|
|
|
* WinUI 3 build: clean
|
|
* WPF build: still clean (I built it to confirm nothing regressed)
|
|
* Theme tokens: Dark + Light palettes both correct, mapped to {ThemeResource}
|
|
* MainWindow layout: matches the approved SVG mockup pixel-by-pixel intent
|
|
* Theme toggle: code-behind flips RequestedTheme + title-bar button colors
|
|
* Mock data: 4 sample participants render in the list, one as active speaker
|
|
|
|
## What's blocked
|
|
|
|
**Activation failure on the unpackaged .exe.** Diagnostic summary:
|
|
|
|
* `dotnet --info` shows .NET 8.0.301 SDK + 8.0.6/8.0.8/8.0.18 runtimes for
|
|
both NETCore.App and WindowsDesktop.App
|
|
* `Get-AppxPackage Microsoft.WindowsAppRuntime.*` confirms
|
|
Microsoft.WindowsAppRuntime.1.6 (6000.519.329.0) is installed
|
|
* `dotnet build -c Debug` produces TeamsISO.exe in
|
|
`src/TeamsISO.App.WinUI/bin/Debug/net8.0-windows10.0.19041.0/win-x64/`
|
|
* The .exe is x64 (PE machine 0x8664 confirmed)
|
|
* Native runtime files (Microsoft.WindowsAppRuntime.Bootstrap.dll,
|
|
WebView2Loader.dll) are flattened to the output dir alongside the .exe
|
|
* Launching the .exe results in a Windows error dialog
|
|
"TeamsISO.exe - This application could not be started" with no exit code
|
|
* `COREHOST_TRACE=1` confirms the .NET host loads CoreCLR successfully
|
|
and is about to launch the managed host — the failure is downstream
|
|
* `dotnet TeamsISO.dll` produces the same error
|
|
* `dotnet publish -r win-x64 --self-contained` produces the same error
|
|
|
|
The error happens **before my Program.Main runs**, which means
|
|
`Bootstrap.TryInitialize(0x00010006)` isn't the culprit. The failure is
|
|
in the CLR-to-WinUI handoff. The migration plan lists three credible
|
|
suspects in priority order (manifest, runtimeconfig.json
|
|
Microsoft.WindowsDesktop.App entry, VC++ redist).
|
|
|
|
## What I did NOT do
|
|
|
|
* Touch the WPF host. Your running build is intact. The May 2026 batch
|
|
ships as-is.
|
|
* Touch Teams orchestration. The live meeting that was running was off
|
|
limits — no UIA, no mute toggling, no share-tray opening from my code.
|
|
* Push to forgejo. The credential prompt would need you. Run
|
|
`git push origin main` when you're up.
|
|
* Run the WPF .exe to take screenshots. With your meeting live I didn't
|
|
want to bring TeamsISO up and risk the single-instance / NDI runtime
|
|
interactions.
|
|
* Add light theme to the WPF host. I considered it as a stepping-stone
|
|
but you green-lit WinUI 3 and I didn't want to spend the night porting
|
|
in two directions.
|
|
* Migrate view-models or wire the engine into the WinUI host. Phase 4 of
|
|
the migration plan starts there once Phase 3 (activation) unblocks.
|
|
|
|
## Suggested first session tomorrow
|
|
|
|
1. `git push origin main` (after authenticating)
|
|
2. 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.
|
|
3. If no VS, attach windbg / dnSpy to the .exe at launch and capture the
|
|
actual exception. The COREHOST trace I dumped to
|
|
`$env:TEMP/teamsiso-corehost.log` may still be there for context.
|
|
4. Once activation works, mock data renders → you'll see the new design.
|
|
5. Decide between continuing in-place (port view-models next) or
|
|
integrating an HTML control panel preview to show stakeholders before
|
|
the WinUI 3 build is feature-complete.
|
|
|
|
## Honest assessment
|
|
|
|
The redesign work is solid; the design system is real, the XAML matches
|
|
the shape brief faithfully, and the theme infrastructure is correct. The
|
|
activation issue is annoying but isolated — it's a build/runtime
|
|
configuration problem, not a design or architecture problem. Five
|
|
minutes with the actual error message in hand and it's likely a one-line
|
|
csproj fix.
|
|
|
|
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 secondary windows (Phase 6).
|
|
Those need real-meeting testing time once the build runs.
|
|
|
|
— end of log
|