Architecture
The one-way dependency layering and the invariants that hold it together
Architecture
Dependency direction is one-way and enforced by tests, not just convention. Both orchestration and the vendor adapters depend on the neutral core — never the reverse:
uze-corenever names a harness. No Claude, Codex, OpenCode, or Antigravity string in production code — enforced bycore_never_names_a_vendor_harness; the same neutrality holds foruze-applicationand the CLI/TUI.uze-integrationsis the only vendor-specific layer. One module per harness implementing the sharedIntegrationPort; itsregistryis the single composition root. A new harness should require no semantic change to Store, Engine, or Router — only a new integration vertical, one registry entry, conformance, and docs.- Antigravity is the Google-family v0 harness (ADR-027); the four supported harnesses are the current set. Planned: Cursor CLI, Muse, PI.
Repository layout
Invariants
docs/architecture/invariants.md is the canonical list of "do not break this" behaviors, each
tied to the test that proves it — receipts drive lifecycle safety, the Store is the single source
of truth, derived artifacts are rebuildable, the runtime shim never recurses into itself, every
CLI leaf command is performance-classified.
Design decisions with their rationale live in docs/adr/; recent ones cover generated
native-package projection, Skill invocation policy, and portable hooks.