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
parent cec94ac00f
commit 21bfd5fa49
19 changed files with 819 additions and 25 deletions
--- a/docs/initial-inventory.md
+++ b/docs/initial-inventory.md
@@ -0,0 +1,146 @@
+# Ops Hub Initial Inventory
+
+Date: 2026-06-06
+
+## Purpose
+
+This document is the first structured inventory for `ops-hub`, the VSM
+Operations / System 1 hub. It turns the current operations situation into a
+catalogable model for this implementation repo.
+
+Source background:
+
+- `/home/worsch/helix-forge/wiki/CurrentOperationsSituation.md`
+- `/home/worsch/helix-forge/workplans/HF-WP-0001-establish-ops-hub-first-extension.md`
+
+## Repository Boundary
+
+As of 2026-06-06, `ops-hub` implementation belongs in `/home/worsch/ops-hub`
+with remote `gitea-remote:coulomb/ops-hub.git`.
+
+- `ops-hub` owns collectors, adapters, scheduled probes, runtime
+  packaging, UI/extensions, tests, and Inter-Hub bootstrap/smoke clients.
+- `inter-hub` remains the generic hub framework, manifest/registry substrate,
+  authentication surface, widget/event API, and bootstrap API owner.
+- `helix-forge` keeps architecture context and the original coordinating
+  workplan.
+- Railiance repos own deployable infrastructure/service state and the
+  operational evidence that `ops-hub` should surface.
+
+## VSM Placement
+
+| Field | Value |
+|---|---|
+| Hub | `ops-hub` |
+| Hub family | `vsm` |
+| VSM function | `OPS` |
+| VSM system | `S1` |
+| Primary concern | Operational truth and evidence |
+
+`ops-hub` owns the description of what is currently running, where it runs, how
+it is reached, what state it is in, and what operational evidence exists. It
+does not replace State Hub workstreams or Inter-Hub governance.
+
+## Environments
+
+| Environment | Role | Current state | Notes |
+|---|---|---|---|
+| `local` | Workstation development and local services | Active, important, not production | Hosts State Hub and local build/runtime pieces. |
+| `coulombcore` | Live transitional production | Active, production-like, historically hand-built | Public IP `92.205.130.254`; runs current Gitea and experimental operational services. |
+| `railiance01` | Future production foundation | Provisioning target | Public IP `92.205.62.239`; first server of intended ThreePhoenix shape. |
+| `threephoenix-prod` | Target production topology | Planned | Future governed multi-node production environment. |
+
+## Hosts
+
+| Host | Environment | Address | Role | Known gaps |
+|---|---|---|---|---|
+| `coulombcore` | `coulombcore` | `92.205.130.254` | Current live production-like server | Needs service catalog, drift tracking, backup/restore evidence, and migration disposition. |
+| `railiance01` | `railiance01` | `92.205.62.239` | First ThreePhoenix production foundation node | Needs full inventory, readiness gates, and cluster/platform bootstrap evidence. |
+| local workstation | `local` | local/private | State Hub and development runtime host | Needs explicit service ownership and backup expectations. |
+
+Ops Bridge may provide reachability evidence for connected servers, but it is
+not the service catalog. `ops-hub` should turn bridge reachability into
+inventory signals rather than treating the bridge itself as the inventory.
+
+## Clusters
+
+| Cluster | Environment | Role | Current notes |
+|---|---|---|---|
+| CoulombCore Kubernetes | `coulombcore` | Current operational Kubernetes runtime | Hosts current Gitea deployment and related services. |
+| ThreePhoenix Kubernetes | `threephoenix-prod` | Target production runtime | Future governed production cluster assembled through Railiance repos. |
+
+## Services
+
+| Service | Current environment | Owner repo | Current evidence | Gaps |
+|---|---|---|---|---|
+| Gitea | `coulombcore` | `railiance-apps` | Helm release `gitea`, namespace `default`, app version `1.25.4`, NodePort `32166`, public registry path returns auth challenge. | SOPS Helm values update, package token, `docker login`, push, pull, backup coverage, restore evidence. |
+| Gitea database | `coulombcore` | `railiance-platform` | Database `gitea-db` in namespace `databases`. | Backup and restore evidence not recorded here yet. |
+| Gitea shared storage | `coulombcore` | `railiance-platform` / `railiance-apps` | PVC `default/gitea-shared-storage`. | Package blob backup and restore evidence not confirmed. |
+| State Hub | `local` | `the-custodian/state-hub` | Local API and dashboard are operational enough for repo registration and workplan sync. | Future cluster deployment/readiness still needs gates and evidence. |
+| Inter-Hub | live public endpoint | `inter-hub` | `https://hub.coulomb.social/api/v2/openapi.json` and docs are reachable. | Hub bootstrap still depends on authenticated UI or migration. |
+| Ops Bridge | local/remote bridge | `ops-bridge` | Useful for connected-server visibility. | Not a service catalog; should emit reachability evidence into `ops-hub`. |
+
+## Endpoints
+
+| Endpoint | Service | Environment | Current status | Evidence |
+|---|---|---|---|---|
+| `https://gitea.coulomb.social/v2/` | Gitea OCI registry | `coulombcore` | Route fixed; returns registry auth challenge | Expected `401` with OCI registry challenge. |
+| `https://hub.coulomb.social/api/v2/openapi.json` | Inter-Hub API | live Inter-Hub | Reachable | OpenAPI document fetched on 2026-05-16. |
+| `https://hub.coulomb.social/Hubs` | Inter-Hub UI | live Inter-Hub | Requires login | Redirects to `/NewSession`. |
+| `http://127.0.0.1:8000/state/health` | State Hub API | `local` | Reachable locally | Used for StateHub registration/sync. |
+
+## Service Catalog Gap
+
+There is no central place that answers these questions:
+
+- What runs where?
+- Which repo owns its desired state?
+- Which endpoint exposes it?
+- Which data stores back it?
+- Which backups and restore tests cover it?
+- Which migration wave will replace or move it?
+- Which current evidence proves it is healthy?
+
+`ops-hub` should be the first place where these answers are explicit and
+machine-addressable.
+
+## First Ops Widgets
+
+Seed these in Inter-Hub once `ops-hub` exists:
+
+- `ops-env-local`
+- `ops-env-coulombcore`
+- `ops-env-railiance01`
+- `ops-env-threephoenix-prod`
+- `ops-host-coulombcore`
+- `ops-host-railiance01`
+- `ops-service-catalog`
+- `ops-service-gitea`
+- `ops-service-state-hub`
+- `ops-service-inter-hub`
+- `ops-endpoint-gitea-registry`
+- `ops-readiness-gitea-registry`
+- `ops-readiness-state-hub-cluster-deploy`
+- `ops-migration-coulombcore-to-threephoenix`
+
+## First Evidence Events
+
+The first event should be the Gitea registry endpoint verification:
+
+```json
+{
+  "widgetId": "<ops-endpoint-gitea-registry-widget-id>",
+  "eventType": "ops-endpoint-verified",
+  "viewContext": "railiance-apps/workplans/RAIL-AP-WP-0001",
+  "metadata": {
+    "vsmFunction": "OPS",
+    "vsmSystem": "S1",
+    "endpoint": "https://gitea.coulomb.social/v2/",
+    "expectedStatus": 401,
+    "observedHeader": "Docker-Distribution-Api-Version: registry/2.0"
+  }
+}
+```
+
+This event is blocked until the ops event type is registered by an active
+manifest and the target widget exists.