Module dashboard 

The dashboard module: the Overview of the Dashboard Suite, as a projection of the capabilities that already answer each of its facts (ADR 0088).

A dashboard has no data of its own. dashboard.overview answers four questions — is it healthy, what changed, what is broken, what needs action — and every card under them is one fact read out of another capability’s answer through the same executor MCP, the HTTP routes and the Cockpit use. Nothing here is stored, counted or judged a second time: the card carries the capability it asked, the input it asked with, and the RFC 6901 pointer into that answer its value was read from, so a reader — or a test — can ask the source the same question and get the same value.

The value is the source’s, exactly. A card’s DashboardSource::measure is one of two readings, and neither is arithmetic on the source’s behalf:

• DashboardMeasure::Exact — value == answer.pointer(pointer), and null when the pointer resolves to nothing;
• DashboardMeasure::Count — the number at the pointer, or the length of the list or map there, and 0 when the source left it out: the sources omit an empty list and a zero tally (skip_serializing_if), so absence is their way of saying none.

tests/dashboard.rs and test/cases/534_the_overview_answers_four_questions.sh hold that sentence for every card, naming none: they execute each card’s source with its input and compare. A card that computed its own number fails them.

Status words are the sources’ verdicts. fail where the source says something refuses (a failing check, a worktree out of place, a question that refuses finish), warn where it names something worth looking at (a pending bump, a blocked issue, two workers claiming one scope), ok otherwise — and unknown, never ok, when the source could not answer, with its error as the card’s detail. No threshold is invented here.

It is cheap. Each source is asked once per answer, and the sources are the ones that read what this process already holds: no delivery report, no release analysis, no evidence judgement — nothing that rebuilds canonical state or refuses on a network. They are asked at once, so the answer costs its slowest source, not the sum of them.

use majordomus_cli::capability::builtin::dashboard::module;

// one capability, reachable from every surface the registry projects
let m = module();
let c = &m.capabilities[0].capability;
assert_eq!(c.id.as_str(), "dashboard.overview");
assert_eq!(c.exposure.http.as_ref().unwrap().path, "/api/v1/dashboard/overview");
assert_eq!(c.exposure.cli.as_ref().unwrap().path, ["dashboard", "overview"]);

Structs

DashboardCard

One fact on a dashboard: a value read out of one capability’s answer, the verdict the source gives it, where a reader drills in, and what acts on it.

DashboardOverview

The Overview: four questions, each answered by facts other capabilities hold.

DashboardQuestion

One of the four questions the Overview answers, with the cards that answer it.

DashboardSource

Where a card’s value came from: the capability asked, the input it was asked with, and the pointer into its answer. Asking the capability the same question and reading the pointer with the same measure yields the card’s value; that is the whole contract.

Enums

DashboardMeasure

How a card’s value is read out of its source’s answer. Neither reading is arithmetic on the source’s behalf.

Functions

module

The dashboard module: the Dashboard Suite’s pages, each a projection of the capabilities that hold its facts. The Overview is the first.