The Darling viewer's sidebar dot and its Overview card disagree about a never-collected server

[erikdarlingdata]

Found by review on #2470 (the Lite half, #2458). The duplication is the smaller half of it — the two surfaces already disagree on dev, which is the thing #2429's collapse was written to make impossible.

The disagreement

Both are stamped from the same ClassifyFreshness(LastCollectionTime, nowUtc) call, and they answer differently.

ServerSummaryItem.ApplyFreshness (ViewerDataService.Overview.cs:733):

var freshness = ClassifyFreshness(LastCollectionTime, nowUtc);
if (freshness == ServerFreshness.NeverCollected)
{
    IsOnline = null;
    HasCollectorErrors = false;
    AwaitingFirstCollection = true;
    return;
}

DarlingServer.ApplyFreshness (ViewerDataService.cs:130) — the sidebar row's:

var freshness = ServerSummaryItem.ClassifyFreshness(lastCollectionUtc, nowUtc);
IsOnline = freshness == ServerFreshness.NeverCollected ? null : freshness != ServerFreshness.Offline;
HasCollectorErrors = freshness == ServerFreshness.Stale;

There is no AwaitingFirstCollection on DarlingServer, and DotStatus (ViewerDataService.cs:116) has no arm for it:

public string DotStatus => IsOnline switch
{
    true => HasCollectorErrors ? "Warning" : "Online",
    false => "Offline",
    _ => "Unknown"
};

So for a registered-but-never-collected server, on the same screen:

	sidebar row	Overview card
word	"Unknown"	"Awaiting first collection"
colour	no DataTrigger matches → ForegroundMutedBrush (grey)	amber #FFD54F
tooltip	none	the card's, naming the state

MainWindow.xaml:531-537 has DataTriggers for Online / Offline / Warning only, so "Unknown" falls through to the muted default. The dot is silently the pre-#2429 answer.

This is the exact failure #2429 spent two review rounds on, and its own enum doc says why it should not be reachable:

with a single discriminant there is no combination left for the renderings to disagree about, because they no longer each decide.

ServerCardStatus.AwaitingFirstCollection exists specifically because "a red 'Offline' on a merely-queued server sent a 24-server field report chasing a phantom scheduler bug". The sidebar's answer is grey rather than red, so it is the milder version — but it is still the surface a reader points at first, and it is telling them something the card contradicts one panel over.

Why it was not done in #2470

#2470 collapsed Lite's copy onto ServerCardStatusRules.Classify (one Classify, one Word(), one Headline(), both surfaces rendering the result). The viewer cannot just take that:

• Different enum. The viewer's ServerCardStatus has five members — Stale where Lite has CollectorErrors, plus AwaitingFirstCollection, which Lite has no equivalent of and Say why Lite's card is amber, and which axis the word is about (#2437) #2451 verified Lite cannot reach.
• Different meaning for the same amber. The viewer's word is derived from collection freshness; Lite's is a connection word from a live check. Same colour, same word "Warning", different cause — written down in both enums' remarks, and Band Lite's collection freshness, so a quiet server stops looking green (#2452) #2457 turned down folding freshness into Lite's word for exactly this reason.
• So picking the viewer's vocabulary is a decision, and making it inside a Lite PR would have been making it quietly.

What settling it looks like

1. DarlingServer renders the viewer's ServerCardStatus instead of deriving its own ladder — which needs it to carry AwaitingFirstCollection (or, better, the classified ServerFreshness itself, since both ApplyFreshness implementations already start from it and immediately throw the discriminant away in favour of two booleans).
2. MainWindow.xaml gains the fifth state, or the dot binds the enum rather than the string so an unhandled member cannot fall through to grey.
3. The sidebar dot gets the tooltip its card already has, as Lite's did in Collapse the sidebar dot onto the status the Overview card renders (#2458) #2470.
4. A pin in the shape both Say why Lite's card is amber, and which axis the word is about (#2437) #2451 and Collapse the sidebar dot onto the status the Overview card renders (#2458) #2470 landed: the words are written in one place, scanned syntax-agnostically. Collapse the sidebar dot onto the status the Overview card renders (#2458) #2470's experience is the argument for the syntax-agnostic form — Say why Lite's card is amber, and which axis the word is about (#2437) #2451's Assert.Equal(1, CountOccurrences(source, "IsOnline switch")) counted one literal in one file, and the copy it existed to forbid was in another file and written as if statements, so it evaded both axes at once.

The thing to decide first

What the viewer's sidebar dot should say for AwaitingFirstCollection. "Awaiting first collection" does not fit a dot, so it is a colour plus a tooltip — and the colour choice is the whole question. Amber matches the card and reads as "needs attention" for a server that is merely queued; grey matches today and reads as "no information", which is arguably honest for a server nothing is known about yet. The card already chose amber and wrote down why ("queued, not dead"), so matching it is the default — but it is worth saying out loud rather than inheriting, because the two surfaces are answering at different sizes.

[erikdarlingdata]

Fixed on dev by #2474. The premise held exactly as filed — ServerSummaryItem.ApplyFreshness sets three flags, DarlingServer.ApplyFreshness sets two (it has no AwaitingFirstCollection at all), and MainWindow.xaml carried DataTriggers for Online/Offline/Warning only, so the fifth state fell through to the muted brush. Grey dot beside an amber card, same server, same ClassifyFreshness call.

The dot is amber now, with the card's word. Grey was a second answer to a question the card had already answered on the same screen, which is the defect rather than a styling choice.

Widening the pin is what made this worth doing, and it found two more ladders, both in the headless service:

• DarlingFleetReader.StatusLabel — agreed with the others, but a fourth independent derivation.
• DarlingMcpDataTools.FreshnessStatus — written as if statements, in another file, against its own duplicate thresholds. I verified this on dev: it declared StaleThreshold = TimeSpan.FromMinutes(2) locally, while the shared ServerHealthThresholds.StaleThreshold is derived as CollectorCadence.Ticks * 2. So the MCP tool hardcoded what the viewer computes, and the moment a fleet's fastest cadence is not one minute the two surfaces disagree about the same server's freshness. That is a live drift bug, not a tidiness one, and nothing would have surfaced it.

That is #2470's evasion shape twice over — another file, and if statements rather than a switch. The ladder moved to PerformanceMonitor.Common as ServerCollectionStatus, renamed deliberately: Lite's ServerCardStatus answers the connection question under #2457's separation, so sharing the name would not even have compiled — which is a nice property, since the type system enforced the distinction the naming had to make.

Two complementary syntax-agnostic scans now guard it: the distinctive phrase written once anywhere across three trees, and "any file that calls ClassifyFreshness spells none of the words" — the second is what catches a four-state copy, which is what this defect was. Comments stripped by a lexer rather than a line prefix. Five of six pins fail against dev.