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
1.5 KiB
repo, updated
| repo | updated |
|---|---|
| ops-hub | 2026-06-06 |
INTENT
Why it exists
ops-hub is the Operations / System 1 extension for Inter-Hub. It turns
operational reality into governed, queryable, and evidence-backed hub records:
environments, hosts, clusters, services, endpoints, releases, backups,
incidents, risks, runbooks, readiness gates, and migration waves.
It exists because Railiance and HelixForge operations need a durable
operational truth surface while the current CoulombCore environment transitions
toward the ThreePhoenix production shape. State Hub continues to own
workstreams and decisions; Inter-Hub continues to own the generic hub substrate.
ops-hub owns the operations extension behavior built on top of that substrate.
Governing principle
This repository should stay focused on the purpose above. Work that changes its authority, ownership boundaries, or operational promises should be captured in a workplan before implementation.
The first implementation rule is: domain-specific runtime code belongs here,
while generic hub framework behavior belongs in inter-hub.
What it enables
- Operators can see what runs where, how it is reached, and what evidence proves it is healthy.
- Collectors, adapters, and scheduled probes can report operational facts into Inter-Hub using the ops vocabulary.
- Readiness and migration gates can be represented as explicit, auditable operational records.
- Future VSM hubs can reuse the extension pattern without turning Inter-Hub itself into a domain-specific operations product.