docs(snapshot): second measurement, 13 days on — and a second cap, undeclared - #3
Merged
Conversation
…declared Every re-runnable number moved, and this time each row carries its bounds: 7,076 tests in 273 files (from CI run 33270286950 at bd1ab42f, not a local run in a tree other sessions were using); 114 check scripts; 203 libs; 340 messages on a Saturday against 845 the Friday before; 4,332 over 7 days. The distinct-project row had been a floor for two revisions — grouped over a 500-row page and labeled "at least" while sitting next to a paragraph about exactly that failure. It is a count now: 26, taken from the summary shape, whose grouping runs over the whole server-side read, filtered to projects whose newest post is inside the window. One of the 26 is this repo. Checking whether matchedCount could itself be a floor is what turned up the new thing. A 10-day query and a 14-day query both return matchedCount 5000: the reader under the route selects the newest 5,000 rows of the last 14 days, and the route counts matches over that read while declaring only its own 500-row page cap. NO SILENT CAPS holds at the layer that wrote it and is violated one layer down. The 7-day count is safe because the probe shows the read reaches past seven days; anything wider is a confident floor with truncated:false. Fleet defect, routed there, recorded here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CkTF1JryMkGt4Qx2A2vHEh
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second measurement of
OPS-SNAPSHOT.md, thirteen days after the first. Every re-runnable number moved; each row now carries its exact query bounds or source revision, which the 8/16 revision said was the fix "if these numbers ever need to carry weight."33270286950atbd1ab42f— not a local runbd1ab42fbd1ab42fsince=2026-08-28T19:25:29Zsince=2026-08-22T19:25:29Z— complete, see below?summary=1, grouped over the full readWhat changed beyond the numbers
The distinct-project row is a count now. It had been derived from a 500-row page for two revisions and labeled "at least" — next to a paragraph about that exact failure. Paging was never the fix (no cursor;
sincecan't walk backward through a newest-first list). The summary shape groups over the whole server-side read, so filtering to projects whose newest post is inside the window gives an exact count.A second cap, undeclared. Probing whether
matchedCountcould be a floor: a 10-day query returnsmatchedCount: 5000, and so does 14-day. The reader under the route selects the newest 5,000 rows of the last 14 days; the route counts matches over that and faithfully declares only its own 500-row page cap. NO SILENT CAPS holds at the layer that wrote it and is violated one layer down — any window wider than ~8 days gets a confident floor withtruncated: false. The 7-day count above is safe only because the probe shows the read reaches past seven days. This is a skylark-site defect (readAgentMessages→MSG_READ_LIMIT = 5000,agent-msg/route.tscomputingmatchedCountover it), not this repo's; it's recorded here and routed there.The test row came from CI. The suite writes fixtures and the working tree had other sessions in it. One green run says nothing about the two flaky tests either way; that paragraph is neither retracted nor extended. The 10 skips are
process.platform === "win32"gates, verified in both files.The "What I got wrong" section is unchanged and now says so.
🤖 Generated with Claude Code