Technical Documentation: Kiranism/next-shadcn-dashboard-starter

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (`README.md`) Copy Section

Admin Dashboard Template with Next.js & Shadcn UI

Overview Copy Chapter

A free, open source (MIT) admin dashboard starter built with Next.js 16, shadcn/ui on Base UI primitives, TypeScript, and Tailwind CSS v4.

Every feature is a working, production-ready implementation, not static demo UI. Tables search, filter, sort, and paginate for real. Forms validate and mutate with cache invalidation.
Auth, organizations, and billing function end-to-end.

Clone it, strip what you don't need with the built-in cleanup script, and start building on patterns you'd write yourself. It works well as a base for SaaS apps, internal tools, and admin panels.

Why This Template Copy Section

Most dashboard templates are static demo boilerplates: screens that look finished but need rebuilding the moment you wire in real data. This starter takes the opposite approach:

• Everything actually works. Data tables run end-to-end: server prefetch, client-side React Query cache, and URL-synced search, filtering, sorting, and pagination via nuqs. Forms are built from reusable, composable fields with Zod validation, including advanced patterns like multi-step and dialog/sheet forms, with real create/update mutations and cache invalidation on success.
• Industry-standard implementations. The data layer follows the official TanStack Query SSR pattern (server prefetch + HydrationBoundary + useSuspenseQuery), typed end to end, organized in a feature-based structure with a clean API layer per feature. These are patterns you copy into production code as-is, not mockups you rebuild from scratch.
• Minimal by design. Deliberately lean, with no bloated boilerplate, so you spend your time tweaking it to your use case, not deleting someone else's code. The built-in cleanup script strips any feature you don't need in under a minute.

Tech Stack Copy Section

• Framework - Next.js 16
• Language - TypeScript
• Auth - Clerk
• Error tracking - Sentry
• Styling - Tailwind CSS v4
• Components - shadcn/ui on Base UI primitives
• Charts - Recharts • Evil Charts
• Schema validation - Zod
• Data fetching - TanStack React Query
• State management - Zustand
• Search param state - Nuqs
• Tables - TanStack Data Tables • Dice Table
• Forms - TanStack Form + Zod
• Command+K interface - kbar
• Linter / Formatter - OxLint • Oxfmt
• Pre-commit hooks - Husky
• Themes - tweakcn

Looking for a TanStack Start version? Here's the repo.

Features Copy Chapter

• Pre-built dashboard layout with sidebar, header, and content area
• Analytics overview page with cards and charts
• Data tables with React Query prefetch, client-side cache, search, filter, and pagination
• Authentication and user management through Clerk
• Multi-tenant workspaces using Clerk Organizations (create, switch, manage teams)
• Billing and subscriptions via Clerk Billing for B2B, with plan management and feature gating
• Client-side RBAC navigation that filters menu items by organization, permissions, and roles
• Infobar component for tips, status messages, or contextual notes on any page
• shadcn/ui components on Base UI primitives, styled with Tailwind CSS
• Six-plus themes with a theme switcher
• Feature-based folder structure
• A starting point for SaaS dashboards, internal tools, and client admin panels

Use Cases Copy Chapter

A few things you can build with it:

• SaaS admin dashboards
• Internal tools and operations panels
• Analytics dashboards
• Client project admin panels
• A boilerplate for new Next.js shadcn projects

Pages Copy Chapter

Folder Structure Copy Chapter

/* Detailed source-code truncated for AI context efficiency. */

Getting Started Copy Chapter

[!NOTE]
This starter uses Next.js 16 (App Router) with React 19 and shadcn/ui. To run it locally:

Clone the repo:

git clone https://github.com/Kiranism/next-shadcn-dashboard-starter.git

• bun install
• Copy the example env file: cp env.example.txt .env.local
• Fill in the required variables in .env.local
• bun run dev

Environment variables

See env.example.txt for the variables you need. They cover authentication and error tracking.

Clerk setup

For setting up Clerk auth (including organizations, workspaces, and teams), see clerk_setup.md.

The app should now be running at http://localhost:3000.

[!WARNING]
After cloning or forking, be careful when pulling the latest changes. Updates can cause merge conflicts.

Cleanup Script: Start Minimal in 60 Seconds Copy Chapter

Most starters make you hand-delete demo pages and rip out dependencies. This one ships with a cleanup script that removes the optional features you don't need (folders, files, dependencies, docs, and env entries), leaving a minimal base to build on. Run --list to see what's removable:

bun run cleanup --interactive    # interactive mode
bun run cleanup --list           # see available features
bun run cleanup --dry-run chat   # preview before removing
bun run cleanup kanban chat      # remove specific features

Run bun run cleanup --help for all options (with npm, pass flags after --: npm run cleanup -- --list). The replacement files it writes live in scripts/cleanup-templates/ as real, typechecked code. When you're done, delete scripts/cleanup.js, scripts/cleanup-templates/, and the cleanup entry in package.json.

FAQ Copy Chapter

Is it production ready?
Yes. Every feature is a complete, working implementation: authentication, CRUD flows, table search/filter/sort/pagination, and form validation with mutations all function end-to-end. It's a starting point for real applications, not a visual mockup.

How is this different from other dashboard templates?
Most dashboard templates are static demo boilerplates: screens that look finished but need rebuilding once you wire in real data. Here the tables, forms, auth, organizations, and billing all work end-to-end, the implementations follow official TanStack and Next.js patterns, and a cleanup script keeps the base minimal so you tweak it to your use case instead of deleting code.

Is it free for commercial use?
Yes. MIT-licensed and free for both personal and commercial projects: no paid tier, no license keys.

Can I use it without Clerk?
Yes. Run bun run cleanup clerk to remove Clerk authentication (along with organizations and billing) and wire in your own auth solution.

How do I remove demo pages or features I don't need?
Run bun run cleanup --interactive and pick what to strip, or bun run cleanup --list to see what can be removed.

Does it support Next.js 16, React 19, and Tailwind CSS v4?
Yes. The template is built on Next.js 16 (App Router), React 19, and Tailwind CSS v4, with shadcn/ui on Base UI primitives, and is actively maintained to track new releases.

Can I use npm instead of Bun?
Yes. Bun is preferred, but npm works too, and the repo even ships both Node.js and Bun Dockerfiles for deployment.

Does it work with AI coding assistants?
Yes. The repo ships AGENTS.md and CLAUDE.md with the project's conventions, plus a bundled Claude Code skill (.claude/skills/kiranism-shadcn-dashboard) that teaches agents how to add pages, tables, forms, and navigation the template way. Works with Claude Code, Cursor, and any tool that reads AGENTS.md.

What data fetching pattern does it use?
TanStack React Query with the official SSR pattern: prefetchQuery on the server, HydrationBoundary with dehydrate for hydration, and useSuspenseQuery on the client, plus nuqs for URL-synced search-param state. Mutations invalidate the cache on success.

How do I deploy it?
Deploy to Vercel out of the box, or use the included Docker setups: a Node.js Dockerfile and a Bun Dockerfile, both using Next.js standalone output mode. See the deployment guide.

Deploy Copy Chapter

Deploy to Vercel out of the box, or use the included Docker setups: a Node.js Dockerfile and a Bun Dockerfile, both using Next.js standalone output mode. Full guide: docs/deployment.md.

Support Copy Section

If this template saved you some time, a star is appreciated. You can also buy me a coffee if you'd like.

Overview (`.agents/skills/vercel-composition-patterns/README.md`) Copy Section

React Composition Patterns

A structured repository for React composition patterns that scale. These
patterns help avoid boolean prop proliferation by using compound components,
lifting state, and composing internals.

Structure Copy Chapter

• rules/ - Individual rule files (one per rule)
  • _sections.md - Section metadata (titles, impacts, descriptions)
  • _template.md - Template for creating new rules
  • area-description.md - Individual rule files
• metadata.json - Document metadata (version, organization, abstract)
• AGENTS.md - Compiled output (generated)

Rules Copy Chapter

Component Architecture (CRITICAL) Copy Section

• architecture-avoid-boolean-props.md - Don't add boolean props to customize
  behavior
• architecture-compound-components.md - Structure as compound components with
  shared context

State Management (HIGH) Copy Section

• state-lift-state.md - Lift state into provider components
• state-context-interface.md - Define clear context interfaces
  (state/actions/meta)
• state-decouple-implementation.md - Decouple state management from UI

Implementation Patterns (MEDIUM) Copy Section

• patterns-children-over-render-props.md - Prefer children over renderX props
• patterns-explicit-variants.md - Create explicit component variants

Core Principles Copy Chapter

1. Composition over configuration — Instead of adding props, let consumers
   compose
2. Lift your state — State in providers, not trapped in components
3. Compose your internals — Subcomponents access context, not props
4. Explicit variants — Create ThreadComposer, EditComposer, not Composer
   with isThread

Creating a New Rule Copy Chapter

1. Copy rules/_template.md to rules/area-description.md
2. Choose the appropriate area prefix:
   • architecture- for Component Architecture
   • state- for State Management
   • patterns- for Implementation Patterns
3. Fill in the frontmatter and content
4. Ensure you have clear examples with explanations

Impact Levels Copy Chapter

• CRITICAL - Foundational patterns, prevents unmaintainable code
• HIGH - Significant maintainability improvements
• MEDIUM - Good practices for cleaner code

Overview (`.agents/skills/vercel-react-best-practices/README.md`) Copy Section

React Best Practices

A structured repository for creating and maintaining React Best Practices optimized for agents and LLMs.

Structure Copy Chapter

• rules/ - Individual rule files (one per rule)
  • _sections.md - Section metadata (titles, impacts, descriptions)
  • _template.md - Template for creating new rules
  • area-description.md - Individual rule files
• src/ - Build scripts and utilities
• metadata.json - Document metadata (version, organization, abstract)
• AGENTS.md - Compiled output (generated)
• test-cases.json - Test cases for LLM evaluation (generated)

Getting Started Copy Chapter

1. Install dependencies:

   bash Copy

   pnpm install

2. Build AGENTS.md from rules:

   bash Copy

   pnpm build

3. Validate rule files:

   bash Copy

   pnpm validate

4. Extract test cases:

   bash Copy

   pnpm extract-tests

Creating a New Rule Copy Chapter

1. Copy rules/_template.md to rules/area-description.md
2. Choose the appropriate area prefix:
   • async- for Eliminating Waterfalls (Section 1)
   • bundle- for Bundle Size Optimization (Section 2)
   • server- for Server-Side Performance (Section 3)
   • client- for Client-Side Data Fetching (Section 4)
   • rerender- for Re-render Optimization (Section 5)
   • rendering- for Rendering Performance (Section 6)
   • js- for JavaScript Performance (Section 7)
   • advanced- for Advanced Patterns (Section 8)
3. Fill in the frontmatter and content
4. Ensure you have clear examples with explanations
5. Run pnpm build to regenerate AGENTS.md and test-cases.json

Rule File Structure Copy Chapter

Each rule file should follow this structure:

---
title: Rule Title Here
impact: MEDIUM
impactDescription: Optional description
tags: tag1, tag2, tag3
---

## Rule Title Here

Brief explanation of the rule and why it matters.

**Incorrect (description of what's wrong):**

```typescript
// Bad code example
```

Correct (description of what's right):

// Good code example

Optional explanatory text after examples.

Reference: Link

File Naming Convention Copy Chapter

• Files starting with _ are special (excluded from build)
• Rule files: area-description.md (e.g., async-parallel.md)
• Section is automatically inferred from filename prefix
• Rules are sorted alphabetically by title within each section
• IDs (e.g., 1.1, 1.2) are auto-generated during build

Impact Levels Copy Chapter

• CRITICAL - Highest priority, major performance gains
• HIGH - Significant performance improvements
• MEDIUM-HIGH - Moderate-high gains
• MEDIUM - Moderate performance improvements
• LOW-MEDIUM - Low-medium gains
• LOW - Incremental improvements

Scripts Copy Chapter

• pnpm build - Compile rules into AGENTS.md
• pnpm validate - Validate all rule files
• pnpm extract-tests - Extract test cases for LLM evaluation
• pnpm dev - Build and validate

Contributing Copy Chapter

When adding or modifying rules:

1. Use the correct filename prefix for your section
2. Follow the _template.md structure
3. Include clear bad/good examples with explanations
4. Add appropriate tags
5. Run pnpm build to regenerate AGENTS.md and test-cases.json
6. Rules are automatically sorted by title - no need to manage numbers!

Acknowledgments Copy Chapter

Originally created by @shuding at Vercel.

Overview (`.claude/skills/vercel-composition-patterns/README.md`) Copy Section

React Composition Patterns

A structured repository for React composition patterns that scale. These
patterns help avoid boolean prop proliferation by using compound components,
lifting state, and composing internals.

Structure Copy Chapter

• rules/ - Individual rule files (one per rule)
  • _sections.md - Section metadata (titles, impacts, descriptions)
  • _template.md - Template for creating new rules
  • area-description.md - Individual rule files
• metadata.json - Document metadata (version, organization, abstract)
• AGENTS.md - Compiled output (generated)

Rules Copy Chapter

Component Architecture (CRITICAL) Copy Section

• architecture-avoid-boolean-props.md - Don't add boolean props to customize
  behavior
• architecture-compound-components.md - Structure as compound components with
  shared context

State Management (HIGH) Copy Section

• state-lift-state.md - Lift state into provider components
• state-context-interface.md - Define clear context interfaces
  (state/actions/meta)
• state-decouple-implementation.md - Decouple state management from UI

Implementation Patterns (MEDIUM) Copy Section

• patterns-children-over-render-props.md - Prefer children over renderX props
• patterns-explicit-variants.md - Create explicit component variants

Core Principles Copy Chapter

1. Composition over configuration — Instead of adding props, let consumers
   compose
2. Lift your state — State in providers, not trapped in components
3. Compose your internals — Subcomponents access context, not props
4. Explicit variants — Create ThreadComposer, EditComposer, not Composer
   with isThread

Creating a New Rule Copy Chapter

1. Copy rules/_template.md to rules/area-description.md
2. Choose the appropriate area prefix:
   • architecture- for Component Architecture
   • state- for State Management
   • patterns- for Implementation Patterns
3. Fill in the frontmatter and content
4. Ensure you have clear examples with explanations

Impact Levels Copy Chapter

• CRITICAL - Foundational patterns, prevents unmaintainable code
• HIGH - Significant maintainability improvements
• MEDIUM - Good practices for cleaner code

Overview (`.claude/skills/vercel-react-best-practices/README.md`) Copy Section

React Best Practices

A structured repository for creating and maintaining React Best Practices optimized for agents and LLMs.

Structure Copy Chapter

• rules/ - Individual rule files (one per rule)
  • _sections.md - Section metadata (titles, impacts, descriptions)
  • _template.md - Template for creating new rules
  • area-description.md - Individual rule files
• src/ - Build scripts and utilities
• metadata.json - Document metadata (version, organization, abstract)
• AGENTS.md - Compiled output (generated)
• test-cases.json - Test cases for LLM evaluation (generated)

Getting Started Copy Chapter

1. Install dependencies:

   bash Copy

   pnpm install

2. Build AGENTS.md from rules:

   bash Copy

   pnpm build

3. Validate rule files:

   bash Copy

   pnpm validate

4. Extract test cases:

   bash Copy

   pnpm extract-tests

Creating a New Rule Copy Chapter

1. Copy rules/_template.md to rules/area-description.md
2. Choose the appropriate area prefix:
   • async- for Eliminating Waterfalls (Section 1)
   • bundle- for Bundle Size Optimization (Section 2)
   • server- for Server-Side Performance (Section 3)
   • client- for Client-Side Data Fetching (Section 4)
   • rerender- for Re-render Optimization (Section 5)
   • rendering- for Rendering Performance (Section 6)
   • js- for JavaScript Performance (Section 7)
   • advanced- for Advanced Patterns (Section 8)
3. Fill in the frontmatter and content
4. Ensure you have clear examples with explanations
5. Run pnpm build to regenerate AGENTS.md and test-cases.json

Rule File Structure Copy Chapter

Each rule file should follow this structure:

---
title: Rule Title Here
impact: MEDIUM
impactDescription: Optional description
tags: tag1, tag2, tag3
---

## Rule Title Here

Brief explanation of the rule and why it matters.

**Incorrect (description of what's wrong):**

```typescript
// Bad code example
```

Correct (description of what's right):

// Good code example

Optional explanatory text after examples.

Reference: Link

File Naming Convention Copy Chapter

• Files starting with _ are special (excluded from build)
• Rule files: area-description.md (e.g., async-parallel.md)
• Section is automatically inferred from filename prefix
• Rules are sorted alphabetically by title within each section
• IDs (e.g., 1.1, 1.2) are auto-generated during build

Impact Levels Copy Chapter

• CRITICAL - Highest priority, major performance gains
• HIGH - Significant performance improvements
• MEDIUM-HIGH - Moderate-high gains
• MEDIUM - Moderate performance improvements
• LOW-MEDIUM - Low-medium gains
• LOW - Incremental improvements

Scripts Copy Chapter

• pnpm build - Compile rules into AGENTS.md
• pnpm validate - Validate all rule files
• pnpm extract-tests - Extract test cases for LLM evaluation
• pnpm dev - Build and validate

Contributing Copy Chapter

When adding or modifying rules:

1. Use the correct filename prefix for your section
2. Follow the _template.md structure
3. Include clear bad/good examples with explanations
4. Add appropriate tags
5. Run pnpm build to regenerate AGENTS.md and test-cases.json
6. Rules are automatically sorted by title - no need to manage numbers!

Acknowledgments Copy Chapter

Originally created by @shuding at Vercel.

Clerk Setup (`docs/clerk_setup.md`) Copy Section

Clerk Setup Guide

This guide covers the setup and configuration of Clerk features used in this starter template.

Clerk Scopes Required Copy Chapter

• Authentication - User sign-in/sign-up and session management
• Organizations - Multi-tenant workspace management (see setup below)
• Billing - Organization-level subscription management (see setup below)

Clerk Organizations Setup (Workspaces & Teams) Copy Chapter

This starter kit includes multi-tenant workspace management powered by Clerk Organizations. To enable this feature:

Enable Organizations in Clerk Dashboard: Copy Section

1. Go to Clerk Dashboard
2. Navigate to configure
3. Click Organizations settings
4. Configure default roles if needed in the roles and permissions.

Server-Side Permission Checks: Copy Section

• This starter follows Clerk's recommended patterns

Navigation RBAC System: Copy Section

• Fully client-side navigation filtering using useNav hook
• Supports requireOrg, permission, and role checks (all client-side, instant)
• Configured in src/config/nav-config.ts with access properties
• See docs/nav-rbac.md for detailed documentation

For more information, see: Copy Section

• Clerk Organizations documentation
• Multi-tenant authentication guide

Clerk Billing Setup (Organization Subscriptions) Copy Chapter

This starter kit includes Clerk Billing for B2B to manage organization-level subscriptions. Plans and features are managed through the Clerk Dashboard, and the application checks access using Clerk's has() function.

[!WARNING]
Billing is currently in Beta and its APIs are experimental and may undergo breaking changes. To mitigate potential disruptions, we recommend pinning your SDK and clerk-js package versions.

Key Features: Copy Section

• Organization-level subscription management
• Plan-based access control using the <Show> component
• Feature-based authorization
• Integrated Stripe payment processing
• Server-side plan/feature checks using has() function

Billing Cost Structure: Copy Section

Clerk Billing costs 0.7% per transaction, plus transaction fees which are paid directly to Stripe. Clerk Billing is not the same as Stripe Billing. Plans and pricing are managed directly through the Clerk Dashboard and won't sync with your existing Stripe products or plans. Clerk uses Stripe only for payment processing, so you don't need to set up Stripe Billing.

Setup Instructions: Copy Section

1. Enable Billing:

• Navigate to Billing Settings in the Clerk Dashboard
• Enable billing for your application
• Choose payment gateway:
  • Clerk development gateway: A shared test Stripe account for development instances. This allows developers to test and build Billing flows in development without needing to create and configure a Stripe account.
  • Stripe account: Use your own Stripe account for production. A Stripe account created for a development instance cannot be used for production. You will need to create a separate Stripe account for your production environment.

2. Create Plans:

• Navigate to Plans page in the Clerk Dashboard
• Select Plans for Organizations tab
• Click Add Plan and create plans (e.g., free, pro, team)
• Set pricing and billing intervals
• Toggle Publicly available to show in `` and <OrganizationProfile /> components

3. Add Features to Plans:

• You can add Features when creating a Plan, or add them later:
  1. Navigate to the Plans page
  2. Select the Plan you'd like to add a Feature to
  3. In the Features section, select Add Feature
• Feature names in Clerk Dashboard should match what you check in code

4. Usage in Code:

Server-side checks using has():

// Check if organization has a Plan
const hasPremiumAccess = has({ plan: 'gold' });

// Check if organization has a Feature
const hasPremiumAccess = has({ feature: 'widgets' });

The has() method is available on the auth object and checks if the Organization has been granted a specific type of access control (Role, Permission, Feature, or Plan) and returns a boolean value.

Client-side protection using <Show>:

<Show
  when={{ plan: 'bronze' }}
  fallback={<p>Only subscribers to the Bronze plan can access this content.</p>}
>
  <h1>Exclusive Bronze Content</h1>
</Show>

Or protect by Feature:

<Show
  when={{ feature: 'premium_access' }}
  fallback={<p>Only subscribers with the Premium Access feature can access this content.</p>}
>
  <h1>Exclusive Premium Content</h1>
</Show>

Deployment (`docs/deployment.md`) Copy Section

Deployment

The starter deploys to Vercel out of the box, or anywhere Docker runs. next.config.ts sets output: 'standalone', so production builds are optimized for self-hosting.

Vercel (Recommended) Copy Chapter

1. Connect the repository to Vercel
2. Add environment variables in the dashboard
3. Deploy

For other platforms, see the Next.js deployment docs.

Environment Variables for Production Copy Chapter

Ensure these are set in your deployment platform:

• NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY
• CLERK_SECRET_KEY
• All NEXT_PUBLIC_* variables for client-side access
• SENTRY_* variables if using error tracking

Sentry source maps are uploaded automatically in CI.

Docker Copy Chapter

Two production-ready Dockerfiles are included: Dockerfile (Node.js) and Dockerfile.bun (Bun). Pass NEXT_PUBLIC_* variables as --build-arg at build time and runtime secrets via -e at run time.

Build the image:

# Node.js
docker build \
  --build-arg NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_live_xxxxx \
  -t shadcn-dashboard .

# OR Bun
docker build -f Dockerfile.bun \
  --build-arg NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_live_xxxxx \
  -t shadcn-dashboard .

Run the container:

docker run -d -p 3000:3000 \
  -e NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_live_xxxxx \
  -e CLERK_SECRET_KEY=sk_live_xxxxx \
  --restart unless-stopped \
  --name shadcn-dashboard \
  shadcn-dashboard

Forms (`docs/forms.md`) Copy Section

Forms

Forms follow the official shadcn TanStack Form conventions, scaled with
TanStack's own createFormHook
pattern: the doc's Field anatomy is written once per widget as a reusable
field component, and pages use them as one-liners inside form.AppField.

• shadcn: TanStack Form — the
  anatomy inside every field component
• TanStack Form docs — validators,
  listeners, arrays, async validation

Architecture Copy Chapter

The pattern Copy Chapter

One useAppForm per form, a Zod schema validated on submit, and one
form.AppField per field rendering the matching component:

'use client';

import { useAppForm } from '@/lib/form';
import { FieldGroup } from '@/components/ui/field';
import * as z from 'zod';

const formSchema = z.object({
  title: z.string().min(5, 'Title must be at least 5 characters.'),
  severity: z.string().min(1, 'Select a severity.')
});

export function BugReportForm() {
  const form = useAppForm({
    defaultValues: { title: '', severity: '' },
    validators: { onSubmit: formSchema },
    onSubmit: ({ value }) => console.log(value)
  });

  return (
    <form
      onSubmit={(e) => {
        e.preventDefault();
        form.handleSubmit();
      }}
    >
      <FieldGroup>
        <form.AppField
          name='title'
          children={(field) => (
            <field.TextField label='Bug Title' required placeholder='Login button broken' />
          )}
        />
        <form.AppField
          name='severity'
          children={(field) => (
            <field.SelectField
              label='Severity'
              options={[
                { value: 'low', label: 'Low' },
                { value: 'high', label: 'High' }
              ]}
            />
          )}
        />
        <form.AppForm>
          <form.SubmitButton>Submit</form.SubmitButton>
        </form.AppForm>
      </FieldGroup>
    </form>
  );
}

form.AppField's name is fully typed against defaultValues — typos are
compile errors. Field-level validators/listeners go on the form.AppField
element (async checks, onChangeListenTo linked fields).

Available field components Copy Chapter

All render inside form.AppField as field.XxxField; every one takes
label, description?, required?.

One-off custom fields — drop down to `form.Field` Copy Chapter

For anything the components don't cover (object-row arrays, bespoke UI), use
the raw doc pattern directly — it composes freely with the components:

<form.Field
  name='members'
  mode='array'
  children={(field) => (
    <>
      {field.state.value.map((_, i) => (
        <form.Field
          name={`members[${i}].name`}
          children={(subField) => {
            const isInvalid = subField.state.meta.isTouched && !subField.state.meta.isValid;
            return (
              <Field data-invalid={isInvalid}>
                <Input
                  value={subField.state.value}
                  onChange={(e) => subField.handleChange(e.target.value)}
                  onBlur={subField.handleBlur}
                  aria-invalid={isInvalid}
                />
                {isInvalid && <FieldError errors={subField.state.meta.errors} />}
              </Field>
            );
          }}
        />
      ))}
      <Button type='button' onClick={() => field.pushValue({ name: '' })}>Add</Button>
    </>
  )}
/>

The doc conventions inside any custom field: data-invalid on <Field>,
aria-invalid on the control, {isInvalid && <FieldError errors={…} />},
function validators return { message: '…' } objects.

Scaling to large forms — `withForm` sections Copy Chapter

Split a big form into reusable section components with withForm (also
exported from @/lib/form). Sections receive the form instance as a prop and
keep fully typed field names — a typo'd name inside a section is still a
compile error:

import { useAppForm, withForm } from '@/lib/form';

const ShippingSection = withForm({
  defaultValues: checkoutDefaults, // ties the section to the form's shape
  render: function ShippingRender({ form }) {
    return (
      <FieldGroup>
        <form.AppField
          name='shipping.street'
          children={(field) => <field.TextField label='Street' required />}
        />
        <form.AppField
          name='shipping.city'
          children={(field) => <field.TextField label='City' required />}
        />
      </FieldGroup>
    );
  }
});

// In the page:
const form = useAppForm({ defaultValues: checkoutDefaults, ... });
<ShippingSection form={form} />

Deep paths (org.billing.address.city), array sub-paths
(admins[0].prefs.notify), and union-typed leaves all stay typed, and
typechecking stays fast at 40+ fields.

Template-specific notes Copy Chapter

Submitting with React Query. onSubmit awaits the mutation; success/error
handling lives on the mutation (see features/products/components/product-form.tsx):

onSubmit: async ({ value }) => {
  await createMutation.mutateAsync(value);
};

Sheet / Dialog forms. The submit button lives in the footer, outside the
<form> element, connected via the HTML form attribute
(features/users/components/user-form-sheet.tsx):

<form id='user-form-sheet' onSubmit={…}>…</form>
<SheetFooter>
  <Button type='submit' form='user-form-sheet'>Save</Button>
</SheetFooter>

Multi-step forms. useFormStepper(stepSchemas, { fullSchema }) from
@/hooks/use-stepper gates step navigation: Next validates the current
step's schema and paints its errors; the final submit re-validates the whole
schema and never submits invalid data. Route every submit through the gate —
see features/forms/components/multi-step-product-form.tsx.

Number inputs. TextField type='number' already converts at the edge;
give required numbers a human message: z.number({ error: 'Price is required' }).

Caveats to know (verified by stress testing):

• field.XxxField components assert their value type via
  useFieldContext<T>() — the compiler checks the name path exists, but
  not that the widget matches the path's value type (a SwitchField on a
  string path compiles and renders wrong values). Match widgets to the table
  above.
• Rendering a field component outside form.AppField throws a clear error
  (fieldContext only works when within a fieldComponent…) — it cannot fail
  silently.
• Two forms with identical field names mounted at once (a sheet over a page)
  produce duplicate id attributes — the shadcn doc's id={field.name}
  convention. Form state stays fully isolated; only label-target ids
  collide. Rename fields or avoid simultaneous mounting if labels must stay
  clickable in both.
• Forgetting mode='array' on an AppField using CheckboxGroupField /
  TagsField / ToggleGroupField still renders and updates — but keep the
  convention: array mode gives TanStack correct per-item meta tracking.

Examples in the dashboard Copy Chapter

Nav Rbac (`docs/nav-rbac.md`) Copy Section

Simplified Navigation RBAC System

Overview Copy Chapter

This document explains the fully client-side RBAC (Role-Based Access Control) system for navigation items.

Key Insight: Navigation visibility is UX only, not security. We can check everything client-side using Clerk's hooks!

Architecture Copy Chapter

Core Files Copy Section

1. src/hooks/use-nav.ts - Single hook that handles all filtering logic (fully client-side)
2. src/types/index.ts - Type definitions with access property

Why Client-Side? Copy Section

• Navigation visibility is UX only - Users can't bypass security by seeing/hiding nav items
• Clerk provides all data client-side - useOrganization() gives us membership.permissions and membership.role
• Zero server calls - Instant filtering, no loading states, no UI flashing
• Better performance - No network latency, no async complexity

Note: For actual security (API routes, server actions, page protection), always use server-side checks.

Performance Characteristics Copy Chapter

All Checks Are Synchronous Copy Section

✅ requireOrg: Client-side check using useOrganization()
✅ permission: Client-side check using membership.permissions array
✅ role: Client-side check using membership.role
⚠️ plan/feature: Requires server-side check (see below)

Zero Server Calls Copy Section

• All navigation filtering happens synchronously
• No loading states
• No UI flashing
• Instant results

Usage Copy Chapter

In `nav-config.ts` Copy Section

{
  title: 'Teams',
  url: '/dashboard/workspaces/team',
  icon: 'userPen',
  // Simple: requireOrg (client-side check, instant)
  access: { requireOrg: true }
}

{
  title: 'Admin Panel',
  url: '/dashboard/admin',
  icon: 'settings',
  // All client-side checks - instant!
  access: {
    requireOrg: true,
    permission: 'org:admin:manage',  // Client-side from membership.permissions
    role: 'admin'  // Client-side from membership.role
}

In Components Copy Section

import { useFilteredNavItems } from '@/hooks/use-nav';

function MyComponent() {
  const filteredItems = useFilteredNavItems(navItems);
  // filteredItems is automatically filtered based on RBAC
}

Plan/Feature Checks Copy Section

Plans and features require Clerk's has() function which is server-side only. Options:

1. Store in organization metadata (recommended for navigation):

   typescript Copy

   // In your organization setup
   organization.publicMetadata.plan = 'pro';
   
   // In nav-config.ts
   access: {
     requireOrg: true,
     // Check metadata instead of plan
   }

2. Show item, protect at page level (current approach):

   • Navigation item is shown
   • Page component checks server-side and redirects/shows error if needed

3. Use server action (if you really need it):

   • Only for navigation items that absolutely need plan/feature checks
   • Most navigation items won't need this

Scalability Copy Chapter

Adding New Items Copy Section

Just add to nav-config.ts:

{
  title: 'New Feature',
  url: '/dashboard/new',
  icon: 'star',
  access: { plan: 'pro' }  // That's it!
}

The system automatically:

• Filters it in sidebar
• Filters it in kbar
• Handles async checks if needed
• Handles sync checks immediately

Adding New Access Types Copy Section

1. Add to PermissionCheck interface in src/app/actions/rbac.ts
2. Add check logic in checkAccess() function
3. Update use-nav.ts to handle the new type

Comparison: Before vs After Copy Chapter

Before (Overcomplicated) Copy Section

• 4 files with complex logic
• Multiple hooks and utilities
• Unclear data flow
• Potential for bugs

After (Simplified) Copy Section

• 1 main hook file
• Clear, linear logic
• Easy to understand
• Easy to maintain

Best Practices Copy Chapter

1. Use requireOrg: true for simple cases - It's instant and requires no server call
2. Combine checks when possible - { requireOrg: true, permission: '...' } is more efficient than separate checks
3. Avoid unnecessary checks - Don't add access if the item should always be visible

Migration from Old System Copy Chapter

The old visible function still works for backward compatibility:

// Old way (still works)
visible: (context) => !!context?.organization;

// New way (recommended)
access: {
  requireOrg: true;
}

Future Improvements Copy Chapter

Potential optimizations if needed:

1. Cache permission checks (e.g., React Query)
2. Prefetch permissions on app load
3. Optimistic UI updates

But for now, the current implementation is:

• ✅ Simple
• ✅ Fast
• ✅ Scalable
• ✅ Maintainable

Themes (`docs/themes.md`) Copy Section

Adding New Themes

This guide explains how to add a new theme to the application. The theme system uses CSS custom properties with [data-theme] selectors for easy theme switching.

The Journey: Adding a New Theme Copy Chapter

When adding a new theme, follow this journey:

1. Create theme CSS file → src/styles/themes/your-theme-name.css with [data-theme='your-theme-name']
2. Import theme → Add @import to src/styles/theme.css
3. Register theme → Add to THEMES array in src/components/themes/theme.config.ts
4. Add fonts (if needed) → Import fonts in src/components/themes/font.config.ts if using custom Google Fonts
5. Set as default (optional) → Update DEFAULT_THEME in src/components/themes/active-theme.tsx

See the Step-by-Step Guide section below for detailed instructions.

Quick Start: Set Your Theme as Default Copy Chapter

To make your new theme the default (so it loads automatically without the theme switcher):

1. Open src/components/themes/active-theme.tsx
2. Change line 12: const DEFAULT_THEME = 'your-theme-name';
3. Save and restart your dev server

That's it! Your theme will now be the default for all new users.

Note: Make sure you've completed steps 1-3 above before setting a theme as default.

Theme Structure Copy Chapter

All themes are located in src/styles/themes/ directory. Each theme is a complete, self-contained CSS file that defines all design tokens for both light and dark modes.

File Format Copy Chapter

Each theme file must follow this structure:

/* Detailed source-code truncated for AI context efficiency. */

Step-by-Step Guide: Adding a New Theme Copy Chapter

Follow these steps in order to add a new theme to your application.

Step 1: Create Theme CSS File Copy Section

Create a new file in src/styles/themes/ with a descriptive name (use kebab-case):

src/styles/themes/your-theme-name.css

Important: The filename should match the data-theme attribute value you'll use in the CSS.

Step 2: Define Your Theme with `[data-theme]` Attribute Copy Section

Copy the structure from the "File Format" section above and fill in your color values. Use OKLCH color format for better color consistency:

/* Light mode tokens */
[data-theme='your-theme-name'] {
  --background: oklch(1 0 0); /* White */
  --foreground: oklch(0.145 0 0); /* Dark gray */
  --card: oklch(...);
  /* ... all other tokens */
}

/* Dark mode tokens */
[data-theme='your-theme-name'].dark {
  --background: oklch(0.145 0 0); /* Dark */
  --foreground: oklch(0.985 0 0); /* Light */
  /* ... all other tokens with dark mode values */
}

/* Theme inline mappings for Tailwind */
[data-theme='your-theme-name'] {
  @theme inline {
    /* All the mappings as shown in the File Format section */
  }
}

Color Format:

• Use oklch() format: oklch(lightness chroma hue)
• Example: oklch(0.852 0.199 91.936) = light green-blue
• Lightness: 0-1 (0 = black, 1 = white)
• Chroma: 0+ (0 = grayscale, higher = more saturated)
• Hue: 0-360 (color wheel position)

Key Points:

• The [data-theme='your-theme-name'] selector is what makes your theme work
• The value 'your-theme-name' must match exactly in all places (CSS file, config, etc.)
• Always include both light and dark mode variants
• Include the @theme inline block for Tailwind CSS integration

Step 3: Import Theme in theme.css Copy Section

Add your theme import to src/styles/theme.css:

@import './themes/your-theme-name.css';

This makes your theme available to the application.

Step 4: Add Theme to theme.config.ts Copy Section

Add your theme to the THEMES array in src/components/themes/theme.config.ts:

export const THEMES = [
  // ... existing themes
  {
    name: 'Your Theme Name', // Display name in the UI
    value: 'your-theme-name' // Must match [data-theme] value exactly
  }
];

Important: The value field must match the data-theme attribute value from your CSS file exactly.

Step 5: Add Custom Fonts (If Needed) Copy Section

Only do this step if your theme requires a custom Google Font that isn't already loaded.

If you want to use a Google Font in your theme:

File: src/components/themes/font.config.ts

1. Import the font from next/font/google:

import { Your_Font_Name } from 'next/font/google';

2. Configure the font with a CSS variable:

const fontYourName = Your_Font_Name({
  subsets: ['latin'],
  weight: ['400', '500', '700'], // Adjust weights as needed
  variable: '--font-your-name' // Optional: custom variable name
});

3. Add it to the fontVariables export:

export const fontVariables = cn(
  // ... existing fonts
  fontYourName.variable
);

4. Use the font in your theme CSS by its display name (not the CSS variable):

[data-theme='your-theme-name'] {
  --font-sans: 'Your Font Name', sans-serif; /* Use the actual font name */
  --font-mono: 'Your Mono Font', monospace;
}

Important Notes:

• Use the font's display name in CSS (e.g., 'Geist', 'Architects Daughter'), not the CSS variable
• The font must be imported in font.config.ts for it to be loaded by Next.js
• Font variables from font.config.ts are automatically applied to the body via layout.tsx
• You can use any Google Font available in next/font/google
• Check existing fonts in font.config.ts before adding new ones - you might be able to reuse them

Example: The notebook theme uses Architects Daughter:

• Imported in font.config.ts as Architects_Daughter
• Used in notebook.css as 'Architects Daughter' (with quotes and space)

Step 6: Set as Default Theme (Optional) Copy Section

If you want your theme to be the default theme that loads when users first visit the application (without needing the theme switcher), update the default theme constant:

File: src/components/themes/theme.config.ts

/**
 * Default theme that loads when no user preference is set
 * Change this value to set a different default theme
 */
export const DEFAULT_THEME = 'your-theme-name'; // Change from 'vercel' to your theme name

Note:

• This is the single source of truth for the default theme - it's automatically used in both server-side rendering and client-side code
• This will make your theme the default for all new users
• Existing users who have already selected a theme will still see their saved preference (stored in cookies)
• The default theme is applied immediately on page load (no flash of unstyled content)

Step 7: Test Your Theme Copy Section

1. Start your development server
2. Open the theme selector in the UI
3. Select your new theme
4. Verify it works in both light and dark modes
5. Test scaled variant by selecting "Your Theme Name (Scaled)"
6. If you set it as default, clear your browser cookies and refresh to see it load automatically

Quick Reference: File Locations Copy Chapter

When adding a new theme, you'll work with these files in this order:

1. ✅ src/styles/themes/your-theme-name.css - Create theme file with [data-theme] attribute
2. ✅ src/styles/theme.css - Import your theme file
3. ✅ src/components/themes/theme.config.ts - Add theme to THEMES array
4. ⚠️ src/components/themes/font.config.ts - Add fonts only if needed
5. ⚠️ src/components/themes/active-theme.tsx - Set as default only if desired

Required Tokens Copy Chapter

Minimum Required Copy Section

At minimum, your theme should define these tokens:

• --background
• --foreground
• --card & --card-foreground
• --popover & --popover-foreground
• --primary & --primary-foreground
• --secondary & --secondary-foreground
• --muted & --muted-foreground
• --accent & --accent-foreground
• --destructive & --destructive-foreground
• --border
• --input
• --ring
• --radius

Optional Tokens Copy Section

These can be omitted if not needed:

• --chart-1 through --chart-5 (defaults to primary colors)
• --sidebar-* tokens (defaults to card colors)
• --font-* tokens (uses system defaults)
• --shadow-* tokens (no shadows if omitted)
• --tracking-normal (no letter spacing if omitted)
• --spacing (uses default)

Example: Complete Theme Copy Chapter

See src/styles/themes/claude.css for a complete example with all tokens defined.

Example: Minimal Theme Copy Chapter

For a minimal theme, you can copy an existing theme and modify only the colors you want to change. The system will fall back to defaults for any missing tokens.

Color Format Reference Copy Chapter

OKLCH Format Copy Section

oklch(lightness chroma hue)

• Lightness: 0-1 (0 = black, 1 = white)
• Chroma: 0+ (0 = grayscale, 0.2+ = colorful)
• Hue: 0-360 degrees
  • 0/360 = Red
  • 60 = Yellow
  • 120 = Green
  • 180 = Cyan
  • 240 = Blue
  • 300 = Magenta

Examples Copy Section

/* Pure white */
--background: oklch(1 0 0);

/* Pure black */
--foreground: oklch(0 0 0);

/* Bright blue */
--primary: oklch(0.7 0.2 240);

/* Muted gray */
--muted: oklch(0.5 0 0);

Scaled Variants Copy Chapter

All themes automatically support scaled variants. When a user selects "Theme Name (Scaled)", the .theme-scaled class is applied, which adjusts spacing and text sizes. No additional CSS is needed in your theme file.

Best Practices Copy Chapter

1. Use descriptive theme names: Use kebab-case (e.g., ocean-blue, forest-green)
2. Provide both light and dark modes: Always define both variants
3. Test accessibility: Ensure sufficient contrast between foreground and background
4. Keep tokens consistent: Use similar lightness/chroma values for related colors
5. Document special features: If your theme has unique characteristics (like no shadows or custom fonts), add comments

Troubleshooting Copy Chapter

Theme Not Appearing Copy Section

• Check that the file is imported in src/styles/theme.css
• Verify the theme name matches in both CSS file and theme-selector.tsx
• Ensure the file is saved and the dev server has reloaded

Colors Not Applying Copy Section

• Verify all required tokens are defined
• Check that @theme inline block includes all color mappings
• Ensure OKLCH format is correct (no typos)

Dark Mode Not Working Copy Section

• Verify .dark selector is correct: [data-theme='name'].dark
• Check that dark mode tokens are defined
• Ensure next-themes is properly configured

Setting a Default Theme Copy Chapter

By default, the application uses the vercel theme. To change the default theme that loads for new users:

Change Default Theme Constant Copy Section

Edit src/components/themes/theme.config.ts and update the DEFAULT_THEME constant:

/**
 * Default theme that loads when no user preference is set
 * Change this value to set a different default theme
 */
export const DEFAULT_THEME = 'your-theme-name'; // Change this value

How it works:

• Single source of truth: DEFAULT_THEME is defined in theme.config.ts and imported everywhere it's needed
• Server-side: Applied immediately in the HTML data-theme attribute (no flash)
• Client-side: Used as fallback when no cookie preference exists
• User preferences: Still respects saved user preferences (stored in cookies)
• Automatic: No need to update multiple files - change it once and it works everywhere

Benefits of this approach:

✅ No code duplication - defined once, used everywhere
✅ Type-safe - TypeScript ensures consistency
✅ Easy to change - update one line in one file
✅ Well-documented - clear comments explain its purpose
✅ Immediate application - no flash of unstyled content

Using Google Fonts in Themes Copy Chapter

Note: This section provides additional details about fonts. For the complete step-by-step process, see Step 5 in the "Step-by-Step Guide" above.

When to Add Fonts Copy Section

You only need to add fonts to font.config.ts if:

• Your theme uses a Google Font that isn't already imported
• You want to use a custom font that requires loading

Tip: Check src/components/themes/font.config.ts first - many fonts may already be available!

Font Loading Process Copy Section

1. Import the font in src/components/themes/font.config.ts:

import { Roboto, Roboto_Mono } from 'next/font/google';

2. Configure the font with a CSS variable:

const fontRoboto = Roboto({
  subsets: ['latin'],
  weight: ['400', '500', '700'],
  variable: '--font-roboto'
});

3. Add to fontVariables export:

export const fontVariables = cn(
  // ... existing fonts
  fontRoboto.variable
);

4. Use in your theme CSS with the font's display name:

[data-theme='your-theme'] {
  --font-sans: 'Roboto', sans-serif; /* Use display name, not CSS variable */
  --font-mono: 'Roboto Mono', monospace;
}

Important Notes Copy Section

• Font names: Use the font's display name in CSS (e.g., 'Roboto', 'Open Sans'), not the CSS variable name
• Font loading: Fonts must be imported in font.config.ts to be loaded by Next.js
• Automatic application: Font variables are automatically applied to the body element via layout.tsx
• Available fonts: Check Next.js Font Optimization for available Google Fonts

Example: Notebook Theme Copy Section

The notebook theme uses Architects Daughter:

In font.config.ts:

import { Architects_Daughter } from 'next/font/google';

const fontArchitectsDaughter = Architects_Daughter({
  subsets: ['latin'],
  weight: '400',
  variable: '--font-architects-daughter'
});

export const fontVariables = cn(
  // ... other fonts
  fontArchitectsDaughter.variable
);

In notebook.css:

[data-theme='notebook'] {
  --font-sans: 'Architects Daughter', sans-serif;
}

Reference Files Copy Chapter

• Complete theme example: src/styles/themes/claude.css
• Theme aggregator: src/styles/theme.css
• Theme selector component: src/components/themes/theme-selector.tsx
• Theme provider: src/components/themes/active-theme.tsx
• Theme configuration (includes default theme): src/components/themes/theme.config.ts
• Font configuration: src/components/themes/font.config.ts

--- METRICS ---

• Files Extracted: 10
• Estimated Token Budget: ~15590 tokens
• Canonical Reference: https://codewiki.google/github.com/Kiranism/next-shadcn-dashboard-starter