Health
The same verdicts `capabilities validate`, `bench coverage --check` and `generate --check` reach, read through one capability.
Where this stands
a dimension could not be decided
Every check is decided by an engine that already decides it elsewhere. The Cockpit has no health checks of its own.
The layer as it was read
ok2325 object(s) indexed; 0 error(s), 0 warning(s)
- Decided by
- the index's own diagnostics
- Observed
- index build as of 2026-10-18T00:05:58Z (12 s ago)
majordomus capabilities validateThe capability registry
ok2527 capabilities (202 builtin, 2325 declarative) across 92 modules; fingerprint cfc64482a679
- Decided by
- the registry builder; it refuses to build on a duplicate or a malformed exposure
majordomus capabilities validateThe declared scope
ok6014 of 6656 tracked file(s) in scope, 642 out, read from .ai/repo/scope.yaml
- Decided by
- the scope declaration the index was built under
majordomus scopeVersion control
warnmaster at 707a04c7ce83, working tree dirty
- Decided by
- git, as the index asked it when it was built
- Observed
- git read as of 2026-10-18T00:05:58Z (12 s ago)
git statusBenchmark coverage
warn523 of 605 target(s) covered, 0 missing, 82 waived
- Decided by
- the benchmark projection's coverage, the same one `bench coverage --check` reads
majordomus bench coverage --checkCommitted projections
okdocs/generated/registry.json matches the registry this process built
- Decided by
- the same rendering `majordomus generate` writes, compared with what is committed
majordomus generate --checkHandovers published across machines
ok0 record(s) admitted, 0 refused, 0 resumable from another device
- Decided by
- the admission and lineage checks of `continuity.status`
majordomus-cli continuity statusThe shared server
okabsent: no lease at /home/runner/work/prismatic-majordomus/prismatic-majordomus/.ai/local/state/mcp/server.json, so nothing serves this checkout
- Decided by
- the decision `server.status` makes, from this checkout's lease and one probe of the server it names
majordomus serve statusAttached clients
unknownthis process holds no peer board: it does not hold this checkout's lease, so who is attached is the server's to say
- Decided by
- the peer board of the process holding this checkout's lease, tallied as `environment.preflight` tallies it
majordomus_peersmajordomus serve statusThe mesh runtime
unknownthis process runs no shared server, so no mesh was activated or declined here; ask the server (GET /api/v1/health) or run `majordomus mesh doctor`
- Decided by
- whether a shared server decided the mesh in this process