[Bug]: The success toast uses dark-mode green on every theme — 1.83:1 on light presets

[laurentiu021]

Problem

The completion toast paints three literal greens on a themed fill, so on every light preset the success glyph is close to invisible.

MainWindow.xaml, the ToastOverlay block: the container is Background="{DynamicResource Surface2}" — it follows the theme — while the check glyph is Foreground="#22C55E", the badge behind it Background="#2022C55E" and the border BorderBrush="#4022C55E". The literal is the dark-mode green, used unconditionally.

Measured against each light preset's real Surface2 from ThemeService:

Light preset	Surface2	Toast glyph #22C55E	Themed light Success #166534
clean-indigo	#F1F5F9	2.08:1	6.51:1
sky-breeze	#E0F2FE	1.99:1	6.21:1
mint-fresh	#BBF7D0	1.88:1	5.88:1
warm-sand	#FDE68A	1.83:1	5.73:1

For reference the same green measures 7.66:1 on midnight-indigo's #151A23, which is why it reads correctly in dark mode and was never noticed. WCAG asks 4.5:1 for text and 3:1 for a meaningful graphic; the toast clears neither on any light preset.

The theme system already solved this. ThemeService seeds Success per mode — #22C55E dark, #166534 light — and the source comment beside it names this exact failure: "mode-aware Success brush — one crisp card beside two washed-out ones." The toast simply does not use it.

Expected behavior

The toast uses the themed status brushes (Success / SuccessBgSubtle / SuccessBorder), which already carry per-mode values, so the glyph is legible on all twelve presets.

The guard is one word too narrow

ArchitectureTests.NoThemedFill_CarriesAHardcodedWhiteForeground pins exactly this shape — a hardcoded foreground literal over a DynamicResource fill — and its own remarks describe a hardcoded white measuring 2.15:1 on warm-ember. It watches white only, so a hardcoded green over Surface2 is the same defect in a colour the guard does not look for.

Widen that guard rather than adding a second one: any hardcoded foreground literal over a themed fill, contrast-checked against every preset's value for that fill. It should red on the toast today.

Evidence

• SysManager/SysManager/MainWindow.xaml — the ToastOverlay block
• SysManager/SysManager/Services/ThemeService.cs — per-mode Success / SuccessText / SuccessBgSubtle / SuccessBorder, and the light preset palettes the table above uses
• SysManager/SysManager.Tests/ArchitectureTests.cs — NoThemedFill_CarriesAHardcodedWhiteForeground

Ratios computed with the WCAG 2.x relative-luminance formula against the preset values as they stand in source.

Affected area

Every tab — the toast is in the shell

[laurentiu021]

Fixed in v1.76.15 via #2118.

Two corrections to this issue, both in the direction of it being worse than described.

Six light presets fail, not four — lavender and soft-blossom were missing from the table, and soft-blossom is the worst at 1.65:1. And the ratios are measured against each preset's real Surface2 from ThemeService's table, so the full range is 1.65 to 2.08:1 against 5.16 to 6.51:1 for the themed brush.

The suggested guard change was not the right one. NoThemedFill_CarriesAHardcodedWhiteForeground reads App.xaml styles whose Background binds Accent or Danger, looking for the literal White — different file, different fill, different literal. Widening it would have meant rewriting it into a different check.

Instead: NoViewPaintsItselfWithALiteralColour, a general rule over the shell and Views/. It is cheap because the view layer had only seven literals in total, three of them the toast's. The four that remain are exceptions with distinct reasons — ThemePopup's swatches exist to be a colour, and the FocusRing's two strokes must not follow the theme, since no single themed colour survives every surface the ring lands on (the accent itself falls to 1.00:1 against one of them). That pair is allowed by exact value, so a third literal in App.xaml still fails.

The App.xaml pair was found by the guard, not by me: my own measurement had globbed the shell, Views/ and Resources/ and missed App.xaml.

Mockup at ui-mockups/toast-success-contrast.html, generated from the preset table rather than approximated.