Skip to Content
Design DecisionsRepo Consolidation

Consolidate the aurora repo into the orbit platform repo

Status: Accepted · Date: 2026-07-02 · Area: Repositories

Context

Until July 2026 the platform was split across two repos: orbit (the per-solution apps — reader, agent, Mission Control, shared loader) and aurora (the portfolio control plane plus, in practice, the platform’s infrastructure and release registry). The split had become fiction the tooling papered over: aurora’s releases/ already tracked release records for all four components, its build-images.sh already reached into ../orbit to build the orbit apps, component git tags for the three orbit apps lived in the orbit repo, and orbit had no Azure infrastructure of its own — its designs pointed at aurora’s as the source of truth. Both repos used the same main/develop/feature/* discipline. The tenant-model v3 design also made the registry services first-class platform components, sharpening the question of where “the platform” lives.

Decision

  • One repo: orbit. Aurora’s application (implementation/aurora-webapp), the registry services, the infrastructure scenarios, designs, memory records, and the release registry moved into the orbit repo. The aurora repo was archived and then deleted, with history preserved through the merge (the full merge design is §9 of designs/tenant-model.md).
  • The merge was a clean cut: verified beforehand that the live secrets file (infrastructure/azure/config.local.yaml) was git-ignored and absent from history, so no history purge was needed — only untracked working files were hand-carried.
  • The consolidated repo also keeps dogfooding Trajectory on itself: its own solution-definition/ carries the solution id orbit (renamed with the merge).

Consequences

  • One platform, one repo, one release registry, one local docker-compose stack: infrastructure/local/ runs all apps (orbit apps, aurora-webapp, registry services, Postgres) together, and releases/ is the single per-component registry.
  • Cross-component changes (e.g. the agent-served-solution-data refactor, which touched the agent, the reader, and the shared loader on the same day as the merge) land as one change in one place.
  • The retired Vercel path went with it — the Vercel project had been git-connected to the old aurora repo (ADR-001).
  • Historical release records keep their original coordinates: source.repo says aurora on pre-merge aurora-webapp records and orbit on everything written since — left as written, deliberately.

Evidence

  • designs/tenant-model.md §1 (the v2 → v3 table row deciding the merge) and §9 (the merge design)
  • implementation/ — aurora-webapp and the registry services beside the orbit apps
  • releases/ — one registry, mixed aurora/orbit source.repo history
  • memory/orbit-platform-landscape.md (verified post-merge layout), memory/release-registry.md (the source.repo note)