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)

[erikdarlingdata]

Two V137 pins met the rungs that landed around them — one said "63" meaning "nothing above me", one read a null placeholder as a reader

(1) Lite.Tests.TimeHonestyRungReadTests.AV62Database_ClimbsToV63_AndItsOldRowsReadNull — dev red on f2e1816

Mechanism. The test stamps a real DuckDB file back to 62, re-initializes it, and asserted MAX(version) == 63. DuckDbInitializer.InitializeAsync runs every block above the stamp in one pass, so the version a re-initialized database lands on is the CURRENT top — 64 since #3813 (V137 / Lite v64, the Query Store capture modes) — and the literal was a top-rung claim hiding inside a test about v63's two columns.

Evidence. Dev run 35526527790 at f2e1816 (the #3813 merge): build red on exactly this one test — Expected: 63, Actual: 64 — with Darling PostgreSQL tests and the whole-tree guards green.

Why this shape. The pin now reads (long)DuckDbInitializer.CurrentSchemaVersion — the idiom PerfmonCounterTypeTests' v61→v62 climb already uses — and additionally asserts CurrentSchemaVersion >= 63 so the rung's own floor stays stated. The v63 half the test owns (both columns back, nullable, trailing; the pre-rung rows NULL through the re-expanded v_ views; post-rung rows landing) is untouched; the literal top belongs to the newest Lite rung's own test (QsCaptureModeRungTests.AV63Database_ClimbsToV64_AndItsOldRowsReadNull), where it will move again when v65 lands.

(2) QsCaptureModeRouteKnobToastRungTests.NoReaderNamesAnyOfTheEightColumnsYet — would red on 20215a4

Mechanism. The census scans product code (comments stripped, string constants kept) for the eight V137 column names, so a consumer lane has to retire its arm deliberately. #3797's get_query_store_clutter (4492479, merged 40 minutes after #3813) publishes query_capture_mode = (string?)null beside capture_mode_known = false and a note saying the column lands with V137 — the payload KEY so a caller's shape is stable, never a value read from the store — and DarlingMcpInstructions names the key in the prose that tells an agent what the tool will say. Pointers, not readers: the V136 shape's PgTargetToolRecommendations exclusion.

Why this shape. The two files are excluded from the eight-name scan, and the clutter tool is held POSITIVELY to its pointer state — the null placeholder present, no wait_stats_capture_mode, and no SELECT … FROM [v_]query_store_health span of its naming query_capture_mode — so the moment #3797's reader half lands the arm reds and is retired on purpose, which is what the census is for. Red-then-green on this Mac: the original pin reds against dev + #3797 naming DarlingMcpInstructions.cs; the edited pin passes 7/7.

What this does NOT do

No product code. No other pin moves: a scan of Lite.Tests for literal schema-version equalities finds no other, and the V136 handoff pins in PgDatabaseSizeStatsAndHostMemoryRungTests are green as merged (lane 32's positive-census reshaping and this lane's top-arm handoff landed in different regions of the same file within eight seconds and both survived).

Tests

Executed on this Mac: TimeHonestyRungReadTests 5/5, TimeHonestyRungTests 6/6, QsCaptureModeRungTests 3/3, PerfmonCounterTypeTests 17/17, WatermarkFrameReadTests 3/3 (Lite); QsCaptureModeRouteKnobToastRungTests 7/7 red-then-green, PgDatabaseSizeStatsAndHostMemoryRungTests 6/6, RepoFileAdoptionTests 2/2 (Darling). The V137 lane ran the sibling TimeHonestyRungTests class by name and not this WPF-hosted one; the full Lite sweep had (1) and was not read before push — stated so the census habit is the lesson, not the pin.

Fixes the dev red left by #3813 (partial #3796, partial #3712, partial #3783).