feat: add package-first release flow

docs/registry.md

@@ -1,8 +1,10 @@
 # Registry Install and Upgrade
 
-Cadence UI now supports a minimal internal registry flow for source-owned consumers.
-The goal is not package publishing yet. The goal is to make one reviewed repo state
-directly consumable by another app.
+Cadence UI supports a source-copy registry flow for teams that want local ownership of
+component source inside their own application.
+
+This is the optional customization path. The default downstream consumption model is now
+package install via `@ai-ui/ui`, with `@ai-ui/tokens` available for lower-level token imports.
 
 ## What the registry contains
 
@@ -52,12 +54,22 @@ required dependencies, and verifies that the copied source both typechecks and b
 
 ## Consumer install flow
 
+Choose this flow when:
+
+- your team wants to edit copied component code locally
+- you expect app-specific divergence that would be awkward to upstream immediately
+- you prefer source ownership over centralized package upgrades
+
+If you just want to use Cadence UI in another app with the lowest maintenance overhead,
+use the package flow in [docs/releasing.md](/Users/xd/project/cadence-ui/docs/releasing.md)
+instead.
+
 ### 1. Pin the Cadence UI source
 
 Consumers should install from a reviewed Cadence UI repo state, usually:
 
-- the merge commit of a version PR, or
-- a maintainer-created tag that points at that versioned commit
+- the `cadence-ui-vX.Y.Z` tag created for the release, or
+- the matching merge commit if the source-copy install must be tested before the tag is created
 
 The consumer does not need this repo as a runtime dependency. It only needs access to
 the checked-out source when running the installer.
@@ -130,7 +142,5 @@ This registry flow is intentionally minimal:
 
 It does not yet:
 
-- publish to npm
 - host a remote registry API
-- auto-tag or auto-publish releases
 - resolve consumer-specific codemods during upgrade