feat(dashboard): portfolio risk over time

[haksungjang]

The action queue says what is waiting. This adds the other half of the cockpit: whether the pile is growing — the question a report printed once cannot answer, because answering it needs history the tool has to have kept.

What the series says

GET /v1/dashboard/trends?days=7|30|90 returns one point per day carrying two kinds of number, which are not interchangeable:

• flows (new_findings / resolved_findings) — the set difference between a scan's open exposures and those of the previous scan of the same lineage. The naive portfolio version, today's total minus yesterday's, is wrong in a way that looks right: a CVE fixed in one project and a new one found in another cancel to zero, and the chart reports a quiet day on a day when two things happened.
• levels (critical_open / kev_open) — the standing exposure on each day, anchored to each project's latest succeeded scan on or before it, carried forward on days nobody scanned.

Every point also carries scan_count, which is what lets the UI tell the two apart honestly: a flat line can mean nothing changed or nobody looked.

The set difference runs in the database — a LAG window function for the predecessor, an anti-join each way — so one row per scan crosses the wire rather than one per finding. Five queries regardless of portfolio or window size.

What the security review changed

The Producer-Reviewer rotation (CLAUDE.md §7) traced all five queries and found no team-scope leak. It found two ways the chart would assert things that did not happen, and one way it would fail outright at scale. All three are fixed in d4173d24.

The predecessor ignored what a scan looked at. The LAG partitioned by project alone, so a container scan (OS packages) followed by a source scan (language packages) compared two sets that share nothing: the whole first set read as resolved and the whole second as new, then the inverse the next day. A pull-request scan against a branch is the same defect in miniature. The partition is now (project, kind, ref) — the line the retention model already draws by superseding only same-ref scans.

"No predecessor" did not mean "nothing came before". A first scan contributed its whole open set as new. But scan_retention hard-deletes superseded scans after a grace period of days, so a project scanned daily by CI keeps only its last week on disk, and every 90-day window would have opened with a fabricated spike of hundreds of "new" findings for exposure that had been sitting there for months. A scan without a predecessor now contributes no flow. Nothing is lost — the exposure still enters through the level series, where standing exposure belongs. On the local dataset a 30-day window moved from 1,685 new / 121 resolved to 112 / 227; the first pair was mostly fiction.

The level query round-tripped scan ids through Python, one bind parameter each, crossing asyncpg's 32767-parameter ceiling somewhere inside a 90-day window on a few hundred daily-scanned projects — a 500 visible only on the largest deployments, and only at the widest window. The ids stay in SQL as a subquery now.

Two test defects the review found are worth more than the code fixes. The HTTP isolation test gave team A no project, so the service hit its empty-portfolio early return and never ran a query — deleting every project_id filter in the module would have left it green. And the parity matrix never placed a base scan outside the window, so bounding the LAG by start_ts, the exact mistake its docstring exists to prevent, would have passed every case.

Parity, and how far it reaches

The flow rule now lives in two modules, which is the duplicated-vocabulary trap of hardening rule #2. The closed-status tuple is imported from project_diff_service rather than restated, and test_dashboard_trends_parity.py runs both paths over the same rows across six scenarios × four interference axes. The levels have their own oracle: a test pins the promise that the last point agrees with what /summary reports for today, tie-break included.

Both new rules are verified by mutation rather than assumed: removing the lineage partition fails six tests, removing the no-predecessor rule fails six others, reverting the exposure key fails five.

Two defects found on the way

project_diff_service keyed exposures on (cve id, version string), so one CVE against two packages sharing a version was one entry — a monorepo publishing in lockstep is the ordinary way that happens, and the second package silently vanished from both the introduced and the resolved list. The key is the exposure's identity now, and DiffVulnerability gains the purl, without which two Maven artefacts differing only by classifier render as one line repeated in a non-deterministic order.

The days parameter was typed Literal[7, 30, 90]. A query string arrives as "7" and a literal of ints refuses to coerce it, so every explicit window was rejected with a 422 while the default kept working — a shape no test of the default can see. It is an IntEnum now, re-checked in the service so a widened parameter cannot become an unbounded walk of scan history.

The panel

Three panels rather than one chart: levels and flows are different measures on different scales, and putting them on one plot means two y-axes. Direction carries the flow chart before colour does (new grows up, resolved down), the two hues are a validated pair (ΔE 8.6 under deuteranopia, both above the 3:1 non-text floor), and every value is also in a table view. Switching windows holds the previous series and dims it rather than dropping to skeletons.

--status-danger gains the solid the bars paint with — index.css said to declare one again when something painted with it, which also closes half of a drift where the design-system docs listed four solids for the one that existed.

Gates

• backend: unit + the three new suites green; ruff, mypy (whole tree, tests included) clean
• frontend: 1553 unit tests + 11 new green, tsc clean, token-lint holds at 130
• axe: the dashboard adds no violations
• EN/KO strings shipped together; ko-style 0 findings; design-system EN/KO updated

Visual baselines need recapturing on the Linux runner — the dashboard grew a panel. Doc screenshots are deliberately not regenerated here; that capture waited on containers that exist while their contents are skeletons, and it now waits on the loaded panels instead.

Not in this change

Triage does not survive a re-scan (persist_trivy_findings writes status="new" unconditionally), which this endpoint is the first surface to make visible as an oscillating chart, and which contradicts what the triage guide promises. _accessible_project_ids does not narrow by api_key_project_id — harmless while these routes are JWT-only, but it affects /summary and /action-queue too and should be fixed once in the shared helper. Both need their own tickets.