{
  "$schema": "https://ui.shadcn.com/schema/registry.json",
  "name": "quill-ds",
  "homepage": "https://www.quilldesignsystem.com",
  "items": [
    {
      "name": "quill",
      "type": "registry:base",
      "title": "Quill Design System",
      "description": "Warm parchment surfaces, moss accents, Fraunces display type, and rich ink tones. A handcrafted theme for editorial and creative applications.",
      "author": "Craftwell (https://www.quilldesignsystem.com)",
      "files": [
        {
          "path": "registry/themes/quill.css",
          "type": "registry:base",
          "target": "app/quill-theme.css"
        }
      ]
    },
    {
      "name": "icon",
      "type": "registry:ui",
      "title": "Icon (Material Symbols)",
      "description": "The Quill icon component — Material Symbols Outlined at weight 400, bundled as a self-contained core set covering every icon the Quill blocks use.",
      "files": [
        {
          "path": "registry/lib/icon.tsx",
          "type": "registry:ui",
          "target": "components/ui/icon.tsx"
        },
        {
          "path": "src/components/ui/icons.core.mjs",
          "type": "registry:ui",
          "target": "components/ui/icons.core.mjs"
        },
        {
          "path": "registry/lib/icons.core.d.mts",
          "type": "registry:ui",
          "target": "components/ui/icons.core.d.mts"
        }
      ]
    },
    {
      "name": "tone-badge",
      "type": "registry:ui",
      "title": "Tone badge",
      "description": "Quill's uppercase tag pill for status, tiers, and labels — wraps Badge with the pigment vocabulary (moss/gold/terracotta/indigo/neutral/muted) baked in so tone never drifts per call site.",
      "registryDependencies": [
        "badge"
      ],
      "files": [
        {
          "path": "registry/lib/tone-badge.tsx",
          "target": "components/ui/tone-badge.tsx",
          "type": "registry:ui"
        }
      ],
      "docs": "Quill's uppercase tag pill for status, tiers, and labels — wraps Badge with the pigment vocabulary (moss/gold/terracotta/indigo/neutral/muted) baked in so tone never drifts per call site. Do: Leave `solid` false (the tinted default) for regular status/tier labels — it is the visually quieter option and still hits AA contrast per tone. Don't: Set `solid` on every ToneBadge in a view — solid is reserved for the one strong cue (a \"current\" marker, a live state) and loses its signal once everything is solid. Do: Render every uppercase tag pill through ToneBadge, even one-off labels. Don't: Hand-roll a `rounded-full … uppercase` span with ad hoc tone colors — it drifts from the AA-checked tint/solid pairs and the two-size scale. Do: Use ToneBadge's own size scale — `md` (20px) or `sm` (16px, the count-pill scale). Don't: Shrink a pill by hand-tightening its tracking or padding instead of passing `size=\"sm\"` — type stays `--text-2xs` at 0.1em tracking in both sizes. Use badge when the label is a generic chip outside Quill's tag-pill vocabulary — use Badge directly instead of forcing it through a tone."
    },
    {
      "name": "activity-feed",
      "type": "registry:block",
      "title": "Activity feed",
      "description": "A card timeline of recent events — avatar, action text, and a relative timestamp per entry.",
      "meta": {
        "intent": [
          "data-display"
        ],
        "use_when": "You need to show a chronological history of what happened — recent events with who, what, and when."
      },
      "registryDependencies": [
        "card",
        "avatar",
        "badge",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/activity-feed.tsx",
          "type": "registry:component",
          "target": "components/quill/activity-feed.tsx"
        }
      ],
      "docs": "A card timeline of recent events — avatar, action text, and a relative timestamp per entry. Do: Use relative timestamps (\"2 hours ago\") for recent activity — they read faster than absolute dates. Don't: Force users to parse a full timestamp for something that happened minutes ago. Use notifications when the events need an unread/read state and a mark-all-read action, not just a read-only history. Use data-table when the events are really records you need to filter, sort, or act on, not just skim chronologically."
    },
    {
      "name": "alerts",
      "type": "registry:block",
      "title": "Alert stack",
      "description": "A vertical stack of informational, success, and destructive alerts with icons.",
      "meta": {
        "intent": [
          "feedback"
        ],
        "use_when": "You need to surface inline status messages of varying severity (info, success, destructive) within a page."
      },
      "registryDependencies": [
        "alert",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/alerts.tsx",
          "type": "registry:component",
          "target": "components/quill/alerts.tsx"
        }
      ],
      "docs": "A vertical stack of informational, success, and destructive alerts with icons. Do: Match severity to consequence: destructive for blocking errors, default for neutral information. Don't: Use destructive styling for emphasis on non-error messages. Use sonner when the message is transient feedback about an action just taken — use a toast, not an inline alert. Use announcement-banner when the message is site-wide and dismissible rather than local to a page section. Use empty-state when the \"message\" is really an empty view that needs an explanation and a call to action."
    },
    {
      "name": "analytics-charts",
      "type": "registry:block",
      "title": "Analytics charts",
      "description": "A dashboard pair — an area chart of audience growth beside a bar chart of weekly sales, each on its own card.",
      "meta": {
        "intent": [
          "data-viz",
          "data-display"
        ],
        "use_when": "You need a dashboard view of trends over time — an area chart plus a bar chart on card surfaces."
      },
      "registryDependencies": [
        "card",
        "chart",
        "badge"
      ],
      "files": [
        {
          "path": "registry/blocks/analytics-charts.tsx",
          "type": "registry:component",
          "target": "components/quill/analytics-charts.tsx"
        }
      ],
      "dependencies": [
        "recharts"
      ],
      "docs": "A dashboard pair — an area chart of audience growth beside a bar chart of weekly sales, each on its own card. Do: Color each series from the chart token set (--chart-1…--chart-5), assigned in a fixed order. Don't: Hardcode a raw accent pigment (--terracotta, --moss, --indigo…) for a series — some pairs are documented as failing colorblind-distinguishability. Do: Pair a multi-series chart with a ChartLegend, as the Audience chart does — color is tied to a series name in text, never left for the reader to infer. Don't: Ship a multi-series chart with no legend — color becomes the only signal distinguishing readers from subscribers. Use stat-cards when you need at-a-glance numbers, not a trend shape — a single KPI reads faster as a number than a chart. Use data-table when the audience needs to inspect exact values per row, not the shape of change over time."
    },
    {
      "name": "announcement-banner",
      "type": "registry:block",
      "title": "Announcement banners",
      "description": "Two dismissible announcement banners — an inline bordered page banner and a full-bleed primary-color variant.",
      "meta": {
        "intent": [
          "feedback",
          "marketing"
        ],
        "use_when": "You need to announce something site-wide with a dismissible banner, either inline or full-bleed."
      },
      "registryDependencies": [
        "badge",
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/announcement-banner.tsx",
          "type": "registry:component",
          "target": "components/quill/announcement-banner.tsx"
        }
      ],
      "docs": "Two dismissible announcement banners — an inline bordered page banner and a full-bleed primary-color variant. Do: Give every banner variant its own dismiss button with a specific aria-label (e.g. \"Dismiss workshop banner\"), not a generic one. Don't: Ship a banner with no way to dismiss it, or multiple banners sharing one ambiguous \"Dismiss\" label. Use alerts when the message is local to a page section and tied to system status, not a site-wide announcement. Use cookie-consent when the banner requires an explicit choice (accept/reject), not just a dismiss."
    },
    {
      "name": "badge-on-card",
      "type": "registry:block",
      "title": "Badges on card",
      "description": "Default, secondary, and destructive badges shown together on a card surface.",
      "meta": {
        "intent": [
          "data-display"
        ],
        "use_when": "You need to show status or category badges attached to a content card."
      },
      "registryDependencies": [
        "card",
        "badge"
      ],
      "files": [
        {
          "path": "registry/blocks/badge-on-card.tsx",
          "type": "registry:component",
          "target": "components/quill/badge-on-card.tsx"
        }
      ],
      "docs": "Default, secondary, and destructive badges shown together on a card surface. Do: Reserve the destructive variant for a status that actually needs attention (blocked, failed, overdue). Don't: Use destructive styling for emphasis on a badge that isn't actually a warning. Use tone-badge when you need a badge whose color is driven by a semantic tone token rather than the three fixed variants here. Use data-table when the badges are actually per-row status in a list of records, not a single card's labels."
    },
    {
      "name": "calendar-page",
      "type": "registry:block",
      "title": "Calendar page",
      "description": "A single-date calendar paired with the selected day's session list, in one studio-schedule card.",
      "meta": {
        "intent": [
          "scheduling"
        ],
        "use_when": "You need to pick a single date and show what's scheduled that day."
      },
      "registryDependencies": [
        "card",
        "calendar",
        "badge",
        "separator"
      ],
      "files": [
        {
          "path": "registry/blocks/calendar-page.tsx",
          "type": "registry:component",
          "target": "components/quill/calendar-page.tsx"
        }
      ],
      "docs": "A single-date calendar paired with the selected day's session list, in one studio-schedule card. Do: Keep the session list in sync with whatever date is selected in the calendar — the two panes are one control, not two independent widgets. Don't: Let the calendar selection and the listed sessions fall out of sync (e.g. a static list that ignores the picked date). Use calendar-range when the user is booking a span of days, not viewing what's scheduled on one. Use activity-feed when you want a chronological history of past events, not a schedule of upcoming sessions tied to a picked date."
    },
    {
      "name": "calendar-range",
      "type": "registry:block",
      "title": "Calendar range picker",
      "description": "A stateful two-month range calendar for booking a span of days, with clear and reserve actions.",
      "meta": {
        "intent": [
          "scheduling",
          "form"
        ],
        "use_when": "You need to book a span of days with a two-month range picker and confirm/clear actions."
      },
      "registryDependencies": [
        "card",
        "calendar",
        "button",
        "badge"
      ],
      "files": [
        {
          "path": "registry/blocks/calendar-range.tsx",
          "type": "registry:component",
          "target": "components/quill/calendar-range.tsx"
        }
      ],
      "dependencies": [
        "react-day-picker"
      ],
      "docs": "A stateful two-month range calendar for booking a span of days, with clear and reserve actions. Do: Keep the Clear action available whenever a range is selected, separate from Reserve. Don't: Force a user to re-click through the whole range to correct a mis-click — that's what Clear is for. Do: Disable Reserve until both a start and end date are selected. Don't: Let a half-made range (just a start date) submit as if it were a valid booking. Use calendar-page when the user is picking a single day to view, not a multi-day span to reserve. Use checkout when the range is just one field within a larger purchase flow, not the whole card."
    },
    {
      "name": "chat",
      "type": "registry:block",
      "title": "Chat panel",
      "description": "A one-on-one messaging panel — contact header, message bubbles, and a composer input.",
      "meta": {
        "intent": [
          "messaging"
        ],
        "use_when": "You need a one-on-one messaging panel with a contact header, bubbles, and a composer."
      },
      "registryDependencies": [
        "input",
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/chat.tsx",
          "type": "registry:component",
          "target": "components/quill/chat.tsx"
        }
      ],
      "docs": "A one-on-one messaging panel — contact header, message bubbles, and a composer input. Do: Align the current user's messages to one side (right) and the other party's to the other (left) — position is the primary cue for who said what. Don't: Rely on color alone to distinguish sender — pair it with consistent alignment. Use list-detail when you need a list of conversations alongside the open thread, not just the single open thread. Use notifications when the messages are one-way system alerts, not a two-way conversation with someone."
    },
    {
      "name": "checkout",
      "type": "registry:block",
      "title": "Checkout",
      "description": "A two-column checkout — payment method picker and card form beside an order summary sidebar.",
      "meta": {
        "intent": [
          "commerce",
          "form"
        ],
        "use_when": "You need to collect payment and card details alongside an order summary."
      },
      "registryDependencies": [
        "card",
        "input",
        "label",
        "button",
        "radio-group",
        "separator",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/checkout.tsx",
          "type": "registry:component",
          "target": "components/quill/checkout.tsx"
        }
      ],
      "docs": "A two-column checkout — payment method picker and card form beside an order summary sidebar. Do: Use a RadioGroup for payment-method choice (Card/Bank/Wallet) — it's a single mutually exclusive choice, styled as cards. Don't: Use checkboxes or a dropdown for a single mutually exclusive payment method. Do: Pair the payment submit button with a lock icon, so the action itself visibly reads as a secure transaction. Don't: Ship the payment submit button with no lock icon — nothing on the button signals that submitting card data is secure. Use order-summary when you only need the cart-review card, not the full payment form beside it. Use wizard when payment is one step in a longer multi-step flow, not a single standalone page."
    },
    {
      "name": "command-palette",
      "type": "registry:block",
      "title": "Command palette",
      "description": "A searchable ⌘K command palette with grouped actions, recent items, and keyboard shortcuts.",
      "meta": {
        "intent": [
          "navigation"
        ],
        "use_when": "You need a searchable ⌘K launcher for actions and quick navigation."
      },
      "registryDependencies": [
        "command",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/command-palette.tsx",
          "type": "registry:component",
          "target": "components/quill/command-palette.tsx"
        }
      ],
      "docs": "A searchable ⌘K command palette with grouped actions, recent items, and keyboard shortcuts. Do: Group items into labeled sections (Actions, Recent) so a long list stays scannable. Don't: Dump every possible command into one flat, unlabeled list. Use search-results when search results should live inline on the page, not in a global keyboard-triggered overlay. Use dropdown-menu when the list of options is small and tied to a specific trigger element, not a global searchable launcher."
    },
    {
      "name": "contact-form",
      "type": "registry:block",
      "title": "Contact form",
      "description": "A get-in-touch card — name, email, a topic select, and a message field.",
      "meta": {
        "intent": [
          "form"
        ],
        "use_when": "You need a get-in-touch form with name, email, topic, and message fields."
      },
      "registryDependencies": [
        "card",
        "input",
        "label",
        "button",
        "textarea",
        "select"
      ],
      "files": [
        {
          "path": "registry/blocks/contact-form.tsx",
          "type": "registry:component",
          "target": "components/quill/contact-form.tsx"
        }
      ],
      "docs": "A get-in-touch card — name, email, a topic select, and a message field. Do: State a response-time expectation in the description (\"We usually reply within one working day.\") so the form doesn't feel like it disappears into a void. Don't: Leave users with no sense of whether or when they'll hear back. Use newsletter when you only need a single email field to grow a list, not a full multi-field inquiry form. Use settings when the fields are updating an existing profile, not sending a one-off message."
    },
    {
      "name": "cookie-consent",
      "type": "registry:block",
      "title": "Cookie consent",
      "description": "A cookie consent banner offering accept, reject, and preferences actions.",
      "meta": {
        "intent": [
          "feedback"
        ],
        "use_when": "You need a compliance banner offering accept, reject, and preferences choices."
      },
      "registryDependencies": [
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/cookie-consent.tsx",
          "type": "registry:component",
          "target": "components/quill/cookie-consent.tsx"
        }
      ],
      "docs": "A cookie consent banner offering accept, reject, and preferences actions. Do: \"Reject non-essential\" gets the same one-click ease as \"Accept all\" — both are top-level buttons, not one button plus a buried settings link. Don't: Make rejecting cookies harder to find or reach than accepting them — that's a dark pattern, not a real choice. Use announcement-banner when the message is informational only and doesn't require an explicit accept/reject decision. Use alerts when the message is a local, in-page status, not a site-wide compliance notice."
    },
    {
      "name": "dashboard",
      "type": "registry:block",
      "title": "Dashboard shell",
      "description": "An app shell with sidebar navigation, a search header, and KPI stat cards.",
      "meta": {
        "intent": [
          "app-shell",
          "data-display"
        ],
        "use_when": "You need a full application home — sidebar, search header, and KPI cards."
      },
      "registryDependencies": [
        "button",
        "input",
        "badge",
        "card",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/dashboard.tsx",
          "type": "registry:component",
          "target": "components/quill/dashboard.tsx"
        }
      ],
      "docs": "An app shell with sidebar navigation, a search header, and KPI stat cards. Do: Give the current nav item a distinct active state (background + text color), not just a subtle underline. Don't: Leave every nav item looking identical — users lose track of where they are. Use sidebar-nav when you need the collapsible icon-sidebar variant with grouped menus, not this fixed-width text sidebar. Use stat-cards when you only need the KPI row, not the full shell around it."
    },
    {
      "name": "data-table",
      "type": "registry:block",
      "title": "Data table",
      "description": "A filterable members table with a toolbar, status badges, and a per-row actions menu.",
      "meta": {
        "intent": [
          "data-display"
        ],
        "use_when": "You need a filterable, actionable table of records with status badges and row actions."
      },
      "registryDependencies": [
        "table",
        "badge",
        "button",
        "input",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/data-table.tsx",
          "type": "registry:component",
          "target": "components/quill/data-table.tsx"
        }
      ],
      "docs": "A filterable members table with a toolbar, status badges, and a per-row actions menu. Do: Give every icon-only row-action button a per-row aria-label (e.g. \"Actions for Ada Lovelace\"), not a generic one. Don't: Ship a table full of icon-only buttons that all announce as the same unlabeled button to a screen reader. Use activity-feed when you want a read-only chronological list, not sortable/filterable records with row actions. Use kanban when the records are better organized by status columns than by table rows."
    },
    {
      "name": "empty-state",
      "type": "registry:block",
      "title": "Empty state",
      "description": "A dashed-border empty state with an icon, explanatory text, and a primary action.",
      "meta": {
        "intent": [
          "feedback"
        ],
        "use_when": "You need to explain why a view is empty and offer the primary action to fill it."
      },
      "registryDependencies": [
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/empty-state.tsx",
          "type": "registry:component",
          "target": "components/quill/empty-state.tsx"
        }
      ],
      "docs": "A dashed-border empty state with an icon, explanatory text, and a primary action. Do: Pair the explanation with a real, primary action button that actually fills the view (e.g. \"New project\"). Don't: Explain that a view is empty and leave the user with no way to act on it from that screen. Use error-404 when the view is empty because the resource doesn't exist or the route is wrong, not because the user hasn't created anything yet. Use onboarding when there's a multi-step setup to walk through, not a single action to take right now."
    },
    {
      "name": "error-404",
      "type": "registry:block",
      "title": "404 page",
      "description": "A full-page 404 error state with go-back and home recovery actions.",
      "meta": {
        "intent": [
          "feedback"
        ],
        "use_when": "You need a full-page not-found state with recovery actions."
      },
      "registryDependencies": [
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/error-404.tsx",
          "type": "registry:component",
          "target": "components/quill/error-404.tsx"
        }
      ],
      "docs": "A full-page 404 error state with go-back and home recovery actions. Do: Offer both a contextual escape (Go back) and an absolute one (Take me home) — never strand the user with only one recovery path. Don't: Leave a 404 page with no action at all, or only a single 'Home' link buried in a header the user has to hunt for. Use empty-state when the resource exists but is legitimately empty (no items yet), not missing or misrouted. Use alerts when the error is recoverable inline on the current page, not a full-page dead end that needs its own route."
    },
    {
      "name": "faq",
      "type": "registry:block",
      "title": "FAQ section",
      "description": "A centered FAQ section — an accordion of common questions with a contact call-to-action footer.",
      "meta": {
        "intent": [
          "content",
          "marketing"
        ],
        "use_when": "You need to answer common questions in an accordion with a contact fallback."
      },
      "registryDependencies": [
        "accordion",
        "button"
      ],
      "files": [
        {
          "path": "registry/blocks/faq.tsx",
          "type": "registry:component",
          "target": "components/quill/faq.tsx"
        }
      ],
      "docs": "A centered FAQ section — an accordion of common questions with a contact call-to-action footer. Do: Open the first question by default (defaultValue=['item-0']) so the section doesn't read as empty on load. Don't: Start every item collapsed and force a first click just to prove the section has content. Use accordion when you need a bare accordion with no marketing framing (heading, contact footer) around it. Use contact-form when the user needs to ask something not covered — this pattern only offers a CTA button, not the form itself."
    },
    {
      "name": "feature-section",
      "type": "registry:block",
      "title": "Feature section",
      "description": "A marketing section with an editorial heading and a three-column feature grid.",
      "meta": {
        "intent": [
          "marketing"
        ],
        "use_when": "You need to present product features in an editorial multi-column grid."
      },
      "registryDependencies": [
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/feature-section.tsx",
          "type": "registry:component",
          "target": "components/quill/feature-section.tsx"
        }
      ],
      "docs": "A marketing section with an editorial heading and a three-column feature grid. Do: Keep the grid to three (or a multiple of three) features so it reads evenly across the row. Don't: Let an uneven feature count leave a dangling, unbalanced last row on wide screens. Use stats-band when you're presenting numbers, not descriptive feature callouts with icons and body text. Use pricing when the features are tied to specific paid tiers, not the product as a whole."
    },
    {
      "name": "file-upload",
      "type": "registry:block",
      "title": "File upload",
      "description": "An asset-upload card with a drag-and-drop dropzone and a progress-tracked upload queue.",
      "meta": {
        "intent": [
          "form"
        ],
        "use_when": "You need drag-and-drop asset upload with a progress-tracked queue."
      },
      "registryDependencies": [
        "card",
        "button",
        "progress",
        "separator",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/file-upload.tsx",
          "type": "registry:component",
          "target": "components/quill/file-upload.tsx"
        }
      ],
      "docs": "An asset-upload card with a drag-and-drop dropzone and a progress-tracked upload queue. Do: Make the dropzone a real, focusable <button> that also opens a file picker on click/Enter — never make drag-and-drop the only way in. Don't: Ship a dropzone that only responds to a pointer drag gesture. Do: Give each in-progress file its own progress bar, so users can see exactly how far each individual upload has gotten. Don't: Show one shared progress bar for the whole queue — users can't tell which file it belongs to or how far any single file has gotten. Use contact-form when you need a single attachment inside a broader form, not a dedicated upload queue as the whole card."
    },
    {
      "name": "footer",
      "type": "registry:block",
      "title": "Site footer",
      "description": "A marketing footer with brand blurb, link columns, and legal links.",
      "meta": {
        "intent": [
          "marketing",
          "navigation"
        ],
        "use_when": "You need a site-wide footer with link columns, a brand blurb, and legal links."
      },
      "registryDependencies": [
        "separator"
      ],
      "files": [
        {
          "path": "registry/blocks/footer.tsx",
          "type": "registry:component",
          "target": "components/quill/footer.tsx"
        }
      ],
      "docs": "A marketing footer with brand blurb, link columns, and legal links. Do: Wrap each link column in its own <nav aria-label>, as this block already does, so screen-reader users can jump between them. Don't: Render link columns as bare, unlabeled <div> lists that all announce as one undifferentiated block. Do: Separate the bottom legal row (copyright, Privacy, Terms) from the link columns with a visible Separator, as this block does. Don't: Rely on extra margin alone with no divider — the legal row reads as just another link column, not a distinct footer end-cap. Use sidebar-nav when the links are primary in-app navigation, not secondary site-wide links at the page's end. Use navbar when the links belong at the top of the page as primary navigation, not the bottom as reference."
    },
    {
      "name": "forgot-password",
      "type": "registry:block",
      "title": "Forgot password",
      "description": "A password-reset request card — an email field, a send-link action, and a way back to sign in.",
      "meta": {
        "intent": [
          "auth"
        ],
        "use_when": "You need a password-reset request card that sends a recovery link."
      },
      "registryDependencies": [
        "card",
        "input",
        "label",
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/forgot-password.tsx",
          "type": "registry:component",
          "target": "components/quill/forgot-password.tsx"
        }
      ],
      "docs": "A password-reset request card — an email field, a send-link action, and a way back to sign in. Do: Keep the ghost \"Back to sign in\" button so a user who clicked in by mistake isn't stuck. Don't: Ship this card as a dead end with no return path to sign-in. Use otp-verification when recovery works by a typed one-time code rather than an emailed link. Use login when the user hasn't actually forgotten anything — this card is only the detour reached from login's \"Forgot your password?\" link."
    },
    {
      "name": "hero",
      "type": "registry:block",
      "title": "Hero",
      "description": "A centered marketing hero — a release badge, serif headline, supporting copy, and primary/secondary calls to action.",
      "meta": {
        "intent": [
          "marketing"
        ],
        "use_when": "You need the top-of-page marketing statement — headline, supporting copy, and calls to action."
      },
      "registryDependencies": [
        "badge",
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/hero.tsx",
          "type": "registry:component",
          "target": "components/quill/hero.tsx"
        }
      ],
      "docs": "A centered marketing hero — a release badge, serif headline, supporting copy, and primary/secondary calls to action. Do: Keep exactly one primary (default-variant) button — the single most important action — with any secondary action as outline/ghost. Don't: Give two calls-to-action equal visual weight; competing primaries dilute the one action that matters most. Use feature-section when you're past the opening statement and need to break down specific product capabilities. Use announcement-banner when the message is a small, dismissible update, not the page's primary opening statement."
    },
    {
      "name": "invoice",
      "type": "registry:block",
      "title": "Invoice",
      "description": "A printable invoice card — sender and recipient details, a line-item table with totals, and a download action.",
      "meta": {
        "intent": [
          "commerce",
          "data-display"
        ],
        "use_when": "You need a printable invoice with parties, line-item totals, and a download action."
      },
      "registryDependencies": [
        "card",
        "table",
        "badge",
        "button",
        "separator",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/invoice.tsx",
          "type": "registry:component",
          "target": "components/quill/invoice.tsx"
        }
      ],
      "docs": "A printable invoice card — sender and recipient details, a line-item table with totals, and a download action. Do: Keep the total in a table footer, visually distinct from line items (its own row, right-aligned). Don't: Let the total blend in as just another line item — it needs to read as the sum, not another charge. Use order-summary when you're showing a cart before payment, not a record of a completed transaction. Use data-table when you need a list of many invoices to browse, not the full detail of one."
    },
    {
      "name": "kanban",
      "type": "registry:block",
      "title": "Kanban board",
      "description": "A three-column kanban board with card counts, tagged task cards, and an add-card affordance per column.",
      "meta": {
        "intent": [
          "productivity"
        ],
        "use_when": "You need to manage work across status columns with draggable, tagged task cards."
      },
      "registryDependencies": [
        "badge",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/kanban.tsx",
          "type": "registry:component",
          "target": "components/quill/kanban.tsx"
        }
      ],
      "docs": "A three-column kanban board with card counts, tagged task cards, and an add-card affordance per column. Do: Keep each column's card-count badge in sync with its actual card list — it's a running total, not a caption. Don't: Let the count badge drift out of sync when cards move between columns. Use data-table when status is one column among many sortable fields — a table reads better than columns once you need to sort or filter across many records. Use onboarding when the steps are a single sequential checklist, not parallel work items across independent columns."
    },
    {
      "name": "list-detail",
      "type": "registry:block",
      "title": "List + detail",
      "description": "An inbox-style split view — a selectable message list beside a detail pane with archive and delete actions.",
      "meta": {
        "intent": [
          "messaging",
          "app-shell"
        ],
        "use_when": "You need an inbox-style split view pairing a selectable list with a detail pane."
      },
      "registryDependencies": [
        "badge",
        "button",
        "separator",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/list-detail.tsx",
          "type": "registry:component",
          "target": "components/quill/list-detail.tsx"
        }
      ],
      "docs": "An inbox-style split view — a selectable message list beside a detail pane with archive and delete actions. Do: Keep the selected thread visually marked in the list (background fill) while its detail is open, so context isn't lost. Don't: Let the list's selection state go stale or unmarked once a thread is open in the detail pane. Use mail-shell when you need a fuller mail client — search, reply composer, forward — not just list-and-read. Use chat when the conversation is a live back-and-forth thread, not discrete messages you select and read one at a time."
    },
    {
      "name": "login",
      "type": "registry:block",
      "title": "Login",
      "description": "The standard email-and-password sign-in card, with remember-me and a forgot-password escape hatch.",
      "meta": {
        "intent": [
          "auth"
        ],
        "use_when": "You need the standard email-and-password sign-in with remember-me and reset links."
      },
      "registryDependencies": [
        "card",
        "input",
        "label",
        "button",
        "checkbox"
      ],
      "files": [
        {
          "path": "registry/blocks/login.tsx",
          "type": "registry:component",
          "target": "components/quill/login.tsx"
        }
      ],
      "docs": "The standard email-and-password sign-in card, with remember-me and a forgot-password escape hatch. Do: Treat \"Remember me\" as extending session length, never as the only thing standing between a device and the account. Don't: Rely on the remember-me checkbox as a security boundary. Do: Style \"Forgot your password?\" as a link beneath \"Sign in\" — one unmistakable primary action per card. Don't: Give \"Forgot your password?\" the same solid button treatment as \"Sign in\" — now two buttons compete to be primary. Use login-split-panel when the sign-in is a full page, not an embedded card, and you want a branded testimonial panel alongside it. Use login-minimal when you want the leanest possible sign-in — a single email field for a one-time code, no password at all. Use login-oauth when most of your users sign in through Google, GitHub, or Apple rather than a password you store. Use forgot-password when the user has already clicked \"Forgot your password?\" — that's a separate card, not a state of this one."
    },
    {
      "name": "login-minimal",
      "type": "registry:block",
      "title": "Minimal login",
      "description": "The bare-minimum sign-in — no card chrome, a single email field, sign-in by one-time code.",
      "meta": {
        "intent": [
          "auth"
        ],
        "use_when": "You need the leanest possible sign-in — a single field for one-time-code entry."
      },
      "registryDependencies": [
        "input",
        "label",
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/login-minimal.tsx",
          "type": "registry:component",
          "target": "components/quill/login-minimal.tsx"
        }
      ],
      "docs": "The bare-minimum sign-in — no card chrome, a single email field, sign-in by one-time code. Do: Reserve the bare, uncontained layout for cases where the surrounding page or modal already frames it. Don't: Drop this pattern directly onto a busy page background with nothing to separate it visually. Use login when you're collecting a password, not sending a one-time code — this pattern has no password field at all. Use login-oauth when you want a provider-first flow instead of email-only. Use otp-verification when the user already submitted their email and you're now showing the six-digit code entry — that's a separate step from this one."
    },
    {
      "name": "login-oauth",
      "type": "registry:block",
      "title": "Login with OAuth providers",
      "description": "Provider-first sign-in — Google, GitHub, and Apple buttons above an email fallback.",
      "registryDependencies": [
        "input",
        "label",
        "button",
        "separator"
      ],
      "files": [
        {
          "path": "registry/blocks/login-oauth.tsx",
          "target": "components/quill/login-oauth.tsx",
          "type": "registry:component"
        }
      ],
      "meta": {
        "intent": [
          "auth"
        ],
        "use_when": "Identity comes from a provider (Google, GitHub, Apple) rather than a password you store."
      },
      "docs": "Provider-first sign-in — Google, GitHub, and Apple buttons above an email fallback. Do: Treat the provider buttons as the primary path; keep the email form below the rule as a fallback, not the headline. Don't: Give the email field equal visual weight to the provider buttons when most users have a provider account. Do: Keep provider marks as their official inlined artwork, with GitHub and Apple taking currentColor so they invert correctly in Dusk. Don't: Restyle a provider mark to match your palette — that breaks the brand guidelines you agree to by using their sign-in. Use signup-social when this is account creation, not sign-in — signup-social also leads with OAuth providers. Use login when you store first-party passwords and don't want a provider-first order at all. Use login-minimal when you don't have OAuth providers configured and just need a single email field."
    },
    {
      "name": "login-split-panel",
      "type": "registry:block",
      "title": "Login with split panel",
      "description": "A full-page, branded sign-in — a testimonial panel beside an email/password form with a magic-link option.",
      "meta": {
        "intent": [
          "auth",
          "marketing"
        ],
        "use_when": "You need a branded full-page sign-in with a testimonial side panel and magic-link option."
      },
      "registryDependencies": [
        "input",
        "label",
        "button",
        "separator",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/login-split-panel.tsx",
          "type": "registry:component",
          "target": "components/quill/login-split-panel.tsx"
        }
      ],
      "docs": "A full-page, branded sign-in — a testimonial panel beside an email/password form with a magic-link option. Do: Let the brand panel drop out on small viewports and let the form take the full width. Don't: Force the two-column grid at phone widths — the testimonial panel has no room to be legible. Use login when the sign-in is an embedded card inside an existing page shell, not its own full page. Use login-minimal when you don't have a testimonial or brand story worth the real estate — go bare instead."
    },
    {
      "name": "mail-shell",
      "type": "registry:block",
      "title": "Mail inbox shell",
      "description": "A two-pane mail client shell — a searchable message list and a reading pane with toolbar and inline reply.",
      "meta": {
        "intent": [
          "messaging",
          "app-shell"
        ],
        "use_when": "You need a two-pane mail client — searchable list plus a reading pane with toolbar and reply."
      },
      "registryDependencies": [
        "badge",
        "button",
        "input",
        "label",
        "separator",
        "avatar",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/mail-shell.tsx",
          "type": "registry:component",
          "target": "components/quill/mail-shell.tsx"
        }
      ],
      "docs": "A two-pane mail client shell — a searchable message list and a reading pane with toolbar and inline reply. Do: Hide the reading pane on narrow viewports so the message list gets the full width instead of squeezing both panes. Don't: Force the two-pane layout at phone widths where neither pane has room to be usable. Use list-detail when you need the simpler read-and-select pattern with no search, toolbar, or reply composer. Use chat when the messaging is a live conversational thread, not discrete emails with subjects."
    },
    {
      "name": "navbar",
      "type": "registry:block",
      "title": "Navbar",
      "description": "A top navigation bar with brand wordmark, a responsive link list, and sign-in / get-started actions.",
      "meta": {
        "intent": [
          "navigation"
        ],
        "use_when": "You need a top navigation bar with wordmark, links, and sign-in / get-started actions."
      },
      "registryDependencies": [
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/navbar.tsx",
          "type": "registry:component",
          "target": "components/quill/navbar.tsx"
        }
      ],
      "docs": "A top navigation bar with brand wordmark, a responsive link list, and sign-in / get-started actions. Do: Keep \"Get started\" as the one default-variant (primary) button; \"Sign in\" stays ghost so it doesn't compete. Don't: Style both actions as equally prominent primary buttons. Use sidebar-nav when primary navigation belongs in a persistent side rail for an app, not a top bar for a marketing site. Use command-palette when navigation is keyboard-driven and searchable, not a fixed row of links."
    },
    {
      "name": "theme-selector",
      "type": "registry:block",
      "title": "Theme selector",
      "description": "A dropdown picker for the four Quill themes and four pigment accents — sets data-theme/data-accent and persists both to localStorage.",
      "meta": {
        "intent": [
          "settings"
        ],
        "use_when": "You need to let users switch among Quill's four themes and four accents, persisted to localStorage."
      },
      "registryDependencies": [
        "button",
        "dropdown-menu",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/theme-selector.tsx",
          "type": "registry:component",
          "target": "components/quill/theme-selector.tsx"
        }
      ],
      "docs": "A dropdown picker for the four Quill themes and four pigment accents — sets data-theme/data-accent and persists both to localStorage. Do: Read the persisted theme/accent from localStorage in an effect, after mount — never during render, or prerendered markup mismatches the client. Don't: Read localStorage synchronously during render; that guarantees a hydration mismatch since the server always renders Dawn/moss. Do: Show a color swatch next to each accent option in the menu, as this picker does, so people see the actual hue before picking it. Don't: List accent names as plain text with no swatch, forcing a guess at what \"Terracotta\" or \"Indigo\" actually look like. Use settings when theme choice is one field among many in a broader preferences form, not a standalone quick-switch control."
    },
    {
      "name": "newsletter",
      "type": "registry:block",
      "title": "Newsletter signup",
      "description": "A centered newsletter-signup section — an email field, subscribe action, and social proof.",
      "meta": {
        "intent": [
          "marketing",
          "form"
        ],
        "use_when": "You need an email-capture section with social proof to grow a list."
      },
      "registryDependencies": [
        "input",
        "label",
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/newsletter.tsx",
          "type": "registry:component",
          "target": "components/quill/newsletter.tsx"
        }
      ],
      "docs": "A centered newsletter-signup section — an email field, subscribe action, and social proof. Do: Say plainly what subscribers are signing up for and that they can leave any time (\"No spam, no noise — unsubscribe any time.\"). Don't: Ask for an email with no context on frequency or an easy way out. Use contact-form when you need more than an email — name, topic, a message — this pattern is intentionally a single field. Use footer when the signup is one small element within a full site footer, not its own standalone section."
    },
    {
      "name": "notifications",
      "type": "registry:block",
      "title": "Notifications",
      "description": "A notifications card listing recent events with icons, timestamps, unread indicators, and a mark-all-read action.",
      "meta": {
        "intent": [
          "feedback",
          "data-display"
        ],
        "use_when": "You need a notifications center with unread indicators and a mark-all-read action."
      },
      "registryDependencies": [
        "card",
        "button",
        "separator",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/notifications.tsx",
          "type": "registry:component",
          "target": "components/quill/notifications.tsx"
        }
      ],
      "docs": "A notifications card listing recent events with icons, timestamps, unread indicators, and a mark-all-read action. Do: Pair the unread dot with a real accessible label (role=\"img\" aria-label=\"Unread\"), as this block already does. Don't: Ship an unread indicator that's purely decorative with no accessible signal. Do: Give each notification an icon that matches its content (a person icon for membership events, a check for successful deploys) so the list can be scanned by icon alone. Don't: Reuse one generic bell icon for every notification regardless of type, forcing people to read each title just to tell them apart. Use activity-feed when the list is a read-only history with no read/unread state or mark-all action. Use sonner when the message is transient feedback about something that just happened — use a toast, not a persistent notifications list."
    },
    {
      "name": "onboarding",
      "type": "registry:block",
      "title": "Onboarding checklist",
      "description": "A setup checklist card with a progress bar, completed and pending tasks, and start links for remaining steps.",
      "meta": {
        "intent": [
          "productivity"
        ],
        "use_when": "You need a setup checklist that tracks progress and links to remaining steps."
      },
      "registryDependencies": [
        "card",
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/onboarding.tsx",
          "type": "registry:component",
          "target": "components/quill/onboarding.tsx"
        }
      ],
      "docs": "A setup checklist card with a progress bar, completed and pending tasks, and start links for remaining steps. Do: Pair the visual progress bar with a text fraction (\"2 of 4 complete\") so the state isn't conveyed by bar width alone. Don't: Show only a progress bar with no numeric readout of how much is actually done. Use wizard when the steps must happen in a strict sequence in one sitting, not a checklist a user dips in and out of over time. Use empty-state when there's a single action to take, not a multi-step checklist to track."
    },
    {
      "name": "order-summary",
      "type": "registry:block",
      "title": "Order summary",
      "description": "A checkout order-summary card — line items, a promo code field, a total, and a pay-now button.",
      "meta": {
        "intent": [
          "commerce"
        ],
        "use_when": "You need a cart-review card with line items, a promo field, a total, and a pay button."
      },
      "registryDependencies": [
        "card",
        "button",
        "input",
        "separator",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/order-summary.tsx",
          "type": "registry:component",
          "target": "components/quill/order-summary.tsx"
        }
      ],
      "docs": "A checkout order-summary card — line items, a promo code field, a total, and a pay-now button. Do: Recompute the total the instant a promo code applies or a line item changes — never leave a stale total on screen after an update. Don't: Require a page refresh or separate action to see the corrected total. Do: Show an applied promo as its own line item with the discount amount, so the line items and the total add up to the same number. Don't: Let the total drop after a promo applies with no corresponding line item — buyers can't verify what changed. Use invoice when you're showing a record of a completed, already-paid transaction, not a cart pending payment. Use checkout when you need the full payment form (card fields, billing address) alongside the summary, not just the review."
    },
    {
      "name": "otp-verification",
      "type": "registry:block",
      "title": "OTP verification",
      "description": "A six-digit one-time-passcode entry card for verifying an email, with expiry messaging and a resend action.",
      "meta": {
        "intent": [
          "auth"
        ],
        "use_when": "You need to verify an email with a six-digit one-time passcode and resend."
      },
      "registryDependencies": [
        "card",
        "input-otp",
        "label",
        "button"
      ],
      "files": [
        {
          "path": "registry/blocks/otp-verification.tsx",
          "type": "registry:component",
          "target": "components/quill/otp-verification.tsx"
        }
      ],
      "docs": "A six-digit one-time-passcode entry card for verifying an email, with expiry messaging and a resend action. Do: State the code's expiry window in the card body (\"expires in 10 minutes\"), not just in the email. Don't: Leave users guessing why a code that worked a moment ago now fails. Use login-minimal when you're sending the initial one-time code, not verifying a code the user already received — that's a separate step upstream of this card. Use forgot-password when recovery works by emailed link, not a typed code."
    },
    {
      "name": "page-header",
      "type": "registry:block",
      "title": "Page header",
      "description": "A page header with a breadcrumb trail, title and description, and duplicate/new action buttons.",
      "meta": {
        "intent": [
          "navigation",
          "app-shell"
        ],
        "use_when": "You need a screen header with breadcrumbs, title, description, and primary actions."
      },
      "registryDependencies": [
        "breadcrumb",
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/page-header.tsx",
          "type": "registry:component",
          "target": "components/quill/page-header.tsx"
        }
      ],
      "docs": "A page header with a breadcrumb trail, title and description, and duplicate/new action buttons. Do: Render the current page as BreadcrumbPage (plain text), not a link — you can't navigate to where you already are. Don't: Make every breadcrumb crumb, including the current page, a clickable link. Use sidebar-nav when you need the breadcrumb as part of a full app shell's top bar, not a standalone header block. Use hero when this is a marketing page's opening statement, not a utility screen's title bar."
    },
    {
      "name": "pricing",
      "type": "registry:block",
      "title": "Pricing",
      "description": "A three-tier pricing grid with a highlighted popular plan, feature checklists, and per-plan calls to action.",
      "meta": {
        "intent": [
          "marketing",
          "commerce"
        ],
        "use_when": "You need a tiered pricing grid with a highlighted plan and feature checklists."
      },
      "registryDependencies": [
        "card",
        "button",
        "badge",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/pricing.tsx",
          "type": "registry:component",
          "target": "components/quill/pricing.tsx"
        }
      ],
      "docs": "A three-tier pricing grid with a highlighted popular plan, feature checklists, and per-plan calls to action. Do: Mark exactly one plan as featured (ring + Popular badge) to guide the decision. Don't: Feature more than one plan, or none — either dilutes the recommendation this pattern exists to make. Use feature-section when you're describing capabilities in general, not comparing specific paid tiers against each other. Use order-summary when the user has already chosen a plan and is now reviewing a specific purchase, not comparing options."
    },
    {
      "name": "profile-card",
      "type": "registry:block",
      "title": "Profile card",
      "description": "A compact, centered profile card — avatar initials, role, follower stats, and follow/message actions.",
      "meta": {
        "intent": [
          "data-display"
        ],
        "use_when": "You need a compact user profile with avatar, role, stats, and follow / message actions."
      },
      "registryDependencies": [
        "card",
        "button",
        "badge",
        "separator",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/profile-card.tsx",
          "type": "registry:component",
          "target": "components/quill/profile-card.tsx"
        }
      ],
      "docs": "A compact, centered profile card — avatar initials, role, follower stats, and follow/message actions. Do: Label every stat (\"Followers\", \"Following\") directly beneath its number — a bare number has no meaning on its own. Don't: Show raw numbers with no label and expect position alone to convey what they mean. Use activity-feed when you want to show what someone did, not a static summary of who they are. Use data-table when you're listing many people at once — a table or list reads better than a full card per person."
    },
    {
      "name": "search-results",
      "type": "registry:block",
      "title": "Search results",
      "description": "A docs search panel — query input, result count, and a linked result list with breadcrumbs and type badges.",
      "meta": {
        "intent": [
          "navigation",
          "data-display"
        ],
        "use_when": "You need a search panel with a query input, result count, and a linked result list."
      },
      "registryDependencies": [
        "input",
        "badge",
        "separator",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/search-results.tsx",
          "type": "registry:component",
          "target": "components/quill/search-results.tsx"
        }
      ],
      "docs": "A docs search panel — query input, result count, and a linked result list with breadcrumbs and type badges. Do: State the result count in visible text (\"4 results for \\\"token\\\"\") so users know the query actually ran. Don't: Leave users guessing whether zero results means the search hasn't run yet or genuinely found nothing. Use command-palette when search is a global, keyboard-triggered overlay (⌘K) rather than an inline panel on the page. Use data-table when results are structured records with multiple sortable columns, not a simple linked list."
    },
    {
      "name": "settings",
      "type": "registry:block",
      "title": "Settings form",
      "description": "A profile settings card — name fields, a bio textarea, and an email-notification toggle.",
      "meta": {
        "intent": [
          "settings",
          "form"
        ],
        "use_when": "You need a profile settings form with name, bio, and notification preferences."
      },
      "registryDependencies": [
        "card",
        "input",
        "textarea",
        "label",
        "button",
        "switch",
        "separator"
      ],
      "files": [
        {
          "path": "registry/blocks/settings.tsx",
          "type": "registry:component",
          "target": "components/quill/settings.tsx"
        }
      ],
      "docs": "A profile settings card — name fields, a bio textarea, and an email-notification toggle. Do: Keep Save changes and Cancel as two distinct, clearly differentiated actions (primary vs ghost). Don't: Make Cancel look as prominent as Save — the user should never mis-tap away unsaved changes as the default action. Use contact-form when you're sending a one-off message, not editing a persistent profile. Use wizard when setup needs multiple sequential steps, not a single settings page a user returns to and edits freely."
    },
    {
      "name": "sidebar-nav",
      "type": "registry:block",
      "title": "Sidebar navigation shell",
      "description": "A collapsible icon-sidebar app shell with grouped menus, badges, a breadcrumb header, and a card grid main area.",
      "meta": {
        "intent": [
          "app-shell",
          "navigation"
        ],
        "use_when": "You need a collapsible icon-sidebar app shell with grouped menus and a content area."
      },
      "registryDependencies": [
        "sidebar",
        "breadcrumb",
        "avatar",
        "separator",
        "card",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/sidebar-nav.tsx",
          "type": "registry:component",
          "target": "components/quill/sidebar-nav.tsx"
        }
      ],
      "docs": "A collapsible icon-sidebar app shell with grouped menus, badges, a breadcrumb header, and a card grid main area. Do: Group sidebar items under labeled sections (e.g. \"Workspace\", \"Studio\"), as this block already does, rather than one long flat list. Don't: List every nav item at the same level with no grouping once the count grows past a handful. Use dashboard when you need a simpler, fixed-width text sidebar without the icon-collapse behavior. Use mail-shell when the main content area is a two-pane message list/reading layout, not a card grid."
    },
    {
      "name": "signup",
      "type": "registry:block",
      "title": "Sign up",
      "description": "Standard account-creation card — name, email, password, and a link back to sign-in.",
      "meta": {
        "intent": [
          "auth"
        ],
        "use_when": "You need standard account creation — name, email, password, and a sign-in link."
      },
      "registryDependencies": [
        "card",
        "input",
        "label",
        "button"
      ],
      "files": [
        {
          "path": "registry/blocks/signup.tsx",
          "type": "registry:component",
          "target": "components/quill/signup.tsx"
        }
      ],
      "docs": "Standard account-creation card — name, email, password, and a link back to sign-in. Do: Use the description line to state what happens next (trial length, no card required) so the form isn't just fields with no context. Don't: Leave the card as a bare field list with no framing for why someone would fill it out. Use signup-social when you want OAuth providers to lead instead of a bare email/password form. Use login when the user already has an account — this card is only for new ones."
    },
    {
      "name": "signup-social",
      "type": "registry:block",
      "title": "Signup — social first",
      "description": "Signup that leads with GitHub and Google provider buttons, falling back to an email/password form.",
      "meta": {
        "intent": [
          "auth"
        ],
        "use_when": "You need signup that leads with OAuth providers and falls back to email/password."
      },
      "registryDependencies": [
        "card",
        "input",
        "label",
        "button",
        "separator"
      ],
      "files": [
        {
          "path": "registry/blocks/signup-social.tsx",
          "type": "registry:component",
          "target": "components/quill/signup-social.tsx"
        }
      ],
      "docs": "Signup that leads with GitHub and Google provider buttons, falling back to an email/password form. Do: Put the provider buttons above the divider and the email/password fields below it, matching login-oauth's provider-first order. Don't: Bury the provider buttons below a full email/password form — that defeats the point of offering them. Use signup when you don't have OAuth providers configured, or want email/password as the primary path, not a fallback. Use login-oauth when this is sign-in, not new-account creation — login-oauth is the matching pattern for returning users."
    },
    {
      "name": "stat-cards",
      "type": "registry:block",
      "title": "Stat cards",
      "description": "A responsive grid of KPI cards, each showing a value with a delta badge versus last month.",
      "meta": {
        "intent": [
          "data-display"
        ],
        "use_when": "You need a row of KPI cards showing values with period-over-period deltas."
      },
      "registryDependencies": [
        "card",
        "badge"
      ],
      "files": [
        {
          "path": "registry/blocks/stat-cards.tsx",
          "type": "registry:component",
          "target": "components/quill/stat-cards.tsx"
        }
      ],
      "docs": "A responsive grid of KPI cards, each showing a value with a delta badge versus last month. Do: Match badge tone to whether the delta is actually good news for that metric (e.g. rising churn is bad, so it gets destructive tone even though the number itself looks like growth). Don't: Default every rising number to a positive tone — a rising \"Open tickets\" count is bad news, not good. Use analytics-charts when you need to show the trend shape over time, not just the current value and one delta. Use data-table when you have more metrics than fit comfortably in a card grid, or need to compare many rows at once."
    },
    {
      "name": "stats-band",
      "type": "registry:block",
      "title": "Stats band",
      "description": "A marketing band of headline statistics separated by vertical dividers on a card background.",
      "meta": {
        "intent": [
          "marketing"
        ],
        "use_when": "You need a marketing band of headline statistics separated by dividers."
      },
      "registryDependencies": [
        "separator"
      ],
      "files": [
        {
          "path": "registry/blocks/stats-band.tsx",
          "type": "registry:component",
          "target": "components/quill/stats-band.tsx"
        }
      ],
      "docs": "A marketing band of headline statistics separated by vertical dividers on a card background. Do: Color headline numbers from the accent-driven token (--accent-pigment), so they follow the page's data-accent like every other emphasis element. Don't: Hardcode a fixed pigment (e.g. --terracotta) for the numbers — that breaks when a consumer sets a different accent. Do: Pair every headline number with its own visible label directly beneath it (e.g. \"Components\"), as every stat in this band does. Don't: Ship a bare number with no label — a viewer has no way to tell what it counts. Use stat-cards when each number needs its own card with a period-over-period delta — this pattern is a single flat band with no per-item chrome or comparison. Use feature-section when you're describing capabilities, not reporting numbers."
    },
    {
      "name": "tabs-page",
      "type": "registry:block",
      "title": "Tabs page",
      "description": "A tabbed settings page with account, notifications, and security panels.",
      "meta": {
        "intent": [
          "navigation",
          "settings"
        ],
        "use_when": "You need a settings screen split into account, notifications, and security tabs."
      },
      "registryDependencies": [
        "tabs",
        "card",
        "input",
        "label",
        "switch"
      ],
      "files": [
        {
          "path": "registry/blocks/tabs-page.tsx",
          "type": "registry:component",
          "target": "components/quill/tabs-page.tsx"
        }
      ],
      "docs": "A tabbed settings page with account, notifications, and security panels. Do: Keep each TabsTrigger's `value` identical to its TabsContent's `value` when you rename a section (here, `account`/`notifications`), so the tab a user lands on always has a panel to show. Don't: Rename a TabsTrigger's `value` (e.g. Notifications → Alerts) without updating its TabsContent to match — the renamed tab still highlights as active since its own value is valid, but the panel underneath renders empty because no content shares that value anymore. Use settings when everything fits on one page without needing to split into separate tabbed sections. Use wizard when the sections are sequential setup steps completed once, not independent settings a user revisits and edits freely."
    },
    {
      "name": "team-section",
      "type": "registry:block",
      "title": "Team section",
      "description": "A marketing team grid with avatar cards showing each member's name, role, specialty badge, and email action.",
      "meta": {
        "intent": [
          "marketing"
        ],
        "use_when": "You need a marketing team grid with member cards, roles, and contact actions."
      },
      "registryDependencies": [
        "card",
        "avatar",
        "badge",
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/team-section.tsx",
          "type": "registry:component",
          "target": "components/quill/team-section.tsx"
        }
      ],
      "docs": "A marketing team grid with avatar cards showing each member's name, role, specialty badge, and email action. Do: Give every team member their own contact action, labeled with their name (e.g. \"Email Ada Lovelace\"). Don't: Ship one generic \"Contact us\" action for the whole grid — it defeats the point of a per-person team grid. Use profile-card when you're showing one person in detail (stats, follow/message), not a grid of many team members at a glance. Use testimonial when you're quoting what someone said, not introducing who's on the team."
    },
    {
      "name": "testimonial",
      "type": "registry:block",
      "title": "Testimonial",
      "description": "A customer-quote card with a serif pull-quote, avatar initials, and attribution.",
      "meta": {
        "intent": [
          "marketing",
          "content"
        ],
        "use_when": "You need a customer-quote card with a serif pull-quote and attribution."
      },
      "registryDependencies": [],
      "files": [
        {
          "path": "registry/blocks/testimonial.tsx",
          "type": "registry:component",
          "target": "components/quill/testimonial.tsx"
        }
      ],
      "docs": "A customer-quote card with a serif pull-quote, avatar initials, and attribution. Do: Pair every quote with a real name, role, and organization — an anonymous quote reads as unverifiable. Don't: Ship a testimonial with no attribution, or attribution too small/muted to actually read. Use team-section when you're introducing people, not quoting what a customer said about the product. Use stats-band when the proof point is a number, not a quote."
    },
    {
      "name": "wizard",
      "type": "registry:block",
      "title": "Setup wizard step",
      "description": "A multi-step setup card — a progress stepper, workspace fields, and back/continue navigation.",
      "meta": {
        "intent": [
          "form",
          "productivity"
        ],
        "use_when": "You need a multi-step setup flow with a progress stepper and back/continue navigation."
      },
      "registryDependencies": [
        "card",
        "input",
        "label",
        "button",
        "https://www.quilldesignsystem.com/r/icon.json"
      ],
      "files": [
        {
          "path": "registry/blocks/wizard.tsx",
          "type": "registry:component",
          "target": "components/quill/wizard.tsx"
        }
      ],
      "docs": "A multi-step setup card — a progress stepper, workspace fields, and back/continue navigation. Do: Show every step in the stepper up front (done/current/todo), so users know how much is left. Don't: Reveal steps one at a time with no sense of total progress. Use onboarding when the steps are a checklist of tasks to complete over time, not a linear form flow completed in one sitting. Use settings when there's only one step and no sequence to track — this is a single settings page, not a flow."
    }
  ]
}