the-daily-epub/docs/plans/briefs/web-dashboard/handoff-step3.md

Step 3 handoff — dashboard reads: overview, runs, articles

Landed

• src/web/dashboard/mod.rs: the overview (§9.1) — last-run card built from runs.report_json via RunReport::info_block() (legacy-counter fallback when the report is missing or unparseable), budget-today <meter> per referenced provider plus voyage from db::provider_spend_for_utc_day(now), ratings this week by label, "Unrated picks" (last three issues' picks with no explicit event, each with the step 2 rating widget posting back to /dashboard), a jobs summary read straight from the jobs table (active rows plus the last five finished; the pages themselves are step 6), and the ! lines of Config::check_report. Sparklines are a marked HTML comment for step 6. The module also carries the helpers the read pages share: Pager, SignalsView (the parsed signals_json behind _signals_table.html), allow_listed, like_pattern, Bind/bind_all/ dynamic_query, formatting helpers, and the STAGES/REASONS/ RETRIEVERS allow-lists.
• src/web/dashboard/runs.rs (§9.2): /dashboard/runs with ?status= and pagination (50), and /dashboard/runs/{id} with header (issue link when the issue exists, previous/next run by id), the funnel from candidate_runs grouped by stage and reason, admission mix, preference state, timings, provider usage, warnings (#warnings anchor used by the overview and the list), top-20 feeds, the config diff (flatten_json + config_diff) against the previous non-dry run that recorded a config, ten near misses via telemetry::near_misses, and the candidates table (100 per page) with the stage/reason/admitted_by/q/flag filters and utility (default)/ rank/triage/quality/fit/title sorts. Each row's title is a <details> that expands _signals_table.html.
• src/web/dashboard/articles.rs (§9.3): /dashboard/articles (50 per page) joining the best entry, the latest candidate_runs row through the MAX(run_id) subquery (the index idx_candidate_runs_article_run is in migration 0004 — confirmed), both assessments, the current explicit rating and the latest publication; every listed filter and sort; /dashboard/articles/{id} with the six blocks in the plan's order, provider_rejected rows called out as such, run history rows expanding their signals, neighbours/interests from the latest row, embedding metadata only (never the vector), all rating events with source/user/note/value, the rating widget with show_note = true, and "Explain (text)" wrapping telemetry::render_explain verbatim in <pre>.
• Templates: dashboard/overview.html, runs.html, run.html, articles.html, article.html, partials _signals_table.html, _candidate_row.html and dashboard/_pager.html. Every table sits in .scroll-x; badges per stage/reason/label/status; tables carry data-filter.
• app.css / app.js: one appended block each (/* step 3 … */): cards, filters, funnel bar, pager, signals details, diff colours, and the filter-as-you-type behaviour for table[data-filter] (inserts a search input before the table's .scroll-x wrapper, hides non-matching rows on the current page only).

Deviations and notes

• sqlx 0.9 dynamic SQL. sqlx::query only accepts &'static str or AssertSqlSafe, so the list queries go through dashboard::dynamic_query, which wraps the assembled string in AssertSqlSafe. The audit holds because the string is built only from constants and allow-listed fragments (CANDIDATE_SORTS/ARTICLE_SORTS map names to fixed ORDER BY text); every user value is bound through bind_all. An unknown sort or filter value falls back to the default / is dropped, never an error.
• Funnel semantics. stage records where a row stopped, so the bars show the cumulative "reached" count (rows at this stage or a later one, so the first bar is everything considered) with "stopped here" and the reason breakdown beside it. Widths are <svg width="N%"> children of .funnel because the CSP (style-src 'self') forbids inline style attributes; the budget card uses <meter> for the same reason.
• Prev/next run links go to the neighbouring run ids overall (the header already links the date's issue); a rerun of the same date is therefore the immediate neighbour.
• Extract method is not shown on the article page: db::article_from_row hard-codes ExtractMethod::Miniflux for every loaded article, so the value would be meaningless. excerpt_only is shown instead. Source kinds render via their Debug names (Feed, Scour, …).
• admitted_by filter is allow-listed against the six retriever names and still applied as the plan's prefix LIKE on json_extract(admitted_by, '$[0]').
• The _pagination.html partial from step 1 (text only) was left alone; the dashboard uses its own dashboard/_pager.html with prev/next links that preserve the other query parameters.
• Only additive edits outside my files: two appended blocks in app.css and app.js. No changes to web/mod.rs, db.rs, rate.rs or telemetry.rs (a private first_retriever in telemetry was reimplemented as admitted_by_parts rather than made pub).

Left for later steps

• Step 6: overview sparklines (placeholder comment in overview.html), and the /dashboard/jobs pages the overview's job links point at.
• Step 4: /dashboard/ratings, linked from the overview's ratings card.
• The overview's ratings-this-week card counts all explicit events in the last seven days by label (a cleared is listed but not counted in the total).

Verification (outside the sandbox)

• cargo fmt: pass.
• cargo clippy --all-targets -- -D warnings: pass.
• cargo test web::dashboard: 11 passed, 0 failed.
• cargo test (full suite): 387 lib tests passed, 0 failed, plus every integration test binary green (7, 2, 3, 4, 7, 9, 2), nothing skipped.