# Ops interface pattern migration

Ops uses the platform monitoring and governed-operation patterns. It projects sanitized state owned by Core and modules; it does not become the repair authority for domain effects.

## Surfaces

- `ops.page` is the route-level operations workspace and `ops.navigation` is its navigation entry.
- `ops.page.summary` presents readiness, capacity, queue, storage, backup, recovery, provider, and governance metrics.
- `ops.page.health` owns bounded module probes; `ops.action.run-probes` is available only to an operations runner.
- `ops.page.runtime` owns runtime heartbeats and the confirmed `ops.action.drain-node` lifecycle action.
- `ops.page.recovery` presents sanitized durable recovery evidence without replay controls.
- `ops.page.governance`, `ops.page.deployment`, and `ops.page.sizing` expose declared architecture, provider, topology, and capacity assumptions.
- `ops.widget.health` is a read-only Dashboard projection of the same status endpoint.

Backend and WebUI manifests publish the same identifiers and parent hierarchy for Views and configured-system Docs.

## Consequences

Running probes performs only bounded, declared operational checks and refreshes the status projection. Draining a node stops new work from being routed to the selected runtime incarnation while in-flight work completes; cancellation is possible while the node remains draining. The shared confirmation dialog names the target and consequence. Stale, stopped, unauthorized, loading, and already-running states remain visible with an explicit reason.

Ops does not reconcile outcome-unknown work, restore backups, expose secrets, or invoke private sibling-module code. Operators follow the owning module's recovery contract and use Ops only for bounded observation and runtime coordination.