chore(consistency): sync task status from DB [auto]

Updated by fix-consistency on 2026-07-01:
  - update .custodian-brief.md for inter-hub

.claude/rules/first-session.md

@@ -1,11 +1,11 @@
 ## First Session Protocol
 
-Triggered when `get_domain_summary("custodian")` shows **no workstreams**.
+Triggered when `get_domain_summary("infotech")` shows **no workstreams**.
 The project is registered but work has not yet been structured.
 
 **Step 1 — Read, don't write**
-- `~/the-custodian/canon/projects/custodian/project_charter_v0.1.md` — purpose, scope
+- `~/the-custodian/canon/projects/infotech/project_charter_v0.1.md` — purpose, scope
-- `~/the-custodian/canon/projects/custodian/roadmap_v0.1.md` — planned phases
+- `~/the-custodian/canon/projects/infotech/roadmap_v0.1.md` — planned phases
 - Scan repo root: README, directory structure, existing code or docs
 
 **Step 2 — Survey in-progress work**
@@ -17,7 +17,7 @@ roadmap phase. **Wait for approval before creating.**
 
 **Step 4 — Create workplan file first, then DB record (ADR-001)**
 ```
-workplans/inter-hub-WP-NNNN-<slug>.md   ← write this first
+workplans/IHUB-WP-NNNN-<slug>.md   ← write this first
 ```
 Then register in the hub:
 ```
@@ -28,7 +28,7 @@ create_task(workstream_id="<id>", title="...", priority="high|medium|low")
 **Step 5 — Record the setup**
 ```
 add_progress_event(
-    summary="First session: structured custodian into N workstreams, M tasks",
+    summary="First session: structured infotech into N workstreams, M tasks",
     event_type="milestone",
     topic_id="cee7bedf-2b48-46ef-8601-006474f2ad7a",
     detail={"workstreams": [...], "tasks_created": M}

.claude/rules/repo-identity.md

@@ -1,5 +1,5 @@
 **Purpose:** Governed, observable interaction substrate for hub-based AI-enabled software systems (IHF specification and reference implementation).
 
-**Domain:** custodian
+**Domain:** infotech
 **Repo slug:** inter-hub
 **Topic ID:** cee7bedf-2b48-46ef-8601-006474f2ad7a

.claude/rules/session-protocol.md

@@ -1,6 +1,7 @@
 ## Session Protocol
 
-State Hub: http://127.0.0.1:8000
+Dev Hub (State Hub API): http://127.0.0.1:8000
+MCP server name in `~/.claude.json`: `dev-hub`
 
 **Step 1 — Orient**
 
@@ -10,7 +11,7 @@ cat .custodian-brief.md
 ```
 Then call the MCP tool for richer cross-domain context when MCP tools are exposed:
 ```
-get_domain_summary("custodian")
+get_domain_summary("infotech")
 ```
 If MCP tools are unavailable in the current agent session, use the REST API:
 ```bash
@@ -39,11 +40,11 @@ curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
 ls workplans/
 ```
 For each file with `status: ready`, `active`, or `blocked`, note pending
-`todo`/`in_progress` tasks.
+`wait`/`todo`/`progress` tasks.
 
 **Step 4 — Present brief**
 
-1. **Active workstreams** for `custodian` — title, task counts, blocking decisions
+1. **Active workstreams** for `infotech` — title, task counts, blocking decisions
 2. **Pending tasks** from `workplans/` + any `[repo:inter-hub]` hub tasks
 3. **Goal guidance** — if `goal_guidance` in summary:
    - `needs_workplan`: surface as top action — *"Repo goal '{title}' has no workplan yet"*

.claude/rules/workplan-convention.md

@@ -1,7 +1,7 @@
 ## Workplan Convention (ADR-001)
 
-File location: `workplans/inter-hub-WP-NNNN-<slug>.md`
+File location: `workplans/IHUB-WP-NNNN-<slug>.md`
-ID prefix: `INTER-WP`
+ID prefix: `IHUB-WP-`
 
 Work items originate as files in this repo **before** being registered in the hub.
 
@@ -12,7 +12,7 @@ repo state, and `finished` when implementation is complete. `stalled` and
 `needs_review` are derived health labels, not stored statuses.
 
 Closed workplans may be moved to `workplans/archived/` with a completion-date
-prefix: `YYMMDD-inter-hub-WP-NNNN-<slug>.md`. The frontmatter id remains
+prefix: `YYMMDD-IHUB-WP-NNNN-<slug>.md`. The frontmatter id remains
 unchanged; the prefix is only for quick visual reference.
 
 Small opportunistic tasks discovered during another session use **Ad Hoc Tasks**:
@@ -25,4 +25,16 @@ Ecosystem todos from other agents arrive as `[repo:inter-hub]` hub tasks —
 visible at session start. Pick one up by creating the workplan file, then registering
 the workstream.
 
+Task blocks use this shape:
+
+```task
+id: IHUB-WP-NNNN-T01
+status: wait | todo | progress | done | cancel
+priority: high | medium | low
+state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
+```
+
+Status progression is `todo` → `progress` → `done`; use `wait` for waiting or
+blocked work and `cancel` for stopped work.
+
 <!-- Ralph Loop rules and HEUREKA sequence: ~/.claude/CLAUDE.md — do not duplicate here -->

.custodian-brief.md

@@ -1,8 +1,8 @@
 <!-- custodian-brief: generated by fix-consistency — do not edit manually -->
 # Custodian Brief — inter-hub
 
-**Domain:** inter_hub  
+**Domain:** infotech  
-**Last synced:** 2026-06-21 14:07 UTC  
+**Last synced:** 2026-07-01 19:37 UTC  
 **State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)*
 
 ## Current Goal
@@ -43,6 +43,6 @@ Progress: 0/1 done  |  workstream_id: `9e7a50b4-da7f-4df9-9154-7b89a071f520`
 ## MCP Orientation (when available)
 
 If the state-hub MCP server is reachable, call:
-`get_domain_summary("inter_hub")`
+`get_domain_summary("infotech")`
 This provides richer cross-domain context.
 If the MCP call fails, use this file as your orientation source.

.repo-classification.yaml

@@ -0,0 +1,27 @@
+# Repo classification (Repo Classification Standard v1.0).
+
+repo_classification:
+  standard: Repo Classification Standard
+  version: '1.0'
+  classified_at: '2026-06-22'
+  classified_by: human
+  category: research
+  domain: infotech
+  secondary_domains:
+  - agents
+  capability_tags:
+  - governance
+  - observability
+  - platform
+  - coordination
+  - orchestration
+  business_stake:
+  - technology
+  - intelligence
+  - operations
+  business_mechanics:
+  - control
+  - coordination
+  - adaptation
+  notes: Specification + reference implementation of the Interaction Hub Framework (IHF).
+    Core output is the governed framework/substrate, so classified research.

AGENTS.md

@@ -4,10 +4,10 @@
 
 **Purpose:** Governed, observable interaction substrate for hub-based AI-enabled software systems (IHF specification and reference implementation).
 
-**Domain:** custodian
+**Domain:** infotech
 **Repo slug:** inter-hub
 **Topic ID:** `cee7bedf-2b48-46ef-8601-006474f2ad7a`
-**Workplan prefix:** `INTER-WP-`
+**Workplan prefix:** `IHUB-WP-`
 
 ---
 
@@ -63,8 +63,8 @@ Omit `workstream_id` / `task_id` when not applicable.
 ```bash
 curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
   -H "Content-Type: application/json" \
-  -d '{"status": "in_progress"}'
+  -d '{"status": "progress"}'
-# values: todo | in_progress | done | blocked
+# values: wait | todo | progress | done | cancel
 ```
 
 ### Flag a task for human review
@@ -83,7 +83,7 @@ curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
 1. `cat .custodian-brief.md` — domain goal and open workstreams (offline-safe)
 2. Check inbox: `GET /messages/?to_agent=inter-hub&unread_only=true`; mark read
 3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks
-4. Check blocked tasks: `GET /tasks/?needs_human=true`
+4. Check human-needed tasks: `GET /tasks/?needs_human=true`
 
 **During work:**
 - Update task statuses in workplan files as tasks progress
@@ -151,6 +151,11 @@ every repo's agent instructions because it is high-frequency, high-risk, and eas
 get wrong.
 
 **Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`
+
+<!-- REPO-AGENTS-EXTENSIONS -->
+<!-- Append repo-specific agent instructions below this marker.
+     The state-hub template sync preserves content after this line. -->
+
 ---
 
 ## Workplan Convention (ADR-001)
@@ -176,7 +181,7 @@ anything needing analysis, design, approval, dependencies, or multiple phases.
 id: INTER-WP-NNNN
 type: workplan
 title: "..."
-domain: custodian
+domain: infotech
 repo: inter-hub
 status: proposed | ready | active | blocked | backlog | finished | archived
 owner: codex
@@ -198,7 +203,7 @@ derived health labels, not frontmatter statuses.
 
 ` ` `task
 id: INTER-WP-NNNN-T01
-status: todo | in_progress | done | blocked
+status: wait | todo | progress | done | cancel
 priority: high | medium | low
 state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
 ` ` `
@@ -206,7 +211,7 @@ state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
 Task description text.
 ```
 
-Status progression: `todo` → `in_progress` → `done` (or `blocked`)
+Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work.
 
 To create a new workplan:
 1. Write the file following the format above

docs/contracts/ops-hub-activity-core-event-payloads.md

@@ -1,6 +1,7 @@
 # Ops Hub Activity-Core Event Payloads
 
 Date: 2026-06-15
+Updated: 2026-06-27
 
 Workplan: `IHUB-WP-0022`
 
@@ -33,6 +34,28 @@ Each request body must use the Inter-Hub v2 interaction-event shape:
 Inter-Hub sets `occurredAt` on receipt. Activity-core must send the actual
 probe timestamp as `metadata.attributes.observed_at`.
 
+## Live Vocabulary Alignment
+
+Use event names declared by the live ops-hub manifest:
+
+- `ops-service-discovered`
+- `ops-endpoint-verified`
+- `ops-backup-verified`
+- `ops-drift-detected`
+
+Transitional aliases may be accepted in local mapping logic but should not be
+submitted to Inter-Hub:
+
+| Earlier activity-core name | Live event name |
+| --- | --- |
+| `ops-service-observed` | `ops-service-discovered` |
+| `ops-inventory-drift` | `ops-drift-detected` |
+
+`ops-access-path-checked` is deferred because the live manifest has no
+access-path event type or access-path widget type. Keep State Hub fallback
+posting for access-path evidence until ops-hub adds that vocabulary or an
+operator decision maps it to `ops-readiness-gate-updated` or `ops-risk-raised`.
+
 ## Shared Rules
 
 - `widgetId` must be a UUID for an existing ops-hub widget.
@@ -41,7 +64,7 @@ probe timestamp as `metadata.attributes.observed_at`.
   be declared by that manifest.
 - `viewContext` should be `ops-inventory-probe` unless a more specific context
   is useful, such as `ops-inventory-probe/endpoints`.
-- `metadata.type` must match the Inter-Hub `eventType`.
+- `metadata.type` must match the Inter-Hub `eventType` after alias translation.
 - `metadata.version` must match the activity-core event definition version.
 - `metadata.publisher` must be `activity-core`.
 - `metadata.attributes.idempotency_key` is required, even though Inter-Hub does
@@ -69,26 +92,27 @@ Use `reason` for compact machine-readable explanations, for example:
 - `backup_probe_not_implemented`
 - `missing_endpoint`
 
-## Example: Service Observed
+## Example: Service Discovered
 
 ```json
 {
-  "widgetId": "<service-widget-uuid>",
+  "widgetId": "<service-or-catalog-widget-uuid>",
-  "eventType": "ops-service-observed",
+  "eventType": "ops-service-discovered",
   "viewContext": "ops-inventory-probe/services",
   "metadata": {
-    "type": "ops-service-observed",
+    "type": "ops-service-discovered",
     "version": "1.0",
     "publisher": "activity-core",
     "attributes": {
       "activity_core_run_id": "12345678-aaaa-bbbb-cccc-123456789abc",
-      "idempotency_key": "12345678-aaaa-bbbb-cccc-123456789abc:state-hub:ops-service-observed",
+      "idempotency_key": "12345678-aaaa-bbbb-cccc-123456789abc:state-hub:ops-service-discovered",
       "service_id": "state-hub",
       "service_name": "State Hub",
       "environment": "local",
-      "lifecycle_state": "observed",
+      "lifecycle_state": "discovered",
       "observed_status": "ok",
-      "observed_at": "2026-06-05T10:15:01Z"
+      "observed_at": "2026-06-05T10:15:01Z",
+      "widget_ref": "ops:service:state-hub"
     }
   }
 }
@@ -124,37 +148,26 @@ Use `reason` for compact machine-readable explanations, for example:
 }
 ```
 
-## Example: Access Path Checked
+## Deferred: Access Path Checked
 
-```json
+Do not submit `ops-access-path-checked` to Inter-Hub while the live ops-hub
-{
+manifest lacks that event type and a matching widget type. Activity-core should
-  "widgetId": "<access-path-widget-uuid>",
+continue to include compact access-path detail in State Hub fallback summaries
-  "eventType": "ops-access-path-checked",
+and return a non-secret deferred sink result for Inter-Hub.
-  "viewContext": "ops-inventory-probe/access-paths",
+
-  "metadata": {
+If the operator chooses to represent access-path state as readiness or risk,
-    "type": "ops-access-path-checked",
+create a separate mapping decision and send the supported event type instead of
-    "version": "1.0",
+silently rewriting access-path evidence.
-    "publisher": "activity-core",
-    "attributes": {
-      "activity_core_run_id": "12345678-aaaa-bbbb-cccc-123456789abc",
-      "idempotency_key": "12345678-aaaa-bbbb-cccc-123456789abc:gitea:gitea-access-1:ops-access-path-checked",
-      "service_id": "gitea",
-      "access_path_id": "gitea-access-1",
-      "access_path_type": "k8s",
-      "declared_status": "unknown",
-      "observed_status": "skipped",
-      "reason": "unsupported_access_path_type",
-      "observed_at": "2026-06-05T10:15:01Z"
-    }
-  }
-}
-```
 
 ## Example: Backup Verified
 
+This event is declared by the live manifest, but it needs a target
+`ops-backup-set` widget such as `ops:backup-set:aggregate` before the smoke can
+submit it.
+
 ```json
 {
-  "widgetId": "<backup-widget-uuid>",
+  "widgetId": "<backup-set-widget-uuid>",
   "eventType": "ops-backup-verified",
   "viewContext": "ops-inventory-probe/backups",
   "metadata": {
@@ -170,26 +183,27 @@ Use `reason` for compact machine-readable explanations, for example:
       "restore_verified": false,
       "observed_status": "skipped",
       "reason": "backup_probe_not_implemented",
-      "observed_at": "2026-06-05T10:15:01Z"
+      "observed_at": "2026-06-05T10:15:01Z",
+      "widget_ref": "ops:backup-set:aggregate"
     }
   }
 }
 ```
 
-## Example: Inventory Drift
+## Example: Drift Detected
 
 ```json
 {
-  "widgetId": "<drift-widget-uuid>",
+  "widgetId": "<readiness-or-risk-widget-uuid>",
-  "eventType": "ops-inventory-drift",
+  "eventType": "ops-drift-detected",
   "viewContext": "ops-inventory-probe/drift",
   "metadata": {
-    "type": "ops-inventory-drift",
+    "type": "ops-drift-detected",
     "version": "1.0",
     "publisher": "activity-core",
     "attributes": {
       "activity_core_run_id": "12345678-aaaa-bbbb-cccc-123456789abc",
-      "idempotency_key": "12345678-aaaa-bbbb-cccc-123456789abc:gitea:gitea-oci-registry:ops-inventory-drift",
+      "idempotency_key": "12345678-aaaa-bbbb-cccc-123456789abc:gitea:gitea-oci-registry:ops-drift-detected",
       "service_id": "gitea",
       "inventory_object_id": "gitea-oci-registry",
       "drift_kind": "status_mismatch",
@@ -197,7 +211,8 @@ Use `reason` for compact machine-readable explanations, for example:
       "observed_summary": "status_code=200",
       "observed_status": "degraded",
       "reason": "expected_status_mismatch",
-      "observed_at": "2026-06-05T10:15:01Z"
+      "observed_at": "2026-06-05T10:15:01Z",
+      "widget_ref": "ops:readiness:gitea-registry"
     }
   }
 }
@@ -208,12 +223,12 @@ Use `reason` for compact machine-readable explanations, for example:
 Activity-core should treat these as configuration or rollout errors:
 
 | Error | Meaning | Recovery |
-|---|---|---|
+| --- | --- | --- |
 | `401` | Missing or invalid `OPS_HUB_KEY` | Check Secret provisioning; do not log the key. |
-| `422` with `unregistered_event_type` | Event type not in Inter-Hub registry | Activate the ops-hub manifest vocabulary. |
+| `422` with `unregistered_event_type` | Event type not in Inter-Hub registry | Use a live manifest event or activate a corrected ops-hub manifest. |
 | `422` with `event_type_not_in_manifest` | Runtime consumer manifest does not declare the event | Bind the consumer to the active manifest or activate a corrected manifest. |
-| `422` with `Widget not found` | Mapping points at a missing widget | Refresh `OPS_HUB_WIDGET_MAPPING`. |
+| `422` with `Widget not found` | Mapping points at a missing widget | Refresh `OPS_HUB_WIDGET_MAPPING` from authenticated widget lookup. |
-| `422` with `unregistered_policy_scope` during widget seed | Policy scope is absent | Declare and activate `ops-evidence`. |
+| `422` with `unregistered_policy_scope` during widget seed | Policy scope is absent | Use one of the declared ops scopes, not the old `ops-evidence` proposal. |
 
 For the first activity-core slice, a failed Inter-Hub submission should not
 fail the whole probe if State Hub fallback posting succeeds. It should return a

docs/contracts/ops-hub-activity-core-mapping.md

@@ -1,6 +1,7 @@
 # Ops Hub Activity-Core Widget Mapping
 
 Date: 2026-06-15
+Updated: 2026-06-27
 
 Workplan: `IHUB-WP-0022`
 
@@ -8,8 +9,21 @@ Workplan: `IHUB-WP-0022`
 
 `OPS_HUB_WIDGET_MAPPING` tells activity-core which Inter-Hub widget receives
 each ops evidence event. The value must be non-secret JSON. It may contain
-Inter-Hub widget UUIDs and logical references, but it must never contain
+Inter-Hub widget UUIDs and stable logical refs, but it must never contain
-`OPS_HUB_KEY` or any operator credential.
+`OPS_HUB_KEY`, bearer tokens, cookies, or any operator credential.
+
+This revision aligns the contract to the live `ops-hub` manifest vocabulary
+observed on 2026-06-27 and to the source seed files in `ops-hub`:
+
+- event types use the live registry names such as `ops-service-discovered` and
+  `ops-drift-detected`;
+- widget types use live seed types such as `ops-service`, `ops-endpoint`,
+  `ops-backup-set`, `ops-readiness-gate`, and `ops-risk`;
+- policy scopes use the declared ops scopes; there is no `ops-evidence` scope
+  in the live manifest;
+- access-path evidence remains deferred until ops-hub explicitly adds an
+  access-path event and widget type or activity-core maps it to a supported
+  readiness/risk event by decision.
 
 Activity-core currently only checks that a mapping value is present before
 returning `inter_hub_sink_deferred`. This document defines the contract that
@@ -17,6 +31,9 @@ the future Inter-Hub submission implementation should parse.
 
 ## Versioned Shape
 
+The shape remains version `v1`; this is a compatibility revision of the
+vocabulary inside the mapping, not a structural breaking change.
+
 ```json
 {
   "version": "ops-hub.activity-core.widget-mapping.v1",
@@ -24,87 +41,109 @@ the future Inter-Hub submission implementation should parse.
     "slug": "ops-hub",
     "id": "<ops-hub-uuid>"
   },
-  "policyScope": "ops-evidence",
   "defaultViewContext": "ops-inventory-probe",
+  "allowedPolicyScopes": [
+    "ops-local",
+    "ops-transitional-prod",
+    "ops-production",
+    "ops-threephoenix",
+    "ops-registry",
+    "ops-secrets",
+    "ops-backup-retention"
+  ],
+  "eventAliases": {
+    "ops-service-observed": "ops-service-discovered",
+    "ops-inventory-drift": "ops-drift-detected"
+  },
+  "deferredEvents": {
+    "ops-access-path-checked": {
+      "reason": "not_declared_by_live_ops_hub_manifest",
+      "fallback": "state-hub-progress",
+      "decisionNeeded": "add ops-access-path vocabulary or map access-path evidence to ops-readiness-gate-updated/ops-risk-raised"
+    }
+  },
   "events": {
-    "ops-service-observed": {
+    "ops-service-discovered": {
       "family": "services",
-      "aggregateWidgetRef": "ops:service:aggregate"
+      "selector": "service_id",
+      "defaultWidgetRef": "ops:service-catalog"
     },
     "ops-endpoint-verified": {
       "family": "endpoints",
-      "aggregateWidgetRef": "ops:endpoint:aggregate"
+      "selector": "<service_id>:<endpoint_id>",
-    },
+      "defaultWidgetRef": "ops:endpoint:gitea-registry"
-    "ops-access-path-checked": {
-      "family": "accessPaths",
-      "aggregateWidgetRef": "ops:access-path:aggregate"
     },
     "ops-backup-verified": {
       "family": "backups",
-      "aggregateWidgetRef": "ops:backup:aggregate"
+      "selector": "<service_id>:<backing_store_ref>",
+      "defaultWidgetRef": "ops:backup-set:aggregate",
+      "requiresSeed": true
     },
-    "ops-inventory-drift": {
+    "ops-drift-detected": {
-      "family": "drift",
+      "family": "readiness",
-      "aggregateWidgetRef": "ops:drift:aggregate"
+      "selector": "<service_id>:<inventory_object_id>",
+      "defaultWidgetRef": "ops:readiness:gitea-registry"
     }
   },
   "widgets": {
-    "aggregate": {
+    "byRef": {
-      "ops:service:aggregate": {
+      "ops:service-catalog": {
         "widgetId": "<uuid>",
-        "widgetType": "ops-service-card",
+        "widgetType": "ops-service-catalog",
-        "name": "Ops Service Evidence Intake"
+        "policyScope": "ops-production",
+        "name": "Operations Service Catalog"
       },
-      "ops:endpoint:aggregate": {
+      "ops:service:state-hub": {
         "widgetId": "<uuid>",
-        "widgetType": "ops-endpoint-card",
+        "widgetType": "ops-service",
-        "name": "Ops Endpoint Evidence Intake"
+        "policyScope": "ops-local",
+        "name": "State Hub Service"
       },
-      "ops:access-path:aggregate": {
+      "ops:service:gitea": {
         "widgetId": "<uuid>",
-        "widgetType": "ops-access-path-card",
+        "widgetType": "ops-service",
-        "name": "Ops Access Path Evidence Intake"
+        "policyScope": "ops-transitional-prod",
+        "name": "Gitea Service"
       },
-      "ops:backup:aggregate": {
+      "ops:service:inter-hub": {
         "widgetId": "<uuid>",
-        "widgetType": "ops-backup-card",
+        "widgetType": "ops-service",
-        "name": "Ops Backup Evidence Intake"
+        "policyScope": "ops-production",
+        "name": "Inter-Hub Service"
       },
-      "ops:drift:aggregate": {
+      "ops:endpoint:gitea-registry": {
         "widgetId": "<uuid>",
-        "widgetType": "ops-drift-card",
+        "widgetType": "ops-endpoint",
-        "name": "Ops Inventory Drift Evidence Intake"
+        "policyScope": "ops-registry",
+        "name": "Gitea Registry Endpoint"
+      },
+      "ops:readiness:gitea-registry": {
+        "widgetId": "<uuid>",
+        "widgetType": "ops-readiness-gate",
+        "policyScope": "ops-registry",
+        "name": "Gitea Registry Readiness"
+      },
+      "ops:backup-set:aggregate": {
+        "widgetId": "<uuid>",
+        "widgetType": "ops-backup-set",
+        "policyScope": "ops-backup-retention",
+        "name": "Ops Backup Evidence Intake",
+        "requiresSeed": true
       }
     },
     "services": {
-      "state-hub": {
+      "state-hub": { "widgetRef": "ops:service:state-hub" },
-        "widgetRef": "ops:service:state-hub",
+      "gitea": { "widgetRef": "ops:service:gitea" },
-        "widgetId": "<uuid>"
+      "inter-hub": { "widgetRef": "ops:service:inter-hub" }
-      }
     },
     "endpoints": {
-      "gitea:gitea-oci-registry": {
+      "gitea:gitea-oci-registry": { "widgetRef": "ops:endpoint:gitea-registry" }
-        "widgetRef": "ops:endpoint:gitea-registry",
-        "widgetId": "<uuid>"
-      }
-    },
-    "accessPaths": {
-      "gitea:gitea-access-1": {
-        "widgetRef": "ops:access-path:gitea-access-1",
-        "widgetId": "<uuid>"
-      }
     },
     "backups": {
-      "gitea:database:gitea-db": {
+      "gitea:database:gitea-db": { "widgetRef": "ops:backup-set:aggregate" }
-        "widgetRef": "ops:backup:gitea-db",
-        "widgetId": "<uuid>"
-      }
     },
-    "drift": {
+    "readiness": {
-      "gitea:gitea-oci-registry": {
+      "gitea:gitea-oci-registry": { "widgetRef": "ops:readiness:gitea-registry" }
-        "widgetRef": "ops:drift:gitea-oci-registry",
-        "widgetId": "<uuid>"
-      }
     }
   }
 }
@@ -115,44 +154,60 @@ the future Inter-Hub submission implementation should parse.
 Activity-core should choose a widget in this order:
 
 1. If the evidence payload carries a `widget_ref` and that reference exists in
-   the mapping, use it.
+   `widgets.byRef`, use it.
-2. For `ops-service-observed`, use `services["<service_id>"]`.
+2. If the event name is present in `eventAliases`, translate it to the live
-3. For `ops-endpoint-verified`, use
+   event name before selector lookup and submission.
-   `endpoints["<service_id>:<endpoint_id>"]`.
+3. For `ops-service-discovered`, use `services["<service_id>"]`; otherwise use
-4. For `ops-access-path-checked`, use
+   `ops:service-catalog`.
-   `accessPaths["<service_id>:<access_path_id>"]`.
+4. For `ops-endpoint-verified`, use
+   `endpoints["<service_id>:<endpoint_id>"]`; otherwise skip or use a
+   deliberately seeded endpoint aggregate.
 5. For `ops-backup-verified`, use
-   `backups["<service_id>:<backing_store_ref>"]`.
+   `backups["<service_id>:<backing_store_ref>"]`; otherwise skip until a
-6. For `ops-inventory-drift`, use
+   backup-set widget is seeded.
-   `drift["<service_id>:<inventory_object_id>"]`.
+6. For `ops-drift-detected`, use
-7. If no entity-specific widget exists, use the event's aggregate widget.
+   `readiness["<service_id>:<inventory_object_id>"]`; otherwise use a seeded
-8. If neither an entity-specific nor aggregate widget exists, skip Inter-Hub
+   readiness/risk widget chosen by the operator.
-   submission with a non-secret result that names the missing selector.
+7. For `ops-access-path-checked`, do not submit to Inter-Hub yet. Keep State
+   Hub fallback evidence unless ops-hub adds access-path vocabulary or an
+   explicit decision maps access-path checks to readiness/risk events.
+8. If no selector can resolve to a widget id, skip Inter-Hub submission with a
+   non-secret result naming the missing selector.
 
 ## Bootstrap Widget Names
 
-The initial aggregate widgets should be seeded before activity-core is pointed
+These refs are already present in the current `ops-hub` seed file and should be
-at Inter-Hub:
+looked up in the protected widget registry during the authenticated bootstrap:
 
-| Widget ref | Widget type | Suggested name |
+| Widget ref | Widget type | Name |
-|---|---|---|
+| --- | --- | --- |
-| `ops:service:aggregate` | `ops-service-card` | Ops Service Evidence Intake |
+| `ops:service-catalog` | `ops-service-catalog` | Operations Service Catalog |
-| `ops:endpoint:aggregate` | `ops-endpoint-card` | Ops Endpoint Evidence Intake |
+| `ops:service:gitea` | `ops-service` | Gitea Service |
-| `ops:access-path:aggregate` | `ops-access-path-card` | Ops Access Path Evidence Intake |
+| `ops:service:state-hub` | `ops-service` | State Hub Service |
-| `ops:backup:aggregate` | `ops-backup-card` | Ops Backup Evidence Intake |
+| `ops:service:inter-hub` | `ops-service` | Inter-Hub Service |
-| `ops:drift:aggregate` | `ops-drift-card` | Ops Inventory Drift Evidence Intake |
+| `ops:endpoint:gitea-registry` | `ops-endpoint` | Gitea Registry Endpoint |
+| `ops:readiness:gitea-registry` | `ops-readiness-gate` | Gitea Registry Readiness |
+
+Additional seed required before backup evidence can be smoke-tested:
+
+| Widget ref | Widget type | Suggested name | Policy scope |
+| --- | --- | --- | --- |
+| `ops:backup-set:aggregate` | `ops-backup-set` | Ops Backup Evidence Intake | `ops-backup-retention` |
 
 Per-entity widgets may be seeded later without changing the event contract.
-When a per-entity widget is added, update the mapping and keep the aggregate
+When a per-entity widget is added, update the mapping and keep a deliberate
-widget as the fallback.
+fallback only when the fallback widget actually exists in the protected widget
+registry.
 
 ## Compatibility Rules
 
 - `version` is required. Reject unknown major versions.
 - Consumers must tolerate additional fields.
 - Widget UUIDs may rotate, but `widgetRef` values should remain stable.
-- Removing a widget mapping is a breaking change for that selector unless the
+- Event aliases are a transition aid only. New activity-core submissions should
-  aggregate fallback remains present.
+  use live registry event names directly.
+- Removing a widget mapping is a breaking change for that selector unless a
+  verified fallback widget remains present.
 - Mapping updates must be deployed before activity-core starts sending events
   that depend on the new selectors.
 - The mapping is non-secret and may be stored in a ConfigMap or environment
@@ -160,7 +215,9 @@ widget as the fallback.
 
 ## Minimum Valid Mapping
 
-For the first live smoke, an aggregate-only mapping is enough:
+For the first live smoke, use only live registry events and widgets that are
+known from the seed contract and can be confirmed through an authenticated
+widget lookup. Backup and access-path evidence can remain deferred.
 
 ```json
 {
@@ -169,37 +226,30 @@ For the first live smoke, an aggregate-only mapping is enough:
     "slug": "ops-hub",
     "id": "<ops-hub-uuid>"
   },
-  "policyScope": "ops-evidence",
   "defaultViewContext": "ops-inventory-probe",
+  "eventAliases": {
+    "ops-service-observed": "ops-service-discovered",
+    "ops-inventory-drift": "ops-drift-detected"
+  },
   "events": {
-    "ops-service-observed": {
+    "ops-service-discovered": {
       "family": "services",
-      "aggregateWidgetRef": "ops:service:aggregate"
+      "defaultWidgetRef": "ops:service-catalog"
     },
     "ops-endpoint-verified": {
       "family": "endpoints",
-      "aggregateWidgetRef": "ops:endpoint:aggregate"
+      "defaultWidgetRef": "ops:endpoint:gitea-registry"
     },
-    "ops-access-path-checked": {
+    "ops-drift-detected": {
-      "family": "accessPaths",
+      "family": "readiness",
-      "aggregateWidgetRef": "ops:access-path:aggregate"
+      "defaultWidgetRef": "ops:readiness:gitea-registry"
-    },
-    "ops-backup-verified": {
-      "family": "backups",
-      "aggregateWidgetRef": "ops:backup:aggregate"
-    },
-    "ops-inventory-drift": {
-      "family": "drift",
-      "aggregateWidgetRef": "ops:drift:aggregate"
     }
   },
   "widgets": {
-    "aggregate": {
+    "byRef": {
-      "ops:service:aggregate": { "widgetId": "<uuid>" },
+      "ops:service-catalog": { "widgetId": "<uuid>" },
-      "ops:endpoint:aggregate": { "widgetId": "<uuid>" },
+      "ops:endpoint:gitea-registry": { "widgetId": "<uuid>" },
-      "ops:access-path:aggregate": { "widgetId": "<uuid>" },
+      "ops:readiness:gitea-registry": { "widgetId": "<uuid>" }
-      "ops:backup:aggregate": { "widgetId": "<uuid>" },
-      "ops:drift:aggregate": { "widgetId": "<uuid>" }
     }
   }
 }

docs/research/ops-hub-evidence-intake-current-state.md

@@ -1,6 +1,7 @@
 # Ops Hub Evidence Intake - Current State
 
 Date: 2026-06-15
+Updated: 2026-06-27
 
 Workplan: `IHUB-WP-0022`
 
@@ -17,6 +18,26 @@ slice is therefore contract-first:
 - wait on live ops-hub manifest/widgets, key provisioning, and production
   smoke before enabling per-entity Inter-Hub submission.
 
+
+## 2026-06-27 Live Vocabulary Alignment
+
+Public production probes now show an `ops-hub` row and public registry
+vocabulary on `https://hub.coulomb.social`. The live ops-hub seed vocabulary
+supersedes the early activity-core proposal for several names:
+
+| Early proposal | Live target |
+| --- | --- |
+| `ops-service-observed` | `ops-service-discovered` |
+| `ops-inventory-drift` | `ops-drift-detected` |
+| `ops-access-path-checked` | Deferred; no live access-path event or widget type |
+| `ops-evidence` policy scope | Use declared scopes such as `ops-production`, `ops-registry`, or `ops-backup-retention` |
+| card-style widget types | Use live widget types such as `ops-service`, `ops-endpoint`, `ops-backup-set`, `ops-readiness-gate`, and `ops-risk` |
+
+The contract docs have been revised to target the live seed vocabulary and to
+keep access-path evidence on the State Hub fallback path until ops-hub either
+adds access-path vocabulary or records an explicit readiness/risk mapping
+decision.
+
 ## Inter-Hub API Surface
 
 The current repo supports the necessary primitives through `/api/v2`.
@@ -119,30 +140,39 @@ Known gates before per-entity Inter-Hub submission can be treated as live:
 
 ## Recommended Manifest Vocabulary
 
-Use one policy scope for the first slice:
+Use the live ops-hub manifest vocabulary rather than the early proposal names.
+The current target is:
 
-- `ops-evidence`
+Policy scopes:
 
-Use one annotation category:
+- `ops-local`
+- `ops-transitional-prod`
+- `ops-production`
+- `ops-threephoenix`
+- `ops-registry`
+- `ops-secrets`
+- `ops-backup-retention`
 
-- `ops-risk`
+Widget types for activity-core evidence:
 
-Use these widget types unless the operator prefers to keep a smaller aggregate
+- `ops-service-catalog`
-surface:
+- `ops-service`
+- `ops-endpoint`
+- `ops-backup-set`
+- `ops-readiness-gate`
+- `ops-risk` when risk-specific drift representation is needed
 
-- `ops-service-card`
+Event types for the first Inter-Hub activity-core slice:
-- `ops-endpoint-card`
-- `ops-access-path-card`
-- `ops-backup-card`
-- `ops-drift-card`
 
-Use the activity-core event types exactly as published:
+- `ops-service-discovered`
-
-- `ops-service-observed`
 - `ops-endpoint-verified`
-- `ops-access-path-checked`
+- `ops-backup-verified` after a backup-set widget exists
-- `ops-backup-verified`
+- `ops-drift-detected`
-- `ops-inventory-drift`
+
+Keep `ops-access-path-checked` deferred until ops-hub declares access-path
+vocabulary or a separate decision maps those checks to readiness/risk events.
+Do not seed the old `ops-evidence` policy scope unless the manifest is
+explicitly expanded to include it.
 
 ## Open Questions
 

workplans/ADHOC-2026-06-06.md

@@ -9,6 +9,7 @@ owner: codex
 topic_slug: inter_hub
 created: "2026-06-06"
 updated: "2026-06-06"
+state_hub_workstream_id: "302b4e09-a03c-4afe-939f-4c89c84bc2c9"
 ---
 
 # ADHOC-2026-06-06 - Ad hoc fixes for 2026-06-06
@@ -19,6 +20,7 @@ updated: "2026-06-06"
 id: ADHOC-2026-06-06-T01
 status: done
 priority: medium
+state_hub_task_id: "153f02de-803c-4a78-9cd7-0f6483c787ea"
 ```
 
 Added default `make` help plus `install`, `install-nix`, `doctor`, and `ui`

workplans/IHUB-WP-0001-ihf-phase1-minimal-interaction-core.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0001
 type: workplan
 title: "IHF Phase 1 — Minimal Interaction Core"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0002-ihf-phase2-structured-feedback-and-triage.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0002
 type: workplan
 title: "IHF Phase 2 — Structured Feedback and Triage"
-domain: custodian
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0003-ihf-phase3-governance-and-decision-linkage.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0003
 type: workplan
 title: "IHF Phase 3 — Governance and Decision Linkage"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0004-ihf-phase4-outcome-observation-and-antifragility.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0004
 type: workplan
 title: "IHF Phase 4 — Outcome Observation and Antifragility Loop"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0005-ihf-phase5-agent-assisted-distillation.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0005
 type: workplan
 title: "IHF Phase 5 — Agent-Assisted Distillation and Suggestion"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0006-ihf-phase6-cross-framework-ui-adaptation.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0006
 type: workplan
 title: "IHF Phase 6 — Cross-Framework UI Adaptation Layer"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0007-ihf-phase7-advanced-observability-and-operational-integration.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0007
 type: workplan
 title: "IHF Phase 7 — Advanced Observability and Operational Integration"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0008-ihf-phase8-federated-hub-maturity.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0008
 type: workplan
 title: "IHF Phase 8 — Federated Hub Maturity"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0009-gaaf-compliance-foundation.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0009
 type: workplan
 title: "IHF GAAF Compliance Foundation — Type Registries, Extension Manifests, and Architectural Contracts"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0010-ihf-phase9-external-api.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0010
 type: workplan
 title: "IHF Phase 9 — External API Surface and Consumer SDKs"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0011-ihf-phase10-hub-registry.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0011
 type: workplan
 title: "IHF Phase 10 — Hub Registry and Widget Marketplace"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0012-ihf-phase11-advanced-ai-federation.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0012
 type: workplan
 title: "IHF Phase 11 — Advanced AI Federation"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0013-ihf-phase12-platform-memory.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0013
 type: workplan
 title: "IHF Phase 12 — Platform Memory and Continuous Learning"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0014-pre-flight-deployment-gaps.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0014
 type: workplan
 title: "Pre-flight: Close Deployment Gaps"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0015-local-deployment-intro-ui.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0015
 type: workplan
 title: "Local Deployment — Intro and Tutorial Web UI"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian
@@ -11,8 +11,7 @@ created: "2026-04-03"
 updated: "2026-04-03"
 state_hub_sync: done
 state_hub_workstream_id: "946d50b8-441c-4c0a-b1a0-2a4fb3340d16"
-depends_on: IHUB-WP-0014
+depends_on: IHUB-WP-0014---
----
 
 # IHUB-WP-0015 — Local Deployment: Intro and Tutorial Web UI
 

workplans/IHUB-WP-0016-build-infrastructure-and-error-loop.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0016
 type: workplan
 title: "Build Infrastructure: Incremental Compilation and Autonomous Error-Fix Loop"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0017-error-fix-loop.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0017
 type: workplan
 title: "Autonomous Error-Fix Loop: Reach Clean Build"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: done
 owner: custodian

workplans/IHUB-WP-0018-railiance01-deployment.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0018
 type: workplan
 title: "Railiance01 Deployment — Production Operations Scaffold"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: finished
 owner: custodian

workplans/IHUB-WP-0019-vsm-hub-bootstrap-api.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0019
 type: workplan
 title: "VSM Hub Bootstrap API Hardening"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: finished
 owner: codex

workplans/IHUB-WP-0020-personal-dashboard-framework.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0020
 type: workplan
 title: "Personal Dashboard Framework"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: finished
 owner: tegwick

workplans/IHUB-WP-0021-personal-dashboard-implementation.md

@@ -2,7 +2,7 @@
 id: IHUB-WP-0021
 type: workplan
 title: "Personal Dashboard Implementation"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: ready
 owner: codex

workplans/IHUB-WP-0022-ops-hub-evidence-intake.md

@@ -2,13 +2,13 @@
 id: IHUB-WP-0022
 type: workplan
 title: "Ops Hub Evidence Intake for Activity Core"
-domain: inter_hub
+domain: infotech
 repo: inter-hub
 status: active
 owner: codex
 topic_slug: inter_hub
 created: "2026-06-15"
-updated: "2026-06-16"
+updated: "2026-06-27"
 planning_priority: high
 planning_order: 22
 related_repos:
@@ -94,20 +94,22 @@ closed.
 
 ## Proposed Evidence Vocabulary
 
-Activity-core has already declared the event contracts it wants to send:
+The original activity-core suggestion used five evidence names. Production
+ops-hub now exposes a live seed vocabulary, so the Inter-Hub activation target
+is the compatibility mapping below rather than the early names verbatim:
 
-| Event type | Suggested widget family | Purpose |
+| Original evidence intent | Live Inter-Hub target | Widget family | Purpose |
-|---|---|---|
+|---|---|---|---|
-| `ops-service-observed` | service inventory | Record that a service exists and was observed. |
+| `ops-service-observed` | `ops-service-discovered` | `ops-service` / `ops-service-catalog` | Record that a service exists and was discovered. |
-| `ops-endpoint-verified` | endpoint inventory | Record endpoint reachability, auth challenge, or health verification. |
+| `ops-endpoint-verified` | `ops-endpoint-verified` | `ops-endpoint` | Record endpoint reachability, auth challenge, or health verification. |
-| `ops-access-path-checked` | access path inventory | Record operator or service access path verification. |
+| `ops-access-path-checked` | deferred | State Hub fallback until ops-hub adds access-path vocabulary or maps it to readiness/risk | Record operator or service access path verification without inventing unsupported registry names. |
-| `ops-backup-verified` | backup inventory | Record backup presence, recency, or restore-drill evidence. |
+| `ops-backup-verified` | `ops-backup-verified` | `ops-backup-set` | Record backup presence, recency, or restore-drill evidence after a backup-set widget exists. |
-| `ops-inventory-drift` | drift inventory | Record drift between expected and observed operations inventory. |
+| `ops-inventory-drift` | `ops-drift-detected` | `ops-readiness-gate` / `ops-risk` | Record drift between expected and observed operations inventory. |
 
-The first implementation should keep one stable widget per entity and evidence
+The first implementation should use existing seeded widgets where possible and
-family where possible. If activity-core cannot know entity identity reliably,
+seed only the missing backup/risk widgets that are needed for the attended
-use one aggregate intake widget per family as a conservative first slice, then
+smoke. If activity-core cannot know entity identity reliably, keep State Hub
-split into per-entity widgets after payload evidence proves stable.
+fallback evidence rather than submitting to a made-up aggregate widget.
 
 ## Tasks
 
@@ -179,6 +181,13 @@ versioned non-secret `OPS_HUB_WIDGET_MAPPING` JSON shape, aggregate-first
 fallback widgets, per-entity selector rules, stable `widgetRef` values, and
 Secret-only handling for `OPS_HUB_KEY`.
 
+Compatibility note (2026-06-27): revised the mapping contract to match the
+live ops-hub seed vocabulary. The mapping now aliases `ops-service-observed`
+to `ops-service-discovered`, aliases `ops-inventory-drift` to
+`ops-drift-detected`, uses declared ops policy scopes instead of the old
+`ops-evidence` proposal, and defers access-path evidence until ops-hub has a
+supported event/widget target.
+
 ---
 
 ### T03 - Prepare manifest vocabulary and seed widgets
@@ -218,6 +227,12 @@ environment with the `5101eb5` COUNT decode fix live and an authenticated
 operator/runtime key path. The required vocabulary is documented, but no live
 manifest or widget seed was performed in this implementation slice.
 
+Progress note (2026-06-27): public production probes show an `ops-hub` row and
+the live seed registry vocabulary, and the contract docs now target that live
+vocabulary. T03 remains waiting because protected widget lookup, widget ids,
+any missing backup/risk seed widgets, and authenticated smoke evidence still
+require the operator/runtime key path.
+
 ---
 
 ### T04 - Provision the runtime API key outside Git
@@ -289,6 +304,11 @@ Inter-Hub request envelope, shared validation rules, idempotency expectations,
 forbidden payload material, expected API errors, and one example for each
 activity-core event type.
 
+Compatibility note (2026-06-27): revised payload examples to submit only live
+ops-hub event types. Access-path payloads are documented as deferred fallback
+evidence, and old event names are treated as aliases that should not be posted
+to Inter-Hub.
+
 ---
 
 ### T06 - Validate fallback-first intake