govoplan-ops/docs/INTERFACE_PATTERN_MIGRATION.md

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.