docs: establish ops-hub bootstrap artifacts

workplans/HF-WP-0001-establish-ops-hub-first-extension.md

@@ -142,6 +142,48 @@ Assessment:
   the quickstart as aspirational for bootstrap automation until Inter-Hub is
   hardened.
 
+## Confirmed Bootstrap Path
+
+Checked against the live API and local Inter-Hub source on 2026-05-16.
+
+Decision:
+
+- Bootstrap `ops-hub` through the authenticated Inter-Hub admin UI where
+  possible, with a migration-backed fallback when a repeatable bootstrap is
+  needed before the public API is hardened.
+- Treat Pattern A, API Consumer Hub, as the first implementation pattern.
+- Store VSM classification in the manifest capability description for now,
+  because the current `hubs` table only has `slug`, `name`, `domain`, and
+  `hub_kind`; there are no first-class `hub_family`, `vsm_function`, or
+  `vsm_system` columns yet.
+- Use `hub_kind = domain` for `ops-hub`.
+- Record missing first-class VSM metadata fields and create endpoints as
+  Inter-Hub hardening work under T10.
+
+Confirmed current support:
+
+- Live `/Hubs` redirects to `/NewSession`, so hub creation is an authenticated
+  UI flow.
+- Local `HubsController` supports creating and editing hub rows through the UI.
+- Local `HubCapabilityManifestsController` supports draft creation, JSON-array
+  vocabulary editing, activation, and registry upsert.
+- Local `ApiConsumersController` and `ApiKeysController` support authenticated
+  UI creation of consumers and static keys.
+- Local `/api/v2/interaction-events` supports `POST` and validates event types.
+
+Confirmed gaps:
+
+- Live OpenAPI has no `POST /api/v2/hubs`.
+- Live OpenAPI has no `POST /api/v2/widgets`; widgets are read-only in v2.
+- There are no v2 endpoints for manifest draft creation, manifest activation,
+  API consumer creation, or API key creation.
+- There is no `/api/v2/policy-scopes` endpoint.
+- Live type registries currently return empty arrays, so the ops vocabulary
+  still needs manifest activation before events can be accepted.
+- Event metadata is exposed in the response schema, but the v2 interaction
+  event create controller currently does not persist submitted metadata.
+- Webhook dispatch still uses the hard-coded `"clicked"` event name.
+
 ## Architectural Decision
 
 Start with **Pattern A: API Consumer Hub** for `ops-hub`, plus a manual or
@@ -291,7 +333,7 @@ The first explicit service-catalog gap:
 
 ```task
 id: HF-WP-0001-T01
-status: todo
+status: done
 priority: high
 state_hub_task_id: "2587a3b8-3b9b-4948-acaf-1547644e4563"
 ```
@@ -315,6 +357,8 @@ Done when: there is a concrete, repeatable path to create the `ops-hub` row,
 manifest, API consumer, and API key, with enough metadata to classify it as the
 Operations / System 1 hub.
 
+Output: `Confirmed Bootstrap Path` section in this workplan.
+
 ---
 
 ### T02 — Register ops-hub in Inter-Hub as the Operations hub
@@ -440,7 +484,7 @@ and annotations.
 
 ```task
 id: HF-WP-0001-T06
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "2a0b2f69-5a3d-433c-9cbd-85fd868b63d8"
 ```
@@ -465,6 +509,8 @@ Done when: a human can see the CoulombCore, local, railiance01, and
 ThreePhoenix relationship, including the current Gitea registry state, without
 reading multiple repo workplans or relying on shell history.
 
+Output: `wiki/OpsHubInventory.md`.
+
 ---
 
 ### T07 — Instrument the current Gitea registry work as the first ops-hub signal
@@ -504,7 +550,7 @@ traceable back to the Railiance workplan.
 
 ```task
 id: HF-WP-0001-T08
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "72a58622-c3ac-4765-8026-5c2489af2058"
 ```
@@ -523,6 +569,8 @@ responsibility from CoulombCore to ThreePhoenix:
 
 Done when: each gate has an owner repo, evidence requirement, and status.
 
+Output: `wiki/OpsHubReadinessGates.md`.
+
 ---
 
 ### T09 — Decide whether to create a separate ops-hub repository