@equal-experts/kuat-vue 0.15.1 → 0.15.2

package/agent-docs/external/kuat-agent-rules/reference/media-types/web-product/patterns/detail-page.md

@@ -0,0 +1,196 @@
+# Detail page
+
+**User goal:** See everything about one record — a profile, a business unit, a case — understand its
+current state, and act on it, without leaving the page to piece together context from elsewhere.
+
+> **Pattern:** *Pages* · single-medium (web-product) — concept and implementation together.
+> Covers profile pages, business-unit pages, and single-record views reached from a list, search, or hub.
+
+## Context
+
+A detail page exists once a user has found the record they want (from
+[browse and filter](./browse-and-filter.md) or a [section hub](./section-hub.md)) and needs the full
+picture: identity, current status, related data, and the actions available on this specific record.
+
+## Principles
+
+| Principle | Implementation |
+|-----------|-----------------|
+| Identity first | Name, status, and key identifiers visible without scrolling |
+| Related data is one click away | Group related content into tabs or sections, not one long scroll |
+| Actions stay attached to context | Primary actions live near the identity block, not in a footer |
+| A way back | Breadcrumb or back link to the list/hub the user came from |
+
+Success shows up as: time to find a specific fact about the record, task completion rate for the actions
+offered on the page, and navigation-back rate (whether users needed to bounce back to search again).
+
+## Solution in web-product
+
+### Layout
+
+**Base Layout:** Sidebar Navigation
+
+#### Structure
+
+```
+┌──────┬──────────────────────────────────┐
+│      │ Breadcrumb: List > Record Name   │
+│ Side ├──────────────────────────────────┤
+│ bar  │ ┌────┐ Record Name        [Edit] │
+│      │ │Avat│ Status badge · Metadata   │
+│      │ │ar  │                           │
+│      │ └────┘                           │
+│      ├──────────────────────────────────┤
+│      │ [Overview] [Activity] [Related]  │  ← tabs
+│      ├──────────────────────────────────┤
+│      │                                  │
+│      │   Tab content                    │
+│      │   (fields, chart, table, list)   │
+│      │                                  │
+└──────┴──────────────────────────────────┘
+```
+
+#### Specifications
+
+| Element | Value |
+|---------|-------|
+| Sidebar width | 240-280px (collapsible to 64px) |
+| Identity block height | Auto, generous padding (24-32px) |
+| Content padding | 24-32px |
+| Tabs | Underline style, horizontal, below the identity block |
+
+### Design
+
+#### Colour Tokens
+
+| Element | Token |
+|---------|-------|
+| Page background | `bg-background` |
+| Identity block | `bg-card` or transparent with a bottom `border` |
+| Status badge | Semantic colour per state (e.g. `bg-green-*` active, `bg-muted` inactive) — never colour alone |
+| Tab active indicator | `border-primary` |
+
+#### Identity Block Pattern
+
+| Element | Specification |
+|---------|-----------------|
+| Avatar/logo | Left, fixed size (e.g. 64-96px) |
+| Title | `text-2xl font-bold` — record name |
+| Status/metadata row | `text-sm text-muted-foreground`, badges + key facts inline |
+| Primary actions | Right-aligned, at the same height as the title |
+
+#### Typography Hierarchy
+
+| Element | Style |
+|---------|-------|
+| Record name | `text-2xl font-bold` |
+| Section headers (within tabs) | `text-lg font-semibold` |
+| Field labels | `text-sm text-muted-foreground` |
+| Field values | `text-base` |
+
+Charts within a detail page (e.g. a trend for this record) reuse
+[dashboard](./dashboard.md)'s Chart Container Pattern rather than a separate spec.
+
+### Content
+
+#### Identity Block Copy
+
+**Structure:**
+
+1. Record name (title)
+2. Status badge (current state, in plain language — "Active", "On hold", not a raw enum)
+3. Key metadata inline ("Joined Mar 2023", "12 direct reports")
+
+#### Tab Labels
+
+- Name tabs for what's inside, not generic labels ("Engagements", not "Tab 2")
+- Default to the tab most users need first (usually "Overview")
+
+#### Empty States
+
+| Scenario | Message |
+|----------|---------|
+| No activity/history yet | "No activity yet" |
+| A related list is empty | "No [related items] yet" + a create/add action, if applicable |
+| Field has no value | Show "—" or "Not set", never a blank space |
+
+#### Loading States
+
+- Identity block: skeleton for avatar + title + badge
+- Tab content: skeleton matching the eventual layout (fields, table, or chart)
+
+### Accessibility
+
+**Base requirements:** See [accessibility foundations](../../../accessibility/accessibility.md) and
+[web accessibility](../accessibility.md)
+
+**Scenario-specific:**
+
+| Requirement | Implementation |
+|--------------|------------------|
+| Status conveyed beyond colour | Badge carries a text label, not colour alone |
+| Tabs | Use the native tab pattern (`role="tablist"`, arrow-key navigation), not styled links |
+| Heading structure | Record name is the page's single H1; tab section headers are H2 |
+| Back navigation | Breadcrumb is a real link, keyboard-reachable before the identity block |
+
+### Implementation
+
+#### State Management
+
+| State | Handling |
+|-------|----------|
+| Loading | Skeleton identity block + tab content |
+| Not found | Explain the record doesn't exist or was removed; link back to the list |
+| No permission | Explain access is restricted; do not reveal partial data |
+| Error | Show error message with retry |
+
+#### Responsive Behaviour
+
+| Breakpoint | Identity block | Tabs |
+|------------|------------------|------|
+| Mobile | Stacks: avatar, then name, then actions | Horizontal scroll |
+| Tablet | Inline, actions may wrap below | Horizontal, all visible if they fit |
+| Desktop | Fully inline | Horizontal |
+
+## Best Practices
+
+### Do's
+
+1. **Put identity above the fold** - Name and status visible without scrolling
+2. **Keep actions near identity** - Not buried in a tab
+3. **Provide a way back** - Breadcrumb to the list/hub the user came from
+
+### Don'ts
+
+1. **Don't split identity across tabs** - Name, status, and primary actions stay in the identity block
+2. **Don't use colour alone for status** - Pair with a text label
+3. **Don't nest another full page inside a tab** - Tabs hold sections of this record, not separate pages
+
+### Common Mistakes
+
+| Mistake | Solution |
+|---------|----------|
+| No way back to the list | Add a breadcrumb or back link above the identity block |
+| Status shown only as a colour dot | Add a text label alongside |
+| Everything crammed onto one scrolling page | Split into tabs once there are 3+ distinct sections |
+
+### Edge Cases
+
+| Case | Handling |
+|------|----------|
+| Record has no name/title | Fall back to a stable identifier (ID, email) |
+| Record was deleted after being linked to | Show a "not found" state, not a blank page |
+| User lacks permission for one tab only | Disable that tab with a reason, rather than hiding the whole page |
+
+## Examples
+
+The sidebar-navigation frame above is the canonical detail page: identity block, tabs, and tab content
+reached from [browse and filter](./browse-and-filter.md) or a [section hub](./section-hub.md). Charts
+inside a tab reuse [dashboard](./dashboard.md)'s chart container pattern rather than a separate spec.
+
+## Related
+
+- [Product Design](../design.md) - Sidebar Navigation layout
+- [Browse and filter](./browse-and-filter.md) - Where a detail page is usually reached from
+- [Dashboard](./dashboard.md) - Chart container pattern, reused here
+- [Accessibility foundations](../../../accessibility/accessibility.md) - Colour and contrast

package/agent-docs/external/kuat-agent-rules/reference/media-types/web-product/patterns/give-feedback-on-an-action.md

@@ -0,0 +1,184 @@
+# Help users to know the outcome of their action
+
+**User goal:** Know, immediately and unambiguously, whether an action worked — and what, if
+anything, to do next.
+
+> **Pattern:** *Help users to…* · single-medium (web-product) — concept and implementation together.
+> Covers what happens immediately after a user takes an action: form submissions, saves, deletes,
+> multi-step transactions, and system-triggered status changes.
+
+## Context
+
+A user has just done something — submitted a form, saved a setting, deleted a record, started a
+process. Two failure modes sit on either side of this moment: under-communicating (the user isn't
+sure the action landed, so they retry or abandon) and over-communicating (every action triggers a
+banner or dialog, so real warnings get tuned out).
+
+This pattern is scoped to feedback after an action completes or fails. It is not:
+
+- Confirmation *before* a destructive action — see [content/confirmations.md](../content/confirmations.md).
+- Validation *while* filling in a form — see [content/errors.md](../content/errors.md) and the
+  form-validation section of [complete a form](./complete-a-form.md).
+- Persistent status indicators (RAG dots on a progress tracker) — a separate, related gap; see
+  the Badge row in [component-registry.md](../component-registry.md).
+
+## Principles
+
+| Principle | Implementation |
+|-----------|----------------|
+| Match feedback weight to the significance of the action | A completed, committed transaction needs a stopping point; a small in-place update doesn't |
+| Write the message before choosing the component | Draft the copy first, then pick the component that matches its severity/weight — not the reverse |
+| One message per priority tier, on screen, at a time | Avoids alert fatigue |
+| Be specific, not generic | Real values (names, numbers, dates), not "an error occurred" |
+| Don't blame the user | "Your changes couldn't be saved," not "You entered invalid data" |
+| Always pair colour with icon + label | Never rely on red/green alone (CVD) |
+
+Success shows up as: task completion confirmed without a support contact, low retry/duplicate-submit
+rate, and low dismissal-without-reading rate on assertive messages.
+
+## Solution in web-product
+
+### Layout
+
+Placement communicates priority. Cap how many messages can be visible per zone at once.
+
+| Zone | Where | Used for | Cap |
+|------|-------|----------|-----|
+| Global | Full-width, above the app shell (see the [system banner region](../design.md#region-breakdown)) | System-wide status only (outage, deprecation, access changes) | 1 at a time, app-wide |
+| Top of content area | Full-width, above the page's main heading or form (see the [Feedback row](../design.md#region-breakdown) in the main content composition table) | Page/section-level feedback tied to a submitted action: error summary, inline confirmation banner | 1 at a time, per content area |
+| Inline | Directly beside/below the specific element it concerns | Field-level validation, helper text | No hard cap, but consolidate rather than crowd — summarise if more than one |
+| Toast | Fixed position, top-right by default | Lightweight, transient task feedback that doesn't need a persistent record | Treat the component's visible-toast default as a ceiling, not a target; most screens should show one at a time |
+
+Reserve warning/danger states for when they're genuinely necessary. A page that regularly shows
+more than one top-of-content-area or global message at once signals an underlying issue to
+consolidate, not a reason to stack messages.
+
+A confirmation page (application/order/payment/account-creation submitted, with a reference number
+or "what happens next") uses the narrow/centred [Single Column](../design.md#option-3-single-column)
+layout — the same shape as auth/forms/wizards, not a distinct page type. It answers, in order: what
+was completed, what happens next and when, contact/help info, and a way to keep a record (print,
+PDF, email).
+
+### Design
+
+| Element | Token |
+|---------|-------|
+| Positive feedback | `bg-callout-positive`, `border-callout-positive-foreground` |
+| Informational feedback | `bg-callout-info`, `border-callout-info-foreground` |
+| Warning feedback | `bg-callout-warning`, `border-callout-warning-foreground` |
+| Error/issue feedback | `bg-callout-issue`, `border-callout-issue-foreground` |
+| Success text (inline, non-callout) | `text-success` |
+
+Every state pairs its colour with an icon and a text label — never colour alone.
+
+### Content
+
+Use the existing anatomy in [content/errors.md](../content/errors.md) (what went wrong → why, if
+it helps → how to fix) for failures, and [content/confirmations.md](../content/confirmations.md)
+for pre-action dialogs. For the feedback copy this pattern adds:
+
+- Lead with the outcome, not the mechanism: "Your changes were saved," not "Update successful."
+- State the outcome before any secondary detail.
+- Confirmation-page body copy answers, in order: what was completed, what happens next, and when.
+- Keep toast copy to one short sentence; if it needs more than that, it's a callout or a page, not
+  a toast.
+
+### Accessibility
+
+- Toasts: reserve an assertive announcement for errors that need immediate attention; default to a
+  polite announcement for success/info so screen reader users aren't interrupted mid-task.
+- Confirmation pages: the page `<title>` reflects completion (e.g. "Application complete").
+- Error summaries: move keyboard focus to the summary on submission failure; each error links to
+  its field via `aria-describedby` (see [complete a form](./complete-a-form.md)'s Form Validation
+  Pattern). A validation-failure summary needs assertive announcement on submit, which a passive
+  live region doesn't give — the composing component takes on this behaviour itself.
+- Never rely on colour alone — every state pairs an icon with its colour and label.
+
+### Implementation
+
+Choose the mechanism in order:
+
+1. Is this warning the user *before* an irreversible/destructive action? → Not this pattern; use
+   the confirmation-dialog pattern in [content/confirmations.md](../content/confirmations.md).
+2. Did the action complete (or fail) a distinct task the user came to this page/flow to do — an
+   application, an order, an onboarding step, a payment, a submission with a reference number —
+   such that the user would want a stopping point, a record, or a "you're done, here's what's next"
+   moment? → Confirmation page.
+3. Did it complete a meaningful sub-task while the user stays on a multi-purpose page — one card in
+   a settings page, one step submitted mid-wizard — where a persistent record isn't needed, but a
+   toast alone would be too easy to miss or dismiss before the user has registered it? → Inline
+   confirmation banner, in the page/section, above or below the content it relates to.
+4. Is this a small, low-stakes, in-place update — a single field, a toggle, a preference — where the
+   user stays in flow and keeps working immediately? → Toast.
+5. Did something fail? → Component depends on whether the failure is field-level, form-level, or
+   system-level; see the table below.
+
+| Scenario | Component | Why not the alternatives |
+|----------|-----------|---------------------------|
+| Application/order/payment/account-creation submitted; reference number or "what happens next" exists | Confirmation page | A toast can be dismissed or missed and leaves nothing to point back to |
+| One settings card saved, user stays on a multi-section settings page | Inline confirmation banner in that card/section | A page navigation would be disproportionate; a toast risks being missed if the user has scrolled away |
+| Single field/toggle/preference updated in place | Toast | Lightweight, non-blocking, matches the size of the change |
+| Field-level validation error | Inline error message next to the field | See [content/errors.md](../content/errors.md) / [complete a form](./complete-a-form.md) |
+| Multiple fields fail on submit | Error summary at top of form, focus moved to it | Same |
+| System-wide status (outage, deprecation, maintenance) | Global banner, top of the app, above navigation | Not tied to a single user action; needs the highest-priority placement |
+
+**Component guide:** see [component-registry.md](../component-registry.md) for the Callout,
+Sonner, AlertDialog, and Error Summary entries — the consumer package `agent-docs/` or overlay
+carries each component's implementation doc.
+
+## Best Practices
+
+### Do's
+
+1. **Choose the mechanism by weight, not habit** — match the component to the significance of the
+   action, not what's fastest to implement.
+2. **Keep exactly one message per priority zone visible at a time.**
+3. **Write the message first, then pick the component.**
+
+### Don'ts
+
+1. **Don't use a toast for anything the user might need to reference later** — receipts, reference
+   numbers.
+2. **Don't stack multiple callouts of the same priority on one page.**
+3. **Don't use warning/danger styling for routine, expected outcomes.**
+
+### Common Mistakes
+
+| Mistake | Solution |
+|---------|----------|
+| Toast for a completed transaction with a reference number | Use a confirmation page instead |
+| Multiple top-of-content-area messages at once | Consolidate into one summary |
+| Generic error copy ("An error occurred") | Name the real field/value that failed |
+| Colour-only status signalling | Pair every state with an icon and label |
+
+### Edge Cases
+
+| Case | Handling |
+|------|----------|
+| Action succeeds but a secondary effect fails (e.g. save succeeds, notification email fails) | Report the secondary failure separately, don't block on it |
+| User navigates away before a toast is read | Escalate to an inline banner or confirmation page instead of relying on the toast |
+| Repeated identical toasts in quick succession | Consolidate rather than stack — respect the component's visible-toast ceiling |
+
+## Examples
+
+A settings page where one card saves independently uses an inline confirmation banner in that
+card, not a page-level toast or navigation. A multi-step application ending in a reference number
+uses a confirmation page. A single preference toggle uses a toast. A failed multi-field form
+submission uses an error summary at the top of the form with focus moved to it.
+
+## Open questions
+
+- **Naming:** is "Help users to know the outcome of their action" the right outcome-framed name, or
+  should this split into a `confirm-completion.md` "Pages" pattern plus a separate "Help users
+  to…" pattern for the toast/inline tiers?
+- Does an internal business tool need a "feature discovery" message state, distinct from this
+  pattern's scope?
+
+## Related
+
+- [Confirmations](../content/confirmations.md) — pre-action dialogs
+- [Errors](../content/errors.md) — error copy anatomy
+- [Complete a form](./complete-a-form.md) — form validation timing and layout
+- [Product Design](../design.md) — region model and layout options
+- [Component decision tree](../component-decision-tree.md)
+- [Component registry](../component-registry.md) — Callout, Sonner, AlertDialog, Error Summary

package/agent-docs/external/kuat-agent-rules/reference/media-types/web-product/patterns/section-hub.md

@@ -0,0 +1,174 @@
+# Section hub
+
+**User goal:** Get an overview of what's available in a section, and choose the right sub-page to go
+into next — without a table or a task, just clear options.
+
+> **Pattern:** *Pages* · single-medium (web-product) — concept and implementation together.
+> Covers category landing pages, navigation hubs, and index pages that fan out to detail or sub-pages.
+
+## Context
+
+A section hub exists when there is no single task to complete — the user is orienting themselves inside
+a part of the product and choosing where to go. They want to see what's inside the section at a glance,
+understand what each option leads to before clicking, and reach the right sub-page in as few clicks as
+possible.
+
+## Principles
+
+| Principle | Implementation |
+|-----------|-----------------|
+| Scannable options | Consistent card layout, one glance per option |
+| Descriptive, not decorative | Card copy states what's inside, not just a label |
+| Flat where possible | Avoid hubs that just lead to more hubs — reach real content in 1-2 clicks |
+| Recency/relevance surfaced | Highlight recently used or most relevant sub-pages, if the data exists |
+
+Success shows up as: time to reach a sub-page, click-through rate per card, and bounce rate on the hub
+itself (users leaving without picking anything).
+
+## Solution in web-product
+
+### Layout
+
+**Base Layout:** Sidebar Navigation
+
+#### Structure
+
+```
+┌──────┬──────────────────────────────────┐
+│      │ Header: Section Title + Actions  │
+│ Side ├──────────────────────────────────┤
+│ bar  │ Optional: intro text / search    │
+│      ├──────────────────────────────────┤
+│      │ ┌────┐ ┌────┐ ┌────┐ ┌────┐     │
+│      │ │Card│ │Card│ │Card│ │Card│     │
+│      │ └────┘ └────┘ └────┘ └────┘     │
+│      │ ┌────┐ ┌────┐ ┌────┐             │
+│      │ │Card│ │Card│ │Card│             │
+│      │ └────┘ └────┘ └────┘             │
+└──────┴──────────────────────────────────┘
+```
+
+#### Specifications
+
+| Element | Value |
+|---------|-------|
+| Sidebar width | 240-280px (collapsible to 64px) |
+| Card grid | 3-4 columns desktop, 2 tablet, 1 mobile |
+| Grid gap | 16-24px |
+| Content padding | 24-32px |
+
+### Design
+
+#### Colour Tokens
+
+| Element | Token |
+|---------|-------|
+| Page background | `bg-background` |
+| Card background | `bg-card` |
+| Card border | `border` |
+| Card hover | `bg-accent` or subtle elevation, not colour alone |
+
+#### Card Pattern
+
+| Element | Specification |
+|---------|-----------------|
+| Container | `bg-card`, `border`, 6px radius, whole card is the click target |
+| Icon or thumbnail | Top or left, optional |
+| Title | `text-base font-semibold` |
+| Description | `text-sm text-muted-foreground`, 1-2 lines |
+| Metadata | Optional: item count, last updated |
+
+#### Typography Hierarchy
+
+| Element | Style |
+|---------|-------|
+| Page title | `text-2xl font-bold` |
+| Card title | `text-base font-semibold` |
+| Card description | `text-sm text-muted-foreground` |
+
+### Content
+
+#### Card Copy
+
+**Structure:**
+
+1. Title (the sub-page name)
+2. Description (what the user will find there, not a repeat of the title)
+3. Optional metadata (count, last updated)
+
+**Example Content:**
+
+| Title | Description |
+|-------|--------------|
+| "Client Accounts" | "128 active accounts across 6 regions" |
+| "Engagement Reports" | "Weekly status reports by engagement" |
+
+#### Empty States
+
+| Scenario | Message |
+|----------|---------|
+| Section has no sub-pages yet | "Nothing here yet" + guidance or a create action, if the user can add one |
+| Access-restricted sub-pages | Show the card, disabled, with a short reason ("Ask an admin for access") rather than hiding it |
+
+### Accessibility
+
+**Base requirements:** See [accessibility foundations](../../../accessibility/accessibility.md) and
+[web accessibility](../accessibility.md)
+
+**Scenario-specific:**
+
+| Requirement | Implementation |
+|--------------|------------------|
+| Card as link | Whole card is a single `<a>`/link element, not a div with a click handler |
+| Focus order | Cards in reading order (left to right, top to bottom), matching the visual grid |
+| Disabled cards | `aria-disabled`, with the reason available to screen readers, not just a visual dim |
+
+### Implementation
+
+#### Responsive Behaviour
+
+| Breakpoint | Card grid |
+|------------|------------|
+| Mobile | 1 column |
+| Tablet | 2 columns |
+| Desktop | 3-4 columns |
+
+## Best Practices
+
+### Do's
+
+1. **Make the whole card clickable** - Not just the title
+2. **Write descriptions that inform the choice** - Not filler text
+3. **Keep the grid flat** - Don't nest another hub behind a hub card unless unavoidable
+
+### Don'ts
+
+1. **Don't mix hub cards with task actions** - A hub orients; a dashboard KPI row asks for a decision. Keep them on separate pages
+2. **Don't hide restricted sections** - Show them disabled with a reason, so users understand the section exists
+
+### Common Mistakes
+
+| Mistake | Solution |
+|---------|----------|
+| Cards with no description | Add a one-line description of what's inside |
+| Inconsistent card heights | Fix a minimum height or truncate description consistently |
+| Hub leads to another hub leads to another hub | Flatten navigation; link deep sections directly from the sidebar instead |
+
+### Edge Cases
+
+| Case | Handling |
+|------|----------|
+| Single sub-page in a section | Consider skipping the hub and linking directly to it |
+| Very long list of sub-pages (20+) | Add search/filter above the grid, or group under sub-headings |
+
+## Examples
+
+A section hub is a card grid inside the same sidebar-navigation shell as [dashboard](./dashboard.md) and
+[browse and filter](./browse-and-filter.md) — only the main-content body differs: cards instead of KPIs
+or a table.
+
+## Related
+
+- [Product Design](../design.md) - Sidebar Navigation layout
+- [Detail page](./detail-page.md) - Where a hub card usually leads
+- [Accessibility foundations](../../../accessibility/accessibility.md) - Colour and contrast

package/agent-docs/external/kuat-agent-rules/reference/media-types/web-product/patterns/sign-in.md

@@ -156,7 +156,7 @@ Authentication pages should minimise distraction and focus users on the task.
 - Show requirements list below password field
 - Check/uncheck as requirements are met
 - Unmet: `text-muted-foreground`
-- Met: `text-green-600` with checkmark
+- Met: `text-success` with checkmark
 
 #### Password Reset Flow
 

package/agent-docs/manifest.json

@@ -1,8 +1,8 @@
 {
-  "packageVersion": "0.15.1",
+  "packageVersion": "0.15.2",
   "rules": {
-    "snapshotRef": "bdf7dafd019a6dadb8369bc4fd2d13964f6a111c",
-    "snapshotDate": "2026-07-14T12:19:21.257Z",
+    "snapshotRef": "2048d9c4b1951142ff4aba363a9d50917837796c",
+    "snapshotDate": "2026-07-15T11:15:23.609Z",
     "sourceRepo": "equalexperts/kuat-agent-docs",
     "loadingPath": "agent-docs/rules/LOADING-consumer.md"
   }

package/agent-docs/rules/LOADING-consumer.md

@@ -2,7 +2,7 @@
 
 **Package:** @equal-experts/kuat-core (and mirrored in kuat-react / kuat-vue agent-docs)
 
-**Snapshot:** bdf7dafd019a
+**Snapshot:** 2048d9c4b195
 
 ## Default load (web product / marketing UI)
 

package/dist/{AlertDialogTrigger.vue_vue_type_script_setup_true_lang-DosgAcSM.js → AlertDialogTrigger.vue_vue_type_script_setup_true_lang-Ccs_lGKx.js}

@@ -82,7 +82,7 @@ const G = /* @__PURE__ */ l({
       _: 3
     }));
   }
-}), Q = /* @__PURE__ */ _(E, [["__scopeId", "data-v-630d3e5f"]]), z = /* @__PURE__ */ l({
+}), Q = /* @__PURE__ */ _(E, [["__scopeId", "data-v-8ee0a42e"]]), z = /* @__PURE__ */ l({
   __name: "AlertDialogDescription",
   props: {
     asChild: { type: Boolean },

package/dist/alert-dialog.js

@@ -1,5 +1,5 @@
 import { c as l } from "./utils-DLUjLwnh.js";
-import { _ as r, A as t, a as i, b as g, c as s, d as A, e as D, f as c, g as n } from "./AlertDialogTrigger.vue_vue_type_script_setup_true_lang-DosgAcSM.js";
+import { _ as r, A as t, a as i, b as g, c as s, d as A, e as D, f as c, g as n } from "./AlertDialogTrigger.vue_vue_type_script_setup_true_lang-Ccs_lGKx.js";
 export {
   r as AlertDialog,
   t as AlertDialogAction,

package/dist/index.js

@@ -13,7 +13,7 @@ import { a as yo, I as Co, d as wo, c as Ao, b as To, i as $o } from "./index-lZ
 import { _ as Lo, a as xo, b as Ho, d as Vo, c as Do } from "./CarouselNext.vue_vue_type_script_setup_true_lang-BvnpmYmA.js";
 import { _ as Mo, a as Oo, b as Ro, d as No, c as Bo } from "./KuatCarouselNext.vue_vue_type_script_setup_true_lang-BnDrXaGV.js";
 import { _ as Uo, b as Fo, A as Go, a as Zo } from "./AccordionTrigger-BGVFRlgt.js";
-import { _ as qo, A as Wo, a as zo, b as Yo, c as Xo, d as jo, e as Jo, f as Qo, g as el } from "./AlertDialogTrigger.vue_vue_type_script_setup_true_lang-DosgAcSM.js";
+import { _ as qo, A as Wo, a as zo, b as Yo, c as Xo, d as jo, e as Jo, f as Qo, g as el } from "./AlertDialogTrigger.vue_vue_type_script_setup_true_lang-Ccs_lGKx.js";
 import { B as tl, b as sl } from "./index-DgHHiJiZ.js";
 import { b as ll, a as rl, S as nl, s as il } from "./index-DMDbjdfX.js";
 import { a as dl, b as cl, T as _l, t as hl } from "./index-BMnFWBPu.js";