@dcs-tech/ui 0.2.0 → 0.4.0

package/dist/types/shared-types/src/ui/control.types.d.ts

@@ -1,133 +0,0 @@
-import type { ReactNode } from 'react';
-/**
- * The one vocabulary every control in @pdfinvoice/shared-web-ui speaks.
- *
- * Before this file each component re-spelled its own `Size`, `Layout` and
- * `Color` unions by hand. They agreed today by coincidence, not by
- * construction — `ButtonSize` and `FieldSize` listed the same six literals in
- * two places, and `ChipInputLayout` said `vertical` for the thing every other
- * control called `default`. Anything declared here is declared once; the
- * per-component names remain, as aliases, so call sites and the published
- * barrel are unaffected.
- *
- * Adding a step or a colour here widens every control at once — which is the
- * point, and also the hazard: a literal with no CSS behind it ships a variant
- * that renders as nothing. Widen the stylesheet in the same stroke.
- */
-/**
- * The size scale. Every control resolves to this, so `size="small"` means the
- * same height, padding and font on an Input, a Checkbox and a Button standing
- * next to each other.
- *
- * Each step maps to `--field-height-*`, `--field-padding-x/y-*`,
- * `--control-size-*` and `--font-size-*` in @pdfinvoice/shared-styles.
- */
-export type ControlSize = 'xxs' | 'xs' | 'small' | 'medium' | 'large' | 'xl';
-/**
- * The default every control falls back to when neither a `size` prop nor an
- * enclosing FieldContext supplies one.
- *
- * It is `small` because this is a dense ERP: the invoice grid is the busiest
- * screen in the product and sets the house density. Previously the fields
- * defaulted to `small` and the toggles to `medium`, so a Checkbox beside an
- * Input was a step larger with no props passed on either.
- */
-export declare const DEFAULT_CONTROL_SIZE: ControlSize;
-/**
- * Surface treatment for controls that render a text-entry surface — Input,
- * Select, Suggest, ChipInput. They share one border/background/radius/focus
- * definition, so an outlined Select is the same surface as the outlined Input
- * beside it.
- *
- * `underlined` only makes sense here: it draws a rule beneath the text line.
- */
-export type ControlVariant = 'outlined' | 'filled' | 'standard' | 'underlined' | 'cell';
-/**
- * Surface treatment for the box-shaped toggles — Checkbox and Radio.
- *
- * Deliberately NOT ControlVariant: a checkbox has no text line to underline, so
- * `underlined` would be a valid type with no styling behind it and the control
- * would render with no border or fill. Switch has no variant at all — it has a
- * single track/thumb look by design.
- */
-export type ToggleVariant = 'outlined' | 'filled' | 'standard' | 'cell';
-/** How a control arranges its label against its control box. */
-export type ControlLayout = 'default' | 'horizontal' | 'inline' | 'cell';
-/** Where a toggle's own label sits relative to its box. */
-export type ControlLabelPosition = 'start' | 'end' | 'top' | 'bottom';
-/**
- * The palette's semantic axis. Each member has its own hue variable in
- * `tokens.css` and its own `--on-*` contrast text.
- *
- * Components take a subset via `Extract`/`Exclude` rather than re-listing:
- * `neutral` is a button/surface idea, not a state a field can be in.
- */
-export type SemanticColor = 'primary' | 'secondary' | 'success' | 'error' | 'warning' | 'info' | 'neutral';
-/** What a form control can be tinted: every semantic except the neutral surface. */
-export type FieldColor = Exclude<SemanticColor, 'neutral'>;
-/**
- * The minimum a change event carries.
- *
- * A native `ChangeEvent<HTMLInputElement>` satisfies this structurally, which
- * is the whole trick: Input, Checkbox, Radio, Switch and Suggest keep emitting
- * real DOM events (so `currentTarget` and `preventDefault` survive), while
- * Select and ChipInput — which have no DOM event to forward — emit this shape.
- * A single handler typed `(e: FieldChangeEvent) => void` therefore accepts a
- * change from any field, which is what Fields, EditableTable and the keyboard
- * grid need in order to write one handler per row instead of one per widget.
- *
- * Keep this narrow. Every property added here is one more thing the synthetic
- * emitters have to fabricate.
- */
-export interface FieldChangeTarget<V = any> {
-    name?: string;
-    value: V;
-    /** Mirrors the DOM `type` so `createChangeHandler` can branch on it. */
-    type?: string;
-    /** Only meaningful for checkbox/radio inputs. */
-    checked?: boolean;
-}
-export interface FieldChangeEvent<V = any> {
-    target: FieldChangeTarget<V>;
-}
-/**
- * What a container (Form, Fields, an editable-table row) hands down to the
- * fields inside it. Every member optional and unset by default — a field has to
- * be able to tell "nobody said" from "someone said small".
- */
-export interface FieldContextValue {
-    size?: ControlSize;
-    variant?: ControlVariant;
-    layout?: ControlLayout;
-    disabled?: boolean;
-    readOnly?: boolean;
-    /**
-     * The keyboard policy for everything beneath. This is how a grid says
-     * "every cell in here is in grid mode" and a form says "Enter moves to the
-     * next field" — once, rather than on every field.
-     *
-     * @see FieldKeyboardConfig in `keyboard.types`. Typed structurally here to
-     * keep `control.types` a leaf that imports nothing.
-     */
-    keyboard?: import('./keyboard.types').FieldKeyboardConfig;
-}
-export interface FieldProviderProps extends FieldContextValue {
-    children?: ReactNode;
-}
-/**
- * What an editable-table cell needs to tell the widget sitting in it.
- *
- * These five used to be five separate public props on Input, Select and Suggest
- * — with Suggest re-declaring them inline and typing `registerCellRef` against
- * `HTMLInputElement` where Input typed `HTMLElement`. Grouping them keeps the
- * grid's plumbing out of the props panel and gives the two implementations one
- * signature to agree on.
- */
-export interface FieldCellContext {
-    rowIndex?: number;
-    /** Lower-case to match the `data-cellindex` attribute the DOM carries. */
-    cellindex?: number;
-    onCellFocus?: (rowIndex: number, cellindex: number) => void;
-    registerCellRef?: (rowIndex: number, cellindex: number, ref: HTMLElement | null) => void;
-    eTableProps?: Record<string, unknown>;
-}

package/dist/types/shared-types/src/ui/field.types.d.ts

@@ -1,200 +0,0 @@
-import type { CSSProperties, FocusEvent, KeyboardEvent, ReactNode } from 'react';
-import type { DataAttributes } from './common.types';
-import type { FieldTooltipSupport } from './fieldWrapper.types';
-import type { ControlLabelPosition, ControlLayout, ControlSize, ControlVariant, FieldCellContext, FieldChangeEvent, FieldColor, ToggleVariant } from './control.types';
-import type { FieldKeyboardConfig } from './keyboard.types';
-/**
- * The one field contract.
- *
- * `control.types` unified the *vocabulary* — `ControlSize`, `ControlVariant`,
- * `FieldChangeEvent` — so the values could no longer drift. It did not unify
- * the *shape*: all seven fields still spelled out their own prop lists by hand,
- * and they had already drifted apart in ways nothing could catch.
- *
- * What the audit found, before this file existed:
- *
- * - `name`, `label`, `size`, `disabled`, `readOnly`, `required`, `error`,
- *   `autoFocus`, `tabIndex`, `onFocus`, `onBlur` and `className` were
- *   re-declared by hand in **all seven** props files. Checkbox declared `name`
- *   three times, in three different sub-interfaces.
- * - `onFocus`/`onBlur` had **five different signatures**, and Select disagreed
- *   with itself: `onBlur: (e: SelectEvent)` beside `onFocus: (e: FocusEvent)`,
- *   declared 65 lines apart in two sub-interfaces.
- * - `onKeyDown` existed on **three of seven**. Checkbox, Radio, Switch and
- *   ChipInput could not participate in grid navigation at all.
- * - The helper line under a field was `hint` on Input/Suggest/ChipInput and
- *   `helperText` on Checkbox/Radio/Switch — for the same slot in the same
- *   FieldWrapper.
- * - `FieldCellContext` reached three of seven, and Select imported it under the
- *   alias `InputEditableTableCellProps` — named after a different component.
- *
- * Every axis below is declared **once**. A field's own props file holds only
- * what is genuinely its own; adding an axis later edits this file, not seven.
- */
-/**
- * `C` — the change event a field emits — is a parameter rather than a fixed
- * `FieldChangeEvent`, and deliberately so. Input, Suggest and the toggles
- * forward a **real DOM event**, so their consumers keep `currentTarget` and
- * `preventDefault()`; Select and ChipInput have no DOM event and emit the
- * synthetic shape. Fixing `C` to `FieldChangeEvent` would unify the declaration
- * by quietly taking capability away from five fields.
- *
- * A container still writes one handler for all of them: `FieldChangeEvent` is
- * what a DOM `ChangeEvent` structurally satisfies, so a handler typed against
- * the narrow shape is assignable to every field's `onChange`.
- */
-export interface FieldIdentityProps<V = any, C = FieldChangeEvent<V>> {
-    id?: string;
-    name?: string;
-    value?: V;
-    defaultValue?: V;
-    onChange?: (event: C) => void;
-}
-/**
- * What every field shares. Resolved by `useFieldSurface`
- * (own prop → FieldContext → default), never by a destructuring default.
- */
-export interface FieldSurfaceProps {
-    size?: ControlSize;
-    disabled?: boolean;
-    readOnly?: boolean;
-}
-/** Fields that render a text-entry surface: Input, Select, Suggest, ChipInput. */
-export interface ControlSurfaceProps extends FieldSurfaceProps {
-    variant?: ControlVariant;
-    layout?: ControlLayout;
-}
-/**
- * The box-shaped toggles: Checkbox, Radio, Switch.
- *
- * Separate from `ControlSurfaceProps` on purpose. A toggle has no text line, so
- * `variant: 'underlined'` would type-check and render a box with neither border
- * nor fill, and `layout` has nothing to arrange — a toggle positions its label
- * with `labelPosition`. Handing toggles the text-field surface would make both
- * expressible and meaningless.
- */
-export interface ToggleSurfaceProps extends FieldSurfaceProps {
-    variant?: ToggleVariant;
-    color?: FieldColor;
-    labelPosition?: ControlLabelPosition;
-}
-/**
- * The label / helper / error furniture, all of which FieldWrapper renders.
- *
- * `ReactNode` rather than `string` for label, hint and error: the toggles
- * already passed rich content through the wrapper while Input's types claimed
- * `string`, so the wrapper's real contract was the wider one.
- */
-export interface FieldChromeProps {
-    label?: ReactNode;
-    hint?: ReactNode;
-    error?: ReactNode;
-    required?: boolean;
-    className?: string;
-    labelClassName?: string;
-    style?: CSSProperties;
-    fullWidth?: boolean;
-}
-/**
- * Re-declared per field before this existed, in four of the seven, with the
- * other three simply dropping them.
- */
-export interface FieldA11yProps {
-    'aria-label'?: string;
-    'aria-labelledby'?: string;
-    'aria-describedby'?: string;
-    'aria-required'?: boolean;
-    'aria-invalid'?: boolean;
-}
-/**
- * The focus event a container writes its handler against — the widest one, so
- * `Fields` can pass a single `onBlur` to all seven fields.
- */
-export type FieldFocusEvent = FocusEvent<HTMLElement>;
-/**
- * One focus/key signature, parameterised by the element the field actually
- * focuses — `HTMLInputElement` for Input and the toggles, `HTMLDivElement` for
- * Select's trigger, and so on.
- *
- * Parameterised rather than widened to a flat `HTMLElement` because widening
- * would break every consumer whose handler is annotated with the narrow event
- * type. A container's handler is unaffected either way: TypeScript checks
- * function parameters contravariantly, so a broadly-typed
- * `(e: KeyboardEvent) => void` — which is what the grid and form pass down —
- * remains assignable to every field's `onKeyDown`.
- */
-export interface FieldInteractionProps<E extends HTMLElement = HTMLElement> {
-    autoFocus?: boolean;
-    tabIndex?: number;
-    onFocus?: (event: FocusEvent<E>) => void;
-    onBlur?: (event: FocusEvent<E>) => void;
-    onKeyDown?: (event: KeyboardEvent<E>) => void;
-    /** @see FieldKeyboardConfig — arrow/Enter/edit-key policy. */
-    keyboard?: FieldKeyboardConfig;
-}
-/**
- * Why a popup opened or closed.
- *
- * A boolean is not enough for the grid. "Closed because the user picked an
- * option" must return the cell to navigate mode, while "closed because Escape"
- * must leave it in edit mode with the typed text intact — two different
- * behaviours that a bare `onOpenChange(false)` cannot distinguish.
- */
-export type OpenReason = 'type' | 'focus' | 'key' | 'click' | 'select' | 'escape' | 'blur' | 'programmatic';
-/**
- * Fields with a popup: Select, Suggest, and any date/lookup field added later.
- *
- * Before this, popup state was private to each component — only Select had
- * `onOpen`/`onClose`, neither field accepted `open`, and nothing could be
- * controlled from outside. The grid's rule that an open popup owns the arrow
- * keys had no state to read.
- */
-export interface FieldPopupProps {
-    /** Controlled. Omit for the field to own its own state. */
-    open?: boolean;
-    defaultOpen?: boolean;
-    onOpenChange?: (open: boolean, reason: OpenReason) => void;
-}
-/**
- * What `ref` points at, for every field.
- *
- * It used to be four different DOM nodes and no behaviour, which is why the
- * editable table resorted to `document.querySelector('.smartselect-trigger')`
- * to move focus — there was no other way to focus a Select from outside it.
- *
- * `element` keeps the old capability available, so nothing that a DOM ref could
- * do becomes impossible.
- */
-export interface FieldHandle {
-    focus(opts?: {
-        select?: boolean;
-        caret?: 'start' | 'end';
-    }): void;
-    blur(): void;
-    /** Navigate → edit. `seed` replaces the value, as type-to-replace does. */
-    beginEdit(seed?: string): void;
-    endEdit(commit: boolean): void;
-    openPopup(reason?: OpenReason): void;
-    closePopup(reason?: OpenReason): void;
-    readonly isOpen: boolean;
-    readonly element: HTMLElement | null;
-}
-/**
- * Everything every field has, whatever it renders.
- *
- * Surface is **not** included: text fields and toggles take different surface
- * axes (see `ControlSurfaceProps` / `ToggleSurfaceProps`), and merging them
- * would give a Checkbox a `layout` and an `underlined` variant that mean
- * nothing. Each field extends this plus the surface interface for its family.
- *
- * @typeParam V — the value type
- * @typeParam E — the element the field focuses
- * @typeParam C — the change event it emits
- */
-export type BaseFieldProps<V = any, E extends HTMLElement = HTMLElement, C = FieldChangeEvent<V>> = FieldIdentityProps<V, C> & FieldChromeProps & FieldA11yProps & FieldInteractionProps<E> & FieldCellContext & FieldTooltipSupport & DataAttributes;
-/** The text-entry families: Input, Select, Suggest, ChipInput. */
-export type TextFieldProps<V = any, E extends HTMLElement = HTMLElement, C = FieldChangeEvent<V>> = BaseFieldProps<V, E, C> & ControlSurfaceProps & {
-    placeholder?: string;
-};
-/** The toggle family: Checkbox, Radio, Switch. */
-export type ToggleFieldProps<V = any, E extends HTMLElement = HTMLInputElement, C = FieldChangeEvent<V>> = BaseFieldProps<V, E, C> & ToggleSurfaceProps;

package/dist/types/shared-types/src/ui/index.d.ts

@@ -1,37 +0,0 @@
-/**
- * The UI half of `shared-types`, on its own — a privacy boundary, like its twin in
- * `shared-logic/src/ui/index.ts`.
- *
- * The package barrel (`shared-types/src/index.ts`) re-exports this folder alongside the
- * folders describing this business's own records. Anything importing the barrel pulls all of
- * it into the TypeScript program, and `tsc` emits
- * declarations for a whole program, so the domain then ships wherever those declarations do.
- * That is how `@dcs-tech/ui@0.1.0` reached the public registry carrying them (audited
- * 2026-09-28).
- *
- * `navigation.types` and `common.types` are included because the app-shell components are
- * published and typed against them; neither describes any business record.
- *
- * ONLY `./ui/*` belongs here. Never add a domain module, and never re-export the parent barrel.
- */
-export * from './control.types';
-export * from './tooltip.types';
-export * from './typography.types';
-export * from './button.types';
-export * from './fieldWrapper.types';
-export * from './keyboard.types';
-export * from './field.types';
-export * from './checkbox.types';
-export * from './radio.types';
-export * from './switch.types';
-export * from './input.types';
-export * from './select.types';
-export * from './suggest.types';
-export * from './collapsible.types';
-export * from './fields.types';
-export * from './form.types';
-export * from './chipinput.types';
-export * from './table.types';
-export * from './editableTable.types';
-export * from './navigation.types';
-export type { DataAttributes } from './common.types';

package/dist/types/shared-types/src/ui/keyboard.types.d.ts

@@ -1,155 +0,0 @@
-/**
- * The keyboard contract — one truth table for every field, in every container.
- *
- * Key handling used to be **field-first**: each field ran its own `handleKeyDown`
- * and *might* forward what was left to the container. Three incompatible rules
- * had grown out of that:
- *
- * - Input had no key logic at all, so the grid could only use keys an input
- *   ignores — which is why the editable table navigated on **Ctrl/Alt+Arrow**
- *   instead of the plain arrows every native ERP grid uses.
- * - Suggest swallowed ArrowUp/ArrowDown/Enter/Escape unconditionally, open or
- *   closed, so a closed suggest cell ate the grid's arrows.
- * - Select kept an ad-hoc allow-list of keys to forward *and* a boolean return
- *   from its hook — two arbitration mechanisms inside one component.
- *
- * Which key reached the grid therefore depended on which widget a cell happened
- * to hold, and no truth table existed to test against.
- *
- * This inverts it. The **container arbitrates**; a field only reports what it
- * currently needs, and one pure resolver decides. A field author never writes
- * key handling — they spread the handlers `useField` returns.
- */
-/**
- * What kind of keyboard behaviour a field has. Not the same as the component:
- * a number Input and a text Input are one component and two widgets, because
- * they answer differently on the arrow keys.
- */
-export type FieldWidget = 'text' | 'number' | 'textarea' | 'select' | 'suggest' | 'toggle'
-/** A cell that ACTS instead of holding a value: Space presses it, Enter walks on. */
- | 'button' | 'custom';
-/** What the container is being asked to do. */
-export type NavAction = 'next' | 'prev' | 'up' | 'down' | 'left' | 'right' | 'firstCell' | 'lastCell' | 'firstCellOfTable' | 'lastCellOfTable' | 'pageUp' | 'pageDown' | 'newRow' | 'copyRow' | 'deleteRow' | 'edit' | 'commit' | 'revert' | 'clear' | 'submit' | 'exitGrid' | 'none';
-/** Which half of the cell's two-mode state is live. @see FIELD_KEYBOARD_NAVIGATION.md §2 */
-export type GridMode = 'navigate' | 'edit';
-/**
- * The live field state the resolver needs. Everything here is knowable without
- * touching the DOM at the point of decision, which is what keeps the resolver
- * pure and its truth table runnable under plain Node.
- */
-export interface FieldKeyState {
-    mode: GridMode;
-    isOpen: boolean;
-    /** A popup with nothing in it must not swallow Enter. */
-    hasOptions?: boolean;
-    caretAtStart?: boolean;
-    caretAtEnd?: boolean;
-    hasSelection?: boolean;
-    isEmpty?: boolean;
-    /** Multi-select keeps its popup open on Enter where single-select closes it. */
-    multi?: boolean;
-}
-/**
- * A `React.KeyboardEvent` satisfies this structurally — the same trick
- * `FieldChangeEvent` uses. The resolver takes the minimum so it can live in
- * shared-logic with no React or DOM import, and stay mechanically portable.
- */
-export interface KeyEventLike {
-    key: string;
-    ctrlKey?: boolean;
-    shiftKey?: boolean;
-    altKey?: boolean;
-    metaKey?: boolean;
-}
-/** What the field does with a key it keeps. */
-export type FieldKeyAction = 'native' | 'open' | 'close' | 'highlightNext' | 'highlightPrev' | 'highlightFirst' | 'highlightLast' | 'pick' | 'toggleOption' | 'beginEdit' | 'clear' | 'stepUp' | 'stepDown'
-/**
- * Put a line break in a multi-line cell (Alt+Enter, the Excel/Sheets convention).
- *
- * It needs an action of its own because a grid has no spare Enter: plain Enter moves to the
- * next cell, Shift+Enter to the previous one, Ctrl+Enter adds a row. Alt+Enter is the one
- * combination left, and the browser inserts nothing for it on its own — so unlike every
- * other textual key this cannot resolve to `'native'`.
- */
- | 'insertNewline';
-/**
- * Exactly one owner per key, always. A resolution that named neither owner is
- * how keys used to go missing between a field and its container.
- */
-export type KeyResolution = {
-    owner: 'field';
-    action: FieldKeyAction;
-    preventDefault: boolean;
-} | {
-    owner: 'container';
-    action: NavAction;
-    preventDefault: boolean;
-};
-/**
- * How a field or container behaves on the keyboard.
- *
- * This is the **Interaction axis** of `BaseFieldProps`, so it lands on all seven
- * fields at once rather than the three that happen to have `onKeyDown` today.
- * A container sets it once through `FieldContext` and every field beneath obeys;
- * resolution is the same own prop → provider → default order as `size`.
- */
-export interface FieldKeyboardConfig {
-    /**
-     * `'field'` — an ordinary standalone field; the browser's behaviour, plus
-     * whatever `enter` says.
-     * `'grid'` — the two-mode navigate/edit model a cell needs.
-     */
-    mode?: 'field' | 'grid';
-    /**
-     * What Enter does when no popup is open.
-     *
-     * The library default is `'submit'`, because a `<form>` submitting on Enter
-     * is the web standard and this package is published. Our apps set `'next'`
-     * once on the provider: traditional ERP data entry moves on Enter and
-     * submits on Ctrl+Enter or the action button.
-     */
-    enter?: 'next' | 'submit' | 'native' | 'none';
-    /** Arrow keys in navigate mode. `'container'` moves between cells. */
-    arrows?: 'container' | 'native';
-    /**
-     * Up/Down while editing. `'cell'` commits and moves row — Sheets' "enter
-     * mode", which is what makes column-down entry fast. `'caret'` leaves them
-     * to the browser; a textarea forces this regardless.
-     */
-    arrowsInEdit?: 'cell' | 'caret';
-    /** Navigate + a printable key. `'replace'` wipes the old value; `'append'` keeps it. */
-    typeBehaviour?: 'replace' | 'append';
-    /**
-     * Navigate → edit **without** wiping the value — the "alter" key, as
-     * against type-to-replace. Default `'Insert'`.
-     *
-     * A binding string rather than a fixed key so any table or form overrides it
-     * for its own audience: `Insert` is absent from Mac keyboards and most
-     * compact laptops, and those consumers pass `'F2'` or `'alt+enter'`.
-     */
-    editKey?: string;
-    /**
-     * When a popup opens. `'focus'` is right for a standalone field and wrong in
-     * a grid, where arrowing across a row would pop a list in every cell.
-     */
-    openOn?: 'focus' | 'type' | 'manual';
-    /** After picking from a popup: stay in the cell (default), or move on like Enter. */
-    advanceOnSelect?: boolean;
-    /**
-     * Whether Up/Down step a number's value. `'none'` everywhere by default —
-     * in a grid the arrows belong to navigation, and a key that silently edits
-     * a number while the user believes they are moving is a data-integrity bug,
-     * not a convenience.
-     */
-    stepKeys?: 'none' | 'arrows' | 'ctrlArrows';
-    /** Overrides, keyed by binding string: `{ 'ctrl+enter': 'newRow' }`. */
-    bindings?: Record<string, NavAction>;
-    /** Supplied by the container, never by a consumer. */
-    onNavigate?: (action: NavAction, event: KeyEventLike) => void;
-}
-/** Everything `resolveFieldKey` needs, and nothing it does not. */
-export interface KeyResolutionContext {
-    widget: FieldWidget;
-    state: FieldKeyState;
-    config: FieldKeyboardConfig;
-}

package/dist/types/shared-types/src/ui/navigation.types.d.ts

@@ -1,35 +0,0 @@
-import type { ReactNode } from 'react';
-/**
- * One entry in a navigation structure — a sidebar row, a breadcrumb, a palette result, a tab.
- *
- * ONE shape on purpose. An app builds its route registry once and feeds Sidebar, Breadcrumbs
- * and CommandPalette from the same array, instead of three parallel structures that drift.
- * Nothing here knows where the items came from, which is exactly what makes a registry that
- * changes at runtime — per-business reports generated from `businesses × templates` — work
- * with no special support: it is just a different array.
- */
-export interface NavItem {
-    /** Stable identity. Used for the active match and as the React key. */
-    id: string;
-    label: ReactNode;
-    icon?: ReactNode;
-    /** Trailing marker — a count, a status dot. */
-    badge?: ReactNode;
-    /** Extra terms for search surfaces (CommandPalette). Not rendered. */
-    keywords?: string;
-    disabled?: boolean;
-    /** Plain link target. */
-    href?: string;
-    /**
-     * Extra props spread onto the rendered element — how a router link gets its target,
-     * e.g. `{ to: '/reports/monthly/sales' }` with `as={NavLink}`. Router-agnostic on purpose.
-     */
-    props?: Record<string, unknown>;
-    /** Nested entries. Depth is not assumed anywhere. */
-    children?: NavItem[];
-    /**
-     * Render as a non-interactive section heading rather than a link. Its `children` still
-     * render beneath it.
-     */
-    group?: boolean;
-}

package/dist/types/shared-types/src/ui/tooltip.types.d.ts

@@ -1,68 +0,0 @@
-import type { ReactElement, ReactNode } from 'react';
-export type TooltipPlacement = 'top' | 'bottom' | 'left' | 'right';
-/**
- * Where a field's tooltip is triggered from: a help icon beside the label
- * (default — never fires while someone is typing), or the control itself.
- */
-export type TooltipTrigger = 'icon' | 'control';
-/**
- * What a hover tooltip is positioned against.
- *
- * `auto` (default) anchors to the trigger's box, except when that box is wider
- * than the tooltip itself — a full-width line of text, a table row — where
- * centring on the element puts the tip nowhere near the cursor. Those anchor to
- * the pointer instead.
- *
- * Keyboard focus always anchors to the element: there is no cursor involved.
- */
-export type TooltipAnchorTo = 'auto' | 'element' | 'pointer';
-export interface TooltipConfig {
-    content: ReactNode;
-    placement?: TooltipPlacement;
-    anchorTo?: TooltipAnchorTo;
-    /** ms before showing. Default 500 — 0 while another tooltip is still warm. */
-    delay?: number;
-    /** ms before hiding. Default 100. */
-    closeDelay?: number;
-    disabled?: boolean;
-    className?: string;
-}
-/**
- * What every `tooltip` prop accepts: bare content for the common case
- * (`tooltip="Delete row"`), or a config object when placement/delay matter.
- */
-export type TooltipProp = ReactNode | TooltipConfig;
-export interface TooltipProps extends TooltipConfig {
-    /** A single element — Tooltip clones it rather than wrapping it in a div. */
-    children: ReactElement;
-    id?: string;
-}
-export interface TooltipRect {
-    top: number;
-    left: number;
-    width: number;
-    height: number;
-}
-export interface TooltipPositionInput {
-    /** Trigger box in viewport coordinates. */
-    anchor: TooltipRect;
-    tooltip: {
-        width: number;
-        height: number;
-    };
-    viewport: {
-        width: number;
-        height: number;
-    };
-    placement: TooltipPlacement;
-    /** Gap between trigger and tooltip. */
-    offset: number;
-    /** Minimum distance kept from the viewport edge. */
-    margin?: number;
-}
-export interface TooltipPosition {
-    top: number;
-    left: number;
-    /** Placement actually used — may differ from the request after flipping. */
-    placement: TooltipPlacement;
-}

package/dist/types/shared-web-ui/src/AppBar/AppBar.d.ts

@@ -1,25 +0,0 @@
-import React from 'react';
-export type AppBarSize = 'small' | 'medium' | 'large';
-export type AppBarVariant = 'default' | 'transparent' | 'elevated';
-export interface AppBarProps {
-    /** Leading slot — logo, product name, a back button. */
-    brand?: React.ReactNode;
-    /** Middle slot, takes the slack. Tabs, a search box, breadcrumbs. */
-    children?: React.ReactNode;
-    /** Trailing slot, pinned to the end. */
-    actions?: React.ReactNode;
-    size?: AppBarSize;
-    variant?: AppBarVariant;
-    /** Opt-in — see the note in the stylesheet on why it is not the default. */
-    sticky?: boolean;
-    className?: string;
-    style?: React.CSSProperties;
-    'aria-label'?: string;
-}
-/**
- * The top bar: three slots, a height and a rule. It deliberately holds no navigation logic of
- * its own — put `Tabs`, `Breadcrumbs` or a search trigger in the middle slot, which keeps one
- * implementation of each of those rather than a bar-flavoured copy.
- */
-declare const AppBar: React.FC<AppBarProps>;
-export default AppBar;