---
id: OPS-WP-0002
type: workplan
title: "Bootstrap ops-hub as an Inter-Hub Operations extension"
domain: infotech
repo: ops-hub
status: active
owner: codex
topic_slug: inter_hub
created: "2026-06-06"
updated: "2026-06-06"
---

# Bootstrap ops-hub as an Inter-Hub Operations extension

## Goal

Turn the HelixForge `HF-WP-0001` handoff into the first concrete `ops-hub`
implementation track.

`ops-hub` should become the Operations / System 1 Inter-Hub extension for
operational truth: environments, hosts, clusters, services, endpoints,
releases, backups, incidents, risks, runbooks, readiness gates, and migration
waves.

This repo owns domain-specific implementation assets. `inter-hub` remains the
generic framework, registry, authentication, manifest, widget, event, and
bootstrap API substrate.

## Current Gate

As of 2026-06-06, public production Inter-Hub still returns `404` for:

```text
https://hub.coulomb.social/api/v2/hubs
```

Do not run manual database seeding unless the operator explicitly chooses that
fallback. The preferred bootstrap path is the supported Inter-Hub API once
production exposes the current bootstrap surface.

Gate criteria:

- Unauthenticated `GET /api/v2/hubs` returns `401`, not `404`.
- OpenAPI lists `/hubs`, `/hub-capability-manifests`, `/api-consumers`, and
  `/policy-scopes`.
- The bootstrap/smoke client can create or reuse the `ops-hub` hub, activate
  its manifest, create the runtime API consumer/key, seed initial widgets, and
  persist the first governed ops event.

## Handoff Sources

- `/home/worsch/helix-forge/workplans/HF-WP-0001-establish-ops-hub-first-extension.md`
- `/home/worsch/helix-forge/wiki/OpsHubInventory.md`
- `/home/worsch/helix-forge/wiki/OpsHubReadinessGates.md`
- `/home/worsch/helix-forge/wiki/OpsHubBootstrapRunbook.md`
- `/home/worsch/helix-forge/wiki/ops-hub-manifest.draft.json`
- `/home/worsch/helix-forge/wiki/ops-hub-widgets.seed.json`

## Port HelixForge Handoff Artifacts

```task
id: OPS-WP-0002-T01
status: done
priority: high
```

Create repo-local docs and seed data for the ops vocabulary, initial inventory,
readiness gates, bootstrap runbook, manifest draft, and widget seed.

Done when the `ops-hub` repo can be understood without opening HelixForge for
routine implementation details. Keep links back to HelixForge for architectural
context.

Completed 2026-06-06:

- Ported initial inventory to `docs/initial-inventory.md`.
- Ported readiness gates to `docs/readiness-gates.md`.
- Ported bootstrap runbook to `docs/bootstrap-runbook.md`.
- Ported manifest and widget seeds to `seeds/`.
- Added `docs/README.md` as the handoff index.

## Define Repository Source Layout

```task
id: OPS-WP-0002-T02
status: done
priority: high
```

Choose and create the first source layout for bootstrap/smoke tooling,
collectors, adapters, and tests. Add the repo-native lint, test, build, and run
commands to `AGENTS.md`.

Done when future code changes have an obvious home and a verification command.

Completed 2026-06-06:

- Added `pyproject.toml`.
- Added Python package layout under `src/ops_hub/`.
- Added operator scripts under `scripts/`.
- Added tests under `tests/`.
- Documented current verification commands in `AGENTS.md`.

## Implement Inter-Hub Production Gate Probe

```task
id: OPS-WP-0002-T03
status: done
priority: high
```

Build a small probe that checks the public Inter-Hub bootstrap API gate:

- `/api/v2/hubs` response is `401` unauthenticated.
- OpenAPI lists the required bootstrap paths.
- The result is machine-readable and suitable for a scheduled ops signal later.

Done when the probe can run locally without secrets and reports the current
gate as pass/fail with clear reasons.

Completed 2026-06-06: `scripts/interhub-gate-probe.py` checks unauthenticated
`/api/v2/hubs` status and required OpenAPI bootstrap paths, emits JSON, and
exits nonzero while the gate is closed.

## Implement Bootstrap Smoke Client

```task
id: OPS-WP-0002-T04
status: wait
priority: high
```

Implement the authenticated bootstrap/smoke client once Inter-Hub production
exposes the supported bootstrap API.

The client should use `IHUB_BASE` and `IHUB_OPERATOR_KEY` and should create or
reuse:

- `ops-hub` hub row
- active capability manifest
- runtime API consumer/key
- initial governed ops widgets
- first `ops-endpoint-verified` event

Done when a dry-run and an attended real run both produce repeatable evidence
without direct DB access.

Waiting on: Inter-Hub production API gate from T03.

## Seed First Operational Signal

```task
id: OPS-WP-0002-T05
status: wait
priority: medium
```

Submit the first governed ops signal for the Gitea registry endpoint once the
manifest, widget, event type, and API key exist.

Initial signal:

```json
{
  "eventType": "ops-endpoint-verified",
  "endpoint": "https://gitea.coulomb.social/v2/",
  "expectedStatus": 401,
  "viewContext": "railiance-apps/workplans/RAIL-AP-WP-0001"
}
```

Done when the event is visible in Inter-Hub and traceable to the owning
Railiance workplan.

Waiting on: T04 and an available `ops-hub` runtime API key.