Files
ops-hub/INTENT.md
tegwick 21bfd5fa49 Normalize agent instructions and workplan frontmatter (STATE-WP-0067)
- 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
2026-06-22 23:16:27 +02:00

40 lines
1.5 KiB
Markdown

---
repo: ops-hub
updated: "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.