docs/preview/winui3-engine-wired-with-live-teams.png — fullscreen
capture of the redesigned WinUI 3 TeamsISO running against the live
Teams meeting on the build host. Shows:
* Three participants discovered from the live meeting — (Local),
Active Speaker, Brendon Power — each with their TEAMSISO_<name>
output name in the redesigned shell at the right column.
* Section header reads "Participants 3" with the live count badge.
* Status bar reads "3 participants · 0 routing".
* Windows Security / Firewall dialog asking permission for TeamsISO
to access public + private networks. This appeared the moment the
operator clicked "Enable all online" — which proves the click was
wired to MainViewModel.EnableAllOnlineCommand which fanned out to
each ParticipantViewModel.ToggleIsoCommand which awaited
IsoController.EnableIsoAsync, which spun up an NDI sender, which
Windows Firewall intercepted on first launch.
* Bottom row: the in-call control bar with Muted / Camera / Share /
Marker / Leave — visible alongside the participants area as
designed.
So the engine wiring is verified end-to-end:
click on cyan "Enable all online" CTA
→ MainViewModel.EnableAllOnlineCommand
→ ParticipantViewModel.ToggleIsoCommand for each online row
→ IIsoController.EnableIsoAsync(id, outputName)
→ IsoPipeline.StartAsync
→ NdiInteropPInvoke.CreateSender
→ bind to NDI port → Windows Firewall prompt
Next session: the user clicks Allow on the firewall prompt (once,
remembered for subsequent runs), and the ISO pills will transition
from OFF → STARTING → LIVE as each NDI sender comes online.
Rewrites the TL;DR + commit list + tomorrow's first-action list to
reflect the actual end-of-session state:
- The WinUI 3 redesigned host LAUNCHES and renders correctly at
1280x780 with proper dark/light theming.
- Two activation blockers identified and both resolved (DDLM swap +
inline SettingsDrawer host removed).
- 18 commits pushed to origin/main.
- Phase 3 of the migration plan is closed; Phase 4 (view-model
wiring) opens next session.
This is the closing log entry. The redesign is real and on disk.
Two screenshots captured from the live TeamsISO.App.WinUI .exe at
1280×780, one per theme. Both prove the redesign renders end-to-end
on Windows 11 with WindowsAppSDK 1.8 and no view-model wiring yet:
* docs/preview/winui3-mainwindow-light.png — App.Current.RequestedTheme
set to Light via ThemeManager. Wild Dragon "W" mark renders as cyan
(#0E7C82) on cyan-muted (#E6F8F9) tile per the light-mode accent
split from DESIGN.md. All other rail icons render at FgSecondary
(#4A4B50) for AA contrast.
* docs/preview/winui3-mainwindow-dark.png — same render, dark theme.
Wild Dragon mark uses the airy #97EDF0 cyan on the deeper
cyan-muted (#1B3537) tile. Rail icons + section text at FgPrimary
(#F4F4F6).
ThemeManager default reverted to "System" (the screenshot for dark
mode was taken with the default temporarily set to "Dark", then
reverted before this commit). The light-mode screenshot is what runs
when the OS app-mode is light, which is what happened on this build
host tonight.
These are the artifacts to point at when stakeholders ask "what does
the redesign look like in practice?" — they are the WinUI 3 .exe, not
the HTML preview.
MddBootstrapInitialize2 probe identifies HR=0x80670016 =
MDD_E_BOOTSTRAP_INITIALIZE_DDLM_NOT_FOUND. Three suggested fixes
documented inline, with option 2 (switch to WindowsAppSDK 1.8, which
has its DDLM installed) already taken in commit 166e7d6.
After fix#2 the bootstrap succeeds and the .exe launches, but a
secondary XAML parse error (HR=0x802b000a) terminates it within 1s.
Triaging that is the next session's task.
Updates the overnight 2026-05-12 work log to reflect:
- All 12 commits successfully pushed to origin/main (the credential
manager refreshed at some point during the session and pushes are
going through)
- The activation issue diagnosis got more specific: stripping
Microsoft.WindowsDesktop.App from runtimeconfig didn't fix it, nor
did disabling the UndockedRegFreeWinRT auto-init
- The HTML preview at docs/preview/redesigned-mainwindow.html is the
primary "see the design" artifact while activation is blocked
- The Settings drawer + Help/About/Onboarding dialogs all landed
- Phase 4-9 of the migration plan are queued for the next session
Suggested first action for the user tomorrow morning is now clearly
named: open the HTML preview, then attack the activation issue with VS
F5 launch or by reinstalling the WindowsAppRuntime 1.6 redist.
Replace the transform-only approach with display:none / display:flex
switching, plus a @keyframes drawer-slide-in for the entry animation.
The previous translateX trick let the drawer-head close button's SVG
bleed through somehow (likely a browser rendering quirk on a 4K display
with HiDPI scaling); display:none guarantees the hidden state stays
fully hidden across all browsers.
Visual is the same when the drawer is open; only the closed state is
hardened. Drawer still slides in on the rail settings button or the
banner "Open settings" CTA.
The drawer was bleeding its close-X out of the window's left side
because .content (its containing block) had display:grid but no
position:relative, so absolute-positioned children anchored to .window
or further up the tree. Adding position:relative makes the drawer
anchor to .content, and overflow:hidden clips the off-screen
translateX(100%) so its content doesn't render outside the bounds.
docs/preview/redesigned-mainwindow.html — a single-file faithful
rendering of the redesigned MainWindow at 1280×780 fidelity. Built so
you can SEE the redesign tomorrow morning even with the WinUI 3
activation issue unresolved.
What's interactive:
* Title-bar sun/moon icon toggles dark <-> light. The full CSS variable
set swaps in-place; both themes are accurate to DESIGN.md's token
table (Wild Dragon cyan stays as the surface fill in both; accent.cyan
for text darkens to #0E7C82 on the light palette for AA contrast).
* Rail "settings" icon (the gear) slides the settings drawer in from
the right with a 220ms ease-out-quart transition.
* Esc dismisses the drawer.
* Banner "Toggle dark / light" and "Open settings" buttons for
hover-discoverable parity.
What's faithful to the WinUI 3 implementation:
* All structural decisions from the shape brief: 64px rail, 44px
title bar with absorbed live pills (live · 00:14:32 / rec 3 / 482GB
free), section header with primary button + secondary actions, 64px
table rows with avatar+name, signal+lock dot, audio meter,
output-name in mono, ISO pill at right, conditional in-call control
bar, slim 32px status bar.
* Active-speaker row (Maya) has the cyan left border + cyan-muted
background tint, matching the data trigger in MainWindow.xaml.
* Wild Dragon brand mark in the rail uses the same cyan-muted square +
cyan-text "W" treatment as the WinUI 3 Avatar style.
* In-call buttons use the destructive style for Muted + Leave (coral
border and text) and Secondary for Camera / Share / Marker, mirroring
the button-hierarchy commitment from DESIGN.md.
* Settings drawer shows the Appearance tab with the System / Dark /
Light radio group + the accent peek panel.
Open it in any modern browser:
file:///C:/Users/zacga/Documents/Claude/Projects/Teams%20ISO/docs/preview/redesigned-mainwindow.html
This is documentation; the actual product is the WinUI 3 XAML in
src/TeamsISO.App.WinUI/. Once activation unblocks, the preview can be
deleted (or kept for future stakeholder demos before binaries ship).
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.
Added Vortice.MediaFoundation 3.6.2 NuGet package to TeamsISO.Engine so the scaffold compiles when MF_AVAILABLE is defined. However: the scaffold (May 9) was written against an older Vortice surface and the 3.6.2 API has materially changed:
- MFVersion not on MediaFactory, MF_LOW_LATENCY moved
- IMFAttributes.SetUINT32 replaced with generic Set
- IMFMediaType.MajorType / SubType / AvgBitrate property setters → SetGUID(MFAttributeKeys.MajorType, ...) etc.
- VideoFormatGuids.RGB32 renamed (likely Rgb32)
- IMFMediaBuffer.Lock signature changed (explicit out IntPtr / out int / out int)
- IMFSinkWriter.Finalize_ renamed
Leaving MF_AVAILABLE undefined for now so the build stays clean. NuGet ref stays so a porter doesn't need to re-add. docs/REAL-TIME-RECORDING.md updated with the deferred status + the specific API gaps to port.
When the new ControlSurfaceLanReachable preference is on, both the REST/WebSocket control surface and the OSC bridge bind to all interfaces (http://+:port/ via HttpListener wildcard, IPAddress.Any for OSC) instead of loopback. The settings VM persists the toggle, restarts both surfaces when flipped, and surfaces a ControlSurfaceUrl computed from the first non-loopback IPv4 + a Copy button so operators can paste the URL onto a control PC.
Use case: a headless host PC runs Teams + TeamsISO; a thin client on the same LAN drives it via /ui or a Stream Deck. Closed-network deployment, no auth — documented as a trusted-LAN-only mode in docs/CONTROL-SURFACE.md, including the one-time 'netsh http add urlacl url=http://+:9755/ user=Everyone' requirement and the firewall rule.
Adds a small auto-dismissing pill notification at the bottom-center of the participants area: 'Settings saved' on Apply Changes, 'Transcoder topology applied — restart Teams to take effect' after the one-click NDI groups setup. ToastViewModel owns its own DispatcherTimer and resets the dismissal countdown on successive calls, so the most recent message is always the one visible. Hooked into MainViewModel and threaded into GlobalSettingsViewModel via constructor injection.
_NEXT.md rewritten to reflect the May 2026 hardening pass: separates engine / UI / networking / Phase E.1 / diagnostics / CI / tests sections, lists every shipped item, and re-prioritizes the remaining work (Phase E.2-E.3 embedded Teams, code-signing the MSI, refresh-discovery affordance, output thumbnail previews, settings panel UX, auto-disable on departure, operator presets).
First step of Phase E.1 from the new spec at docs/superpowers/specs/2026-05-08-embedded-teams-orchestration.md: a third icon in the left rail launches the Microsoft Teams desktop client as a subprocess of TeamsISO so the operator doesn't have to leave the app to start a meeting.
Services/TeamsLauncher tries the ms-teams: URI first, falls back to %LOCALAPPDATA%\\Microsoft\\WindowsApps\\ms-teams.exe (new Teams), then the classic Update.exe handoff. On failure surfaces a friendly MessageBox with the install link.
The spec doc lays out the full three-phase roadmap (launcher -> window orchestration -> in-app meeting controls via Graph API or UIAutomation) and explicitly calls out what's out of scope (replacing Teams' media stack).
_NEXT.md updated to mark Phase D done and queue Phase E + remaining polish items (code-signing, Inter/JetBrains Mono font bundling, real Wild Dragon dragon-mark, drops counter, running-fps display).
.forgejo/workflows/release.yml triggers on annotated tag pushes matching v*.*.*. The workflow runs on a Windows runner (required for WiX MSI), restores and builds the Windows solution filter, runs unit tests (skipping the requires=ndi tier — CI runners don't have NDI), publishes TeamsISO.App + TeamsISO.Console for win-x64 framework-dependent, builds the WiX MSI scaffold, and uploads the MSI both as a workflow artifact (downloadable from the run page) and as an asset on the auto-created Release for the tag.
Tag version is parsed from refs/tags/vX.Y.Z and threaded into /p:Version on every dotnet build invocation so the publish output, the assembly metadata, and the MSI ProductVersion all agree.
Release-asset upload uses the Forgejo REST API directly via curl + Invoke-RestMethod rather than depending on a third-party action; if the auto-create-release-on-tag-push setting is off, the workflow creates the release itself. Pre-release flag is set when the tag contains -alpha/-beta/-rc.
docs/RELEASING.md walks through cutting a release and flags the code-signing TODO (SignOutput property is wired but no cert; SmartScreen will warn on first launch until that lands).
