backend module manifest ops
operator-facing status APIs
runtime-node registration, heartbeat, composition, stale-node, and expected replica projection
audited API and worker drain/cancel controls
recovery-operation status and evidence-chain summaries
governance inventory for module-declared permissions, roles, capabilities, policies, documentation, access-control hooks, search providers, and migration ownership
sanitized runtime health, freshness, conflict, and recovery state for configured external-provider bindings
deployment profile and sizing assumption summaries
WebUI route contribution @govoplan/ops-webui
future operational runbooks that describe the configured platform rather than generic product possibilities

Core owns lifecycle management, module discovery, maintenance mode, package installation safety, and shared WebUI shell behavior.

Core exposes the registry contract but does not own an operations dashboard. Ops projects the provider-neutral registry metadata and runtime checks into the operator-facing governance surface.

Provider declarations describe supported behavior; module-owned runtime-state providers describe the currently configured bindings. An optional provider failure is isolated and reported as an attention state without suppressing the rest of the governance inventory. Secrets, endpoints, and raw provider errors are not part of this projection.

Runbooks

docs/SCALABILITY_PROFILES.md explains how to use the Ops page with the canonical sizing matrix, readiness model, and profile-selection worksheet.

The Runtime cluster panel is backed by Core's shared PostgreSQL coordination tables. A drain request is durable and is observed on the node heartbeat: API readiness closes and workers stop taking new queue work. The Recovery panel shows operations requiring forward recovery or manual intervention; it does not claim that a production database backup exists.