Module health 

The health module: whether what this process serves is healthy, answered by the engines that already decide it rather than by checks written a second time here.

The module is health and not system because the benchmark projection reserves system for the transports’ own targets (system.http.index, system.mcp.ping) and buckets its coverage by that name. A capability module called system would have its lines tallied as transport targets and silently vanish from the per-transport denominators; reserved_namespace_is_not_a_module holds that shut.

Every check delegates: the index’s own diagnostics say whether the layer read cleanly, the benchmark projection’s coverage says whether every executable capability is timed, generate --check — the same comparison the command runs — says whether the committed projections are stale, and crate::capability::builtin::server::standing_at — the reading server.status answers from — says where the shared server of this checkout stands. A check that computed its own verdict would be a second opinion, and two opinions drift.

Four readings of “ready”, and why none of them is this one

This crate answers “ready” four times, about four different subjects. The full table, with what asks each one, is in docs/MCP.md; in short:

• crate::http::Served::ready — is a surface’s producer’s output on disk? Per surface, and what the home page renders as not built.
• Readiness (health.ready, GET /api/v1/ready) — can this process answer a request? Local initialisation only, never a dependency: a readiness probe that contacts another service fails a deployment for something that is not this process.
• crate::environment::ServiceAvailability — does anything accept a connection at the address the lease published? One bounded TCP connect, no DNS, because it runs on a shell prompt.
• crate::capability::builtin::server::ServerStanding — is what answers at that address current: this checkout’s server, from the file on disk, at this version?

The server check below is the fourth, and it is the only one of them that a health report should carry: the first is per surface, the second is the report’s own caller, and the third cannot tell a live server from a socket somebody else holds.

Structs

Health

The health of what this process serves.

HealthCheck

One dimension of the system, decided by one engine, with what a reader needs to check it themselves.

Liveness

The answer to “is this process alive”: the cheapest true thing this executable can say about itself. Deliberately not a summary of anything — a probe that grew an opinion would stop reporting the one fact the platform polls it for.

Readiness

The answer to “can this process serve traffic”: the local initialisation a request would need, and nothing beyond this process. A readiness check that grew a dependency probe fails a deployment because an unrelated service is down.

Enums

HealthStatus

Where one dimension of the system stands. Ordered by severity, so the worst check decides the whole.

Constants

HEALTH_URI

The URI under which system.health is read as an MCP resource.

PROCESS_DIMENSIONS

The dimensions that describe the process serving a checkout and not the repository: the shared server, its peer board and its mesh runtime. Only a process holding the checkout’s lease decides the last two, so in any other they are unknown by construction, never by a fault of the repository.

Functions

module

The module.

repository_status

The worst status among the checks that describe the repository (every one whose id is not in PROCESS_DIMENSIONS); ok when there is none.