@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.