Lite's card and the web dashboard have the two Overview defects #2429 just fixed in the Viewer

[erikdarlingdata]

#2429 fixed both Overview defects in the Darling Viewer. Two other surfaces have the same ones, verified in source.

Lite's card has the identical unexplained status

Lite/MainWindow.xaml:442:

<TextBlock Text="{Binding StatusDisplay}" Foreground="{Binding StatusBrush}"
           FontSize="11" Margin="0,0,0,10"/>

Same bare binding, same absent ToolTip. A Lite user reads "Warning" and scans the metric rows for the yellow one, exactly as @ehaar had to on the Viewer in #2422.

This is a port rather than a wiring change, which is the whole difficulty: Lite has no FleetRollup and no BuildReason, so the reason has to be built rather than bound. The Viewer's version is worth copying carefully — BuildReason is deliberately assembled from the card's OWN metric displays so it can never drift from the six rows underneath, and a Lite implementation that recomputed severity independently would lose that property and be worse than no tooltip.

One difference in Lite's favour: it has no AwaitingFirstCollection flag, so the status/tooltip desync family that #2429 spent four review rounds on cannot occur there. Only the unexplained-word half applies.

The web dashboard's "+N more" is the same dead end

Darling/PerformanceMonitor.Darling.Service/wwwroot/js/pages/fleet.js:168:

nodes.push(el("div", { class: "muted", style: "margin:0.4rem 0 0.2rem",
                       text: "+ " + d.additional_problem_count + " more need attention" }));

A plain muted div, no handler, no navigation — the same "here is a number you cannot act on" the Viewer had.

This one should be easier than the WPF version was, because the seam already exists: fleetFilter is a module-level variable at line 33, redrawCards() at 183 already filters lastCards through cardMatches(c, fleetFilter) before sorting, and the count itself arrives on the payload as additional_problem_count. So option (a) from #2424 — make it a link that filters the grid to the servers behind the number — ports nearly as-is.

Keep the two properties #2429 settled on, since they are what make the filter safe rather than confusing: filter on the same predicate the count is computed from, so the destination cannot disagree with the label; and make the active state visible (showing 12 of 57) so a filtered grid can never be mistaken for an unfiltered one.

Worth doing together

They are the same two defects and the Viewer's answers are already reviewed, argued and merged. Doing them in one pass keeps the three surfaces saying the same thing — which is the actual goal, since a user moving between Lite, the Viewer and the dashboard should not have to learn three different levels of helpfulness.

[erikdarlingdata]

Both halves are up, one PR per surface as planned.

• Give the web dashboard's "+52 more" somewhere to go (#2437) #2447 — the web dashboard. + N more need attention is now a keyboard-activatable link into a needs-attention filter over the card grid. It filters on cardNeedsAttention(c) => c.band !== "Healthy" — the card's server-computed band, which is the same predicate BuildRollup counts additional_problem_count from (cards.Where(c => c.Band != FleetHealthBand.Healthy)), so R1 holds and the destination cannot disagree with the label. The active state rides with the cards rather than only with the toggle, because unlike the viewer's docked roll-up header this page head scrolls away.
• Say why Lite's card is amber, and which axis the word is about (#2437) #2451 — Lite's card. Tooltip on the status line and the status dot, built from the card's own displays and gated on the same predicates the row brushes are painted from, so it cannot name a metric whose row is green.

Two findings worth recording against the issue text.

Lite does not have the viewer's stale-collection conflation. Checked in source rather than assumed: the viewer re-purposes HasCollectorErrors to mean "the collection has gone stale" (its own doc comment says so, ViewerDataService.Overview.cs:416), because its status is freshness-derived. Lite's IsOnline comes from _serverManager.GetConnectionStatus(...), a live connection check, and its HasCollectorErrors from ErroringCollectors > 0 — collectors that are genuinely failing. Lite has the inverse conflation instead, and it is arguably sharper: its status word is a connection word that never reflects the metric rows, so a card at 96% CPU with two deadlocks reads a green "Online" over a red border. The tooltip therefore keeps the two axes on separate lines rather than fusing them, which is the one place the port is not a copy.

Lite bands no collection freshness at all — filed as #2452. Building the tooltip meant reading every signal the card carries, and freshness is not one of them: LastCollectionDisplay has no brush, IsOnline is a connection check, and HasCollectorErrors counts errors rather than silence. So a Lite server whose collectors stop producing rows while the connection stays up shows a green "Online" and a stale timestamp nobody is asked to read. Not papered over in the tooltip on purpose — asserting a band the row underneath does not show is exactly the drift the whole design prevents.

That issue also records ServerConnection.DotStatus (Lite/Models/ServerConnection.cs:199) as the remaining independent copy of the same four-word ladder, for the sidebar row.

[erikdarlingdata]

Fixed on dev by #2447 (web dashboard) and #2451 (Lite's card). Both ports answered the questions I put in the brief, and one answered it the opposite way from what I expected.

The JS predicate matches the server's, and is now pinned against both artifacts rather than transcribed. BuildRollup counts cards.Where(c => c.Band != FleetHealthBand.Healthy), the payload carries that band per card, and cardNeedsAttention reads it — with a test that builds the expected literal from the shipped serializer (JsonSerializer.Serialize(FleetHealthBand.Healthy, DarlingFleetReader.JsonOptions)) and asserts fleet.js contains return c.band !== "Healthy";. So renaming the enum member breaks the test rather than silently emptying the grid, which is the failure this pairing invites.

Lite did NOT have the stale-collection conflation — it has the inverse one. I asked whether Lite repeated the Viewer's fusion of "stale" and "metric breach" into one Warning. It does not: the Viewer re-purposes HasCollectorErrors to mean staleness (its own doc comment says so), while Lite's is ErroringCollectors > 0, real failures. What Lite has instead is StatusDisplay => IsOnline switch — a pure connection word that never reflects the metrics at all. Verified in source. So a card at 96% CPU with two deadlocks reads a green "Online" over a red border, which is arguably worse than an ambiguous Warning: it is a confident all-clear. The tooltip keeps the two axes on separate lines rather than fusing them, which is the right call.

Review caught a live desync in Lite, not a hypothetical: CardBorderBrush read the raw flags, so an unchecked card carrying a collector-error marker drew the amber "collectors failing" border under an Unknown word — reproduced against dev's own brush value. Border and IsOffline render from the derived status now, pinned by a single-occurrence assertion on IsOnline switch so a second copy of the ladder cannot reappear.

The web half needed three self-inflicted corrections found in review, all of the same family: the count used the fleet as denominator while a search narrowed the grid, the green all-clear fired when a search matched nothing, and the ported "the 1 server monitored is healthy" claimed the fleet held one server. All three are the filter and the label disagreeing — the exact bug the issue exists to fix, reintroduced one level down.

No JS test runner exists in the repo, so the web behaviour was proven by running the shipped fleet.js under a minimal DOM shim (31 assertions over four fleet shapes), with 7 text-scan pins of which 6 fail against dev.

Split out as #2452: Lite bands no collection freshness at all, so a server whose collectors go silent while the connection holds shows a green "Online" and a stale timestamp nobody is asked to read. Deliberately not papered over in the tooltip — asserting a band the row underneath does not show is the drift this design exists to prevent.