coulomb/ops-hub
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(CORE-WP-0007): point ops-hub extension at Core Hub
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 3s
Details

Browse source
This commit is contained in:
tegwick 2026-07-08 12:48:04 +02:00
parent 4ca5c5906e
commit 7ac1871f94
4 changed files with 24 additions and 23 deletions
Download patch file Download diff file Expand all files Collapse all files

17
INTENT.md
View file

@ -7,16 +7,17 @@ updated: "2026-06-06"
## Why it exists ## Why it exists
`ops-hub` is the Operations / System 1 extension for Inter-Hub. It turns `ops-hub` is the Operations / System 1 extension for the interaction framework.
operational reality into governed, queryable, and evidence-backed hub records: It turns operational reality into governed, queryable, and evidence-backed hub
environments, hosts, clusters, services, endpoints, releases, backups, records: environments, hosts, clusters, services, endpoints, releases, backups,
incidents, risks, runbooks, readiness gates, and migration waves. incidents, risks, runbooks, readiness gates, and migration waves.
It exists because Railiance and HelixForge operations need a durable It exists because Railiance and HelixForge operations need a durable
operational truth surface while the current CoulombCore environment transitions operational truth surface while the fleet transitions toward railiance01
toward the ThreePhoenix production shape. State Hub continues to own production. State Hub continues to own workstreams and decisions; **Core Hub**
workstreams and decisions; Inter-Hub continues to own the generic hub substrate. owns the production framework API (`hub.coulomb.social` since 2026-07-03).
`ops-hub` owns the operations extension behavior built on top of that substrate. Historical Haskell Inter-Hub lives in `inter-hub-haskell` (retired). `ops-hub`
owns the operations extension behavior and posts evidence to Core Hub.
## Governing principle ## Governing principle
@ -25,7 +26,7 @@ authority, ownership boundaries, or operational promises should be captured in a
workplan before implementation. workplan before implementation.
The first implementation rule is: domain-specific runtime code belongs here, The first implementation rule is: domain-specific runtime code belongs here,
while generic hub framework behavior belongs in `inter-hub`. while generic hub framework behavior belongs in Core Hub.
## What it enables ## What it enables

7
README.md
View file

@ -1,6 +1,7 @@
Operations / System 1 extension for Inter-Hub. Operations / System 1 extension for Core Hub.
`ops-hub` is the operational truth surface for environments, hosts, clusters, `ops-hub` is the operational truth surface for environments, hosts, clusters,
services, endpoints, releases, backups, incidents, risks, runbooks, readiness services, endpoints, releases, backups, incidents, risks, runbooks, readiness
gates, and migration waves. Generic hub framework work stays in `inter-hub`; gates, and migration waves. Generic hub framework work stays in `core-hub`;
operations-specific extension code belongs here. operations-specific extension code belongs here. Historical Haskell Inter-Hub is
`inter-hub-haskell` (retired 2026-07-08).

19
SCOPE.md
View file

@ -2,33 +2,32 @@
## One-liner ## One-liner
Operations / System 1 extension for Inter-Hub, focused on operational truth, Operations / System 1 extension for Core Hub, focused on operational truth,
readiness evidence, and migration gates. readiness evidence, and migration gates.
## Core Idea ## Core Idea
`ops-hub` is a domain-specific Inter-Hub extension. It should professionalize `ops-hub` is a domain-specific Core Hub extension. It should professionalize
operations by making environments, hosts, clusters, services, endpoints, operations by making environments, hosts, clusters, services, endpoints,
releases, backups, incidents, risks, runbooks, readiness gates, and migration releases, backups, incidents, risks, runbooks, readiness gates, and migration
waves explicit and evidence-backed. waves explicit and evidence-backed.
The repo is intentionally separate from `inter-hub`: generic framework and API The repo is intentionally separate from Core Hub: generic framework and API
substrate work remains in `inter-hub`; operations-specific collectors, substrate work remains in `core-hub`; operations-specific collectors, adapters,
adapters, probes, bootstrap clients, UI/extensions, tests, and packaging belong probes, bootstrap clients, UI/extensions, tests, and packaging belong here.
here.
## In Scope ## In Scope
- Operations hub implementation code and tests. - Operations hub implementation code and tests.
- Ops vocabulary clients, collectors, adapters, and scheduled probes. - Ops vocabulary clients, collectors, adapters, and scheduled probes.
- Inter-Hub bootstrap/smoke tooling for the `ops-hub` extension. - Core Hub bootstrap/smoke tooling for the `ops-hub` extension.
- Operations service catalog, readiness, migration, endpoint, backup, restore, - Operations service catalog, readiness, migration, endpoint, backup, restore,
incident, and runbook models. incident, and runbook models.
- Repo-local workplans for growing the Operations / System 1 extension. - Repo-local workplans for growing the Operations / System 1 extension.
## Out of Scope ## Out of Scope
- Generic Inter-Hub framework behavior, API substrate, authentication, or - Generic Core Hub framework behavior, API substrate, authentication, or
registry semantics. registry semantics.
- State Hub workstream, task, decision, or progress implementation. - State Hub workstream, task, decision, or progress implementation.
- Railiance infrastructure, cluster, platform, enablement, or app desired state. - Railiance infrastructure, cluster, platform, enablement, or app desired state.
@ -41,8 +40,8 @@ here.
- Status: production bootstrap complete (2026-07-07). - Status: production bootstrap complete (2026-07-07).
- Implementation: Python package under `src/ops_hub/`, operator scripts, seeds, - Implementation: Python package under `src/ops_hub/`, operator scripts, seeds,
tests, and Makefile targets for gate probe and attended bootstrap. tests, and Makefile targets for gate probe and attended bootstrap.
- Inter-Hub: `ops-hub` hub, active manifest, seed widgets, and first - Core Hub: `ops-hub` hub, active manifest, seed widgets, and
`ops-endpoint-verified` event are live in production. `ops-endpoint-verified` events post to production Core Hub.
## Getting Oriented ## Getting Oriented

4
docs/readiness-gates.md
View file

@ -29,11 +29,11 @@ Statuses:
| OPS-G08 | Secrets path is governed | `railiance-infra` / `railiance-apps` | SOPS/age keys and operator secret paths are documented; no required secret depends on shell memory. | `partial` | | OPS-G08 | Secrets path is governed | `railiance-infra` / `railiance-apps` | SOPS/age keys and operator secret paths are documented; no required secret depends on shell memory. | `partial` |
| OPS-G09 | Cluster runtime is reproducible | `railiance-cluster` | Kubernetes runtime, ingress, CNI, operators, and routing primitives are recreated through repo-owned automation. | `unknown` | | OPS-G09 | Cluster runtime is reproducible | `railiance-cluster` | Kubernetes runtime, ingress, CNI, operators, and routing primitives are recreated through repo-owned automation. | `unknown` |
| OPS-G10 | Platform services are reproducible | `railiance-platform` | PostgreSQL/CNPG, object storage, secret management, and identity dependencies have repo-owned deployment evidence. | `unknown` | | OPS-G10 | Platform services are reproducible | `railiance-platform` | PostgreSQL/CNPG, object storage, secret management, and identity dependencies have repo-owned deployment evidence. | `unknown` |
| OPS-G11 | Application deployment is reproducible | `railiance-apps` | Gitea, Inter-Hub, State Hub, and other application releases are declared with Helm values and deployment runbooks. | `partial` | | OPS-G11 | Application deployment is reproducible | `railiance-apps` | Gitea, Core Hub, State Hub, and other application releases are declared with Helm values and deployment runbooks. | `partial` |
| OPS-G12 | Rollback path is documented | owning service repos | Each migration wave has rollback conditions, steps, and data safety notes. | `unknown` | | OPS-G12 | Rollback path is documented | owning service repos | Each migration wave has rollback conditions, steps, and data safety notes. | `unknown` |
| OPS-G13 | Operator runbooks exist | owning service repos | Deploy, restore, rotate, incident response, and migration runbooks exist for each critical service. | `unknown` | | OPS-G13 | Operator runbooks exist | owning service repos | Deploy, restore, rotate, incident response, and migration runbooks exist for each critical service. | `unknown` |
| OPS-G14 | Observability and health checks are explicit | `railiance-cluster` / `railiance-platform` / service repos | Health checks, logs, metrics, and endpoint probes are documented and tied to service catalog entries. | `unknown` | | OPS-G14 | Observability and health checks are explicit | `railiance-cluster` / `railiance-platform` / service repos | Health checks, logs, metrics, and endpoint probes are documented and tied to service catalog entries. | `unknown` |
| OPS-G15 | Inter-Hub ops bootstrap is available | `inter-hub` / `ops-hub` / `helix-forge` | `ops-hub` can be created through UI, supported API, or explicit migration fallback, manifest activated, API consumer/key created, widgets seeded, and events accepted. | `partial` | | OPS-G15 | Core Hub ops bootstrap is available | `core-hub` / `ops-hub` | `ops-hub` evidence posts to Core Hub; manifest, API consumer, widgets, and interaction events verified in production. | `ready` |
## Initial Migration Waves ## Initial Migration Waves