This guide is for people changing the dashboard user interface.
What the Frontend Is Supposed to Do¶
The frontend should help a human answer these questions fast:
- what is healthy;
- what is risky;
- what is blocked;
- where do I drill down next.
If a screen does not help with one of those, it is probably noise.
What the Frontend Must Respect¶
The frontend should surface the current architecture clearly:
- code health from the graph layer;
- context readiness from the memory layer;
- session and lifecycle trust from the governance layer.
That is more important than adding another decorative chart.
For the SCA pages, the frontend contract is project-first. Use projectCatalog() to list projects, then load project-specific data through projectScaSummary(name), projectScaDependencies(name), projectScaVulnerabilities(name), and projectScaSbom(name). Treat scaOverview as a portfolio-only SCA aggregate, not as the primary data source for a single project page.
For notification screens, the page is not pre-populated by default. The runtime should call bootstrapNotificationRuntime(body) and load live data through POST /api/v2/dashboard/subscriptions/bootstrap. If you only see demo cards, that is not production evidence.
The frontend guide should also distinguish deck capture from live runtime. The file frontend/scripts/capture_sales_deck_ui.mjs exists for screenshots and fixtures, not as proof that the real notification stream is already loaded.
For portfolio work, the frontend should also expose saved views and portfolio alerts. A saved view lets a person reopen the same filter set, and portfolio alerts let a team subscribe to the same portfolio condition without rebuilding the screen by hand.
A Good Dashboard Screen¶
A strong screen should:
- explain itself quickly;
- show status changes clearly;
- make degraded states visible;
- let the user move to the next decision fast.