Seed State Hub retirement project

history/2026-08-09-genesis.md

@@ -0,0 +1,53 @@
+# 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.