Documentation

Assemble and run the proxy role from an already validated BootEnv.

Resolve the memory, mirroring, credential, mount, and advisory-sync plans, refusing unsafe or incomplete wiring before opening the listener. On success, build the data-plane managers, mirror queue, metadata cache, and runtime Env, then run the HTTP server with the configured background services (runServer and runWorker).

Run the proxy's HTTP front door over the composition-root Env with the config-derived ServerConfig.

The mount wiring behind the served bindings comes from the ecosystem adapter registry: mountBindingFor resolves each configured ecosystem through adapterFor and projects the resolved adapter's serve surface into the otherwise ecosystem-neutral web layer (runServer), so the agnostic server stays closed over the shared Route set. Splitting the server into its own binary later reuses this same entry.

Run the supervised mirror worker over the composition-root Env and the per-ecosystem bundles: the consume → probe → re-evaluate → fetch → verify → publish → ack loop against the queue, in the worker monad (WorkerM) over the worker runtime (workerRuntimeOf). The bundles carry the same prepared rules, artifact request formation, and public origin the serve path gates with, plus each mount's married mirror-write capability, so the worker re-runs current policy against a job before mirroring it and publishes through the job ecosystem's own protocol and target.

This is the composition-root hoist point: it resolves the request-independent dd correlation object (the service identity; no span is active at the worker entry) and installs it as the worker's initial katip context, then discharges the loop to IO through runWorkerM, the worker analogue of the serve path's runHandler boundary. The loop logic lives in Ecluse.Core.Worker; the single-process program runs this alongside runServer.

Resolve an Ecosystem to its complete MountBinding, or Nothing when that ecosystem has no registered adapter. The adapter registry (adapterFor) answers which ecosystems this build supports; the resolved adapter's serve surface supplies the router (the MountRouter), and the path prefix is derived from the ecosystem (prefixFor) rather than configured, so the ecosystem is the single thing that drives the binding (see docs/architecture/web-layer.md → "Multi-ecosystem mounts"). The composition root supplies the packument-serve dependencies once the per-mount registry set is resolved.

An ecosystem with no registered adapter resolves to Nothing: a loud miss at the call site rather than a silently half-wired mount.