ops(scan): fix the always-empty webstatus.dev "widely" Baseline query#110
Merged
Conversation
The routine told the scan to catch newly-Baseline -> Widely transitions with `baseline_status:widely` scoped by `baseline_date:<this run's window>`. That query can never match: `baseline_date` filters on a feature's *low* date (the day it went newly), not its high date, and Widely is reached ~30 months after newly. So a feature going Widely today has a low date ~30 months in the past, and the query silently returns zero every run. Verified against the public API today: baseline_status:widely AND baseline_date:2026-06-01..2026-07-17 -> total 0 baseline_status:widely AND baseline_date:2023-12-01..2024-01-31 -> total 16 The second window returns the 16 features that actually went Widely in June 2026 (high_date = low_date + 30 months in every case), confirming the filter keys off low_date. Document the offset and give both query shapes, so half the Baseline check stops being a no-op that reports "nothing moved" forever. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Deploying specification-website with
|
| Latest commit: |
54d667c
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://815ed608.specification-website.pages.dev |
| Branch Preview URL: | https://ops-fix-baseline-widely-quer.specification-website.pages.dev |
jdevalk
marked this pull request as ready for review
July 17, 2026 06:43
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.
What changed
ops/routines/daily-standards-scan.md— documents that webstatus.dev'sbaseline_datefilter keys off a feature's low date, and gives the corrected query shape for catching newly → Widely transitions.Why now
Today's scan run tripped over this. The routine currently says:
scoped by
baseline_date:<START>..<END>with "a trailing ~8-day window". That combination can never match anything.baseline_datefilters on the feature's low date (when it went newly), not its high date. Widely is reached ~30 months after newly, so a feature that goes Widely today has a low date ~30 months in the past.The failure mode is the bad kind: no error, just
total: 0every single run. Half the Baseline check has been reporting "nothing moved" unconditionally, and would have kept doing so indefinitely.Verification
Both queries run against the public API today (2026-07-17):
metadata.totalbaseline_status:widely AND baseline_date:2026-06-01..2026-07-17(routine as written)baseline_status:widely AND baseline_date:2023-12-01..2024-01-31(window offset back ~30mo)The second returns the features that actually went Widely in June 2026 —
has,loading-lazy,nesting,storage-access,masks,:dir(),url-canparseand others. Every one hashigh_date=low_date+ 30 months exactly, which is what confirms the filter keys offlow_date.Sample from that response:
hasloading-lazystorage-accessSource
Status justification
Not a spec-content change — this is routine plumbing, so no changelog entry per the CLAUDE.md rule that the changelog tracks what the spec says, not tooling.
Worth noting what this fix does not change: the 16 features it now surfaces were reviewed this run anyway, and 14 are rejected by the auditable-outcome rule (CSS/JS authoring ergonomics — the subgrid/#82 precedent). The other two (
loading-lazy,storage-access) are already covered and their statuses stay correct. So the immediate yield is zero new pages; the value is that the query stops lying on future runs.🤖 Generated with Claude Code