@fabricorg/adoption-bindings
Validates a vertical's adoption binding against a capability's published usage contract.
A capability publishes what it needs filled — roles, extension slots, action intents, data shapes. A vertical adopts it by declaring a binding: which component fills each role, which fragment fills each slot, which actions it overrides, how it maps data. This package checks that the binding actually satisfies the contract, so adopting a capability is a reviewed pull request rather than a runtime surprise.
pnpm add -D @fabricorg/adoption-bindings
import { assertBindingValid } from "@fabricorg/adoption-bindings";
assertBindingValid({ contract, binding, packs, coreComponents });
validateBinding returns every finding rather than the first, so one CI run tells a vertical everything it has to change. assertBindingValid throws with each finding's path listed, for use as a build step.
What it checks
- Every role the capability declares is bound, and no binding invents a role it does not.
- A bound component resolves — in a registered pack, or in the core vocabulary — and a pack component declares
role:<name>for the role it fills. - A slot fill names a declared slot and resolves to a view some known capability publishes.
- An action override targets an intent the capability actually dispatches.
- A data map names a view the capability publishes, and maps fields that exist in its shape.
Where this sits
This is enterprise-layer tooling. It consumes Fabric contracts; it is not part of Fabric. Per ADR 0011 no Fabric package defines a binding schema, validates a binding, or knows that bindings exist — the usage contract is Fabric's, the binding is the vertical's, and this package is the seam between them.
It ships from this repository alongside the other separately-versioned build-time tools, in the same integration tier as @fabricorg/gen-sdui. What matters is that the governance core and its hosts never interpret a binding — which the Boundary Guard enforces per package, not per repository.