Schema: Composition/Compositions are exported but unwired (premature public surface)

[nathanacurtis]

Summary

Composition and Compositions (ADR-042/046) are exported from @directededges/specs-schema types/index.ts, but nothing uses them in the wired contract:

• 0 $refs to #/definitions/Composition in schema/component.schema.json (orphan definition).
• 0 type files import Composition.
• No top-level compositions: output key exists in root.schema.json (or anywhere) — the "system-scoped registry" the type's doc comment describes is not plumbed.
• It is only re-exported from index.ts.

So it is published public API surface that does nothing — counter to Constitution §III (minimal, intentional public API). The component-example features that do ship (slotContentExamples, instanceExamples) depend on SlotContent, SlotContentRef (a plain string pointer), and InstanceExample — not on Composition.

Why this matters

Composition is the latent page-composition primitive (a graph of composed content linked by SlotContentRef, where depth = composition references and width = sibling elements). Shipping its name/shape half-built risks ossifying the wrong model before the page-composition workload is designed. Dense, deep, wide page composition is an expected workload and is poorly served by the component-example lineage (see deferred ADR-052 and its Limitations section).

Resolution (to be decided by the page-composition design)

Either:

• Wire it — make compositions: a first-class output, define how a page references sub-compositions, and its relationship to slotContentExamples; or
• Pull it — remove the unused export until the page-composition model is designed, keeping the public API minimal.

Resolve as part of a dedicated page-composition design effort, not piecemeal.

Refs: deferred ADR-052 (path-addressed element overrides).