---
id: OPS-WP-0003
type: workplan
title: "Extension contract alignment"
domain: infotech
repo: ops-hub
status: finished
owner: codex
topic_slug: infotech
created: "2026-08-09"
updated: "2026-08-31"
reviewed_at: "2026-08-31"
reviewed_by: codex
reviewed_against_commit: "9bbbf2032daf257d786446217bad79dc051a529c"
quality_dor: DoR-Ok
quality_dor_at: "2026-08-31"
quality_dor_by: codex
quality_dod: DoD-Ok
quality_dod_at: "2026-08-31"
quality_dod_by: codex
quality_dod_note: >-
  The owner-side 0.1.0 package is versioned and federated, passes hub-core's
  schemas/catalog and all eight implemented conformance checks, and the
  post-cutover production compatibility gate is green. Unimplemented framework
  checks are live residual HUB-WP-0009 rather than reported as passing.
parent_project: prj-state-hub-retirement
parent_workplan: SHR-WP-0001
related:
  - HUB-WP-0004
  - CORE-WP-0010
  - SHR-ARCH-HUB-0001
state_hub_workstream_id: "d688d60b-7f86-5fbe-bf3f-76ff926d9a17"
---

# Extension contract alignment

## Goal

Make ops-hub a **conformant domain/aspect hub** under `helixforge.hub-extension`:
descriptor, reuse-surface id, versioned manifest, health, and consumer
registration without secrets.

## Author hub package artefacts

```task
id: OPS-WP-0003-T01
status: done
priority: high
state_hub_task_id: "a938b0e2-912e-5126-aa6f-d63bdeebca5d"
```

Produce hub descriptor + capability manifest referencing
`capability.infotech.ops-hub` (or current registry id), events emitted/consumed,
and non-secret endpoints.

**Completed 2026-08-31.** Published the owner-side
`helixforge.hub-extension` 0.1.0 package at
`registry/hub-extension/v0.1.0/ops-hub.extension.json`. It uses the current
hub-core fixture identity `capability.operations.ops-hub`, declares the
operations service-catalog handoff, named framework ports, emitted
`ops.endpoint.verified`, consumed `hub.progress.recorded`, and non-secret
discovery/documentation endpoints. The package checksum is
`d48bb22c88598af482a3a779b930d1269e5bd8fd9e245681e278f14c4bd064d0`.

The capability is now a reviewed federation entry (`D3 / A1 / C1 / R1`) rather
than an empty index. `docs/hub-extension.md` records that hub-core owns the
runtime while ops-hub owns operational vocabulary and records; the legacy
dash-separated event remains a compatibility spelling, not a rewrite target.

## Pass Tier 2 conformance against hub-core

```task
id: OPS-WP-0003-T02
status: done
priority: high
state_hub_task_id: "1d1c422d-892c-5404-8d7f-a1f78c5cd87a"
```

When HUB-WP-0004 harness exists, run C1–C10 checks; fix gaps in ops-hub.

**Completed 2026-08-31 with framework residuals.** The owner package validates
against hub-core's packaged Draft 2020-12 descriptor/manifest schemas and event
catalog with zero secret-shaped fields. Injecting that package into a disposable
hub-core runtime passed the complete implemented profile: Tier-2 C1, C3, C4,
C5, C6, C8 and Tier-3 F2/F3 (8/8).

Hub Core contract 0.1.0 explicitly does not automate C2, C7, C9, or C10; those
cannot be fixed honestly in an extension repository. They are residual-owned by
new proposed owner workplan `HUB-WP-0009`, covering registry resolution,
raw-port configuration policy, dependency-aware readiness, version negotiation,
and any remaining tenant-isolation split. It is registered as State Hub
workplan `0d6e94f3-fd15-5f57-af41-60f0b862da5e`. The report does not count
unsupported checks as passing.

## Bootstrap dual-run on consolidated runtime

```task
id: OPS-WP-0003-T03
status: done
priority: high
state_hub_task_id: "947306d4-8a00-5cd6-8c6d-1f266d45055c"
```

Verify bootstrap/smokes against hub-core-hosted `/api/v2` during CORE-WP-0010
dual-run and after cutover.

**Completed 2026-08-31.** `RAPPCOREHUB-WP-0002-T04` records the ops-hub
consumer gate passing against the public candidate during the S1–S5 dual-run.
The production cutover and exercised rollback/forward recovery repeated the
consumer gates. A fresh post-cutover `make interhub-gate` now passes against
`https://hub.coulomb.social`: `/api/v2/hubs` fails closed with 401 for an
anonymous caller, `/api/v2/openapi.json` returns 200, and all four required
bootstrap resources are present.

No new authenticated bootstrap mutation was needed or performed. The routed
Inter-Hub operator-key lane is high-risk and attended
(`inter-hub-bootstrap-ssh`); repeating a successful bootstrap merely to obtain
fresh evidence would create credentials and production records without a
functional change. Existing idempotent bootstrap behavior remains covered by
the source tests, while the current production check is non-mutating.

## Acceptance

- [x] Hub package artefacts present and versioned
- [x] Tier 2 conformance green (or residual-owned gaps)
- [x] Bootstrap works on consolidated runtime