Capability contract vocabulary: the declared, machine-readable description of
what one MCP tool's commands are, what they accept, and how stable they are.

Contract: a manifest is DATA. It holds no handlers and never dereferences a
:schema — schema refs are registry keys, resolved by hive-spi.schema.capability.
Deps: hive-dsl + malli only.

Facade for the addon mounter — the public surface a host consumes.

Re-exports the pure solver (solve), the effectful boundary (mount!, dry-run,
teardown!, discover-specs, parse-spec), the DIP config resolver + host
constructor (resolve-config-default, atom-mount-host), and the schema
validators/keys. mount-classpath! is the one-call composition root:
discover-specs -> solve -> mount!. The IMountHost protocol is NOT re-exported
(a protocol cannot be plain-def aliased) — implement it from its canonical
home hive-addon.mount.port.

Rationale lives in hive memory (KG-linked), not here.

Effectful boundary of the addon mounter — all IO and var resolution, injected
through the IMountHost port and an optional config resolver.

Collect: discover-specs scans the classpath for META-INF/hive-addons/*.edn.
Promote: parse-spec turns an EDN string into a validated MountSpec Result.
Pipeline is hive-addon.mount.solve (pure, elsewhere).
Boundary: mount!/dry-run/teardown! resolve constructors, inject already-mounted
sibling instances into each dependent's config (DIP), and drive the host.

mount! GRACEFULLY DEGRADES: a spec that fails at any step is recorded in the
MountReport and the loop CONTINUES; already-mounted addons are NEVER torn down
on a mid-DAG failure. teardown! shuts down in reverse mount order and always
reports :teardown/data-preserved? true (shutdown! never deletes data).

Composition root: select discovered MountSpecs through declarative plug layers
(build.edn / iaddon.edn), then order + mount them.

Joins the two pure engines by :addon/id — hive-addon.plug (SELECT, keyed by
lib-sym) and hive-addon.mount (ORDER + EXECUTE, keyed by :addon/id). Per-addon
plug :config overrides merge on top of the injected base config resolver.
With no plug layers (or none carrying :iaddon/plugs) every discovered spec is
kept — behaviourally identical to mount/mount-classpath!.

DIP seam for the addon mounter — the host registry abstraction.

IMountHost is the port through which the effectful boundary registers,
initializes, shuts down, and looks up addon instances. hive-addon ships one
in-memory implementation (atom-mount-host) for tests, dry-run, and non-MCP
hosts; a real host (an MCP server) supplies its own. resolve-config-default
is the identity-ish config resolver — a host may inject a richer one (e.g.
hive-di-backed) at the boundary.

register!/shutdown! are no-nuke: a duplicate register! MUST NOT throw and
shutdown! MUST NOT delete data.

Malli value objects for the addon mounter.

Declarative mount manifests (MountSpec), the pure solver output (MountPlan),
and the effectful outcome reports (MountResult, MountReport, TeardownReport).
Shapes are uncompiled malli DATA (house idiom: PascalCase defs) seeded into a
LOCAL composite registry that COMPOSES hive-addon.schema's registry — the
AddonId/AddonType/CapabilitySet value objects are reused, never redefined.
The registry is NEVER installed as the malli global default; reach it via
`schema`/`validate`/`explain`/`validate*` or by passing {:registry registry}
yourself.

Mount shapes are registered under :mount/* keys (:mount/spec, :mount/plan,
:mount/result, :mount/report, :mount/teardown-report).

TeardownReport carries the no-nuke invariant as data: :teardown/data-preserved?
is [:= true], so a report can only validate when teardown preserved data.

Pure DAG solver for the addon mounter — spec set -> MountPlan. No IO, no var
resolution.

Ordering constraints are a rule-chain: IDependencyRule turns the spec set
into directed [from-id to-id] edges (from mounts before to); `edges` folds the
chain into one edge set. Two built-in rules cover hard id deps
(:addon/dependencies) and looser capability deps (:addon/requires-capabilities
satisfied by any peer whose :addon/capabilities contains the cap).

`solve` is a pure deterministic fn of the spec SET: it Kahn topo-sorts with a
lowest-:addon/id lexicographic tie-break, so shuffled input yields an
identical :ordered. Cycles/missing-deps/unmet-capabilities are diagnosed as
data. Graceful by default (acyclic subset ordered, cycles reported); opt-in
:fail-closed-cycles true returns (r/err :mount/unsolvable ...).

Resolve ordered iaddon.edn layers (lowest precedence first) into the selected
plug set: merge → validate → lint → profile → drop-disabled → capability-select.

Fail-closed lint of a merged iaddon config — an extensible registry of pure rules.

Fold iaddon config layers into one, with the trust security inversion applied to
:iaddon/trust so higher-precedence layers can only tighten, never loosen.

Malli schemas for iaddon.edn (:iaddon/* keys), in a local composite registry.
Credential values never appear here — only reference chains.

Plug sources as trust-aware value objects: a tools.deps coord classified into a
family with its mutability/locality, behind the ISource protocol.

IAddon protocol — THE single source of truth for addon contracts.

A host loads addons that implement this protocol to gain capabilities
(DIP): the host depends on this abstraction, never the concrete addons,
and no addon compile-depends on the host. Any project — an MCP server or
something unrelated — can host addons by consuming this leaf lib.

All addons implement this protocol. A host's registry operates on
instances via this abstraction barrier.

Addon types:
- :native      — Built-in Clojure addons (same JVM)
- :mcp-bridge  — External MCP servers proxied via stdio/sse/http
- :external    — Non-MCP integrations (REST APIs, CLIs, etc.)

Lifecycle:
  (initialize! addon config) → Start services, open connections
  (shutdown! addon)          → Release resources, close connections
  (health addon)             → Query current health status

Malli schema layer for the IAddon contract.

Every data shape that crosses the IAddon protocol boundary has a schema
here, so a host can validate an addon's contract outputs and an addon can
validate the config it receives. Stratified: the schemas sit as pure data
BELOW the protocol — they read the protocol's own constants (single source,
no drift) and the protocol never depends on the schemas.

Self-contained by design (DDD): the addon bounded context owns its schemas.
Deps are malli + hive-dsl only — NO hive-spi. Schemas are registered in a
LOCAL composite registry under :addon/* keys; reach them via `schema`,
`validate`, `explain` (which thread {:registry registry}) or by passing
{:registry registry} yourself. The registry is NEVER installed as the malli
global default (shared-JVM safety).

Errors bridge to hive-dsl Result: the `validate*`/`validate-addon` helpers
return (r/ok x) on success and (r/err :addon/... {:explanation ...}) on
failure, with a qualified-keyword error category.