54 lines
2.4 KiB
Markdown
54 lines
2.4 KiB
Markdown
|
# Project genesis
|
||
|
|
|
||
|
|
**Recorded:** 2026-08-09
|
||
|
|
|
||
|
|
## Starting condition
|
||
|
|
|
||
|
|
State Hub had grown from a useful repository-backed work coordination service
|
||
|
|
into a broad system containing development records, messages, progress,
|
||
|
|
capability workflows, service and third-party catalogs, telemetry, execution
|
||
|
|
controls, and cross-domain projections. The breadth made orientation and
|
||
|
|
authority boundaries increasingly difficult.
|
||
|
|
|
||
|
|
An earlier architecture proposed domain hubs around a shared framework and an
|
||
|
|
Orthogonal Architecture Standard. The second-generation Inter-Hub runtime was
|
||
|
|
implemented in Haskell/IHP but proved operationally too specialized. A
|
||
|
|
third-generation Python/FastAPI `core-hub` replacement was deployed, while
|
||
|
|
generic primitives were extracted into a separate `hub-core` library.
|
||
|
|
|
||
|
|
This successfully retired the Haskell production path, but left three problems:
|
||
|
|
|
||
|
|
- `core-hub` and `hub-core` split one conceptual framework across confusingly
|
||
|
|
named repositories;
|
||
|
|
- the Orthogonal Architecture Standard remained mostly documentary rather than
|
||
|
|
an executable extension and information model; and
|
||
|
|
- State Hub retained a large mixture of repository, cross-domain, and
|
||
|
|
domain-specific responsibilities.
|
||
|
|
|
||
|
|
## Direction established
|
||
|
|
|
||
|
|
The project begins from the following direction:
|
||
|
|
|
||
|
|
- consolidate `core-hub` into `hub-core` and make hub-core the surviving
|
||
|
|
cross-domain framework and runtime;
|
||
|
|
- build domain hubs through explicit extension contracts rather than a mesh of
|
||
|
|
direct service dependencies;
|
||
|
|
- keep specialized authorities such as identity, authorization, scheduling,
|
||
|
|
issues, audit, and finance behind delegated ports;
|
||
|
|
- create Repo Manager as the complete repository integration boundary;
|
||
|
|
- move cross-entity communication and information flow into hub-core and its
|
||
|
|
supporting components; and
|
||
|
|
- retire State Hub completely once every capability and consumer has an
|
||
|
|
evidence-backed disposition.
|
||
|
|
|
||
|
|
## Why a project repository
|
||
|
|
|
||
|
|
The work spans many repositories and changes their relationships. No single
|
||
|
|
functional repository should own the transformation plan. This repository is
|
||
|
|
therefore the first proposed `prj-` repository flavor: a temporary,
|
||
|
|
outcome-oriented coordination and provenance surface.
|
||
|
|
|
||
|
|
It owns the project goal and gates while implementation remains local to the
|
||
|
|
affected repositories. When the outcome is achieved and durable decisions have
|
||
|
|
moved to their permanent homes, this repository is archived.
|