nx_weblatbench.nx

nx_weblatbench.nx -- STANDING LATENCY BENCH for the WEB serve (operator standing order 2026-08-12: progress claims need a referee that is not the claimant -- until this organ existed, every /search speed number was an ad-hoc probe chosen by the seat that wanted the number to look good). Fixed 8-query set spanning every measured shape, driven through the LIVE serve over LOOPBACK (127.0.0.1:18456 /api/search?scope=web -- the exact production stack; fetch pattern composed from nx_web_relevance_bench). One pass per run, SEQUENTIAL (this bench must never itself hammer the box: envelope = 8 queries/run, beat hourly, log ~200B/run). PRE-DECLARED ACCEPT RULE (before the first run, 2026-08-12; RATCHET DOWN as rungs land, never up): GREEN iff ok=8/8 fetches (HTTP 200 + JSON marker) AND the did-you-mean tooth fires AND p50 <= 3000ms AND max <= 20000ms. WHY these numbers: in-window queries measured 0.25-2.8s on 2026-08-12 (p50 3000 = that + margin); max 20000 deliberately TOLERATES one reopen-lottery draw (measured 10.2-11.5s, debt 1786555686) so the bench reports the tail without being permanently RED -- a detector that is always RED is one everyone learns to ignore. When the incremental-refresh re-lands, ratchet max to 5000. Output: per-query ms ALWAYS printed (a gate that reports only a boolean cannot say why), last line verdict=GREEN|RED (positional anchor), exit code carries the verdict. Appends one row per run to knowledge/status/weblatbench.log (append-only; the DISTRIBUTION over beats is the instrument -- a single run is still just a sample and must never be quoted as the population). license_tier: ORIGINAL No hw writes (Rule 26).