[Bug]: Nine integration assertions are permanently red and one asserts the wrong last tab — CI only compiles that project

[laurentiu021]

Problem

SysManager.IntegrationTests is compile-checked in CI but never executed (ci.yml: "Build integration tests (compile check)"), and the main workstation cannot run dotnet test. So a stale expectation there is invisible indefinitely. Two independent rots have accumulated:

1. The StatusColors migration never reached this project — 9 red assertions

StatusColors members are now theme brush KEYS, not hex strings: Good = "Success", Neutral = "TextMuted", Bad = "Danger". HealthAnalyzer assigns those keys to diag.ColorHex, and HealthDiagnostic._colorHex defaults to StatusColors.Neutral. The integration tests still compare against the pre-migration hex literals:

• HealthAnalyzerExtendedTests.cs:75 — Assert.Equal("#06D6A0", diag.ColorHex), now "Success"
• HealthAnalyzerExtendedTests.cs:237-243 — AllVerdicts_ProduceValidColor, 7 [InlineData] rows of hex
• HealthDiagnosticTests.cs:19 — Assert.Equal("#9AA0A6", d.ColorHex), now "TextMuted"

Nine failing cases. The other hex literals in the project (ConvertersTests, PingTargetTests, DiskHealthReportTests) pass their own literal in and read it back, so they are unaffected.

2. NavItems_CorrectOrder_AboutLast asserts a tab that is no longer last

DeepCleanupViewUiTests.cs:65 asserts vm.NavItems.Last().Id == "nav-about". grp-advanced was added after grp-info, so the real last item is nav-env-variables. The test's intent — About sits at the end of the sidebar — stopped being true when Advanced was appended, and nobody had to decide whether that was intended.

Expected behavior

Assertions compare against StatusColors members rather than duplicating their values, so the next rename cannot rot them silently. The nav-order test asserts what the sidebar is actually supposed to end with, or is rewritten to state the invariant it really means (About is the last entry of its group).

Beyond the two fixes, the shape of the problem needs a mechanical answer: a project whose assertions cannot run anywhere in the pipeline will rot again. Either run it somewhere (a non-blocking scheduled job, or a machine that runs the suites as a documented gate) or move the pure assertions into the blocking unit suite.

Evidence

• .github/workflows/ci.yml — integration project is dotnet build, never dotnet test
• SysManager/SysManager/Helpers/StatusColors.cs — Good = "Success", Neutral = "TextMuted"
• SysManager/SysManager/Models/HealthDiagnostic.cs:32 — _colorHex = StatusColors.Neutral
• SysManager/SysManager/ViewModels/MainWindowViewModel.cs — grp-advanced follows grp-info

Affected area

Test suite / CI