# Implementations


Two complementary surfaces live on this ornament: a **typed-spec**
layer and a **consumer-coordination** layer.

## Typed-spec layer

A `define` call describes a project that supports multiple
interchangeable implementations under a single `langName`. Each
`ImplementationDescriptor` carries a `name` and an open
`capabilities` attrset for impl-specific metadata (e.g. invocation
flags, version range, supported targets).

`select spec implName` returns the descriptor or throws if absent.
`available spec excluded` filters out broken/excluded impls.
`perImpl spec f` evaluates `f` against each impl and returns the
results keyed by impl name — the typed analog of dynamic
`.${implName}` projections.

## Consumer-coordination layer

`defineSystem { langName; implementations; defaultImpl;
makeOverridable; allowUserExtensions ? false }` returns
`{ impls; withExtras; filterByName }` (plus `extend` when
extensions are allowed). The `implementations` argument is an
attrset (`{ impl-a = {...}; impl-b = {...}; ... }`) so consumers
can produce the coordination record without re-shaping input.

`withExtras builderFunction args` projects per-impl variants under
`result.${implName}` attributes, injects `passthru.repl` when an
impl exposes `replWith`, and populates `passthru.meta.ci.targets`
with the implementations minus the current one and `brokenOn`.

`filterByName impl xs` resolves implementation-specific
sources/dependencies — plain values pass through; non-derivation
attrsets are treated as per-impl selectors with optional `default`.

`makeBuilder { implsSystem; createPublicAPI; baseToolEnv }`
recursively wraps a `createPublicAPI` projection with `extend`
and `withTools` so downstream consumers receive the full builder
surface (not just an impls-system) after extension or tool
augmentation. Cross-ornament dependency on `mb.ornaments.toolEnv`.