I0905 — Liveness and readiness are registered capabilities, not router hacks
Expose cheap liveness and readiness endpoints through the capability registry, so that the provider health check, the container test and the smoke suite all point at routes the registry knows about.
DONE wave 2 · p0 · implementation profile · parallel safe
Objective
Expose cheap liveness and readiness endpoints through the capability registry, so that the provider health check, the container test and the smoke suite all point at routes the registry knows about.
Why
A health route added directly to the router would be invisible to OpenAPI, to the documentation and to the route-derived smoke suite — three projections silently missing the one endpoint the platform polls most.
Current state
system.health still aggregates index diagnostics, benchmark coverage and projection staleness, and liveness and readiness are now separate registered capabilities in apps/majordomus-cli/src/capability/builtin/health.rs, each with its own handler and unit tests. 2026-09-10 changed the surrounding half as well: ADR 0035 made the server's own state a capability (server.status, GET /api/v1/server), the health report names the process behind the address, and readiness stopped meaning three unrelated things (PR #153, PR #164). What is not established here is the rest of the contract -- the measured cost inside the blocking-check budget, and a deployment object whose validation refuses a reference to a route that is not registered. Measured on master 6042f4286, 2026-09-10.
Desired state
Liveness answers whether this process is alive, cheaply and without touching the layer. Readiness answers whether it can serve traffic, checking only local initialisation. Both are registered, both are documented, and both have measured cost.
Scope
- apps/majordomus-cli/src/capability/builtin/health.rs
Out of scope
- Contacting any external provider or network service to decide readiness
- Replacing or weakening the existing system.health aggregate
Dependencies
What waits on this
- I0909READY The production image is a generated projection of the build specification
- I0916BLOCKED The smoke suite is derived from the route registry, never written twice
Acceptance criteria
- Liveness returns quickly with no filesystem traversal, no index build and no network access
- Readiness checks only the local initialisation required to serve, and never an external provider
- Neither requires authentication and both are registered capabilities that appear in OpenAPI and the generated reference
- The measured cost of each is recorded and stays inside the blocking-check budget the policy declares
- The canonical deployment object references these routes and validation would refuse a reference to a route that is not registered
Validation
- cargo test --workspace --all-features
- majordomus generate --check
Evidence required
- healthz_registered
- readyz_registered
- cheap_measured
Evidence
| covers | type | command | result | at commit |
|---|---|---|---|---|
| healthz_registered | test | cargo test --locked --manifest-path apps/majordomus-cli/Cargo.toml --lib -- capability::builtin::health | test result: ok. 12 passed; 0 failed — incl. both_are_registered_routes (health.rs:963), liveness_is_the_same_answer_whatever_the_layer_holds (:924), readiness_reports_what_this_process_already_holds (:947); run 2026-10-22 ~22:40Z on macbook-2 at e2c9675d6df (master 2034d4a + one health change) | 355a0ce |
| readyz_registered | test | cargo test --locked --manifest-path apps/majordomus-cli/Cargo.toml --lib -- capability::builtin::health | test result: ok. 12 passed; 0 failed — incl. both_are_registered_routes (health.rs:963), liveness_is_the_same_answer_whatever_the_layer_holds (:924), readiness_reports_what_this_process_already_holds (:947); run 2026-10-22 ~22:40Z on macbook-2 at e2c9675d6df (master 2034d4a + one health change) | 355a0ce |
| cheap_measured | artifact | majordomus bench health.live / health.ready, quick profile, debug build: p99 2.1 ms and 6.4 ms over HTTP, under blocking_check_ms 25 (recorded in the deployment object) | 355a0ce |
Risk
A readiness check that grows into a dependency probe will fail a deployment because an unrelated service is down. Readiness answers one question: can this process serve a page.
Timeline
- started
- 2026-10-23T00:48:36Z
- verified
- 2026-10-23T00:49:20Z
- completed
- 2026-10-23T00:49:53Z
Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.
Canonical record: .ai/repo/project/issues/I0905.yaml. Read it back with majordomus plan show I0905.