# Ops Hub extension package Ops Hub implements the owner side of `helixforge.hub-extension` 0.1.0. Hub Core owns and runs the framework ports; this repository owns the operations descriptor, capability declarations, event boundary, compatibility bootstrap, and evidence used to move service-catalog responsibility out of State Hub. The canonical package is `registry/hub-extension/v0.1.0/ops-hub.extension.json`. Its stable identity is `capability.operations.ops-hub`; it also declares `capability.operations.service-catalog` as an owner capability. ## Ownership boundary | Surface | Owner | | --- | --- | | Descriptor, manifest, operational vocabulary, service-catalog records | `ops-hub` | | `port.*` schemas, event catalog, registry and projection runtime | `hub-core` | | Runtime and operator credentials | OpenBao/platform custody; never this package | | State Hub compatibility routes during retirement | `state-hub` until their evidenced cutover | Ops Hub is an aspect hub, not a second hub-core deployment. The API endpoint in the manifest is a discovery reference to the hub-core-hosted compatibility surface at `https://hub.coulomb.social/api/v2`. ## Events and legacy compatibility The 0.1.0 port contract emits `ops.endpoint.verified` and consumes `hub.progress.recorded`. The older `/api/v2` bootstrap seed uses `ops-endpoint-verified`; hub-core's compatibility adapter retains that legacy spelling. New port-native evidence uses the dotted catalog event and must not silently rewrite historical events. ## Validation ```bash make test make hub-extension-check make hub-core-conformance make interhub-gate ``` `hub-extension-check` validates the owner package against hub-core's packaged Draft 2020-12 descriptor and manifest schemas, checks every declared event against hub-core's catalog, and emits a non-secret checksum receipt. `hub-core-conformance` injects this repository's package into a disposable hub-core reference runtime. Contract version 0.1.0 automates C1, C3, C4, C5, C6, and C8 plus Tier-3 F2 and F3. C2 registry resolution, C7 raw-port policy, C9 dependency-aware readiness, and C10 version negotiation are not automated by the current hub-core harness and are not represented as passing. `interhub-gate` is the safe post-cutover production check. It proves that the hub-core-hosted `/api/v2` surface exposes the bootstrap resources without requiring a credential or mutating production. ## Authenticated bootstrap The existing `scripts/ops-hub-bootstrap-api.py` remains the idempotent compatibility bootstrap client. It creates or reuses the hub, manifest, API consumer, widgets, and verification event. Follow `docs/bootstrap-runbook.md`. Operator and runtime keys are never arguments, logs, Git content, or extension fields. Credential routing starts with: ```bash warden route show inter-hub-bootstrap-ssh --json ``` The current route is high-risk and attended. A source change or public gate does not authorize another live bootstrap mutation. ## State Hub retirement handoff This package satisfies the receiving-side contract for `STATE-WP-0079` Wave D1. Removing State Hub's service-catalog routes still requires a separate caller inventory, projection/count comparison, rollback receipt, and explicit production writer-cutover authorization. Owner readiness is not cutover proof.