the-daily-epub/docs/plans/briefs/web-dashboard/03-dashboard-reads.md

Step 3 — Dashboard reads: overview, runs, articles

Read 00-shared.md, the plan (§3, §4, §9 in full, §16, §17 "Dashboard queries"), the curation v2 plan sections it cites (docs/plans/2026-09-02-personalized-curation-v2.md §7 tables, §9–§13 signals/admission/utility/editor, §15 explain/stats) and the handoffs for steps 1–2. This is plan §19 item 3. Study src/curate/telemetry.rs (ExplainRow, resolve_run, explain_row, near_misses, render_explain, SignalsJson) — the dashboard renders the same data as HTML and must reuse those loaders/types where they fit rather than re-deriving them.

Deliverables

1. src/web/dashboard/mod.rs — the overview (§9.1): last-run card from runs.report_json (counters fallback), budget-today card per provider (config.referenced_providers() + voyage, db::provider_spend_for_utc_day), ratings this week by label, "Unrated picks" (last three issues' picks with no explicit event, with the inline rating widget from step 2), jobs summary (the jobs table; the pages come in step 6), config-on-disk ! lines from Config::check_report. Sparklines are step 6 — leave a clearly marked placeholder section or omit.
2. src/web/dashboard/runs.rs (§9.2): the list with ?status= filter and pagination; the detail with header + prev/next run, the funnel (from candidate_runs grouped by stage/reason, in pipeline order, bars via the .funnel CSS), admission mix, preference state, timings, provider usage, warnings, per-feed top 20, the config diff against the previous non-dry run (flatten both config_json documents to dotted keys), near misses via telemetry::near_misses, and the candidates table with the allow-listed filters (stage, reason, admitted_by via json_extract(admitted_by,'$[0]'), q, flag) and sorts (utility default, rank, triage, quality, fit, title), 100 per page, a <details> per row with _signals_table.html built from signals_json.
3. src/web/dashboard/articles.rs (§9.3): the list with the latest candidate_runs row join (the index idx_candidate_runs_article_run exists from migration 0004 — confirm), all listed filters and sorts allow-listed, 50 per page; the detail with the six blocks in the plan's order (article facts, assessments incl. provider_rejected, run history with expandable signals, neighbours/interests, embedding metadata never the vector, rating events). The "Explain (text)" <details> wraps telemetry::render_explain output in <pre>. The rating widget here carries the note field.
4. Templates: dashboard/overview.html, dashboard/runs.html, dashboard/run.html, dashboard/articles.html, dashboard/article.html, partials _signals_table.html, _candidate_row.html. Every table inside .scroll-x; badges per stage/reason/label; sticky thead; the data-filter client-side filter from §4.4 in app.js.
5. Sort/filter parameters are validated against allow-lists and never interpolated into SQL; an unknown sort falls back to the default, never errors.
6. Tests (§17 "Dashboard queries"): funnel counts against a seeded candidate_runs set; candidate filters/sorts allow-listed; config diff finds changed dotted keys and ignores unchanged; articles list filters; article detail shows assessments, run history and rating events. Router-level tests for the admin guard on each new route.