Skip to content

The Cockpit: the registry rendered for a person

The same server that answers agents renders every capability, object, graph, worktree and health check as pages, with a runner generated from each capability's own schema; nothing on it is a second list.

status
feature status: stable
domain
Surfaces
on the homepage
featured

What it does

Every page asks a capability through the one executor MCP and the HTTP routes use, so the Cockpit cannot answer a question differently from the API. The sidebar's catalogues are the registry's modules, the index's kinds and the graph derivations; a capability's page carries its schemas, its projections, its provenance and a form generated from its input schema that calls its real route. A capability, a kind or a graph added to the backend has a page, a navigation entry and a search entry the first time it exists, with no line of the Cockpit written for it.

The browser layer is an enhancement in the strict sense: a command palette, the runner, a graph drawing and two optional views, under a strict content-security policy with no inline script and no remote origin. With JavaScript off every page still shows everything it knows.

What it does not do

It holds no model, no catalogue and no verdict of its own. It writes nothing of its own either: what writes is a declared command, which the runner can reach like any other capability, and a command whose declared effect is repository_mutation carries that warning on its Run card before it is sent (docs/COCKPIT.md, "What writes is declared"). It is not the published website; that is a static projection of the same registry with no server behind it.

Why it exists

Operational moments from the Why catalogue that name one of this feature's mechanisms. Nothing here was assigned: a moment appears because it names a rule, a command, a capability or a claim this feature also names.

Every moment it answers (11)

How it works

The capability modules of the executable this feature names, each with the capabilities it composes. The interfaces each one reaches are listed under Interfaces below: they are projections of one declaration, not separate registrations.

Health health behaviorally verified

Whether what this process serves is healthy, decided by the engines that already decide it: the index's diagnostics, the registry builder, the benchmark projection's coverage, the comparison `generate --check` makes and the lease reading `server.status` answers from. No check here has an opinion of its own.

Design system design behaviorally verified

The one declaration of how every surface of this tool looks — the semantic roles, the status vocabulary, the type scale, the theme contract — as this executable carries it: its fingerprint, its tokens, what any one of them means, and whether the colours it pairs are readable on one another. The stylesheets the site and the Cockpit load, the tokens the executable's own pages compile in, and the dataset the site's templates read are all projections of it; a page compares its `--mj-design` with this fingerprint to know whether it is wearing the design this executable was built with.

Dashboards dashboard behaviorally verified

The Dashboard Suite as a projection of the canonical state: every card is one fact read out of an existing capability's answer, carrying the capability it asked, the input, the JSON pointer its value was read from, the Cockpit page that holds the evidence and the command that acts on it. No dashboard stores, counts or judges anything of its own (ADR 0088).

Where it sits

domain
Surfaces — One declaration in the repository becomes the command line, the HTTP API, MCP, the UI, the Cockpit, the documentation and this site, and a projection that disagrees with it fails the build.
areas of work
observability
names
Declare onceInterfaces
named by
Declare onceObservatoryUI

Interfaces

Each capability behind it, on every interface it is projected onto. A link goes to this site's reference for that interface; an HTTP route and an MCP tool are answered by a running majordomus serve, not by this site.

The capabilities behind this feature, by interface
capabilitycommand lineHTTPMCP tool
health.live —none GET /api/v1/live —none
health.ready —none GET /api/v1/ready —none
health.report —none GET /api/v1/health majordomus_health
design.contrast —none GET /api/v1/design/contrast majordomus_design_contrast
design.explain —none GET /api/v1/design/explain majordomus_design_explain
design.system —none GET /api/v1/design majordomus_design
design.tokens —none GET /api/v1/design/tokens majordomus_design_tokens
dashboard.overview majordomus dashboard overview GET /api/v1/dashboard/overview majordomus_dashboard_overview
in the Cockpit, of a running server
/cockpit Overview
/cockpit/capabilities Capabilities
/cockpit/objects Objects
/cockpit/directories Directories
/cockpit/graphs Graphs
/cockpit/continuity Continuity
/cockpit/worktrees Worktrees
/cockpit/health Health
/cockpit/artifacts Artifacts
/cockpit/design Design
/cockpit/api API
served by the executable
/cockpit The registry, rendered for a person

Evidence

What is guaranteed

Each claim this feature names, with the status its row declares, the verdict the recorded runs support, and the test that settles it.

The rules that hold it

  • blocking External interfaces are projections of one capability definitionproject.interfaces-are-projections

The decisions behind it

Using it

From the executable's command line

The synopsis of each, as the executable's own help prints it.

  • majordomus dashboard overview [OPTIONS]

    Is it healthy, what changed, what is broken, what needs action: every card with its value, the source's verdict, and the capability and pointer it was read from; exit 10 when the overview is fail or unknown

Where this page comes from

the file
.ai/repo/features/cockpit.md
the same answer
majordomus product show cockpit
read further

The Cockpit — the registry, rendered for a person

Searches the titles and descriptions of every page this site publishes.