Compose the table system

Treat the table as four cooperating layers: one schema, one state adapter, visible UI, and an optional data source. Do not create a second column definition for the API or detail sheet.

1. Install data-table and data-table-schema. Define one createTableSchema value with stable keys, labels, data types, filter behavior, sorting, sizing, and sheet visibility.
2. Generate columns, filter fields, and sheet fields from that definition. Keep secrets and unauthorized fields out of the schema instead of relying on a hidden column.
3. Choose exactly one adapter. Use the included memory adapter for an embedded/local table, nuqs for shareable URL state and browser history, or Zustand for an existing client store.
4. Render the provider and table inside the application's existing React and Tailwind setup. The registry item carries its shadcn primitives, CSS variables, and animation keyframes. Merge those additions through the shadcn CLI; do not copy the upstream site's global CSS.
5. Add cells, the command palette, detail sheet, and chart only after the base table works. They must consume the same provider and schema so a filter applied in one surface appears in every other surface.

For server data, serialize filters once and use that same shape in the query key and route. Timestamp, array, and record values need the source parser/serializer, not an ad hoc JSON conversion. Give every row a stable id. Test empty data, one page, multiple pages, filter changes during loading, and back/forward navigation if state lives in the URL.

Secure the server-backed integrations

The generated schema describes data and filter inputs. It is not authentication or authorization. Authenticate each route, derive the tenant and actor from the session, and apply that scope before a query, action, AI request, remote manifest, or MCP tool reaches application data.

For Drizzle, keep DATABASE_URL on the server. Map every filterable schema key to an actual column, preserve the handler's validation, and cap page sizes. Keep user-provided sorting and filters inside the supplied query builder rather than interpolating SQL.

For row actions, the _actions values returned with a row only control presentation. The write route must authorize again and intersect requested ids or filters with the action's server-side guard. Supply the authenticated actor separately; never trust an actor field from the request body. Prefer idempotent handlers and use the command id for deduplication or auditing when a retry could be harmful.

For AI filters, select a Vercel AI SDK provider in server code, keep its key out of the browser, rate-limit the route, and validate streamed output with the generated Zod schema. Field descriptions, allowed values, and numeric bounds become model context, so author them as carefully as UI labels.

For remote tables, validate the manifest, declare only capabilities the endpoint actually supports, and allow-list cross-origin action URLs. Resolve transport headers at request time so refreshed credentials are not captured at mount.

For MCP, wrap createTableMCPHandler in the application's route authentication and scope getData to the caller. An MCP client can request broad filters and repeated pages; enforce the same row visibility, rate limits, and audit policy used by the web route. Expose only the tools and fields intended for agents.