@sesamehr/react-design-system 2.0.0-beta.2 → 2.0.0-beta.21

package/dist/Forms/Inputs/DatePicker/month.d.ts

@@ -0,0 +1,28 @@
+/**
+ * Month arithmetic the header and its two selectors all need. Mirrors
+ * `@sesame/orxata-core` `DatePicker/month.ts`.
+ *
+ * Shared rather than repeated because the comparison has to be the same one
+ * `Calendar` makes: bounds are read by month, so a `from` set mid-month does
+ * not hide the month it sits in.
+ */
+/** Months since year zero, so two months compare as two numbers. */
+export declare const monthIndex: (date: Date) => number;
+/** The first day of the month `offsetInMonths` away from `date`. */
+export declare const monthOf: (date: Date, offsetInMonths?: number) => Date;
+/**
+ * How far the year selector reaches when nothing bounds it.
+ *
+ * A birth year is the case that makes a year selector worth having at all, so
+ * the window has to be deep enough to hold one; forward it only has to cover
+ * the scheduling a caller who set no bounds could plausibly want. Both are
+ * defaults a caller overrides by passing `constraints`, which is the only
+ * statement about reachable dates this package will believe.
+ */
+export declare const YEARS_BACK = 100;
+export declare const YEARS_FORWARD = 10;
+/** The inclusive year range the year selector offers. */
+export declare const yearRange: (visible: Date, from?: Date, to?: Date) => {
+    first: number;
+    last: number;
+};

package/dist/Forms/Inputs/DatePicker/useDatePickerHeader.d.ts

@@ -0,0 +1,23 @@
+import { CalendarConstraints } from '../Calendar/constraints.ts';
+import { CalendarNav } from '../Calendar/nav.ts';
+/**
+ * What `DatePickerHeader` publishes to whatever is put inside it. Mirrors
+ * `@sesame/orxata-core` `useDatePickerHeader`.
+ *
+ * The two selectors need the visible month, a way to jump to another one, and
+ * the bounds that say which months exist — the same three things the header
+ * itself is given. Passing them down as props would be prop drilling through
+ * `children`, and would put `nav` on the public API of every part.
+ */
+export interface DatePickerHeaderContextValue {
+    nav: CalendarNav;
+    constraints?: CalendarConstraints;
+}
+export declare const DatePickerHeaderContext: import('react').Context<DatePickerHeaderContextValue | null>;
+/**
+ * The message is spelled identically in `@sesame/orxata-core`. A part that
+ * escapes its header is the same mistake in both packages, and a developer who
+ * meets it twice should not have to recognise two wordings of it.
+ */
+export declare const DATE_PICKER_HEADER_MISSING = "OxDatePickerMonthSelect and OxDatePickerYearSelect must be rendered inside OxDatePickerHeader.";
+export declare const useDatePickerHeader: () => DatePickerHeaderContextValue;

package/dist/Forms/Inputs/InputOtp/InputOtp.d.ts

@@ -5,5 +5,12 @@ import { InputOtpProps } from './types.ts';
  * Radix ships no PinInput, so the behaviour lives here — focus advance,
  * backspace, arrow keys, paste spreading, per-slot labels — and reaches the
  * slots through context. One `<input>` per slot.
+ *
+ * `role="group"` is here unconditionally, not just inside a field. A bare
+ * `<div>` cannot take a name from the author — so without the role the slots
+ * announce as anonymous text fields and the `aria-labelledby` below would be
+ * dropped on the floor. Outside an `<OxFieldGroup>` the group has no name,
+ * which is correct: the design system ships no strings, so there is nothing to
+ * call it.
  */
 export declare const InputOtp: import('react').ForwardRefExoticComponent<InputOtpProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/InputPassword/InputPassword.d.ts

@@ -15,6 +15,14 @@ export interface InputPasswordProps extends Omit<React.HTMLAttributes<HTMLDivEle
  * InputPassword root — mirrors `@sesame/orxata-core` InputPassword.
  * Provides the value and clear-text state to `InputPasswordInput` and
  * `InputPasswordToggle` through context.
- * Both `field` and `visible` work controlled or uncontrolled.
+ *
+ * Both `field` and `visible` work controlled or uncontrolled, and which one
+ * you get depends on **whether the change handler is there, not whether the
+ * value is**. The Vue original is a pair of `defineModel`s, and a
+ * `defineModel` given a value but no listener keeps driving itself. Gate on
+ * the value alone and `visible={false}` — a perfectly ordinary way to say
+ * "start hidden" — turns the reveal toggle into a dead button: `toggle()`
+ * computes the next state, declines to store it because the prop is present,
+ * and calls a handler nobody passed.
  */
 export declare const InputPassword: import('react').ForwardRefExoticComponent<InputPasswordProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/InputText/InputText.d.ts

@@ -12,5 +12,14 @@ export interface InputTextProps extends Omit<React.InputHTMLAttributes<HTMLInput
  * `field` + `onFieldChange` are the controlled pair; native `value`/`onChange`
  * still pass through via `...props` for anyone who prefers them. `type`
  * defaults to `'text'`, and a `type` passed by the caller wins.
+ *
+ * **`field` alone does not mean "controlled" — `field` *with* `onFieldChange`
+ * does.** The Vue original is a `defineModel`, and a `defineModel` only hands
+ * control to the parent when the parent actually listens; given a value and no
+ * listener it seeds its own state and goes on working. Port `field` as
+ * unconditionally controlled and that same usage becomes an input pinned to
+ * its initial value with nothing able to change it — one that silently will
+ * not accept a keystroke. Which is exactly what `<OxInputText field="" />`
+ * did, in the story and in any app that wrote it.
  */
 export declare const InputText: import('react').ForwardRefExoticComponent<InputTextProps & import('react').RefAttributes<HTMLInputElement>>;

package/dist/Forms/Inputs/SearchBar/SearchBar.d.ts

@@ -0,0 +1,35 @@
+import { SearchBarVariants } from './index.ts';
+export interface SearchBarProps extends Omit<React.InputHTMLAttributes<HTMLInputElement>, 'size' | 'type' | 'value' | 'defaultValue'> {
+    variant?: SearchBarVariants['variant'];
+    size?: SearchBarVariants['size'];
+    /**
+     * Milliseconds of no typing before `onSearch` fires. `0` fires on every
+     * keystroke.
+     */
+    debounce?: number;
+    /** Controlled term. Pair with `onValueChange`; omit for uncontrolled. */
+    value?: string;
+    /** Starting term when uncontrolled. */
+    defaultValue?: string;
+    /** Called on every keystroke with the next term, without waiting. */
+    onValueChange?: (value: string) => void;
+    /** Called once typing has been quiet for `debounce` ms — and at once on Enter or clear. */
+    onSearch?: (term: string) => void;
+    dataTestid: string;
+}
+/**
+ * A search field: magnifier, term, and a clear button once there is something
+ * to clear. Mirrors `@sesame/orxata-core` SearchBar.
+ *
+ * Written on a native `<input type="search">` rather than on a primitive
+ * because there is no primitive to start from — Radix has no search component,
+ * and shadcn's own `Input` is a bare element too. Nothing here needs what a
+ * primitive would bring: no portal, no focus trap, no escape handling. The one
+ * browser affordance it *does* bring — WebKit's built-in cancel button — is
+ * turned off in the stylesheet, since we draw our own.
+ *
+ * `className` lands on the root, which is the box; everything else a native
+ * `<input>` takes — `placeholder`, `name`, `disabled`, `aria-label` — falls
+ * through to the control. The `ref` is the root for the same reason.
+ */
+export declare const SearchBar: import('react').ForwardRefExoticComponent<SearchBarProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/SearchBar/index.d.ts

@@ -0,0 +1,20 @@
+import { VariantProps } from 'class-variance-authority';
+export { SearchBar } from './SearchBar.tsx';
+export type { SearchBarProps } from './SearchBar.tsx';
+/**
+ * Class names, not utilities — see `Button/index.ts` for why the package
+ * cannot publish `.h-10` and `.rounded-lg` of its own. `SearchBar.module.css`
+ * gives each of these names its declarations, and `moduleClasses` does the
+ * lookup.
+ *
+ * Only two axes here. Figma models a third, `State`, with `Default | Focus |
+ * Filled`, and none of it belongs in a prop: focus is `:focus-within` and
+ * filled is "the input has a value". Both are things the component can see for
+ * itself, and a `state` prop would be asking the caller to keep telling it
+ * something it already knows — wrong the moment the two disagree.
+ */
+export declare const searchBarVariants: (props?: ({
+    variant?: "default" | "ghost" | null | undefined;
+    size?: "sm" | "md" | null | undefined;
+} & import('class-variance-authority/types').ClassProp) | undefined) => string;
+export type SearchBarVariants = VariantProps<typeof searchBarVariants>;

package/dist/Forms/Inputs/SearchPanel/SearchPanel.d.ts

@@ -0,0 +1,71 @@
+import { Command } from 'cmdk';
+export interface SearchPanelProps extends Omit<React.ComponentPropsWithoutRef<typeof Command>, 'value' | 'onValueChange' | 'onSelect'> {
+    /** A row was chosen — by click or by Enter. Carries that row's `value`. */
+    onSelect?: (value: string) => void;
+    /** Escape was pressed. What closing means is the caller's to decide. */
+    onClose?: () => void;
+    dataTestid: string;
+}
+/**
+ * A panel of search results, grouped under headings — the command-palette
+ * pattern. Choosing a row runs something: it navigates, opens a document, or
+ * fires an action.
+ *
+ * Named for what it is rather than what it shows. It was `SearchResults`, which
+ * described the one thing it does not do: it does not search, does not filter
+ * and produces no results — the caller supplies the rows. What it *is* is the
+ * surface searching happens on, a field above a grouped list, and `SearchPanel`
+ * promises nothing it cannot keep.
+ *
+ * `Menu` was the other candidate and is wrong for a reason worth writing down:
+ * in ARIA a `menu` is application commands with their own keyboard model, and
+ * this is a `listbox`. A component called `Menu` that renders `role="listbox"`
+ * invites the next reader to resolve the mismatch in the wrong direction.
+ *
+ * **This card is the field, and nothing else.** Collapsed it is exactly the
+ * search row with the same air above it as below; the results are not in it.
+ * `SearchPanelList` draws its own card and floats it over the page, tethered
+ * to this one — so a result arriving moves nothing below the panel, which is
+ * the whole reason a global search can live in a header. See that file for how
+ * the two are made to read as one surface.
+ *
+ * `Popover.Root` is pinned open and holds no state: the caller decides whether
+ * the list renders at all, so there is no second open state here. What it is
+ * for is the anchor — the card below is the box the list positions itself
+ * against, flips away from and takes its width from.
+ *
+ * **The list brings its own motion**, because the popper gives it a
+ * `data-state` and the shared surface animates on that. Do not wrap it in an
+ * `OxTransition*`: those animate a box growing in the flow, which is the
+ * behaviour this component was changed to stop, and their enter class would be
+ * competing with the surface's own keyframe for the `animation` property.
+ *
+ * Deliberately not a `Combobox`. A combobox's model is "pick a value, the
+ * field then shows it", which is wrong here twice over — the search box must
+ * keep the words the user typed, and a row that ran an action is not a value
+ * anything holds afterwards. Bending a combobox to this shape means clearing
+ * the value after every pick and suppressing the selected state, and the bug
+ * that arrives three months later is the one where a stale selection survives
+ * a reset. shadcn keeps `Command` apart from `Combobox` for the same reason.
+ *
+ * So this root reports `onSelect` and holds nothing. cmdk's own `value` is the
+ * *highlight*, not a selection, which is exactly the model wanted: no row is
+ * ever checked and no row draws a check.
+ *
+ * `shouldFilter` is off. The caller already has the term — `OxSearchBar` owns
+ * the debounce — and whether a result matches is a question about their data,
+ * not about the strings in the DOM.
+ *
+ * The component knows nothing about what is in it. The headings, the icons and
+ * the row contents are all `children`: a caller listing employees with avatars
+ * and files with sizes needs nothing here to change. The categories in the
+ * stories are one application's, not this package's.
+ *
+ * The keyboard comes from cmdk: arrows and Home/End move the highlight while
+ * focus stays in the search field, Enter runs the highlighted row, and
+ * `aria-activedescendant` keeps a screen reader in step. Focusing the field
+ * highlights the first row, so Enter on a fresh panel runs the top hit without
+ * arrowing to it — which also means the first arrow press moves to the
+ * *second* row. Escape is cmdk's one gap and is handled here.
+ */
+export declare const SearchPanel: import('react').ForwardRefExoticComponent<SearchPanelProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/SearchPanel/SearchPanelEmpty.d.ts

@@ -0,0 +1,16 @@
+export type SearchPanelEmptyProps = React.ComponentPropsWithoutRef<'div'>;
+/**
+ * Shown in place of the rows when a search found nothing.
+ *
+ * No default text. "No results found" is English, and which of the caller's
+ * words belong here — and in which language — is not this package's to guess;
+ * `OxComboboxEmpty` carries one for backwards compatibility and that is the
+ * exception, not the pattern. Rendering is the caller's condition too: only
+ * they know whether an empty list means "nothing matched" or "nothing typed
+ * yet".
+ *
+ * Deliberately not cmdk's `CommandEmpty`, which decides for itself when to
+ * appear by counting the items its own filter left — and this panel's filter
+ * is the caller's.
+ */
+export declare const SearchPanelEmpty: import('react').ForwardRefExoticComponent<Omit<import('react').DetailedHTMLProps<import('react').HTMLAttributes<HTMLDivElement>, HTMLDivElement>, "ref"> & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/SearchPanel/SearchPanelGroup.d.ts

@@ -0,0 +1,14 @@
+import { CommandGroup } from 'cmdk';
+export interface SearchPanelGroupProps extends React.ComponentPropsWithoutRef<typeof CommandGroup> {
+    /** The heading above the rows. Anything renderable, and always the caller's. */
+    label?: React.ReactNode;
+}
+/**
+ * A heading and the rows under it.
+ *
+ * Nothing here knows what the heading might say. "Documents", "Recent
+ * conversations", "People" are one application's categories on one day; a
+ * design system that shipped an enum of them would be wrong by the following
+ * release, and wrong for every other application immediately.
+ */
+export declare const SearchPanelGroup: import('react').ForwardRefExoticComponent<SearchPanelGroupProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/SearchPanel/SearchPanelInput.d.ts

@@ -0,0 +1,31 @@
+import { CommandInput } from 'cmdk';
+export type SearchPanelInputProps = Omit<React.ComponentPropsWithoutRef<typeof CommandInput>, 'asChild'>;
+/**
+ * Joins the caller's search field to the list's keyboard.
+ *
+ * Put exactly one control inside — `OxSearchBar` is the intended one, since it
+ * already owns the debounce. `asChild` hands it the arrow/Home/End/Enter
+ * handlers and `aria-activedescendant`, so the highlight moves through the
+ * rows while focus never leaves the field. Radix's `Slot`, which cmdk uses,
+ * throws on a second child rather than quietly merging onto the first.
+ *
+ * This renders no field of its own on purpose. A results panel is a way of
+ * showing what a search found, not a second opinion about what a search box
+ * looks like.
+ *
+ * It does render the row the field sits in, which is a different thing: the
+ * design draws a padded title row across the top of the panel, and `asChild`
+ * alone would have put that padding on the caller's search bar — where it would
+ * have moved the field's own border in from the panel edge instead of insetting
+ * the row.
+ *
+ * Two things cmdk decides that the field cannot override, because it writes
+ * them *after* the spread: the control becomes `type="text"` rather than
+ * `type="search"`, and it is given `role="combobox"` with `aria-controls` and
+ * `aria-activedescendant`. Neither is a problem — the only thing `type=search`
+ * adds is the browser's own clear button, which `OxSearchBar` hides and
+ * redraws anyway, and a text field that owns a list of options is what the
+ * combobox role is for, whatever the panel above it is called. It is a real
+ * difference from the Vue port, where the field keeps `type="search"`.
+ */
+export declare const SearchPanelInput: import('react').ForwardRefExoticComponent<SearchPanelInputProps & import('react').RefAttributes<HTMLInputElement>>;

package/dist/Forms/Inputs/SearchPanel/SearchPanelItem.d.ts

@@ -0,0 +1,20 @@
+import { CommandItem } from 'cmdk';
+export interface SearchPanelItemProps extends Omit<React.ComponentPropsWithoutRef<typeof CommandItem>, 'value' | 'onSelect'> {
+    /** Handed back through the panel's `onSelect`. Unique within the panel. */
+    value: string;
+    disabled?: boolean;
+}
+/**
+ * One result. Choosing it makes the panel call `onSelect` with this `value`.
+ *
+ * No check indicator, and that is the point: nothing here is selected in the
+ * sense a `Select` option is. The row is a thing you run, so it never becomes
+ * the panel's current answer and never grows a tick beside it. The shared row
+ * only leaves room on the right when an indicator is passed, so these sit
+ * flush.
+ *
+ * Whatever goes inside is the caller's — an icon and a label, an avatar and
+ * two lines, a filename and a size. `value` is the only thing this package
+ * wants, and only so it has something to hand back.
+ */
+export declare const SearchPanelItem: import('react').ForwardRefExoticComponent<SearchPanelItemProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/SearchPanel/SearchPanelList.d.ts

@@ -0,0 +1,11 @@
+import { CommandList } from 'cmdk';
+export type SearchPanelListProps = React.ComponentPropsWithoutRef<typeof CommandList>;
+export declare const SearchPanelList: import('react').ForwardRefExoticComponent<Omit<{
+    children?: React.ReactNode;
+} & Pick<Pick<import('react').DetailedHTMLProps<import('react').HTMLAttributes<HTMLDivElement>, HTMLDivElement>, "key" | keyof import('react').HTMLAttributes<HTMLDivElement>> & {
+    ref?: React.Ref<HTMLDivElement>;
+} & {
+    asChild?: boolean;
+}, "asChild" | "key" | keyof import('react').HTMLAttributes<HTMLDivElement>> & {
+    label?: string;
+} & import('react').RefAttributes<HTMLDivElement>, "ref"> & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/SearchPanel/context.d.ts

@@ -0,0 +1,11 @@
+export interface SearchPanelContextValue {
+    /** Called with a row's `value` when that row is chosen. */
+    select: (value: string) => void;
+}
+export declare const SearchPanelContext: import('react').Context<SearchPanelContextValue | null>;
+/**
+ * The Vue port reaches the root through reka's own listbox context; React has
+ * no equivalent to inject, so the root publishes one. The error message
+ * matches the Vue side's on purpose.
+ */
+export declare const useSearchPanelContext: () => SearchPanelContextValue;

package/dist/Forms/Inputs/SearchPanel/index.d.ts

@@ -0,0 +1,6 @@
+export { SearchPanel, type SearchPanelProps } from './SearchPanel.tsx';
+export { SearchPanelEmpty, type SearchPanelEmptyProps, } from './SearchPanelEmpty.tsx';
+export { SearchPanelGroup, type SearchPanelGroupProps, } from './SearchPanelGroup.tsx';
+export { SearchPanelInput, type SearchPanelInputProps, } from './SearchPanelInput.tsx';
+export { SearchPanelItem, type SearchPanelItemProps, } from './SearchPanelItem.tsx';
+export { SearchPanelList, type SearchPanelListProps, } from './SearchPanelList.tsx';

package/dist/Forms/Inputs/Select/SelectContent.d.ts

@@ -4,8 +4,4 @@ export interface SelectContentProps extends Omit<React.ComponentPropsWithoutRef<
     sideOffset?: number;
     align?: 'start' | 'center' | 'end';
 }
-/**
- * The floating list. Always positioned against the trigger rather than over it,
- * so the popup matches the trigger's width and never covers it.
- */
 export declare const SelectContent: import('react').ForwardRefExoticComponent<SelectContentProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/Select/SelectGroup.d.ts

@@ -1,7 +1,11 @@
 import * as SelectPrimitive from '@radix-ui/react-select';
 export interface SelectGroupProps extends React.ComponentPropsWithoutRef<typeof SelectPrimitive.Group> {
-    /** Optional group heading. */
-    label?: string;
+    /**
+     * The group heading. A node rather than a string: it is the caller's word
+     * for their own category, and taking it as text would decide for them that
+     * it can only ever be text.
+     */
+    label?: React.ReactNode;
 }
 /** Groups related options under a heading, announced as a group label. */
 export declare const SelectGroup: import('react').ForwardRefExoticComponent<SelectGroupProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/Select/SelectItem.d.ts

@@ -6,6 +6,12 @@ export interface SelectItemProps extends React.ComponentPropsWithoutRef<typeof S
 /**
  * A single option.
  *
+ * `asChild` hands Radix's item behaviour — `role="option"`, `data-highlighted`,
+ * `data-state`, typeahead, selection — to the shared row, which is the one
+ * thing `Select`, `Combobox` and `SearchPanel` may share. The primitive
+ * itself is not shared: this one and `Combobox`'s wrap different roots and
+ * swapping them breaks the keyboard in both.
+ *
  * The rendered text is published to the root on mount so the trigger's render
  * prop can name the selection. Reading it off the DOM keeps arbitrary markup
  * working, and it runs while the list is closed too: the primitive keeps items

package/dist/Forms/Inputs/Textarea/Textarea.d.ts

@@ -0,0 +1,69 @@
+import { ReactNode } from 'react';
+import { TextareaCounterState } from './index.ts';
+export interface TextareaProps extends Omit<React.TextareaHTMLAttributes<HTMLTextAreaElement>, 'rows' | 'children'> {
+    /**
+     * How tall the surface may grow before it starts to scroll, counted in lines
+     * of text.
+     *
+     * In rows rather than pixels so the cap moves with the line height instead
+     * of cutting a row in half the first time anyone changes the type scale. The
+     * default is the design's 100px box, which is four 20px lines inside its own
+     * padding.
+     */
+    maxRows?: number;
+    /** Controlled value. Pair with `onFieldChange`; omit for uncontrolled. */
+    field?: string;
+    /** Called on every input with the next value. */
+    onFieldChange?: (value: string) => void;
+    /**
+     * Bottom-right inside the box. A node, or a render prop called with
+     * `{ value, length }` — the limit is the caller's business and the count is
+     * the value's, so neither is a prop.
+     */
+    counter?: ReactNode | ((state: TextareaCounterState) => ReactNode);
+    dataTestid: string;
+}
+/**
+ * The multi-line field: a `<textarea>` in the same box the single-line
+ * controls draw, that grows with its content and then scrolls.
+ * Mirrors `@sesame/orxata-core` Textarea.
+ *
+ * **Not `OxChatInput`.** That one is a chat composer — it owns a send
+ * contract, Enter submits, and it draws two corners of action buttons around
+ * the text. This one is a form field: it has no idea what happens to the
+ * value, Enter inserts a newline, and it sits inside an `<OxFieldGroup>` with
+ * a label above it and a message below. Reach for `OxChatInput` when the value
+ * is a message being sent somewhere; reach for this when the value is an
+ * answer on a form. They share `useAutoGrow` and nothing else, which is the
+ * only part of the two that is genuinely the same problem.
+ *
+ * **The label and the message are not here, and that is the point.**
+ * `<OxFieldLabel>` and `<OxFieldMessage>` already exist, already order
+ * themselves around a control, and — through `useFieldControl` below — already
+ * carry the `id`, `aria-invalid` and `aria-describedby` that tie the three
+ * together. A `label` prop would be a second, worse spelling of a component
+ * that is already in the package, and the design system ships no strings
+ * anyway.
+ *
+ * ```tsx
+ * <OxFieldGroup variant="error">
+ *   <OxFieldLabel>Notes</OxFieldLabel>
+ *   <OxTextarea field={notes} onFieldChange={setNotes} dataTestid="notes" />
+ *   <OxFieldMessage>Keep it under 100 characters.</OxFieldMessage>
+ * </OxFieldGroup>
+ * ```
+ *
+ * **`field` alone does not mean "controlled" — `field` *with* `onFieldChange`
+ * does.** The Vue original is a `defineModel`, and a `defineModel` only hands
+ * control to the parent when the parent actually listens; given a value and no
+ * listener it seeds its own state and goes on working. Port `field` as
+ * unconditionally controlled and the same usage becomes a field pinned to its
+ * initial value that silently will not accept a keystroke.
+ *
+ * The `ref` is the **textarea**, not the box — which is where it differs from
+ * `OxChatInput`, whose ref is its root. This is a form control: what a caller
+ * reaches for a ref to do is focus it, select in it, or hand it to a form
+ * library. `className` still lands on the box, since the box is what reads as
+ * the control.
+ */
+export declare const Textarea: import('react').ForwardRefExoticComponent<TextareaProps & import('react').RefAttributes<HTMLTextAreaElement>>;

package/dist/Forms/Inputs/Textarea/index.d.ts

@@ -0,0 +1,21 @@
+export { Textarea, type TextareaProps } from './Textarea.tsx';
+/**
+ * What the `counter` slot is handed.
+ *
+ * Both numbers come from the field rather than from the caller, so a counter
+ * works the same whether the value is controlled or left to the textarea — an
+ * uncontrolled field posting itself in a plain `<form>` has no value in the
+ * caller's scope to count.
+ *
+ * There is no `cva` here on purpose. `Textarea` has no variants: the design
+ * draws one box, and its states come from `OxFieldGroup` through the
+ * `--controller-*` properties rather than from a class this component picks.
+ * An empty variant map would be one more thing to keep in step across two
+ * packages in exchange for nothing.
+ */
+export interface TextareaCounterState {
+    /** The text the field holds now. */
+    value: string;
+    /** How many characters that is — what `<OxCounter>` wants for its `value`. */
+    length: number;
+}

package/dist/Forms/Inputs/Toggle/RadioButton/RadioGroup.d.ts

@@ -5,5 +5,10 @@ export interface RadioGroupProps extends React.ComponentPropsWithoutRef<typeof R
 /**
  * RadioGroup — built on `@radix-ui/react-radio-group`.
  * `v-model` maps to Radix `value` / `onValueChange` (+ `defaultValue`).
+ *
+ * The group is what a field names, not the radios inside it: one id cannot sit
+ * on several `<button role="radio">`s at once, so `RadioButton` stays out of
+ * the field context and this root carries `aria-labelledby` instead. Radix
+ * gives it `role="radiogroup"`, which is what makes that name land.
  */
 export declare const RadioGroup: import('react').ForwardRefExoticComponent<RadioGroupProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/Toggle/ToggleLabel/ToggleLabel.d.ts

@@ -1,5 +1,14 @@
 export interface ToggleLabelProps extends React.LabelHTMLAttributes<HTMLLabelElement> {
     htmlFor?: string;
 }
-/** ToggleLabel — mirrors `@sesame/orxata-core` ToggleLabel. */
+/**
+ * ToggleLabel — mirrors `@sesame/orxata-core` ToggleLabel.
+ *
+ * `htmlFor` falls back to whichever control claimed the surrounding
+ * `<OxFieldGroup>`'s id, because the commonest checkbox layout in the system —
+ * a field wrapping an `<OxToggleGroup>` wrapping a toggle and this — would
+ * otherwise leave the toggle's own label naming nothing. It does not take the
+ * group's `labelId`: `OxFieldLabel` already carries that, and two elements
+ * cannot share an id.
+ */
 export declare const ToggleLabel: import('react').ForwardRefExoticComponent<ToggleLabelProps & import('react').RefAttributes<HTMLLabelElement>>;

package/dist/Forms/Inputs/index.d.ts

@@ -3,6 +3,12 @@ export { InputText, type InputTextProps } from './InputText/InputText.tsx';
 export * from './InputNumber/index.ts';
 export * from './InputPassword/index.ts';
 export * from './InputOtp/index.ts';
+export * from './Calendar/index.ts';
 export * from './Combobox/index.ts';
+export * from './ChatInput/index.ts';
+export * from './DatePicker/index.ts';
+export * from './SearchBar/index.ts';
+export * from './SearchPanel/index.ts';
 export * from './Select/index.ts';
+export * from './Textarea/index.ts';
 export * from './Toggle/index.ts';

package/dist/Layout/Card/Card.d.ts

@@ -2,7 +2,10 @@ import { CardVariants } from './index.ts';
 export interface CardProps extends React.HTMLAttributes<HTMLDivElement> {
     /** Render as the child element instead of a `<div>` (Radix Slot). */
     asChild?: boolean;
-    /** Which surface it is: `default` is white, `muted` is tinted. */
+    /**
+     * Which surface it is: `default` is white, `muted` is tinted, `highlighted`
+     * is filled with the brand colour and carries its own light text.
+     */
     tone?: CardVariants['tone'];
     /** Drops the border, the shadow and the glass — just the surface and its radius. */
     flat?: boolean;

package/dist/Layout/Card/index.d.ts

@@ -3,9 +3,15 @@ export { Card, type CardProps } from './Card.tsx';
 /**
  * Two things vary, and they are not the same thing.
  *
- * `tone` is which surface it is: white, or tinted for the case the white one
- * cannot serve. White on white needs a border around every row to read as
- * separate things; a tinted surface lets the white ones separate on their own.
+ * `tone` is which surface it is: white, tinted for the case the white one
+ * cannot serve, or filled with the brand colour when the card is the one thing
+ * on the page meant to be looked at first. White on white needs a border around
+ * every row to read as separate things; a tinted surface lets the white ones
+ * separate on their own.
+ *
+ * `highlighted` is the only tone that also sets a text colour, because it is
+ * the only one whose surface is dark enough to need it. Everything inside
+ * inherits it, so the content composes exactly as it would on a white card.
  *
  * `flat` is what it carries on top of that surface. They are kept apart
  * because the combinations are all real: a white card over a tinted one, a
@@ -16,6 +22,6 @@ export { Card, type CardProps } from './Card.tsx';
  * styles keyed off `data-flat` rather than being bent into one.
  */
 export declare const cardVariants: (props?: ({
-    tone?: "default" | "muted" | null | undefined;
+    tone?: "default" | "muted" | "highlighted" | null | undefined;
 } & import('class-variance-authority/types').ClassProp) | undefined) => string;
 export type CardVariants = VariantProps<typeof cardVariants>;

package/dist/Layout/Scrollbar/Scrollbar.d.ts

@@ -0,0 +1,46 @@
+import { ScrollbarPort } from './useScrollbar.ts';
+export interface ScrollbarProps extends Omit<React.HTMLAttributes<HTMLDivElement>, 'children'> {
+    /**
+     * The element that scrolls. Everything is measured from it, and its native
+     * scrollbar is hidden for as long as this one is drawn over it.
+     */
+    port?: ScrollbarPort;
+    dataTestid: string;
+}
+/**
+ * An overlay scrollbar for a container that scrolls vertically, drawn instead
+ * of the browser's own. Mirrors `@sesame/orxata-core` Scrollbar.
+ *
+ * Reach for it where the native bar cannot say what it needs to say. A
+ * virtualised table is the case it was built for: the bar has to start below
+ * the column names, and the native one runs the full height of the scrollport
+ * because the scrollport contains the header. A chat composer that grows to a
+ * few lines and then scrolls is the other: a native bar there is a strip of
+ * system chrome inside a rounded box, and in the browsers that reserve a gutter
+ * it shifts the text sideways the moment the field overflows.
+ *
+ * It behaves the way an overlay bar does: out of the way until you scroll or
+ * reach for the edge, and gone again shortly after. The track takes no clicks —
+ * only the thumb does — so the strip down the right of the content stays live.
+ *
+ * **Placement is the parent's.** This positions itself absolutely inside the
+ * nearest positioned ancestor and reads four custom properties for where that
+ * is, all with fallbacks that spell "fill the containing block down its right
+ * edge": `--scrollbar-top` (`0px`), `--scrollbar-right` (`0px`),
+ * `--scrollbar-left` (`auto`) and `--scrollbar-height` (`100%`).
+ *
+ * A parent whose scrollport *is* the containing block sets none of them. One
+ * that has to compensate for something — a header inside the scrollport, an
+ * `offsetParent` that is not the scrollport — works the numbers out itself and
+ * writes them here, which is why none of that arithmetic is a prop.
+ *
+ * Vertical only, deliberately. Horizontal overflow is read from the content
+ * running out of room and from the shadows at the edges; nothing in the system
+ * wants a second bar, and adding one later takes nothing away.
+ *
+ * The bar is `aria-hidden`: it is a picture of a scroll position, and the
+ * scrollport it belongs to is already reachable and scrollable from the
+ * keyboard. `mousedown`/`mousemove` are what drive the thumb, so a coarse
+ * pointer gets nothing from it and keeps the native scrolling it already had.
+ */
+export declare const Scrollbar: import('react').ForwardRefExoticComponent<ScrollbarProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Layout/Scrollbar/index.d.ts

@@ -0,0 +1,2 @@
+export { Scrollbar, type ScrollbarProps } from './Scrollbar.tsx';
+export { useScrollbar, SCROLLBAR_THICKNESS, type ScrollbarPort, type UseScrollbarReturn, } from './useScrollbar.ts';