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: