Compify emits shadcn-consumable registry items

Compify exports the open shadcn registry-item format rather than a proprietary installation protocol. A pinned shadcn 4.16.2 client accepts the repository's golden item, writes both source files, and the clean Next.js fixture builds.

bunx shadcn@4.16.2 add ./button.registry.json

Compatibility is scoped evidence

One passing fixture does not mean every component installs everywhere. Consumer aliases, file targets, monorepos, styles, assets, runtime providers and dependency ranges can change the result. Pin the client, use view/add --dry-run, inspect the diff and build the target application.

Public and private namespaces

{
  "registries": {
    "@compify": {
      "url": "https://registry.example/r/{name}.json",
      "headers": { "Authorization": "Bearer ${COMPIFY_TOKEN}" }
    }
  }
}

Public and unlisted items can be fetched anonymously. Private items are absent from the public index and require the owner's CLI token through the standard Bearer header. The current token is account-wide, not a scoped enterprise credential.

Why native tooling stays downstream

The official shadcn CLI/MCP owns registry dependencies, targets, aliases and installation. Compify's differentiated job is the preceding source selection, static graph explanation, safety checks and provenance.