nx_toolatency.nx

nx_toolatency.nx -- LATENCY CENSUS FOR THE TOOL SURFACE: the evidence behind async-lane routing. WHY THIS EXISTS (2026-08-07). The 503 class is a LATENCY problem. The edge closes its window at 15s (NX_SD2_BACKEND_TIMEOUT_S) and the synchronous lane is budgeted at 14s (TEA_EXEC_TIMEOUT_SYNC_MS), so a call that outruns the budget becomes a 503 WHOSE WORK MAY STILL HAVE LANDED -- the caller is told it failed for a row that exists. async_only_tools.conf fixes that by forcing a tool onto the detached job lane, but its membership was a HAND-WRITTEN LIST of tools somebody noticed failing. You cannot route by a latency you never measured, and until today the daemon logged WHAT ran and WHETHER it worked but never HOW LONG. ta_actlog now emits dur_ms (TOTAL HANDLER TIME, the quantity the edge window actually applies -- exec time alone would understate it). This organ is the consumer that turns those rows into a routing decision, so the lane stops being folklore. TAIL-ANCHORED BY CONSTRUCTION. actlog.jrnl is APPEND-ONLY, so a head-anchored capped read keeps the OLDEST bytes and silently drops the NEWEST -- exactly backwards for a gauge whose job is to notice what got slow LATELY. Measured cost of that mistake in this same estate: nx_wirecensus read this very ledger head-anchored and was blind to 89 invocation records. REFUSES rather than reporting GREEN over data it never read: no-slow-tools and no-measurements are different facts and must not share a representation. DURABLE + ROSTERABLE (2026-08-27, 503 lane): every run appends ONE row to knowledge/status/toolatency.log (its own file, one writer -- the rm_trend_log law), so two runs are a TREND and a fired beat is distinguishable from a dead one. The row carries `unrouted=` -- the over-budget tools still on the sync lane -- so the count travels with its worklist. Refusals write a NODATA row too: an abstention that leaves no artifact is indistinguishable from a beat that never fired.