chore: refresh registry metadata and docs

docs/registry.md

@@ -37,6 +37,10 @@ pnpm registry:check
 The pull request workflow now runs `pnpm registry:check`, and the release version PR
 workflow refreshes the registry automatically via `pnpm release:version`.
 
+The generated index includes transitive local helpers, not just component entrypoints. If a
+component starts importing a shared file such as `packages/ui/src/lib/icons.tsx`, rebuild the
+index before merge so source-copy consumers receive the full dependency graph.
+
 To validate the end-to-end consumer flow locally:
 
 ```bash

docs/rfcs/data-table.md

@@ -2,11 +2,16 @@
 
 ## Status
 
-Proposed
+Implemented
+
+The first `DataTable` slice now ships in `packages/ui` with stories, tests, and registry
+distribution support. This RFC remains as the design record for the shipped scope and the
+guardrails for future follow-up work.
 
 ## Summary
 
-`DataTable` is the next high-value advanced pattern for `@ai-ui/ui`, but it should not ship as a giant "kitchen sink" component.
+`DataTable` is now a shipped advanced pattern for `@ai-ui/ui`, and it should continue to avoid
+turning into a giant "kitchen sink" component.
 
 The recommended path is:
 
@@ -34,11 +39,13 @@ Relevant current building blocks already exist in `packages/ui`:
 - overflow and contextual actions: `DropdownMenu`, `Popover`, `Tooltip`, `Sheet`, `Dialog`, `Toast`
 - empty and first-run states: `EmptyState`
 
-That means the main missing piece for list-heavy product surfaces is not another primitive. It is a stable data presentation pattern.
+At RFC authoring time, the main missing piece for list-heavy product surfaces was not another primitive.
+It was a stable data presentation pattern.
 
 ## Problem statement
 
-Today the design system can express forms, overlays, command/search, and empty states, but it cannot yet express a reusable operational list surface such as:
+Before this work, the design system could express forms, overlays, command/search, and empty
+states, but it could not yet express a reusable operational list surface such as:
 
 - release queues
 - approval backlogs
@@ -94,14 +101,16 @@ This RFC is anchored in the current repo, not an idealized future state.
 
 ### Dependency constraints
 
-Current `packages/ui/package.json` has no table model dependency, no date library, and no grid engine.
+When this RFC was written, `packages/ui/package.json` had no table model dependency, no date
+library, and no grid engine.
 
-That means the first `DataTable` implementation must either:
+That meant the first `DataTable` implementation had to either:
 
 - hand-roll row modeling, sorting, selection, and visibility management, or
 - adopt a focused headless dependency
 
-Hand-rolling is not recommended for this repo stage.
+Hand-rolling was not recommended for this repo stage, and the shipped implementation now uses
+`@tanstack/react-table` internally.
 
 ## Recommendation
 
@@ -353,7 +362,7 @@ At least one smoke scenario should cover:
 - selecting rows reveals a bulk-action affordance
 - opening row detail in `Sheet` still works
 
-## Release plan
+## Original release plan
 
 ### Stage 0: RFC and composition rehearsal
 
@@ -392,9 +401,9 @@ Only if justified by real product usage:
 - virtualization
 - advanced filters
 
-## Likely file layout
+## Implemented file layout
 
-When implementation begins, the initial table slice should probably live in:
+The initial table slice now lives in:
 
 ```txt
 packages/ui/src/components/data-table.tsx
@@ -403,13 +412,14 @@ packages/ui/src/components/data-table.test.tsx
 apps/docs/src/components/data-table.stories.tsx
 ```
 
-If the implementation grows into a larger family, the repo may eventually want a dedicated component folder, but the first slice should stay consistent with the current flat component layout.
+If the implementation grows into a larger family, the repo may eventually want a dedicated
+component folder, but the current slice still follows the flat component layout.
 
 ## Dependency recommendation
 
-### Recommended
+### Current choice
 
-- add `@tanstack/react-table` to `packages/ui`
+- use `@tanstack/react-table` inside `packages/ui`
 
 ### Not recommended for the first slice
 
@@ -420,7 +430,7 @@ If the implementation grows into a larger family, the repo may eventually want a
 
 The first implementation should minimize dependency expansion and keep the complexity budget focused on a single new capability.
 
-## Open questions
+## Follow-up questions
 
 1. Should the public column type stay fully source-owned, or should the first release expose a thin alias around TanStack column defs?
 2. Should the first release include client-side search/filter state inside `DataTable`, or should filtering remain externally controlled?
@@ -428,12 +438,12 @@ The first implementation should minimize dependency expansion and keep the compl
 4. Should pagination UI be part of the root component family, or remain a separate companion component?
 5. Should row selection be opt-in only, or should the root always reserve structure for it?
 
-## Decision
+## Result
 
-The next `DataTable` implementation should:
+The shipped `DataTable` implementation:
 
-- be built as an advanced pattern, not a primitive
-- be source-owned at the public API layer
-- use TanStack Table internally from the first implementation
-- ship as a narrow, headless/core-first operational table
-- defer scale features until real usage proves they are necessary
+- is built as an advanced pattern, not a primitive
+- is source-owned at the public API layer
+- uses TanStack Table internally from the first implementation
+- ships as a narrow, headless/core-first operational table
+- defers scale features until real usage proves they are necessary