The dashboard is for seeing the whole situation quickly.
It is not where deep work happens. It is where you answer:
- which projects are healthy;
- which ones are risky;
- which ones are blocked for release;
- where context, quality, or governance is drifting.
Who It Is For¶
The dashboard is most useful for:
- engineering leads;
- security leads;
- release owners;
- people watching many projects at once.
What You Should See First¶
A useful dashboard should show:
- project health;
- release readiness;
- review and quality drift;
- dependency and supply-chain risk;
- whether context is fresh or lagging.
Why the New Architecture Changes the Dashboard¶
The dashboard is no longer only about code health. It also needs to show:
- session continuity risk;
- memory readiness;
- handoff visibility;
- knowledge state drift.
Without that, a project can look healthy while its context layer is quietly degrading.
How to Read It¶
Start with three questions:
- Is the project healthy?
- Is the project ready?
- Can users trust the context behind that answer?
If the third answer is weak, the first two are weaker than they look.
Portfolio History¶
Portfolio History shows how the same portfolio changed across time windows. Use it when you need to compare today with an earlier period, explain why the red zone changed, or reopen a stable baseline before a review meeting.
When you export a portfolio report, keep the export context stable. In practice that means the same filters, the same period window, and the same saved view should drive the export, so the report stays reproducible.
Notification Runtime Reality¶
The notification page becomes useful only after the runtime has live data.
test-send requires a real project context- the live bootstrap endpoint is
POST /api/v2/dashboard/subscriptions/bootstrap - a successful test delivery is not the same thing as a populated live inbox
If you are validating notifications, bootstrap a real project first and only then judge what the page shows.