First extension struggles. Should I just drop the haskel approach?

wiki/OpsHubBootstrapRunbook.md

@@ -1,6 +1,6 @@
 # Ops Hub Bootstrap Runbook
 
-Date: 2026-05-16
+Date: 2026-06-14
 
 ## Purpose
 
@@ -11,17 +11,45 @@ Use this when an authenticated Inter-Hub admin session or deployment migration
 is available. The current public v2 API is not sufficient to create the hub,
 manifest, API consumer, API key, or seed widgets by itself.
 
+As of 2026-06-06, implementation work for `ops-hub` belongs in the dedicated
+repo at `/home/worsch/ops-hub` with remote `gitea-remote:coulomb/ops-hub.git`.
+This runbook remains a HelixForge bootstrap handoff reference until the
+implementation repo ports or supersedes it.
+
 ## Inputs
 
 - Manifest draft: `wiki/ops-hub-manifest.draft.json`
 - Widget seed: `wiki/ops-hub-widgets.seed.json`
 - Migration fallback: `wiki/ops-hub-bootstrap.sql`
+- Implementation repo: `/home/worsch/ops-hub`
 
 ## Current Bootstrap Decision
 
-Use the authenticated Inter-Hub admin UI first. Use the SQL migration fallback
-only when a repeatable deployment-side bootstrap is needed before the v2 API is
-hardened.
+Prefer the supported Inter-Hub bootstrap API once production exposes the
+current API surface. Do not proceed with manual DB seeding unless the operator
+explicitly chooses that fallback. Until the production API gate passes, the
+authenticated Inter-Hub admin UI and SQL migration remain fallback paths for
+attended operator use only.
+
+Production API gate:
+
+- `https://hub.coulomb.social/api/v2/hubs` returns `401` unauthenticated, not
+  `404`.
+- OpenAPI lists `/hubs`, `/hub-capability-manifests`, `/api-consumers`, and
+  `/policy-scopes`.
+- After the gate passes, run the supported bootstrap/smoke path from the
+  relevant `inter-hub` or `ops-hub` tooling with `IHUB_BASE` and an operator
+  key.
+
+Latest check, 2026-06-14:
+
+- `ops-hub/scripts/interhub-gate-probe.py` still reports the production gate
+  closed.
+- `GET /api/v2/hubs` returns `404`.
+- Live OpenAPI still omits `/hubs`, `/hub-capability-manifests`,
+  `/api-consumers`, and `/policy-scopes`.
+- Do not run the preferred API bootstrap path until the current Inter-Hub API
+  is deployed, unless the operator explicitly chooses the SQL fallback.
 
 VSM classification is stored in the manifest capability description for now:
 

wiki/OpsHubInventory.md

@@ -1,18 +1,34 @@
 # Ops Hub Initial Inventory
 
-Date: 2026-05-16
+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 before `ops-hub` has its own repository, collectors, or UI.
+catalogable model and now serves as a handoff reference for the dedicated
+`ops-hub` implementation repository.
 
 Source background:
 
 - `wiki/CurrentOperationsSituation.md`
 - `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 future 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 this initial inventory and readiness vocabulary as
+  architecture and handoff material until the implementation repo ports or
+  supersedes it.
+- Railiance repos own deployable infrastructure/service state and the
+  operational evidence that `ops-hub` should surface.
+
 ## VSM Placement
 
 | Field | Value |

wiki/OpsHubReadinessGates.md

@@ -1,12 +1,13 @@
 # Ops Hub Readiness Gates
 
-Date: 2026-05-16
+Date: 2026-06-14
 
 ## 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 intended as the first `ops-hub` readiness model.
+They are intended as the first `ops-hub` readiness model and should be ported
+into the dedicated `ops-hub` implementation repo as that repo grows.
 
 Statuses:
 
@@ -19,8 +20,8 @@ Statuses:
 
 | ID | Gate | Owner repo | Evidence requirement | Current status |
 |---|---|---|---|---|
-| OPS-G01 | Environment inventory exists | `helix-forge` | `local`, `coulombcore`, `railiance01`, and `threephoenix-prod` are represented with role, lifecycle state, and owner notes. | `partial` |
-| OPS-G02 | Service catalog exists | `helix-forge` then future `ops-hub` | Each live and target service has environment, owner repo, endpoint, backing stores, lifecycle state, and evidence links. | `partial` |
+| OPS-G01 | Environment inventory exists | `helix-forge` handoff to `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` |
@@ -33,7 +34,14 @@ Statuses:
 | 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` / `helix-forge` | `ops-hub` can be created through UI or migration, manifest activated, API consumer/key created, widgets seeded, and events accepted. | `partial` |
+| 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` |
+
+## Current Bootstrap Gate Evidence
+
+2026-06-14: `ops-hub/scripts/interhub-gate-probe.py` reports the preferred
+production API bootstrap gate still closed. Live `/api/v2/hubs` returns `404`,
+and OpenAPI does not yet list `/hubs`, `/hub-capability-manifests`,
+`/api-consumers`, or `/policy-scopes`.
 
 ## Initial Migration Waves
 
@@ -59,5 +67,6 @@ or widget family with events like:
 - `ops-migration-gate-failed`
 
 Until Inter-Hub can create all required records through API calls, the evidence
-can be maintained in this repository and mirrored into Inter-Hub through the UI
-or migrations.
+can be maintained as HelixForge handoff material or in the `ops-hub`
+implementation repo and mirrored into Inter-Hub through the UI or explicit
+migrations.