Lite's plan-cache trend descriptions still rated every point over the gap since the previous one, the shared unrated_note named one of two unrated reasons, and the latch/spinlock restart row was spelled two ways across SKUs: Lite carries #3700's three-state sentences, the note names the stored-0 restart beside the first-in-window LAG byte-identically on both SKUs, and both tools on both SKUs publish the unknowable row as null rates with interval_seconds beside them (partial #3653)

[erikdarlingdata]

Two Lite descriptions that #3695 made false, a shared sentence that named one of two reasons, and one restart row spelled two ways

Partial #3653 — three clauses of A15/A16 plus the A11 residue, each named last night by a lane that could not touch the file (#3700 named the first two, #3702 the third). Does not close the issue. A fourth clause (#3703's truncated-carries-two-facts finding) was measured and deliberately NOT done; the count and the reason are at the end.

1. Lite's plan-cache trend descriptions said every point was a rate over the gap since the previous one

Lite/Mcp/McpQueryTools.cs get_query_duration_trend and get_procedure_duration_trend, and the get_query_duration_trend row in Lite/Mcp/McpInstructions.cs, still said "Every point is a rate over the gap since the PREVIOUS point, so the window's first collection … carries null rates". Lite's reads have been three-state since #3695 (GetQueryDurationTrendAsync) and v61 (GetProcedureDurationTrendAsync): MAX(sample_interval_seconds) per collection, NULLIF(…, 0) so a restart collection is UNRATED, the LAG only where the store never recorded an interval — verified at the source before editing (LocalDataService.QueryStats.cs:1178–1180, :1273–1275). A caller reading the old sentence would take a null on a mid-window point as a bug, when it is the restart the description never mentioned.

Both descriptions now carry #3700's Darling sentences minus the hourly-route clause, plus one clause saying Lite has one tier. get_query_store_duration_trend's description (LAG-only, no rollup on Lite) was still true and is untouched. The get_procedure_duration_trend instructions row gains six words pointing at the same rule.

2. unrated_note named one of the two reasons a point goes unrated

The trio's shared envelope sentence — DarlingMcpTrendTools.SerializeTrend and Lite McpQueryTools.SerializeTrend, byte-identical and pinned so by McpMissMessageParityPinTests — said "a per-collection rate is the work since the PREVIOUS collection … and the window's first collection has no previous one inside the window". Since #3695/#3700 a stored-0 restart collection is ALSO unrated on both plan-cache trends, on both SKUs, and the note explained a null on that point with a reason that did not apply to it.

One sentence now names both: the collection's STORED sample interval is 0 (a restart or counter reset: the collector could not difference its two snapshots, so the zeros beside it were never measured), or the point is rated against the PREVIOUS one and has none inside the window (the window's first collection where no interval was stored, or one landing in the same second as its predecessor). It stays true on the Query Store trend, which stores no interval and can only hit the second arm — every one of its points is "a collection where no interval was stored". Unknowable is not 0 is kept verbatim: McpZeroIsAMeasurementTests.TheTrendTools_CountAndExplainUnratedPoints anchors on it.

Three pins moved deliberately: the literal in McpMissMessageParityPinTests (60/60 executed — the fragment must appear in BOTH SKUs' trees, which is the byte-identity proof), and the two substring pins in DarlingPerformanceTrendsReadTests and PerformanceTrendsToolTests, which now assert both fragments — the reason their seed exercises (first-in-window LAG) and the one it does not (stored 0) — so a rewording that drops either reds there and not only in the parity pin. The stale comment above Darling's note ("it still names only the first-collection case; widening it is a both-SKU edit") is replaced by the reason the sentence carries both arms.

3. The latch/spinlock restart row was spelled two ways across SKUs

Read at the source, the two twins were never one shape: Darling's get_latch_stats / get_spinlock_stats are WINDOW AGGREGATES (total_delta_* summed over hours_back, rates and the band from the LATEST interval), Lite's are the newest snapshot (cumulative counters plus the last interval's deltas). The class remark on Darling's tool file says so. What the brief's finding actually named is narrower and real: the row whose latest interval was unknowable — the (0, 0) restart marker beside a stored sample_interval_seconds = 0 — was published as

• Lite (since The perfmon chart plotted deltas under a "Value" label with the divisor sitting unused on the row, and a latch/spinlock restart read as zero: both viewers shape every perfmon series through the stored interval (rate counters per second by the /sec name proxy, the rest labelled per interval, the unknowable point a line break) and both snapshot grids render the (0, 0) marker as unknowable with the interval beside it (partial #3653) #3702): delta_* = null, nothing beside it to say why;
• Darling latch: waits_per_second / wait_ms_per_second null, severity_banded_from.interval_seconds null, but severity_banded_from.delta_wait_time_ms = 0 (the marker's fabricated 0, published as the delta the band came from) and severity = "LOW" — banded from that 0 by LatchSeverity(0);
• Darling spinlock: collisions_per_second / spins_per_second null, and nothing beside them at all — the reader never returned the interval for spinlocks.

One vocabulary, argued rather than picked. The brief preferred Darling's shape (interval_seconds beside the delta — it says WHY the rates are null). Half of that is right and adopted: interval_seconds is the why-key, and Lite gains it, with Darling's per-second pair beside it. The other half of Darling's shape — the raw 0 published as the delta — is the #3642 lie both viewers' snapshot grids stopped rendering last night (#3702: "—" with "restart / first sample" beside it) and Lite's tool stopped publishing in the same PR; adopting it would revert that a night later and put the MCP payload at odds with the grid on the same SKU. So the row is spelled, on both tools and both SKUs: rates null, interval_seconds null beside them, the latest delta null — the delta says the numbers were never measured, the interval says why, and neither is inferred from the other. Concretely:

• Lite get_latch_stats rows gain waits_per_second, wait_ms_per_second, interval_seconds; get_spinlock_stats rows gain collisions_per_second, spins_per_second, interval_seconds. The rate is the row's delta over its stored interval (PerSecond), rounded as Darling rounds; interval_seconds is the stored seconds when > 0 and null otherwise (KnownInterval). A pre-v60 row that never stored an interval keeps its deltas (they are real) and nulls only the interval and the rates — one snapshot row has nothing to LAG against, and the rate is not invented. The deltas are unchanged from The perfmon chart plotted deltas under a "Value" label with the divisor sitting unused on the row, and a latch/spinlock restart read as zero: both viewers shape every perfmon series through the stored interval (rate counters per second by the /sec name proxy, the rest labelled per interval, the unknowable point a line break) and both snapshot grids render the (0, 0) marker as unknowable with the interval beside it (partial #3653) #3702.
• Darling get_latch_stats rows gain a row-level interval_seconds beside the two rates (restated inside severity_banded_from the way that block already restates captured_at beside latest_collection_time — the block is the band's provenance in one place, this is the rates' denominator in its place); severity and severity_banded_from.delta_wait_time_ms are null when interval_seconds is — no band from a number nobody measured. get_spinlock_stats rows gain interval_seconds, which needed the reader: SpinlockStatsTopNSql now carries the latch query's own latest_interval_seconds line (same CTE, same CASE WHEN interval_seconds > 0 expression, one more select column), SpinlockStatRow gains the field. That is a SQL const change and was executed on a rig (below). The reader file was fenced "(doc)"; this is the load-bearing twin port the pin needs and is stated as such.
• DarlingMcpLatchSpinlockTools.cs's class remark no longer says "the per-second rate is derived in SQL from the per-class LAG interval, because Darling's delta collectors store no sample_interval_seconds" — false since V127 (The four naked delta families store the interval their deltas accrued over, so a restart's fabricated zero reads as unknowable instead of 0.00 ms/sec (#3540, V127 / Lite v60) #3595). It says the stored interval is the source and the LAG the pre-V127 fallback, and carries the one-vocabulary paragraph.

Why not sample_interval_seconds for the key. Six sites on the wire (get_file_io_stats, get_perfmon_trend, get_memory_grants, both SKUs) publish the stored interval under the column's name; two (Darling's latch block, the PG trends) say interval_seconds. The latch/spinlock tools already spelled it interval_seconds on Darling and this PR makes the pair agree with itself across SKUs; collapsing the two spellings across the whole surface is a vocabulary pass of its own (residue, noted for the coordinator).

What severity: null changes for a reader. server-tabs.js's LATCH_COLUMNS renders severity through statusSev → statusToSev(String(status || "")) → the default arm, and applyFormat prints — for a null — no JS edit needed and none made. DarlingMcpInstructions.cs's latch row ("severity is banded from the LATEST interval only") stays true and is untouched.

The pins

• Darling.Tests/McpPageContractTests.TheSameToolName_SpellsTheUnknowableRowTheSameWay_OnBothSkus (new) — the TheSameToolName_EmitsTheSamePageContractKeys_OnBothSkus idiom for the two tools whose rows are not the same shape: per tool, the set of interval_seconds / *_per_second keys emitted by each SKU's projection is exactly the expected three, and each description on each SKU names interval_seconds and says the row is unknowable. Matcher witnessed both ways (avg_wait_ms_per_request, spins_per_collision are ratios, not rates, and do not match).
• Lite.Tests/McpPageContractTests.GetLatchStats_PublishesNullDeltas_OnTheRestartMarkerRow (extended) and GetSpinlockStats_PublishesNullDeltasAndRates_OnTheRestartMarkerRow (new) — real DuckDB through the real tools, three interval states per tool: the marker null on every key that spells it; the measured row rated over its STORED 60 s (4,000 ms / 100 requests → 66.67 ms/s, 1.67 waits/s; 4,000 collisions / 1,000 spins → 66.67, 16.67 per second); the pre-v60 row keeping its deltas with the interval and rates null.
• DarlingMcpLatchSpinlockToolsLivePostgresTests (extended) — the same three states over Postgres through the real tools: a class whose newer row stores 60 s while the pair is spaced 120 s apart (6,000 / 60 = 100 ms/s proves the stored path; 50 would have proved the LAG ran where it should not), a pre-V127 pair rated by the 120 s LAG (16.67), and the marker: interval_seconds, both rates, severity, severity_banded_from.delta_wait_time_ms and .interval_seconds all null, total_delta_wait_time_ms honestly 0, the row still on the page. Spinlocks: 60,000 / 60 = 1,000 and 300,000 / 60 = 5,000 per second on the stored row, three nulls on the marker.
• DarlingMcpLatchSpinlockToolsSurfaceAndSqlTests — both SQL pins gain END AS latest_interval_seconds / l.latest_interval_seconds; new TheUnknowableRow_IsNullOnEveryKeyThatSpellsIt_InBothProjections pins the projection shape from source (the null predicates present, the retired spellings absent, the false class remark gone).
• McpLatestSnapshotStampTests.LatchSeverity_NamesTheIntervalItWasBandedFrom — its anchor on delta_wait_time_ms = r.LatestDeltaWaitTimeMs moved to the guarded spelling, on purpose.

What this PR does NOT do (clause 4, measured)

truncated on the trend family (get_query_duration_trend / get_procedure_duration_trend / get_query_store_duration_trend / get_query_trend, both SKUs) and on get_query_store_top means the #2364 WINDOW floor, not #3594's page cut. The brief said rename it (window_truncated) if the blast radius stayed inside ~6 consumers, else stop and count. Counted: ~15. Emitters and descriptions: DarlingMcpTrendTools.cs (TrendDisclosure.WriteTo, get_query_trend's anonymous payload, three doc paragraphs), Lite McpQueryTools.WriteDisclosure, four McpInstructions.cs rows, four DarlingMcpInstructions.cs rows, and get_query_store_top — which lives in DarlingMcpDataTools.cs:765–848, not in the trend tools file the brief named, and outside this lane's fence. Consumers: server-tabs.js:379 (drawQueryTrend reads trend.data.truncated). Tests: PerformanceTrendsToolTests (4 asserts), DarlingPerformanceTrendsReadTests (4 asserts + the six-key order block), TrendEmptyParityToolTests (4), QueryStoreTrendRoutingLiveTests (3, live), McpZeroIsAMeasurementTests:784, QueryStoreTopWindowTests:123, DarlingMcpTrendToolsTests (prose), and McpPayloadContractCensusTests' CutNoteKeys roster + class residue paragraph. Lite's envelope DOES publish the key (the brief's hypothesis that it might not was wrong — WriteDisclosure sets it off TruncationSlack), so the rename is both-SKU. Stopped, per the brief; ships 1–3.

Also not done: the frozen deprecated/Dashboard twins (a semantics upgrade, not a bug fix, on a frozen twin); sample_interval_seconds vs interval_seconds across the six other wire sites; CHANGELOG.md; any PgTarget*, collector, perfmon, MeasureCatalog or DarlingTrendReader file.

Executed here

Darling.Tests built net10.0-windows, run in-process with the WindowsDesktop framework entry stripped; the live classes against a throwaway timescale/timescaledb:2.28.1-pg18 (Docker context desktop-linux, migrated by PgMigrations, torn down): DarlingMcpLatchSpinlockToolsSurfaceAndSqlTests 24/24, DarlingMcpLatchSpinlockToolsLivePostgresTests 1/1 (live), DarlingPerformanceTrendsReadTests 1/1 (live), McpPageContractTests 43/43, McpLatestSnapshotStampTests 34/34, McpZeroIsAMeasurementTests 20/20, McpPayloadContractCensusTests 49/49, DarlingMcpTrendToolsSurfaceAndSqlTests 43/43, DarlingMcpToolsTests 16 (1 pre-existing skip), AsOfWindowAnchorTests 29, RepoFileAdoptionTests 2, CommentFilterAdoptionTests 4, ServerPageTabsTests 17, FleetIdentifierScrubTests 2, DocCommentHygieneTests 77 — green. Lite through a throwaway net10.0-windows harness Compile-Including the classes: McpMissMessageParityPinTests 60/60, PerformanceTrendsToolTests 5/5, TrendEmptyParityToolTests 5/5, McpLatestSnapshotStampTests 12/12, McpDescriptionTruthPinTests 4/4, McpPageContractTests 19/21 and DeltaFamilyUnknowableRowReadTests 11/12 — the three reds are the known IgnoredWaitTypes.Load() → PresentationFramework platform artefact on untouched wait-stats reads, reproduced on dev by #3702/#3703.

Builds -c Release -p:EnableWindowsTargeting=true: PerformanceMonitor.Darling.Service, PerformanceMonitorLite, Darling.Tests — 0 warnings; Lite.Tests — dev's one pre-existing xUnit2000 at LogTailOverlapThresholdPinTests.cs:95, untouched. No JS edited (node --check not applicable); zero hits for the retired spellings (no previous one inside the window, per-collection rate is the work since) across the tree.

First executed in CI: the rest of Lite.Tests. No SQL const changed except the spinlock reader's one added column, executed above.

Refs #3653 (partial — A15/A16 Lite trend descriptions + unrated_note + latch/spinlock unknowable-row parity; A11's Lite description residue). Review-dark window: auto-merge NOT armed; self-review in the lane report.

Which component(s) does this affect?

• Lite
• Darling
• Lite Tests
• Darling Tests
• SQL collection scripts
• Documentation
• Full Dashboard (deprecated)
• CLI Installer (deprecated)

How was this tested?

See Executed here: in-process on this Mac, the two live classes against a throwaway PostgreSQL 18 + TimescaleDB 2.28.1 store; no SQL Server involved (store-side reads and descriptions only).

Checklist

• I have read the contributing guide
• My code builds with zero warnings (dotnet build -c Release -p:EnableWindowsTargeting=true)
• I have tested my changes against at least one store (PostgreSQL 18 + TimescaleDB 2.28.1 throwaway; DuckDB through the Lite harness)
• I have not introduced any hardcoded credentials or server names