haze-ui 1.24.1 → 1.26.0

package/dist/registry.json

@@ -0,0 +1,247 @@
+{
+  "$schema": "https://ui.shadcn.com/schema.json",
+  "name": "haze-ui",
+  "homepage": "https://github.com/wmzy/haze-ui",
+  "items": [
+    {
+      "name": "chat-message",
+      "type": "registry:component",
+      "title": "ChatMessage",
+      "description": "Chat bubble with role-based layout (user / assistant / system), avatar, name, timestamp and delivery status.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/chat-message.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { ChatMessage } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/chat-message.css';\n\nexport { ChatMessage };\nexport type { ChatMessageProps, ChatMessageRole } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "chat-container",
+      "type": "registry:component",
+      "title": "ChatContainer",
+      "description": "Chat transcript scroll container with stick-to-bottom auto-scroll.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/chat-container.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { ChatContainer } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/chat-container.css';\n\nexport { ChatContainer };\nexport type { ChatContainerProps } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "chat-input",
+      "type": "registry:component",
+      "title": "ChatInput",
+      "description": "Message composer with a controllable value and onSend callback.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/chat-input.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { ChatInput } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/chat-input.css';\n\nexport { ChatInput };\nexport type { ChatInputProps } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "streaming-text",
+      "type": "registry:component",
+      "title": "StreamingText",
+      "description": "Typewriter effect that reveals streaming text character by character, with an optional cursor.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/streaming-text.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { StreamingText } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/streaming-text.css';\n\nexport { StreamingText };\nexport type { StreamingTextProps } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "markdown-renderer",
+      "type": "registry:component",
+      "title": "MarkdownRenderer",
+      "description": "Renders markdown content (including code blocks) for assistant responses.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/markdown-renderer.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { MarkdownRenderer } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/markdown-renderer.css';\n\nexport { MarkdownRenderer };\nexport type { MarkdownRendererProps } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "tool-call-card",
+      "type": "registry:component",
+      "title": "ToolCallCard",
+      "description": "Card presenting an agent tool call — name, input, output and running state.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/tool-call-card.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { ToolCallCard } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/tool-call-card.css';\n\nexport { ToolCallCard };\nexport type { ToolCallCardProps, ToolCallStatus } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "thinking-indicator",
+      "type": "registry:component",
+      "title": "ThinkingIndicator",
+      "description": "Animated bouncing-dots indicator that the agent is processing.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/thinking-indicator.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { ThinkingIndicator } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/thinking-indicator.css';\n\nexport { ThinkingIndicator };\nexport type { ThinkingIndicatorProps } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "step-timeline",
+      "type": "registry:component",
+      "title": "StepTimeline / StepTimelineItem",
+      "description": "Vertical timeline of agent execution steps with per-step status.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/step-timeline.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { StepTimeline, StepTimelineItem } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/step-timeline.css';\n\nexport { StepTimeline, StepTimelineItem };\nexport type { StepTimelineProps, StepTimelineItemProps, StepStatus } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "approval-card",
+      "type": "registry:component",
+      "title": "ApprovalCard",
+      "description": "Approval gate with approve / deny actions for agent-initiated operations.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/approval-card.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { ApprovalCard } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/approval-card.css';\n\nexport { ApprovalCard };\nexport type { ApprovalCardProps } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "token-counter",
+      "type": "registry:component",
+      "title": "TokenCounter",
+      "description": "Context-window token usage counter with budget progress.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/token-counter.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { TokenCounter } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/token-counter.css';\n\nexport { TokenCounter };\nexport type { TokenCounterProps } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "model-picker",
+      "type": "registry:component",
+      "title": "ModelPicker",
+      "description": "Controllable dropdown for selecting the active model.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/model-picker.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { ModelPicker } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/model-picker.css';\n\nexport { ModelPicker };\nexport type { ModelPickerProps, ModelOption } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "conversation-list",
+      "type": "registry:component",
+      "title": "ConversationList / ConversationItem",
+      "description": "Selectable list of conversations for a chat-history sidebar.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/conversation-list.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { ConversationList, ConversationItem } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/conversation-list.css';\n\nexport { ConversationList, ConversationItem };\nexport type { ConversationListProps, ConversationItemProps } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "diff-viewer",
+      "type": "registry:component",
+      "title": "DiffViewer",
+      "description": "Renders the line diff between old and new content for agent-proposed edits.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/diff-viewer.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { DiffViewer } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/diff-viewer.css';\n\nexport { DiffViewer };\nexport type { DiffViewerProps, DiffLine } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "log-viewer",
+      "type": "registry:component",
+      "title": "LogViewer",
+      "description": "Scrollable log stream with severity-level filtering.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/log-viewer.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { LogViewer } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/log-viewer.css';\n\nexport { LogViewer };\nexport type { LogViewerProps, LogEntry, LogLevel } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    },
+    {
+      "name": "async-section",
+      "type": "registry:component",
+      "title": "AsyncSection",
+      "description": "Declarative loading / error / content states for async data.",
+      "dependencies": [
+        "haze-ui"
+      ],
+      "files": [
+        {
+          "path": "components/haze/async-section.tsx",
+          "content": "// haze-ui agent component wrapper — generated by scripts/generate-registry.mjs.\n//\n// This file deliberately contains no component source: haze-ui is compiled\n// CSS-in-JS (linaria) styled against --haze-* design tokens, so vendoring\n// the source would neither build nor style. It re-exports the published\n// component and imports its stylesheet instead — treat this file as your\n// customization layer (wrap, restyle, compose) while haze-ui stays an npm\n// dependency and keeps updating underneath.\n//\n// Theming (once per app): apply the token classes to a root element, e.g.\n//   import { lightTheme, spacing, typography } from 'haze-ui';\n//   <div className={`${lightTheme} ${spacing} ${typography}`}>…</div>\n// (darkTheme is a drop-in swap). haze-ui dist modules ship their own\n// 'use client' directive, so imports resolve cleanly from RSC; the\n// wrapper inherits client semantics either way.\n\nimport { AsyncSection } from 'haze-ui';\n\nimport 'haze-ui/css/tokens.css';\nimport 'haze-ui/css/async-section.css';\n\nexport { AsyncSection };\nexport type { AsyncSectionProps } from 'haze-ui';\n",
+          "type": "registry:component"
+        }
+      ]
+    }
+  ]
+}

package/dist/tokens/colors.js

@@ -1,4 +1,5 @@
 
+"use client";
 /* empty css                 */
 //#region src/lib/tokens/colors.ts
 var e = "haze-colors__lightTheme", t = "haze-colors__darkTheme";

package/dist/tokens/index.js

@@ -1,3 +1,4 @@
+"use client";
 import { darkTheme as e, lightTheme as t } from "./colors.js";
 import { spacing as n } from "./spacing.js";
 import { typography as r } from "./typography.js";

package/dist/tokens/motion.js

@@ -1,4 +1,5 @@
 
+"use client";
 /* empty css                 */
 //#region src/lib/tokens/motion.ts
 var e = "haze-motion__motion";

package/dist/tokens/oklch.js

@@ -1,3 +1,4 @@
+"use client";
 function e(e) {
 	return e <= .04045 ? e / 12.92 : ((e + .055) / 1.055) ** 2.4;
 }

package/dist/tokens/palette.js

@@ -1,3 +1,4 @@
+"use client";
 import { clampChroma as e, formatOklch as t, parseHex as n, parseOklch as r } from "./oklch.js";
 //#region src/lib/tokens/palette.ts
 var i = {

package/dist/tokens/registry.js

@@ -1,3 +1,4 @@
+"use client";
 import { formatOklch as e } from "./oklch.js";
 import { SEMANTIC_COLOR_TOKENS as t } from "./palette.js";
 //#region src/lib/tokens/registry.ts

package/dist/tokens/spacing.js

@@ -1,4 +1,5 @@
 
+"use client";
 /* empty css                  */
 //#region src/lib/tokens/spacing.ts
 var e = "haze-spacing__spacing";

package/dist/tokens/typography.js

@@ -1,4 +1,5 @@
 
+"use client";
 /* empty css                     */
 //#region src/lib/tokens/typography.ts
 var e = "haze-typography__typography";

package/dist/types/components/AvatarGroup/AvatarGroup.d.ts

@@ -0,0 +1,9 @@
+import type { ComponentPropsWithoutRef } from 'react';
+type AvatarGroupProps = {
+    /** Maximum number of avatars rendered before the "+N" overflow chip. */
+    max?: number;
+    /** Overflow count to display instead of children count - max when truncating. */
+    total?: number;
+} & ComponentPropsWithoutRef<'div'>;
+export default function AvatarGroup({ max, total, className, children, ...rest }: AvatarGroupProps): import("react").JSX.Element;
+export type { AvatarGroupProps };

package/dist/types/components/AvatarGroup/index.d.ts

@@ -0,0 +1,2 @@
+export { default as AvatarGroup } from './AvatarGroup';
+export type { AvatarGroupProps } from './AvatarGroup';

package/dist/types/components/Calendar/Calendar.d.ts

@@ -0,0 +1,21 @@
+import type { ComponentPropsWithoutRef } from 'react';
+import type { ControlOrValue } from 'react-use-control';
+type CalendarProps = {
+    /** Selected date as "YYYY-MM-DD"; empty string means nothing selected. */
+    value?: ControlOrValue<string>;
+    /** Earliest selectable date ("YYYY-MM-DD"). */
+    min?: string;
+    /** Latest selectable date ("YYYY-MM-DD"). */
+    max?: string;
+    /** BCP 47 locale used for month and weekday formatting. */
+    locale?: string;
+    /** Explicit first day of the week: 0 = Sunday, 1 = Monday. */
+    weekStartsOn?: 0 | 1;
+    /**
+     * Called with the picked "YYYY-MM-DD" date. Still fires alongside the
+     * controllable `value` for callers that prefer event-style wiring.
+     */
+    onSelect?: (date: string) => void;
+} & Omit<ComponentPropsWithoutRef<'div'>, 'onSelect'>;
+export default function Calendar({ value: valueControl, min, max, locale, weekStartsOn, onSelect, className, ...rest }: CalendarProps): import("react").JSX.Element;
+export type { CalendarProps };

package/dist/types/components/Calendar/date.d.ts

@@ -0,0 +1,79 @@
+/**
+ * Pure calendar-date math for the Calendar grid, extracted from Calendar.tsx.
+ *
+ * Semantics — naive local civil time:
+ *
+ * - Every `(year, month, day)` triple denotes a civil calendar date realized
+ *   as a *local* Date at midnight via `new Date(year, month, day)`. The UTC
+ *   constructor (`new Date(Date.UTC(…))`) is deliberately never used, and
+ *   `new Date('YYYY-MM-DD')` — which parses as UTC midnight and therefore
+ *   shifts a day in zones behind UTC — is never a source of truth here.
+ * - DST transitions move wall-clock hours (typically 02:00/03:00), never
+ *   midnight, so constructing a local midnight and reading back
+ *   `getFullYear`/`getMonth`/`getDate` round-trips exactly even on
+ *   spring-forward and fall-back days.
+ * - Months are 0-based (`Date#getMonth` semantics: 0 = January, 11 =
+ *   December). All functions are pure: they only read the local zone to
+ *   query weekdays of civil dates they constructed themselves, and never
+ *   normalize dates through out-of-range days (the classic
+ *   `new Date(y, m + 1, 31)` rollover hazard).
+ */
+/** One cell of the Calendar grid; `outside` marks days of adjacent months. */
+export type CalendarCell = {
+    day: number;
+    month: number;
+    year: number;
+    outside: boolean;
+};
+/**
+ * Number of days in a month, via day 0 of the following month
+ * (`new Date(year, month + 1, 0).getDate()`). Out-of-range months
+ * normalize through the Date constructor, so `month` may be `-1` or `12`
+ * and still yields the true length of the adjacent month.
+ */
+export declare function getDaysInMonth(year: number, month: number): number;
+/**
+ * Shift a `(year, month)` view by `delta` months with year carry, e.g.
+ * `(2026, 11) + 1 → { year: 2027, month: 0 }`. Pure integer arithmetic on
+ * the month index — no Date is constructed, so navigating from a long month
+ * into a short one (Jan 31 → February) can never roll a phantom day 29–31
+ * over into the next month the way `new Date(y, m + 1, 31)` would.
+ */
+export declare function addMonths(year: number, month: number, delta: number): {
+    year: number;
+    month: number;
+};
+/**
+ * Number of leading cells (previous-month days) before day 1 of the month,
+ * for a grid whose first column is `weekStart` (`Date#getDay` semantics:
+ * 0 = Sunday, 1 = Monday). The weekday of day 1 is read from the
+ * local-midnight Date of that civil date; DST never moves midnight, so the
+ * offset is stable across transitions.
+ */
+export declare function getLeadingDays(year: number, month: number, weekStart: number): number;
+/**
+ * Flat list of grid cells for one month view: `getLeadingDays` previous-month
+ * days, then every day of the month itself, then just enough next-month days
+ * to complete the final week row. When the month already fills its rows
+ * exactly (e.g. a Sunday-first February with 28 days), no padding row is
+ * added. The result length is always a multiple of 7.
+ */
+export declare function buildMonthCells(year: number, month: number, weekStart: number): CalendarCell[];
+/**
+ * Format a civil date as the `"YYYY-MM-DD"` string Calendar uses as its
+ * value. Value semantics: the string denotes the **local** civil date — it
+ * is a plain calendar date, not a UTC timestamp (parsing it with
+ * `new Date('YYYY-MM-DD')` yields UTC midnight and shifts a day in zones
+ * behind UTC). Pure string math; no Date construction.
+ */
+export declare function formatDate(year: number, month: number, day: number): string;
+/**
+ * Parse a `"YYYY-MM-DD"` value string into a local-midnight Date — the
+ * inverse of {@link formatDate} and the only safe way to turn a value into
+ * a Date (`new Date('YYYY-MM-DD')` parses as UTC midnight and shifts a
+ * day in zones behind UTC, e.g. `'2026-03-01'` lands on local Feb 28 in
+ * America/New_York). Returns `null` for anything that is not a real
+ * calendar date (`'2026-02-30'`, `'2026-13-01'`, malformed input),
+ * leaving the caller free to fall back to today.
+ */
+export declare function parseCivilDate(value: string): Date | null;

package/dist/types/components/Calendar/index.d.ts

@@ -0,0 +1,2 @@
+export { default as Calendar } from './Calendar';
+export type { CalendarProps } from './Calendar';

package/dist/types/components/Cascader/Cascader.d.ts

@@ -0,0 +1,26 @@
+import type { ComponentPropsWithoutRef, ReactNode } from 'react';
+import type { ControlOrValue } from 'react-use-control';
+export type CascaderOption = {
+    label: ReactNode;
+    value: string;
+    children?: CascaderOption[];
+};
+type CascaderProps = {
+    /** Full option tree; each level becomes one column in the drill-down panel. */
+    options: CascaderOption[];
+    /** Selected path as an array of option values, one per level. */
+    value?: ControlOrValue<string[]>;
+    /** Fired with the committed path whenever a selection is made. */
+    onChange?: (value: string[]) => void;
+    placeholder?: string;
+    /**
+     * `false` (default): only leaf options commit a value. `true`: every level
+     * commits its partial path the moment it is chosen (Ant Design semantics).
+     */
+    changeOnSelect?: boolean;
+    /** Whether hovering a parent option expands its column; defaults to click. */
+    expandTrigger?: 'click' | 'hover';
+    className?: string;
+} & Omit<ComponentPropsWithoutRef<'div'>, 'onChange' | 'className'>;
+export default function Cascader({ options, value: valueControl, onChange, placeholder, changeOnSelect, expandTrigger, className, ...rest }: CascaderProps): import("react").JSX.Element;
+export type { CascaderProps };

package/dist/types/components/Cascader/index.d.ts

@@ -0,0 +1,2 @@
+export { default as Cascader } from './Cascader';
+export type { CascaderProps, CascaderOption } from './Cascader';

package/dist/types/components/Combobox/Combobox.d.ts

@@ -7,7 +7,13 @@ type ComboboxProps = {
         label: string;
     }[];
     placeholder?: string;
+    /**
+     * Render the dropdown through VirtualList once the filtered list is
+     * longer than this many options. Defaults to 100; 0 disables
+     * virtualization entirely (plain DOM rendering at any length).
+     */
+    virtualThreshold?: number;
     className?: string;
 };
-export default function Combobox({ value: valueControl, open: openControl, options, placeholder, className, }: ComboboxProps): import("react").JSX.Element;
+export default function Combobox({ value: valueControl, open: openControl, options, placeholder, virtualThreshold, className, }: ComboboxProps): import("react").JSX.Element;
 export type { ComboboxProps };

package/dist/types/components/Combobox/ComboboxOption.d.ts

@@ -3,9 +3,21 @@ type ComboboxOptionProps = {
     value: string;
     highlighted?: boolean;
     selected?: boolean;
+    /**
+     * DOM id of this option — what the combobox input points at via
+     * aria-activedescendant while the row holds the keyboard highlight.
+     */
+    id?: string;
+    /**
+     * Size of the whole option set, per aria-setsize. Must count every
+     * option, not just the rows a windowed (virtualized) list mounted.
+     */
+    setSize?: number;
+    /** 1-based position of this option in the set, per aria-posinset. */
+    posInSet?: number;
     onSelect?: (value: string) => void;
     className?: string;
     children: ReactNode;
 };
-export default function ComboboxOption({ value, highlighted, selected, onSelect, className, children, }: ComboboxOptionProps): import("react").JSX.Element;
+export default function ComboboxOption({ value, highlighted, selected, id, setSize, posInSet, onSelect, className, children, }: ComboboxOptionProps): import("react").JSX.Element;
 export type { ComboboxOptionProps };

package/dist/types/components/DataTable/DataTable.d.ts

@@ -0,0 +1,102 @@
+import type { ComponentPropsWithoutRef, MouseEvent, ReactNode } from 'react';
+import type { ControlOrValue } from 'react-use-control';
+import type { ColumnDef, RowData, RowSelectionState, SortingState } from '@tanstack/react-table';
+/** Per-column metadata understood by DataTable. */
+type DataTableColumnMeta = {
+    /** Column-level sorting switch — overrides the table-level `sortable` default. */
+    sortable?: boolean;
+};
+/** Windowing configuration for the table body, reusing `VirtualList`. */
+type DataTableVirtualized = boolean | {
+    /** Fixed row height in px — must match the rendered row (custom cell
+     * padding or multi-line content need this form). */
+    rowHeight: number;
+    /** Extra rows kept mounted above/below the visible window.
+     * Defaults to `VirtualList`'s `5`. */
+    overscan?: number;
+};
+/** The feature set stitched into every DataTable instance — TanStack v9's
+ * tree-shaking contract: only the row models and registries the component
+ * actually drives are registered. `columnMeta` is a type-only slot that
+ * types `meta` on column definitions. */
+declare const dataTableFeatures: {
+    rowPaginationFeature: import("@tanstack/react-table").TableFeature;
+    paginatedRowModel: (table: import("@tanstack/react-table").Table<any, any>) => () => import("@tanstack/react-table").RowModel<any, any>;
+    rowSelectionFeature: import("@tanstack/react-table").TableFeature;
+    rowSortingFeature: import("@tanstack/react-table").TableFeature;
+    sortedRowModel: (table: import("@tanstack/react-table").Table<any, any>) => () => import("@tanstack/react-table").RowModel<any, any>;
+    sortFns: {
+        alphanumeric: import("@tanstack/react-table").CreatedSortFn<any, any>;
+        text: import("@tanstack/react-table").CreatedSortFn<any, any>;
+    };
+    columnMeta: DataTableColumnMeta;
+};
+/** Column definition accepted by DataTable — a TanStack Table column def
+ * bound to DataTable's feature set and column meta. */
+type DataTableColumnDef<TData extends RowData> = ColumnDef<typeof dataTableFeatures, TData>;
+type DataTableProps<TData extends RowData> = {
+    /** Column definitions: accessors, headers and cell templates. */
+    columns: DataTableColumnDef<TData>[];
+    /** Row data — one item per row. */
+    data: TData[];
+    /** Enable click-to-sort headers. Defaults to `false`; per-column
+     * `meta.sortable` (or native `enableSorting`) overrides per column. */
+    sortable?: boolean;
+    /** Render a leading checkbox column bound to `rowSelection`. */
+    selectable?: boolean;
+    /** Selection state keyed by row id (TanStack `RowSelectionState`). */
+    rowSelection?: ControlOrValue<RowSelectionState>;
+    /** Sort state (TanStack `SortingState`). */
+    sorting?: ControlOrValue<SortingState>;
+    /** Rows per page. Setting this enables the pagination footer. */
+    pageSize?: number;
+    /** Current page, 1-based, when paginating. */
+    page?: ControlOrValue<number>;
+    /** Render skeleton rows instead of data. */
+    loading?: boolean;
+    /** Keep the header visible while the table body scrolls. */
+    stickyHeader?: boolean;
+    /**
+     * Window the table body so only rows near the viewport stay mounted,
+     * reusing the library's `VirtualList`. `true` uses the default row
+     * height; an object pins it explicitly (plus an optional `overscan`,
+     * default 5).
+     *
+     * The default height is `34px` — the natural single-line row of the
+     * default cell styles: 2 × `--haze-space-2` padding (16px) + a 14px
+     * (`--haze-text-sm`) line box + the 1px row border.
+     *
+     * Limitations and tradeoffs (evaluated against keeping `<tr>`s in one
+     * shared table): `VirtualList` positions rows through absolutely
+     * positioned `div` wrappers, and `position: absolute` blockifies
+     * `display: table-row` — so rows cannot stay in the header's table.
+     * Instead each row renders as a complete sibling `<table><tbody><tr>`
+     * inside the wrapper. Rows remain legal, axe-clean table structures
+     * with row/cell roles, and `table-layout: fixed` on header and rows
+     * distributes columns equally in both, keeping them aligned without a
+     * column-width measurement pass. Consequences:
+     * - Fixed row height only — dynamic or wrapping row heights are not
+     *   supported; content taller than `rowHeight` overlaps the next row.
+     * - Columns distribute equally instead of auto-sizing to content;
+     *   per-column widths are not supported in this mode.
+     * - The header sits outside the scroll window (always visible) — the
+     *   `stickyHeader` behavior is implied.
+     * - The root must be height-bounded by the consumer (e.g. a
+     *   `className` setting `height`/`max-height`, or a sized flex
+     *   parent); unbounded, the viewport degenerates to a single row.
+     * - Sorting, selection, pagination and `getRowId` semantics are
+     *   unchanged — the window always shows the post-sort, post-page slice.
+     */
+    virtualized?: DataTableVirtualized;
+    /** Stable row identity; also keys the `rowSelection` state. Defaults to
+     * the row's index. */
+    getRowId?: (row: TData, index: number) => string;
+    /** Row click handler. Clicks originating in interactive cell content
+     * (checkboxes, buttons, links) are ignored. */
+    onRowClick?: (row: TData, event: MouseEvent<HTMLTableRowElement>) => void;
+    /** Custom empty-state node; defaults to the `Empty` component. */
+    empty?: ReactNode;
+    className?: string;
+} & Omit<ComponentPropsWithoutRef<'table'>, 'children'>;
+export default function DataTable<TData extends RowData>({ columns, data, sortable, selectable, rowSelection: rowSelectionControl, sorting: sortingControl, pageSize, page: pageControl, loading, stickyHeader, virtualized, getRowId, onRowClick, empty, className, ...rest }: DataTableProps<TData>): import("react").JSX.Element;
+export type { DataTableProps, DataTableColumnDef, DataTableColumnMeta, DataTableVirtualized, };

package/dist/types/components/DataTable/index.d.ts

@@ -0,0 +1,2 @@
+export { default as DataTable } from './DataTable';
+export type { DataTableProps, DataTableColumnDef, DataTableColumnMeta, DataTableVirtualized, } from './DataTable';

package/dist/types/components/Datepicker/Datepicker.d.ts

@@ -4,8 +4,10 @@ type DatepickerProps = {
     open?: ControlOrValue<boolean>;
     min?: string;
     max?: string;
+    locale?: string;
+    weekStartsOn?: 0 | 1;
     placeholder?: string;
     className?: string;
 };
-export default function Datepicker({ value: valueControl, open: openControl, min, max, placeholder, className, }: DatepickerProps): import("react").JSX.Element;
+export default function Datepicker({ value: valueControl, open: openControl, min, max, locale, weekStartsOn, placeholder, className, }: DatepickerProps): import("react").JSX.Element;
 export type { DatepickerProps };