Compare commits

..

16 Commits

Author SHA1 Message Date
9b0e43a8d2 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-07-01:
  - update .custodian-brief.md for inter-hub
2026-07-01 21:37:52 +02:00
4cb9415bc9 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-07-01:
  - update .custodian-brief.md for inter-hub
2026-07-01 21:22:15 +02:00
cb3182e9fd chore: sync ad hoc workplan hub ids 2026-07-01 20:02:32 +02:00
ba2d8e1f53 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-06-29:
  - update .custodian-brief.md for inter-hub
2026-06-29 17:17:47 +02:00
13003e98dc chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-06-29:
  - update .custodian-brief.md for inter-hub
2026-06-29 17:06:09 +02:00
7cee801f58 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-06-27:
  - update .custodian-brief.md for inter-hub
2026-06-27 14:33:21 +02:00
a412f1430b chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-06-27:
  - update .custodian-brief.md for inter-hub
2026-06-27 14:04:49 +02:00
f93f8169e2 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-06-27:
  - update .custodian-brief.md for inter-hub
2026-06-27 13:47:40 +02:00
59b9913d3a chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-06-27:
  - update .custodian-brief.md for inter-hub
2026-06-27 13:35:47 +02:00
81cb73f593 Align ops-hub activity-core contract vocabulary 2026-06-27 09:58:52 +02:00
b90320e4e7 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-06-23:
  - update .custodian-brief.md for inter-hub
2026-06-23 21:49:12 +02:00
9582bf5277 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-06-23:
  - update .custodian-brief.md for inter-hub
2026-06-23 21:34:37 +02:00
f27e1551c9 Normalize agent instructions and workplan frontmatter (STATE-WP-0067)
All checks were successful
Build and Deploy / build-push-deploy (push) Successful in 3m45s
- 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:25 +02:00
e93145966f chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-06-22:
  - update .custodian-brief.md for inter-hub
2026-06-22 12:39:32 +02:00
e558d3deba Mark .repo-classification.yaml human-reviewed (CUST-WP-0050 T02)
Some checks failed
Build and Deploy / build-push-deploy (push) Has been cancelled
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 11:40:43 +02:00
dbab7ac1d7 Add repo classification (CUST-WP-0050 T02)
Some checks failed
Build and Deploy / build-push-deploy (push) Has been cancelled
First-pass agent classification per the Repo Classification Standard v1.0
(canon-repo-classification); pending human review.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 02:44:46 +02:00
33 changed files with 383 additions and 222 deletions

View File

@@ -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/custodian/roadmap_v0.1.md` — planned phases
- `~/the-custodian/canon/projects/infotech/project_charter_v0.1.md` — purpose, scope
- `~/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}

View File

@@ -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

View File

@@ -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"*

View File

@@ -1,7 +1,7 @@
## Workplan Convention (ADR-001)
File location: `workplans/inter-hub-WP-NNNN-<slug>.md`
ID prefix: `INTER-WP`
File location: `workplans/IHUB-WP-NNNN-<slug>.md`
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 -->

View File

@@ -1,8 +1,8 @@
<!-- custodian-brief: generated by fix-consistency — do not edit manually -->
# Custodian Brief — inter-hub
**Domain:** inter_hub
**Last synced:** 2026-06-21 14:07 UTC
**Domain:** infotech
**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.

27
.repo-classification.yaml Normal file
View File

@@ -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.

View File

@@ -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"}'
# values: todo | in_progress | done | blocked
-d '{"status": "progress"}'
# 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

View File

@@ -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>",
"eventType": "ops-service-observed",
"widgetId": "<service-or-catalog-widget-uuid>",
"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
{
"widgetId": "<access-path-widget-uuid>",
"eventType": "ops-access-path-checked",
"viewContext": "ops-inventory-probe/access-paths",
"metadata": {
"type": "ops-access-path-checked",
"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-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"
}
}
}
```
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
continue to include compact access-path detail in State Hub fallback summaries
and return a non-secret deferred sink result for Inter-Hub.
If the operator chooses to represent access-path state as readiness or risk,
create a separate mapping decision and send the supported event type instead of
silently rewriting access-path evidence.
## 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>",
"eventType": "ops-inventory-drift",
"widgetId": "<readiness-or-risk-widget-uuid>",
"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 `unregistered_policy_scope` during widget seed | Policy scope is absent | Declare and activate `ops-evidence`. |
| `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 | 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

View File

@@ -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
`OPS_HUB_KEY` or any operator credential.
Inter-Hub widget UUIDs and stable logical refs, but it must never contain
`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"
},
"ops-access-path-checked": {
"family": "accessPaths",
"aggregateWidgetRef": "ops:access-path:aggregate"
"selector": "<service_id>:<endpoint_id>",
"defaultWidgetRef": "ops:endpoint:gitea-registry"
},
"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": {
"family": "drift",
"aggregateWidgetRef": "ops:drift:aggregate"
"ops-drift-detected": {
"family": "readiness",
"selector": "<service_id>:<inventory_object_id>",
"defaultWidgetRef": "ops:readiness:gitea-registry"
}
},
"widgets": {
"aggregate": {
"ops:service:aggregate": {
"byRef": {
"ops:service-catalog": {
"widgetId": "<uuid>",
"widgetType": "ops-service-card",
"name": "Ops Service Evidence Intake"
"widgetType": "ops-service-catalog",
"policyScope": "ops-production",
"name": "Operations Service Catalog"
},
"ops:endpoint:aggregate": {
"ops:service:state-hub": {
"widgetId": "<uuid>",
"widgetType": "ops-endpoint-card",
"name": "Ops Endpoint Evidence Intake"
"widgetType": "ops-service",
"policyScope": "ops-local",
"name": "State Hub Service"
},
"ops:access-path:aggregate": {
"ops:service:gitea": {
"widgetId": "<uuid>",
"widgetType": "ops-access-path-card",
"name": "Ops Access Path Evidence Intake"
"widgetType": "ops-service",
"policyScope": "ops-transitional-prod",
"name": "Gitea Service"
},
"ops:backup:aggregate": {
"ops:service:inter-hub": {
"widgetId": "<uuid>",
"widgetType": "ops-backup-card",
"name": "Ops Backup Evidence Intake"
"widgetType": "ops-service",
"policyScope": "ops-production",
"name": "Inter-Hub Service"
},
"ops:drift:aggregate": {
"ops:endpoint:gitea-registry": {
"widgetId": "<uuid>",
"widgetType": "ops-drift-card",
"name": "Ops Inventory Drift Evidence Intake"
"widgetType": "ops-endpoint",
"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": {
"widgetRef": "ops:service:state-hub",
"widgetId": "<uuid>"
}
"state-hub": { "widgetRef": "ops:service:state-hub" },
"gitea": { "widgetRef": "ops:service:gitea" },
"inter-hub": { "widgetRef": "ops:service:inter-hub" }
},
"endpoints": {
"gitea:gitea-oci-registry": {
"widgetRef": "ops:endpoint:gitea-registry",
"widgetId": "<uuid>"
}
},
"accessPaths": {
"gitea:gitea-access-1": {
"widgetRef": "ops:access-path:gitea-access-1",
"widgetId": "<uuid>"
}
"gitea:gitea-oci-registry": { "widgetRef": "ops:endpoint:gitea-registry" }
},
"backups": {
"gitea:database:gitea-db": {
"widgetRef": "ops:backup:gitea-db",
"widgetId": "<uuid>"
}
"gitea:database:gitea-db": { "widgetRef": "ops:backup-set:aggregate" }
},
"drift": {
"gitea:gitea-oci-registry": {
"widgetRef": "ops:drift:gitea-oci-registry",
"widgetId": "<uuid>"
}
"readiness": {
"gitea:gitea-oci-registry": { "widgetRef": "ops:readiness:gitea-registry" }
}
}
}
@@ -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.
2. For `ops-service-observed`, use `services["<service_id>"]`.
3. For `ops-endpoint-verified`, use
`endpoints["<service_id>:<endpoint_id>"]`.
4. For `ops-access-path-checked`, use
`accessPaths["<service_id>:<access_path_id>"]`.
`widgets.byRef`, use it.
2. If the event name is present in `eventAliases`, translate it to the live
event name before selector lookup and submission.
3. For `ops-service-discovered`, use `services["<service_id>"]`; otherwise use
`ops:service-catalog`.
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>"]`.
6. For `ops-inventory-drift`, use
`drift["<service_id>:<inventory_object_id>"]`.
7. If no entity-specific widget exists, use the event's aggregate widget.
8. If neither an entity-specific nor aggregate widget exists, skip Inter-Hub
submission with a non-secret result that names the missing selector.
`backups["<service_id>:<backing_store_ref>"]`; otherwise skip until a
backup-set widget is seeded.
6. For `ops-drift-detected`, use
`readiness["<service_id>:<inventory_object_id>"]`; otherwise use a seeded
readiness/risk widget chosen by the operator.
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
at Inter-Hub:
These refs are already present in the current `ops-hub` seed file and should be
looked up in the protected widget registry during the authenticated bootstrap:
| Widget ref | Widget type | Suggested name |
|---|---|---|
| `ops:service:aggregate` | `ops-service-card` | Ops Service Evidence Intake |
| `ops:endpoint:aggregate` | `ops-endpoint-card` | Ops Endpoint Evidence Intake |
| `ops:access-path:aggregate` | `ops-access-path-card` | Ops Access Path Evidence Intake |
| `ops:backup:aggregate` | `ops-backup-card` | Ops Backup Evidence Intake |
| `ops:drift:aggregate` | `ops-drift-card` | Ops Inventory Drift Evidence Intake |
| Widget ref | Widget type | Name |
| --- | --- | --- |
| `ops:service-catalog` | `ops-service-catalog` | Operations Service Catalog |
| `ops:service:gitea` | `ops-service` | Gitea Service |
| `ops:service:state-hub` | `ops-service` | State Hub Service |
| `ops:service:inter-hub` | `ops-service` | Inter-Hub Service |
| `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
widget as the fallback.
When a per-entity widget is added, update the mapping and keep a deliberate
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
aggregate fallback remains present.
- Event aliases are a transition aid only. New activity-core submissions should
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": {
"family": "accessPaths",
"aggregateWidgetRef": "ops:access-path:aggregate"
},
"ops-backup-verified": {
"family": "backups",
"aggregateWidgetRef": "ops:backup:aggregate"
},
"ops-inventory-drift": {
"family": "drift",
"aggregateWidgetRef": "ops:drift:aggregate"
"ops-drift-detected": {
"family": "readiness",
"defaultWidgetRef": "ops:readiness:gitea-registry"
}
},
"widgets": {
"aggregate": {
"ops:service:aggregate": { "widgetId": "<uuid>" },
"ops:endpoint:aggregate": { "widgetId": "<uuid>" },
"ops:access-path:aggregate": { "widgetId": "<uuid>" },
"ops:backup:aggregate": { "widgetId": "<uuid>" },
"ops:drift:aggregate": { "widgetId": "<uuid>" }
"byRef": {
"ops:service-catalog": { "widgetId": "<uuid>" },
"ops:endpoint:gitea-registry": { "widgetId": "<uuid>" },
"ops:readiness:gitea-registry": { "widgetId": "<uuid>" }
}
}
}

View File

@@ -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
surface:
- `ops-service-catalog`
- `ops-service`
- `ops-endpoint`
- `ops-backup-set`
- `ops-readiness-gate`
- `ops-risk` when risk-specific drift representation is needed
- `ops-service-card`
- `ops-endpoint-card`
- `ops-access-path-card`
- `ops-backup-card`
- `ops-drift-card`
Event types for the first Inter-Hub activity-core slice:
Use the activity-core event types exactly as published:
- `ops-service-observed`
- `ops-service-discovered`
- `ops-endpoint-verified`
- `ops-access-path-checked`
- `ops-backup-verified`
- `ops-inventory-drift`
- `ops-backup-verified` after a backup-set widget exists
- `ops-drift-detected`
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

View File

@@ -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`

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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 |
|---|---|---|
| `ops-service-observed` | service inventory | Record that a service exists and was observed. |
| `ops-endpoint-verified` | endpoint inventory | Record endpoint reachability, auth challenge, or health verification. |
| `ops-access-path-checked` | access path inventory | Record operator or service access path verification. |
| `ops-backup-verified` | backup inventory | Record backup presence, recency, or restore-drill evidence. |
| `ops-inventory-drift` | drift inventory | Record drift between expected and observed operations inventory. |
| Original evidence intent | Live Inter-Hub target | Widget family | Purpose |
|---|---|---|---|
| `ops-service-observed` | `ops-service-discovered` | `ops-service` / `ops-service-catalog` | Record that a service exists and was discovered. |
| `ops-endpoint-verified` | `ops-endpoint-verified` | `ops-endpoint` | Record endpoint reachability, auth challenge, or health 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` | `ops-backup-verified` | `ops-backup-set` | Record backup presence, recency, or restore-drill evidence after a backup-set widget exists. |
| `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
family where possible. If activity-core cannot know entity identity reliably,
use one aggregate intake widget per family as a conservative first slice, then
split into per-entity widgets after payload evidence proves stable.
The first implementation should use existing seeded widgets where possible and
seed only the missing backup/risk widgets that are needed for the attended
smoke. If activity-core cannot know entity identity reliably, keep State Hub
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