A "read by nothing" pin cannot outlive the readers it was waiting for: the V137 eight-column no-reader census is retired whole rather than exempted file by file — #3814 released the clause forty minutes after the rung, #3821 bought one merge by name, and #3796, #3712 and #3783 were each about to red the same method and race to edit it

[erikdarlingdata]

Dev went red at 20215a4 on one fact, QsCaptureModeRouteKnobToastRungTests.NoReaderNamesAnyOfTheEightColumnsYet, in build, Darling PostgreSQL tests and Darling whole-tree guards. #3821 (6163165) patched it green by exempting two files. This PR retires the fact instead, because the thing it pins stopped being true the hour it merged and every consumer merge since has had to edit the same method body to get past it.

While this PR sat in CI the race it describes ran to completion: #3822 (fence on the clutter reader/judgment files) and #3823 (#3796's code half — renamed the fact to NoReaderNamesAnyOfTheSixUnconsumedColumnsYet_AndTheCaptureModeConsumersNameBoth and inverted arm (a) to a positive scan) both merged to dev and both landed inside the method. The rebase conflicted exactly there; the resolution is the same deletion over dev's version of the file (all of #3822's and #3823's hunks in this file were inside the method — nothing outside it was touched by either).

Mechanism

The V137 rung (#3813, f2e1816) added eight nullable columns on three existing tables and shipped with the exit criterion's last clause pinned: no product source in the five Darling/Analysis projects names any of the eight column names, comments stripped, so that each consumer lane would have to release the clause deliberately. The pin scans every *.cs file and throws on the first hit.

A "no reader names the column" census has one honest lifetime: from the rung's merge to the first consumer's merge. Here that was forty minutes. #3814 (#3797's Query Store clutter view, merged 17:56Z) publishes query_capture_mode = (string?)null beside capture_mode_known = false — the payload KEY, a promise that the column exists and is not yet read, not a read of it — and names the key in DarlingMcpInstructions.cs. The census cannot tell a pointer from a reader; it saw the literal and failed.

What failed, quoted

From the dev run at 20215a4 (Darling PostgreSQL tests, 18:01:40Z; identical in Darling whole-tree guards at 18:09:21Z):

Darling.Tests.QsCaptureModeRouteKnobToastRungTests.NoReaderNamesAnyOfTheEightColumnsYet [FAIL]
  D:\a\PerformanceMonitor\PerformanceMonitor\Darling\PerformanceMonitor.Darling.Service\Mcp\DarlingMcpInstructions.cs names query_capture_mode: a consumer landed — retire this pin's arm for that column deliberately (and, for (b), the rung doc's 'written by nothing and read by nothing' clause).
    Darling\Darling.Tests\QsCaptureModeRouteKnobToastRungTests.cs(476,0)

Reproduced on this Mac with the 20215a4 version of the test in the in-process harness against the current tree: same file, same column, same line. (The f2e1816 red one run earlier was the other V137 residue — Lite.Tests.TimeHonestyRungReadTests.AV62Database_ClimbsToV63_AndItsOldRowsReadNull — also fixed by #3821; the census was green there because #3814 had not landed yet.)

Why retire, not patch

#3821 exempted DarlingMcpQueryStoreClutterTools.cs and DarlingMcpInstructions.cs by name and added a positive arm holding the clutter tool to the null placeholder. That is the right shape for a homonym (the toast_bytes on pg_table_bloat_stats the pin already carved out) and it made the tree green, but it fixes the census against one consumer while three more are in flight, all of them the readers the rung was built for:

• query_store_health does not collect QUERY_CAPTURE_MODE or WAIT_STATS_CAPTURE_MODE — the one option that names a plan-churn factory is the one the health row omits #3796 (branch fix/3796-qs-capture-mode-publish, pushed): DarlingWebEndpoints.cs, DarlingConfigHistoryReader.cs, DarlingMcpConfigHistoryTools.cs, ViewerDataService.Config.cs name query_capture_mode / wait_stats_capture_mode.
• Confidence chooses the channel: uncorroborated findings stop paging and land in the digest — unranked alerts cost the attention the true positives need #3712 (lane working tree): DarlingAlertSettings.cs, StoreConfigProvider.cs, DarlingAlertReader.cs, DarlingMcpAlertTools.cs, ViewerDataService.AlertSettings.cs and two more name analysis_uncorroborated_route.
• query_plan_dim's TOAST file sits at 40 % utilisation on the second SQL Server store (~93 GB slack from the V54 conversion + cycling deletes) — publish dimension-table TOAST utilisation in the store self-metrics; reclaim is --recompress-plan-dim --vacuum-full at the maintainer's word #3783 (lane working tree): DarlingStoreMetricsReader.cs, DarlingMcpStoreMetricsTools.cs, DarlingSelfAlertEvaluator.cs name toast_bytes / toast_live_bytes — and that lane is already carrying a 46+/31− edit to this very method to get past it.

Each would red the pin on merge, and each would have to edit the same method body — a three-way conflict on a test whose only remaining job is to be edited. #3796 did exactly that (#3823, merged 18:3xZ): its edit to this file is the method and nothing else. A "read by nothing" pin cannot outlive the readers it was waiting for.

The positive ownership pins — which reader names which column, and what it publishes — belong in those lanes' tests, and for the two consumers that have landed they are already there and stronger than a name scan:

• query_store_health does not collect QUERY_CAPTURE_MODE or WAIT_STATS_CAPTURE_MODE — the one option that names a plan-churn factory is the one the health row omits #3796's readers: DarlingMcpConfigHistoryToolsSurfaceAndSqlTests (QueryStoreHealthReader_KeepsTheModesNullable_AndReadsTheStampAfterThem pins the ordinals 10/11 and the row type; QueryStoreHealth_Description_ExplainsTheCaptureModes_IdenticallyOnBothSkus; QueryStoreHealth_EveryGrid_EndsWithTheTwoCaptureModeColumns pins the web catalogue and both XAML grids) and Lite.Tests/QueryStoreHealthCaptureModePublishTests (three facts over a real DuckDB). The positive arm get_query_store_health said "Query Store health" and skipped the one knob that names a plan-churn factory: both SKUs now publish query_capture_mode and wait_stats_capture_mode as the row's two trailing fields, the three Query Store grids grow the same two columns, and the description says what ALL / AUTO / CUSTOM / NONE costs and what a null means (#3796 code half) #3823 put inside the rung method asserted only that three files contain the two column strings — a subset of what those already prove.
• Query Store clutter view: per-database clutter (read cost, plan churn, config-vs-churn) and per-server QS overhead proxy, composited from rows already collected, on MCP + web + WPF with recommendations #3797's placeholder: QueryStoreClutterTests (query_capture_mode: null and capture_mode_known: false in the description, the README and the rendered row; CaptureModeNote_NamesTheRung_AndTheAmbiguityItLeaves) and QueryStoreClutterLivePostgresTests (the real payload reads capture_mode_known: false and a JSON null). Two V137 pins met the rungs that landed around them: the v62→v63 DuckDB climb asserted the ladder's top was 63 forever, and the eight-column no-reader census read #3797's null-placeholder query_capture_mode key as a reader — dev red since #3813 (V137 residue) #3821's and The V137 no-reader pin's SELECT fence scanned the clutter TOOL file, which holds no SQL: the reader and judgment files — where a capture-mode READ would land — are now held to naming neither column (#3797 lane 6, after #3821) #3822's arms inside the rung method restated these by string.

What this rung test owns is the DDL shape, the ladder, the probe, the two writers and the Lite twin; the consumer roster was never its to keep.

The method and its <summary> are deleted, and the class doc gains one paragraph recording the history in the file's voice: merged with all eight columns read by nothing (true at f2e1816), released the same hour to #3797's clutter reader (#3814) and the three code halves, three PRs (#3821, #3822, #3823) editing the one method body inside an hour, positive pins named where they live. The class doc's "This file is the RUNG: …" sentence drops the clause it no longer carries.

What this does NOT do

• Touches no product file. PgMigrations.cs's V137 rung doc still says (b) is "written by nothing and read by nothing" — that sentence is Confidence chooses the channel: uncorroborated findings stop paging and land in the digest — unranked alerts cost the attention the true positives need #3712's to change when it lands the writer and reader.
• Keeps every other fact in the class byte-for-byte, including the (d) has NO writer in this rung arm inside TheDimensionSweepWritesToastBytes_AndNullLiveBytes_AndNoOtherKindTouchesEither, which asserts StoreSelfMetrics.cs names none of the three checkpointer columns. That is a WRITER pin on one file owned by exactly one lane (query_plan_dim's TOAST file sits at 40 % utilisation on the second SQL Server store (~93 GB slack from the V54 conversion + cycling deletes) — publish dimension-table TOAST utilisation in the store self-metrics; reclaim is --recompress-plan-dim --vacuum-full at the maintainer's word #3783), so it is not the race this PR is about; query_plan_dim's TOAST file sits at 40 % utilisation on the second SQL Server store (~93 GB slack from the V54 conversion + cycling deletes) — publish dimension-table TOAST utilisation in the store self-metrics; reclaim is --recompress-plan-dim --vacuum-full at the maintainer's word #3783 retires it when it lands the row.
• Keeps WithoutComments — the surviving (d) arm still uses it.
• Retires nothing in Lite.Tests/QsCaptureModeRungTests.cs: its three facts pin the v64 block, the DuckDB generator's tail and the v63→v64 climb; none asserts a reader roster. No second "no reader names …" fact exists for the eight columns in either test tree (PgDatabaseSizeStatsAndHostMemoryRungTests.NoReaderNamesTheSizeTableOrTheMemoryColumnsYet is V136's, on different columns, and is untouched).
• Does not re-litigate The V137 no-reader pin's SELECT fence scanned the clutter TOOL file, which holds no SQL: the reader and judgment files — where a capture-mode READ would land — are now held to naming neither column (#3797 lane 6, after #3821) #3822 or get_query_store_health said "Query Store health" and skipped the one knob that names a plan-churn factory: both SKUs now publish query_capture_mode and wait_stats_capture_mode as the row's two trailing fields, the three Query Store grids grow the same two columns, and the description says what ALL / AUTO / CUSTOM / NONE costs and what a null means (#3796 code half) #3823: both merged while this sat in CI and both are honoured — their product changes are untouched and their test-side arms in this file are superseded by the deletion, with the positive pins listed above already carrying what those arms restated.

Tests

Darling.Tests builds -c Release -p:EnableWindowsTargeting=true with 0 warnings. Executed in-process on this Mac (xunit v3, the mactest harness over the built dlls):

• QsCaptureModeRouteKnobToastRungTests — 6/6 green (was 7; one retired), on the tree rebased over Held retention policies waited for a restart nobody was going to do: the coverage gate is re-judged on the running service's hourly store-maintenance tick, the sweep counts transitions instead of verdicts and writes one unconditional 'Retention re-evaluation' line per pass, and every operator sentence that made the restart mandatory now makes it optional (#3812) #3829. The 20215a4 version of the class, dropped into the same harness against the pre-Two V137 pins met the rungs that landed around them: the v62→v63 DuckDB climb asserted the ladder's top was 63 forever, and the eight-column no-reader census read #3797's null-placeholder query_capture_mode key as a reader — dev red since #3813 (V137 residue) #3821 tree, fails exactly the quoted fact on DarlingMcpInstructions.cs / query_capture_mode.
• DarlingMcpConfigHistoryToolsSurfaceAndSqlTests 29 and QueryStoreClutterTests 49 — the positive pins this PR points at, green on this tree.
• RepoFileAdoptionTests 2, DocCommentHygieneTests 77, CommentFilterAdoptionTests 4, StragglerCommandTimeoutTests 48, LiveCleanupConversionRatchetTests 15, LivePostgresCollectionHygieneTests 11, ViewerCommandTimeoutTests 57, MeasurementContractCensusTests 10, McpPageContractTests 43, McpPayloadContractCensusTests 67, FactSourceRegistryTests 5, TsqlConventionGuardTests 14, PgSchemaGeneratorTests 24 — all green.
• QsCaptureModeRouteKnobToastLivePostgresTests skips without DARLING_TEST_PG here; untouched; CI's Darling PostgreSQL tests runs it.

One test file, −133 / +26 lines against dev at 194824d.

Which component(s) does this affect?

• Darling Tests

Checklist

• I have read the contributing guide
• My code builds with zero warnings
• No hardcoded credentials or server names

Follow-up to #3813 (V137 rung); unblocks #3796, #3712, #3783 code halves.