Plugin v0.79.0 added the render_readiness metric (series verdict, unmet, shortfall, rebaseline, satisfied_ms; see packages/plugin/METRICS.md). The console does not read any of it. The coverage guard in packages/console/test/adminAssets.test.js caught this — it fails on main as of 0.79.0 — and is being waived with a pointer here so the plugin fix train is not blocked on a console release.
What the panel needs to answer
This metric exists to make two decisions, in order:
- Is the fleet storing incomplete renders?
verdict by contract: satisfied vs unsatisfied share. unmet by clause: which assertion fails — one clause failing across every render of a page type is a rotted contract (template changed), not a slow fleet.
- Can the contracts be armed, and with what timeout?
satisfied_ms p50 / p95 / p99 per contract against that contract's configured timeoutMs. If p95 approaches the timeout, arming would abandon the contract under load and the optimisation is quietly gone.
Plus the content-loss signal once armed: shortfall by observation and rebaseline counts, per contract.
Readout semantics to get right
verdict is one per governed device variant, so a two-device job emits two. Shares should be read against render.time_ms (one per rendered device), not render.outcome (one per posted result).satisfied_ms is a value series with mean/median/p95 from the plugin analytics endpoint (p99/p999 only from Harper's get_analytics). Unsatisfied renders contribute nothing to it, by design.unmet does not sum to renders — read it against the unsatisfied count. A row where every clause of a contract is unmet is an execution context lost mid-settle (client-side navigation), not rot.shortfall compares a page (URL + device) against its own history; it is silent on a first render and after a rebaseline.
Where it is read today
Raw only: GET /prerender_admin/analytics?range=<ms> → .series[] | select(.metric == "render_readiness") per node; the console's /prerender_console/analytics already returns the rows (keepRow keeps every catalogued metric) — there is just no panel.
🤖 Generated with Claude Code
Plugin v0.79.0 added the
render_readinessmetric (seriesverdict,unmet,shortfall,rebaseline,satisfied_ms; seepackages/plugin/METRICS.md). The console does not read any of it. The coverage guard inpackages/console/test/adminAssets.test.jscaught this — it fails onmainas of 0.79.0 — and is being waived with a pointer here so the plugin fix train is not blocked on a console release.What the panel needs to answer
This metric exists to make two decisions, in order:
verdictby contract: satisfied vs unsatisfied share.unmetby clause: which assertion fails — one clause failing across every render of a page type is a rotted contract (template changed), not a slow fleet.satisfied_msp50 / p95 / p99 per contract against that contract's configuredtimeoutMs. If p95 approaches the timeout, arming would abandon the contract under load and the optimisation is quietly gone.Plus the content-loss signal once armed:
shortfallby observation andrebaselinecounts, per contract.Readout semantics to get right
verdictis one per governed device variant, so a two-device job emits two. Shares should be read againstrender.time_ms(one per rendered device), notrender.outcome(one per posted result).satisfied_msis a value series withmean/median/p95from the plugin analytics endpoint (p99/p999only from Harper'sget_analytics). Unsatisfied renders contribute nothing to it, by design.unmetdoes not sum to renders — read it against theunsatisfiedcount. A row where every clause of a contract is unmet is an execution context lost mid-settle (client-side navigation), not rot.shortfallcompares a page (URL + device) against its own history; it is silent on a first render and after a rebaseline.Where it is read today
Raw only:
GET /prerender_admin/analytics?range=<ms>→.series[] | select(.metric == "render_readiness")per node; the console's/prerender_console/analyticsalready returns the rows (keepRowkeeps every catalogued metric) — there is just no panel.🤖 Generated with Claude Code