generated from coulomb/repo-seed
tegwick
21bfd5fa49
- Align agent files with on-disk workplan prefixes (infer from workplan ids) - Set workplan domain to registered domain_slug; add topic_slug where applicable - Repair frontmatter delimiter formatting; migrate legacy task status literals - Regenerate AGENTS.md, CLAUDE.md, and .claude/rules from State Hub templates
4.7 KiB
4.7 KiB
Ops Hub Readiness Gates
Date: 2026-06-06
Purpose
These gates define what must be true before operational responsibility can move
from the current CoulombCore setup to the future ThreePhoenix production setup.
They are the first repo-local ops-hub readiness model.
Statuses:
unknownmeans no reliable evidence has been cataloged yet.partialmeans some evidence exists, but the gate is not complete.blockedmeans a required precondition is missing.readymeans the evidence requirement is satisfied.
Gates
| ID | Gate | Owner repo | Evidence requirement | Current status |
|---|---|---|---|---|
| OPS-G01 | Environment inventory exists | ops-hub |
local, coulombcore, railiance01, and threephoenix-prod are represented with role, lifecycle state, and owner notes. |
partial |
| OPS-G02 | Service catalog exists | ops-hub |
Each live and target service has environment, owner repo, endpoint, backing stores, lifecycle state, and evidence links. | partial |
| OPS-G03 | DNS and TLS are codified | railiance-cluster / railiance-apps |
Public hostnames, ingress routes, certificate sources, and renewal paths are declared in repo files. | unknown |
| OPS-G04 | Git hosting is reproducible | railiance-apps / railiance-platform |
Gitea or successor deployment can be recreated from repo state, including database and storage dependencies. | partial |
| OPS-G05 | Container registry publishing is proven | railiance-apps |
docker login, push, and pull succeed against https://gitea.coulomb.social/v2/ using governed secrets. |
partial |
| OPS-G06 | Persistent data is backed up | railiance-platform |
Each persistent data store has backup location, schedule, retention, ownership, and latest successful backup evidence. | unknown |
| OPS-G07 | Restore path is proven | railiance-platform / railiance-apps |
Restore test evidence exists for Gitea database, package blobs, and State Hub data. | unknown |
| 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-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-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-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 |
Initial Migration Waves
| Wave | Goal | Required gates |
|---|---|---|
wave-0-catalog |
Establish the operational truth surface without moving services. | OPS-G01, OPS-G02, OPS-G15 |
wave-1-registry-proof |
Prove current Gitea registry publishing and evidence capture. | OPS-G03, OPS-G05, OPS-G08, OPS-G14 |
wave-2-backup-restore |
Confirm backups and restore paths for critical persistent state. | OPS-G06, OPS-G07, OPS-G13 |
wave-3-threephoenix-foundation |
Recreate cluster and platform foundations on railiance01/ThreePhoenix. | OPS-G09, OPS-G10 |
wave-4-service-migration |
Move or replace production responsibilities from CoulombCore to ThreePhoenix. | OPS-G04, OPS-G11, OPS-G12 plus service-specific gates |
Evidence Shape
Each readiness gate should eventually be represented in ops-hub as a widget
or widget family with events like:
ops-readiness-gate-updatedops-endpoint-verifiedops-backup-verifiedops-restore-testedops-risk-raisedops-migration-gate-passedops-migration-gate-failed
Until Inter-Hub can create all required records through API calls, the evidence can be maintained in this repo and mirrored into Inter-Hub through the UI or explicit operator-approved migrations.