diff --git a/architecture/README.md b/architecture/README.md index e3ec063..13665f8 100644 --- a/architecture/README.md +++ b/architecture/README.md @@ -7,6 +7,7 @@ in child repos; durable promotion targets are noted in each document. | --- | --- | --- | | [information-model_v0.1.md](information-model_v0.1.md) | SHR-WP-0001-T03 | draft-reviewable | | [information-model_v0.1.yaml](information-model_v0.1.yaml) | SHR-WP-0001-T03 | companion | -| hub-extension-architecture (T04) | SHR-WP-0001-T04 | pending | +| [hub-extension-architecture_v0.1.md](hub-extension-architecture_v0.1.md) | SHR-WP-0001-T04 | draft-reviewable | +| [hub-extension-contract_v0.1.yaml](hub-extension-contract_v0.1.yaml) | SHR-WP-0001-T04 | companion | Related: [`../inventory/`](../inventory/) disposition inventory, [`../GOAL.md`](../GOAL.md). diff --git a/architecture/hub-extension-architecture_v0.1.md b/architecture/hub-extension-architecture_v0.1.md new file mode 100644 index 0000000..08c197a --- /dev/null +++ b/architecture/hub-extension-architecture_v0.1.md @@ -0,0 +1,430 @@ +--- +id: SHR-ARCH-HUB-0001 +type: architecture +title: "Hub-Core and Domain-Extension Architecture v0.1" +status: draft-reviewable +version: "0.1" +created: "2026-08-09" +updated: "2026-08-09" +workplan_task: SHR-WP-0001-T04 +depends_on: + - SHR-ARCH-IA-0001 +related: + - architecture/information-model_v0.1.md + - the-custodian/canon/standards/orthogonal-architecture_v1.0.md + - the-custodian/docs/hub-ecosystem-architecture.md + - the-custodian/docs/hub-ecosystem-capability-bridge.md + - core-hub/docs/specs/core-hub-architecture.md + - inventory/state-hub-disposition.yaml + - GOAL.md +--- + +# Hub-Core and Domain-Extension Architecture v0.1 + +## Purpose + +Turn Orthogonal Architecture (OA) vocabulary and the HelixForge information +model into an **implementable hub-core + domain-extension contract**: what may +be called a hub, what must remain a functional component or authoritative +service, how extensions register and project, and what conformance means. + +This document satisfies the hub/domain-extension portion of the `GOAL.md` +success gates at **draft-reviewable** fidelity. Runtime schemas, OpenAPI, and +automated conformance suites land in child workplans (T05); this repo freezes +the architecture names and rules those workplans implement. + +Companion: [`hub-extension-contract_v0.1.yaml`](hub-extension-contract_v0.1.yaml). + +--- + +## Target composition (post State Hub retirement) + +```text + ┌──────────────────────────────────┐ + │ Domain hubs (extensions) │ + │ ops-hub · fin-hub · (others) │ + └───────────────┬──────────────────┘ + │ extension contract + │ (manifest, ports, events) + ┌───────────────▼──────────────────┐ + │ hub-core │ + │ runtime + contracts + SDK + │ + │ registry + projections + MCP │ + └───┬──────────┬──────────┬────────┘ + │ │ │ + ┌──────────────▼──┐ ┌────▼────┐ ┌──▼─────────────┐ + │ repo-manager │ │ activity│ │ identity/auth │ + │ (component) │ │ -core │ │ audit / issues │ + └────────┬────────┘ └────┬────┘ └───┬────────────┘ + │ │ │ + ▼ ▼ ▼ + Git / repos schedules specialized DBs +``` + +**Consolidation direction (from project goal):** today’s split of +`hub-core` (library) + `core-hub` (production `/api/v2` runtime) + parts of +`state-hub` (projections, messaging, catalogs) converges so that **hub-core is +the surviving framework and runtime**. `core-hub` is archived after cutover +evidence; State Hub is retired after capability dispositions complete. + +Until cutover, dual-run and compatibility adapters are allowed; **new permanent +authorities must not be added to State Hub**. + +--- + +## Role taxonomy (normative) + +### 1. Hub-core (framework + runtime) + +**hub-core** owns: + +| Area | Responsibility | +| --- | --- | +| Identity & addressing | Domains, hubs, agents, qualified addresses | +| Interaction | Messages, conversations, interaction events | +| Progress projections | Progress events and orientation summaries | +| Extension registry | Manifests, capability bridge, activation | +| Policy integration | Ports to policy engines (not policy authority itself) | +| Telemetry intake | Token/usage samples, correlation | +| Compatibility surface | `/api/v2` (and successors), MCP orientation tools | +| SDK & contracts | Versioned schemas, client helpers, conformance harness entrypoints | + +hub-core **does not** own: + +- Git file authority or fix-consistency (repo-manager) +- Domain-specific business data (domain hubs / specialized services) +- Secrets (credential custody) +- Authorization *decisions* (auth service) +- Schedule execution (activity-core) + +### 2. Domain hub + +A **domain hub** is an extension that represents a **market domain** or an +**orthogonal aspect** (e.g. operations, finance) and participates in HelixForge +via the extension contract. + +| Must | Must not | +| --- | --- | +| Declare a hub slug + reuse-surface capability id | Own repository file authority for other repos | +| Publish a versioned capability manifest | Bypass control-plane / policy ports | +| Own its domain data and domain APIs | Be invented merely because a service supports the framework | +| Emit cataloged interaction/domain events | Dual-write competing copies of work records | +| Provide health/readiness for composition | Store raw secrets in manifests or events | + +Examples: `ops-hub`, `fin-hub`. Counter-examples: Postgres, NATS, ops-bridge, +repo-manager, activity-core — **not** hubs. + +### 3. Functional component + +A reusable infrastructure or integration service that **supports** hubs but is +not a domain composition surface. + +| Component | Role | +| --- | --- | +| **repo-manager** | Repository representation, work-record index, consistency, governed mutations | +| **activity-core** | Schedules, ops runs, event-triggered automation | +| **issue-core** | Non-repo issue projection (if used) | +| **ops-bridge** | Private connectivity only | + +Functional components expose **ports** to hub-core; they do not register as +domain hubs unless they genuinely represent a domain/aspect. + +### 4. Authoritative service + +A specialized system that retains **execution and data authority** behind an +explicit contract: identity, flex-auth, OpenBao, Forgejo, CNPG, fabric engines, +billing ledgers, etc. + +hub-core and domain hubs **adapt** to these services; they do not re-implement +them. + +### 5. Projection + +A rebuildable read model derived from authorities (files, events, service +APIs). Projections may be served by hub-core or a component; losing a projection +DB must not destroy authority. + +### 6. Adapter + +A boundary module that translates between hub-core contracts and an external +or component API (e.g. Forgejo adapter, State Hub compatibility adapter during +migration, activity-core sink adapter). + +Adapters are versioned with the contract they implement and MUST NOT leak +foreign schemas into domain hubs. + +--- + +## Orthogonal Architecture → implementable binding + +| OA dimension | HelixForge binding | +| --- | --- | +| **Stack** | k3s, CNPG, NATS, images, tunnels — ops/platform, not “hubs” | +| **Logic L1 Capability** | `capability..` reuse-surface + catalog | +| **Logic L2 Service** | Deployed services realizing capabilities | +| **Logic L3 Composition** | hub-core extension registry + domain hub manifests | +| **Logic L4 Solution** | Products / operator experiences consuming hubs | +| **Plane P1 Workload** | Domain hub and component runtimes | +| **Plane P2 Control** | hub-core registry, policy ports, governed repo commands | +| **Plane P3 Management** | Operator console, MCP, CLIs | +| **Quality** | Sensitivity, retention, provenance from IA model | +| **Capability contract** | Manifest + OpenAPI/events/SLOs (this document) | +| **Intelligence** | Agents via control plane; autonomy lanes on work records | + +OA remains the descriptive standard; **this contract is the executable subset** +required for hub composition and State Hub replacement. + +--- + +## Extension contract (v0.1) + +### Contract identity + +| Field | Rule | +| --- | --- | +| `contract_id` | `helixforge.hub-extension` | +| `contract_version` | semver; v0.1 is draft-reviewable | +| `information_model_ref` | `SHR-ARCH-IA-0001` / `information-model_v0.1` | +| Compatibility | Additive changes OK in minor; breaking changes require major + dual-run window | + +### Hub registration package + +A domain hub is **conformant to register** when it provides: + +1. **Hub descriptor** + - `hub_slug` (stable) + - `display_name` + - `domain` (primary market domain or aspect id) + - `hub_kind`: `domain` | `aspect` + - `status`: `draft` | `active` | `deprecated` | `retired` + - optional VSM annotations (`vsm_system`, `vsm_function`) for operator UX + +2. **Reuse-surface capability id** + - Form: `capability..` + - Authored in the hub’s (or owning) `registry/capabilities/` + - Referenced by catalog rows and manifests (capability bridge rules) + +3. **Capability manifest** (versioned body) + - `manifest_version` + - `reuse_surface_id` + - `provides`: list of capability ids / API groups + - `consumes`: hub-core ports and peer hubs/components + - `events_emitted` / `events_consumed` (cataloged types only) + - `widgets` or operator surfaces (optional) + - `endpoints` (base URLs or service discovery keys — no secrets) + - `policy_scopes` (names only; decisions via policy port) + - `schema_version` for body evolution + +4. **Health** + - liveness + readiness that composition probes can call + +5. **Auth consumer registration** + - API consumer metadata + key **hash/prefix only** + +### Ports (hub-core provided) + +Domain hubs and components integrate through named ports. Ports are **stable +interfaces**; implementations may move during consolidation. + +| Port | Direction | Purpose | +| --- | --- | --- | +| `port.registry` | in | Register/activate hubs and manifests | +| `port.addressing` | out | Resolve agents, hubs, domains | +| `port.messaging` | in/out | Send/receive messages; conversation ids | +| `port.events.progress` | in | Append progress events (coordination audit) | +| `port.events.interaction` | in | Append interaction events (ops/framework evidence) | +| `port.projection.query` | out | Read orientation summaries, registries | +| `port.repo` | out | Address repositories via repo-manager (not raw Git) | +| `port.work` | out | Query work-record index (file authority remains in repos) | +| `port.policy` | out | Evaluate/authorize actions (decision elsewhere) | +| `port.telemetry` | in | Submit cost/usage samples with subject refs | +| `port.schedule` | out | Request activity-core execution (not embed cron) | + +**Rule:** domain hubs MUST NOT open direct DB connections to repo-manager or +other hubs’ private schemas; only versioned ports/APIs. + +### Events + +- Event types are **cataloged** (name, schema version, sensitivity class). +- Progress vs interaction semantics follow IA model + existing event mapping. +- Correlation via `correlation_id` when an action spans kinds. +- Payloads MUST NOT contain secrets. + +### Projections + +| Projection | Built from | Served by | +| --- | --- | --- | +| Hub registry | descriptors + manifests | hub-core | +| Domain summary | work index + messages + progress | hub-core (replaces State Hub summary) | +| Repo health | repo-manager findings | repo-manager → hub-core facade optional | +| Capability matrix | registry + catalog + manifests | hub-core | +| Ops evidence | interaction events + widgets | hub-core | + +Projections declare `rebuild_from` authorities and a consistency check. + +### Adapters (migration and permanent) + +| Adapter | Role | Lifetime | +| --- | --- | --- | +| **State Hub compatibility** | Present familiar REST/MCP while owners cut over | Until retirement gates | +| **core-hub `/api/v2`** | Preserve ops-hub/activity-core consumers during consolidation into hub-core | Until single runtime serves v2 | +| **repo-manager port adapter** | Normalize repo/work facts to hub-core projections | Permanent | +| **activity-core sink** | Ingest interaction/progress for automation | Permanent | +| **Identity/auth ports** | Subject tokens, never raw passwords | Permanent | + +--- + +## Conformance requirements + +Conformance is **tiered**. Child workplans implement automated suites; this +section is the requirement set. + +### Tier 0 — Descriptive (now) + +- [x] Architecture docs (IA + this document) reviewable +- [x] Machine-readable contract outline YAML +- [x] Inventory capabilities mapped to owners/ports + +### Tier 1 — Contract artefacts (hub-core child WP) + +A release of `helixforge.hub-extension` MUST ship: + +1. JSON Schema (or equivalent) for hub descriptor + manifest body +2. Catalog schema for event types +3. OpenAPI fragments or protobuf for each port +4. Fixtures: at least one sample domain hub package (ops-hub shape) +5. Compatibility matrix vs prior contract version + +### Tier 2 — Runtime conformance (per hub) + +A domain hub is **conformant** when tests prove: + +| # | Requirement | +| --- | ---: | +| C1 | Descriptor + manifest validate against schema | +| C2 | `reuse_surface_id` resolves in registry | +| C3 | Health endpoints pass composition probe | +| C4 | Manifest activation is idempotent | +| C5 | Emitted events validate against cataloged schemas | +| C6 | No secret material in events/manifests (static + sample payload checks) | +| C7 | Consumed ports only (deny list of raw foreign DB URLs in config samples) | +| C8 | Correlation id accepted/propagated on multi-kind write paths | +| C9 | Readiness fails closed if required consumes are unavailable | +| C10 | Version negotiation: hub declares min/max contract version | + +### Tier 3 — Framework conformance (hub-core) + +| # | Requirement | +| --- | ---: | +| F1 | Registry CRUD + activate with audit trail | +| F2 | Progress and interaction families remain distinct | +| F3 | Projection rebuild from authority fixtures | +| F4 | `/api/v2` (or successor) consumer smokes for ops-hub + activity-core | +| F5 | MCP orientation tools bound to projections, not foreign private schemas | +| F6 | Policy port fail-closed on deny/unavailable | +| F7 | Telemetry rejects payloads with secret-like keys (heuristic denylist) | +| F8 | Metadata isolation: host SQLAlchemy `Base` not mixed across runtimes during migration (see hub-core docs) | + +### Tier 4 — Migration conformance (State Hub retirement) + +Aligned with inventory dispositions and T06 gates: + +| # | Requirement | +| --- | ---: | +| M1 | Every `move`/`replace` capability has a named port or owner API | +| M2 | Compatibility adapter feature flags per capability | +| M3 | Row-count / provenance checks on data handoff | +| M4 | Zero normal traffic to State Hub in stabilization window | +| M5 | Rollback path documented and exercised once | + +--- + +## Control-plane rules (OA P2 / Intelligence) + +1. All agent and automation **mutations** that affect shared state go through + hub-core ports or repo-manager governed commands — never silent direct SQL + from agents. +2. Agentic delegation (OA I5) requires policy port approval paths for + non-green autonomy lanes. +3. Management plane (CLI, MCP, console) is a client of the same ports as domain + hubs — no privileged side door without audit. + +--- + +## Mapping from today’s three-repo stack + +| Today | Target | +| --- | --- | +| `hub-core` library factories | Remain + grow into SDK of surviving runtime | +| `core-hub` `/api/v2` runtime | Absorbed into hub-core runtime; repo archived | +| `state-hub` work/file consistency | repo-manager | +| `state-hub` messages/progress/domains/catalogs | hub-core | +| `state-hub` dashboard | projection UI clients (hub-core / ops surfaces) | +| `state-hub` suggestions / workstream aliases | retire | +| `ops-hub` | domain/aspect hub via extension contract | +| `fin-hub` | domain hub; fabric authority stays specialized | +| `activity-core` | functional component on `port.schedule` + event sinks | + +--- + +## Implementation sequencing (for T05) + +Suggested child streams (ids to be created/linked in T05): + +1. **hub-core runtime consolidation** — absorb core-hub runtime, ship contract schemas +2. **repo-manager extraction** — registry, consistency, work index from State Hub +3. **extension conformance suite** — Tier 1–3 automation +4. **compatibility adapters** — State Hub strangler per inventory disposition +5. **domain hub upgrades** — ops-hub/fin-hub manifest alignment +6. **State Hub retirement gates** — T06 evidence + +Dependencies: (2) and (1) can parallelize behind the IA+extension freeze; (3) +depends on (1); (4) depends on (1)(2); (6) depends on (4)(5). + +--- + +## Anti-patterns + +1. Labeling every microservice a “hub.” +2. Domain hub importing another hub’s SQLAlchemy models. +3. Manifest bodies carrying API key material. +4. New features landing only in State Hub during migration. +5. Collapsing progress and interaction into one event type. +6. Repo Manager owning cross-domain inboxes. +7. hub-core owning Git write authority. +8. Conformance by documentation only after Tier 1 (must be tests). + +--- + +## Open questions + +1. **Single deployable vs package+host** — hub-core as one service image vs + library + thin host (target: one primary runtime image; library remains + importable for tests/embed). +2. **Widget model** — keep core-hub widgets as first-class or generalize to + “operator surface” descriptors. +3. **Multi-tenant hub isolation** — quality Q4 strategy per deployment. +4. **Contract storage** — manifests only in DB vs file-backed in hub repos + + index (prefer file-backed declaration + registry projection). +5. **MCP surface split** — one hub-core MCP vs per-component MCP with gateway. + +--- + +## Acceptance for T04 + +- [x] Domain hub vs functional component vs authoritative service defined +- [x] hub-core responsibilities and non-goals listed +- [x] Extension package (descriptor, manifest, ports, events, projections) specified +- [x] OA dimensions bound to implementable artefacts +- [x] Conformance tiers 0–4 defined +- [x] Machine-readable contract outline YAML +- [x] Migration mapping from current three-repo stack +- [ ] Automated conformance suite (child WP; not this task) +- [ ] Human review before treating contract as fleet-normative + +## Related + +- `architecture/information-model_v0.1.md` — kinds and authority +- `inventory/README.md` — capability dispositions +- `orthogonal-architecture_v1.0.md` — descriptive OA standard +- `hub-ecosystem-capability-bridge.md` — capability id bridging diff --git a/architecture/hub-extension-contract_v0.1.yaml b/architecture/hub-extension-contract_v0.1.yaml new file mode 100644 index 0000000..5439166 --- /dev/null +++ b/architecture/hub-extension-contract_v0.1.yaml @@ -0,0 +1,286 @@ +# helixforge.hub-extension contract outline v0.1 +# Descriptive machine-readable form for T04/T05. Runtime JSON Schemas ship in hub-core. + +contract_id: helixforge.hub-extension +contract_version: "0.1.0" +status: draft-reviewable +created: "2026-08-09" +updated: "2026-08-09" +workplan_task: SHR-WP-0001-T04 +document: architecture/hub-extension-architecture_v0.1.md +information_model_ref: SHR-ARCH-IA-0001 + +taxonomy: + hub_core: + role: framework_and_runtime + owns: + - identity_and_addressing + - messaging_and_conversations + - progress_and_interaction_events + - extension_registry + - policy_integration_ports + - telemetry_intake + - compatibility_surface + - sdk_and_contracts + does_not_own: + - git_file_authority + - domain_business_data + - secrets + - authorization_decisions + - schedule_execution + domain_hub: + hub_kind: [domain, aspect] + must: + - hub_descriptor + - reuse_surface_capability_id + - versioned_manifest + - health_endpoints + - own_domain_data + must_not: + - own_other_repos_file_authority + - bypass_policy_ports + - store_secrets_in_manifests_or_events + - dual_write_work_records + functional_component: + examples: [repo-manager, activity-core, issue-core, ops-bridge] + rule: not_a_hub_unless_domain_or_aspect + authoritative_service: + examples: [identity, flex-auth, openbao, forgejo, fabric-engine] + rule: retain_execution_and_data_authority + projection: + rule: rebuildable_from_authority + adapter: + rule: versioned_boundary_no_schema_leak + +oa_binding: + Stack: platform_substrate_not_hubs + Logic.L1: reuse_surface_capabilities + Logic.L2: deployed_services + Logic.L3: extension_registry_and_manifests + Logic.L4: solutions_and_operator_experiences + Plane.P1: workload_runtimes + Plane.P2: hub_core_registry_policy_repo_commands + Plane.P3: cli_mcp_console + Quality: ia_cross_cutting_rules + Capability.contract: this_contract + Intelligence: agents_via_control_plane + +hub_descriptor_fields: + required: + - hub_slug + - display_name + - domain + - hub_kind + - status + - reuse_surface_id + - contract_version_min + - contract_version_max + optional: + - vsm_system + - vsm_function + - description + hub_kind_enum: [domain, aspect] + status_enum: [draft, active, deprecated, retired] + +manifest_fields: + required: + - manifest_version + - reuse_surface_id + - provides + - consumes + - events_emitted + - events_consumed + - schema_version + optional: + - widgets + - endpoints + - policy_scopes + - operator_surfaces + rules: + - no_secrets_in_body + - endpoints_are_discovery_keys_or_non_secret_urls + - event_types_must_be_cataloged + +ports: + - id: port.registry + direction: in + purpose: register_and_activate_hubs_and_manifests + - id: port.addressing + direction: out + purpose: resolve_agents_hubs_domains + - id: port.messaging + direction: bidirectional + purpose: messages_and_conversations + - id: port.events.progress + direction: in + purpose: append_progress_events + - id: port.events.interaction + direction: in + purpose: append_interaction_events + - id: port.projection.query + direction: out + purpose: orientation_and_registry_reads + - id: port.repo + direction: out + purpose: repository_addressing_via_repo_manager + - id: port.work + direction: out + purpose: work_record_index_queries + - id: port.policy + direction: out + purpose: authorization_and_policy_evaluation + - id: port.telemetry + direction: in + purpose: cost_and_usage_samples + - id: port.schedule + direction: out + purpose: activity_core_execution_requests + +event_rules: + families: [progress, interaction, repository_change, domain] + cataloged_types: required + correlation_id: UUIDv7 + dual_write_same_fact: forbidden + secrets_in_payload: forbidden + +projections: + - id: hub_registry + served_by: hub-core + rebuild_from: [hub_descriptors, manifests] + - id: domain_summary + served_by: hub-core + rebuild_from: [work_index, messages, progress_events] + - id: repo_health + served_by: repo-manager + rebuild_from: [repository_files, consistency_findings] + - id: capability_matrix + served_by: hub-core + rebuild_from: [reuse_surface_registry, catalog, manifests] + - id: ops_evidence + served_by: hub-core + rebuild_from: [interaction_events, widgets] + +adapters: + - id: state_hub_compatibility + lifetime: until_retirement_gates + - id: core_hub_api_v2 + lifetime: until_single_runtime + - id: repo_manager_port + lifetime: permanent + - id: activity_core_sink + lifetime: permanent + - id: identity_auth_ports + lifetime: permanent + +conformance: + tier_0_descriptive: + - architecture_docs + - contract_yaml + - inventory_port_map + tier_1_contract_artefacts: + - hub_descriptor_schema + - manifest_schema + - event_type_catalog_schema + - port_openapi_fragments + - sample_hub_fixture + - compatibility_matrix + tier_2_domain_hub: + - C1_schema_validate + - C2_reuse_surface_resolve + - C3_health_probe + - C4_activate_idempotent + - C5_events_validate + - C6_no_secrets + - C7_ports_only + - C8_correlation_propagation + - C9_fail_closed_readiness + - C10_version_negotiation + tier_3_framework: + - F1_registry_audit + - F2_event_family_separation + - F3_projection_rebuild + - F4_api_v2_consumer_smokes + - F5_mcp_bound_to_projections + - F6_policy_fail_closed + - F7_telemetry_secret_heuristic + - F8_metadata_isolation + tier_4_migration: + - M1_disposition_has_port + - M2_compat_feature_flags + - M3_rowcount_provenance + - M4_zero_state_hub_traffic_window + - M5_rollback_exercised + +inventory_port_map: + # capability id -> primary port or owner component + - capability: agent-messaging + port: port.messaging + owner: hub-core + - capability: progress-telemetry + port: port.events.progress + owner: hub-core + - capability: token-telemetry + port: port.telemetry + owner: hub-core + - capability: state-projections + port: port.projection.query + owner: hub-core + - capability: cross-domain-registry + port: port.addressing + owner: hub-core + - capability: capability-catalog + port: port.registry + owner: hub-core + - capability: policy-integration + port: port.policy + owner: hub-core + - capability: repository-registry + port: port.repo + owner: repo-manager + - capability: work-records-workplan + port: port.work + owner: repo-manager + - capability: work-records-task + port: port.work + owner: repo-manager + - capability: repo-consistency + port: port.repo + owner: repo-manager + - capability: workplan-execution-queue + port: port.schedule + owner: activity-core + - capability: task-flow-engine + port: port.schedule + owner: activity-core + - capability: service-catalog + owner: ops-hub + notes: domain_hub_data_plus_registry_manifest + - capability: fabric-graph + owner: fin-hub + notes: authoritative_specialized_with_hub_projection_optional + +migration_stack_map: + hub-core_library: grows_into_sdk_of_surviving_runtime + core-hub_runtime: absorbed_then_archived + state-hub_work_and_consistency: repo-manager + state-hub_messages_progress_domains_catalogs: hub-core + state-hub_dashboard: projection_ui_clients + state-hub_suggestions_and_workstream_aliases: retire + ops-hub: domain_or_aspect_hub + fin-hub: domain_hub + activity-core: functional_component + +child_streams_suggested: + - hub-core-runtime-consolidation + - repo-manager-extraction + - extension-conformance-suite + - compatibility-adapters + - domain-hub-manifest-alignment + - state-hub-retirement-gates + +open_questions: + - single_deployable_vs_library_plus_host + - widget_model_generalization + - multi_tenant_isolation + - file_backed_manifests_vs_db_only + - mcp_gateway_vs_per_component diff --git a/architecture/information-model_v0.1.md b/architecture/information-model_v0.1.md index 39f9e51..95c4087 100644 --- a/architecture/information-model_v0.1.md +++ b/architecture/information-model_v0.1.md @@ -476,7 +476,7 @@ vocabulary that contract must use. ## Related - `inventory/README.md` — disposition inventory -- `architecture/hub-extension-architecture_v0.1.md` — T04 (successor doc) +- `architecture/hub-extension-architecture_v0.1.md` — T04 hub/extension contract - `work-record-types_v0.1.md` — closed work-record kind registry - `project-repository-flavor_v0.1.md` — `prj-` / GOAL.md - ADR-001, ADR-005 — file authority and project repos diff --git a/workplans/SHR-WP-0001-foundation.md b/workplans/SHR-WP-0001-foundation.md index f7bc59b..a3669f9 100644 --- a/workplans/SHR-WP-0001-foundation.md +++ b/workplans/SHR-WP-0001-foundation.md @@ -88,7 +88,7 @@ canon/hub-core promotion; open questions listed for T04. ```task id: SHR-WP-0001-T04 -status: todo +status: done priority: high state_hub_task_id: "90e8350a-8a1c-4f46-a545-69c9cf00e6d1" ``` @@ -97,6 +97,13 @@ Revise the Orthogonal Architecture material into an implementable hub-core and domain-extension contract. Define domain hubs, functional components, authoritative services, projections, adapters, and conformance requirements. +**Result (2026-08-09):** Draft-reviewable `SHR-ARCH-HUB-0001` at +`architecture/hub-extension-architecture_v0.1.md` + contract outline +`hub-extension-contract_v0.1.yaml` (`helixforge.hub-extension` v0.1). Taxonomy, +ports, extension package, OA binding, conformance tiers 0–4, migration stack +map, suggested T05 child streams. Residual: automated suite + human review +before fleet-normative; Tier 1 artefacts in hub-core child WP. + ## Establish the child-workplan map ```task