# Architecture

OMDSH Hub has four layers:

1. The prebuilt Client contributes the Extensions settings UI.
2. The loopback management API turns UI actions into typed manager operations.
3. The manager stages changes into physical Profile generations and delegates package work to the official `dsh` command.
4. Registry, recipe, and ecosystem clients provide strictly parsed discovery metadata.

The selected generation is changed atomically. A launcher boot token ties readiness confirmation to one candidate, and only the token digest is stored. The `official-v2` adapter waits for the official Loader and checks that all enabled Cordis fibers are active before confirming the candidate.

Registry data is cached atomically with a last-good copy. Offline bundled data is always available; remote data is accepted only from configured origins and only after signature verification with a configured Ed25519 key.

OMDSH Hub does not implement another Loader, import host internals, or execute catalog-provided commands. Package intent is resolved from the typed Registry at execution time.