From 54d667c5bdaed219d46fc6381560ce498616a8d5 Mon Sep 17 00:00:00 2001 From: Joost de Valk Date: Fri, 17 Jul 2026 08:12:37 +0200 Subject: [PATCH] ops(scan): fix the always-empty webstatus.dev "widely" Baseline query The routine told the scan to catch newly-Baseline -> Widely transitions with `baseline_status:widely` scoped by `baseline_date:`. 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) --- ops/routines/daily-standards-scan.md | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/ops/routines/daily-standards-scan.md b/ops/routines/daily-standards-scan.md index 8ed5ac19..dc2fc83a 100644 --- a/ops/routines/daily-standards-scan.md +++ b/ops/routines/daily-standards-scan.md @@ -32,11 +32,29 @@ cases and **(b)** send one Slack summary of everything found. movement): `https://api.webstatus.dev/v1/features?q=baseline_status:newly` (public, no auth, JSON) lists features that have _newly_ reached Baseline; add `baseline_date:..` to scope to this run's window — use a trailing ~8-day - window so a skipped run never drops a feature. `baseline_status:widely` catches the - newly-Baseline → Widely transition (a feature now safe to rely on everywhere). This is - the discovery step for section #2's Baseline check; the MDN MCP then corroborates each - hit and supplies the canonical primary-source URL. It is derived data, not editorial — - trustworthy as a signal, but a page still cites the primary standard, not webstatus.dev. + window so a skipped run never drops a feature. This is the discovery step for section + #2's Baseline check; the MDN MCP then corroborates each hit and supplies the canonical + primary-source URL. It is derived data, not editorial — trustworthy as a signal, but a + page still cites the primary standard, not webstatus.dev. + + **`baseline_date` always matches a feature's _low_ date** (the day it went _newly_), even + when you filter on `baseline_status:widely`. Widely is reached ~30 months after newly, so + a feature that goes Widely today has a low date ~30 months in the past. This means the + intuitive query — `baseline_status:widely AND baseline_date:` — is + **always empty** and silently reports "no transitions" forever. To catch the newly → + Widely transition, offset the window back ~30 months: + + ``` + # Newly Baseline this run (trailing ~8-day window on the low date): + baseline_status:newly AND baseline_date:.. + + # Went WIDELY this run — same window shifted back 30 months: + baseline_status:widely AND baseline_date:.. + ``` + + Sanity-check the offset against the returned `baseline.high_date` rather than trusting + the 30-month rule of thumb; the API returns both `low_date` and `high_date` per feature. + - Adjacent (watch, don't blindly trust): `web.dev` — especially — `developer.chrome.com`, Google Search Central — for emerging conventions worth promoting LATER