Repository Boundaries

2026-03-04

This document defines the intended repository boundaries for the UXI/app ecosystem.

Objective

• Separate application suites so each suite is independently buildable and deployable.
• Keep governance centralized in oves-sites.
• Reduce cross-suite coupling and migration risk.

Target Repositories

• dirac-uxi-isr
• ISR suite apps and ISR-specific support code.
• Style policy: TWP-only.
• dirac-uxi-crud
• CRUD suite apps and CRUD-specific support code.
• Style policy: Mosaic-based.
• dirac-uxi-metrics
• Metrics suite apps and metrics-specific support code.
• Style policy: Mosaic-based.
• oves-decks
• Deck applications; each deck behaves as an individual app.
• Must consume corporate standards from oves-sites.
• oves-sites
• Corporate governance and style SPOT.
• Canonical intents/specs and policy docs.

Boundary Rules

• No runtime dependency from one suite repo into another suite repo.
• App documentation is secondary and must not interfere with app build/deploy.
• MkDocs/docs toolchain must be isolated from runtime build pipelines.
• Governance standards are defined in oves-sites and consumed by other repos.

Docs Integration Rule

• App/suite docs belong with the app/suite repo.
• Docs CI and app CI should run as separate jobs.
• Docs build failures should not block app deploy unless explicitly configured.

Migration Constraints

• Preserve current behavior while splitting repos.
• Keep command ergonomics stable for developers (install, dev, build patterns).
• Migrate suite-by-suite with validation gates before cutover.

Initial Rollout Order

1. dirac-uxi-isr (pilot split)
2. dirac-uxi-crud
3. dirac-uxi-metrics
4. finalize consumer governance sync for oves-decks