2.1 KiB
2.1 KiB
HANDOFF — 2026-10-30 (design standard landed; token sweep in flight)
State
- Branch
main, worktree clean. Eight design commits, unpushed (push at your checkpoint):565b8dbDESIGN.md standard ·f2bf577Tokens.xaml + guard ·84c335afonts ·ffdf3b6sans wired ·4ef84f2Controls.xaml ·0275e30shell (top bar, window, scene strip, mono telemetry) ·2dbc35bleft panel ·3edb0d1positive + dark-scrim tokens. - Half-converted on purpose: theme, shell, left panel and readouts are tokenised; the preview pane and the dialogs still carry the old palette.
DESIGN.mdis normative;Themes/Tokens.xamlimplements it. Blue#38bdf8is the only interactive accent; red#ff5451is live/record only;#e94560is retired from chrome.
Next action
Controls/PreviewPane.xaml (110 hexes), then Controls/OverlayHost.xaml + dialogs (~85),
then the VM/service brush literals (MainViewModel.Streaming.cs, .Audio.cs,
NotificationService.cs). Add each file to DesignTokensTests.Converted_surfaces_carry_no_raw_colour.
⚠️ PreviewPane trap: it holds a hardcoded chat-border colour menu — MenuItem rows with
Tag="#22c55e"-style values bound through EnumToBool (~line 265). Those hexes are user data,
not theme; tokenising them breaks the picker. Route them through Models/BorderColorPalette.cs
first (TASK 63 precedent), then sweep the rest.
Landmines
- Not every hex is a theme colour. Tokenise app chrome only; leave
BorderColorPalette, pickerTag=values,Models/Source.cschat defaults, and the on-stream renderers (AlertRenderer,ChatBoxRenderer,Compositor/*,BrandFlashPresenter) literal. Themes/Tokens.xamlis the only file allowed a raw hex; the guard lists converted files.- A red settings control is a bug now — red means live/record.
- Pre-existing: the full test suite hangs (WASAPI teardown). Per-class runs are the way.
Pending
- Launch once: confirm Inter/JetBrains Mono render (pack-URI resolution is unprovable in the test host) and that the blue reads right in the room.
- Vertical-tier camera check; webcam-cadence take in the failing geometry.