I0905 — Liveness and readiness are registered capabilities, not router hacks

BLOCKED wave 2 · p0 · implementation profile · parallel safe

Part of fly-deployment — A deployment is a projection of the repository model, and a reachable URL is its evidence.

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 exists as a capability and aggregates index diagnostics, benchmark coverage and projection staleness. It is not a liveness probe: it is expensive and it can legitimately report failure while the process is perfectly able to serve traffic.

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

• I0902BLOCKED The deployment object becomes typed Rust that refuses nonsense

What waits on this

• I0909BLOCKED 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

None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.

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

—

verified

—

completed

—

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.