import { Theme } from '@mui/material/styles';
/**
 * Custom component variants layered on top of MUI's defaults.
 *
 * These are referenced from `components.ts` and surfaced to consumers through
 * theme augmentation, so `<Button variant="primary" />` is fully typed.
 *
 * The chip variants below are the styling layer that `Chip`'s `purpose` prop
 * selects from -- they are no longer something a caller picks directly.
 */
/**
 * The canonical chip color palette. Two orthogonal axes:
 *   variant (filled | subtle | outlined | dot) x color (10 keys below).
 *
 * This cross-product is the palette `Chip` derives from, not a menu for
 * callers: `purpose` picks the legitimate pairs. See `src/atoms/Chip/Chip.tsx`.
 *
 * MUI already handles filled/outlined for palette-native colors (primary,
 * info, success, warning, error). We generate custom theme variants for
 * the five non-palette colors (neutral, critical, high, medium, low) on
 * filled/outlined, and for ALL colors on the two new custom variants
 * (subtle, dot).
 */
export declare const chipColorMap: {
    readonly neutral: "#C9C9C9";
    readonly info: "#1266CC";
    readonly success: "#199F0F";
    readonly warning: "#E99C16";
    readonly error: "#EB2D36";
    readonly critical: "#c80009";
    readonly high: "#EA5515";
    readonly medium: "#E99C16";
    readonly low: "#D0C800";
    readonly primary: "#00C4AC";
};
export type ChipColorKey = keyof typeof chipColorMap;
/**
 * Tinted background (~12% opacity), colored text, subtle border (~25%
 * opacity). Equivalent to Astryx Badge `appearance="subtle"`.
 *
 * The tint is what lifts a chip off the surface, so this is for pills that
 * should catch the eye in their own colour: severities, statuses, verdicts, and
 * the unselected half of `purpose="select"`, where a toggleable option needs to
 * look unlike the static tags around it. The neutral pills that are meant to be
 * read past -- `category`, `metric`, `filter` -- use `fieldChipVariants`.
 *
 * Ink is mode-aware: see `chipLabelInk`. The tint keeps the original hue so a
 * darkened light-mode label still sits in a recognisably coloured pill.
 */
export declare const subtleChipVariants: {
    props: {
        variant: "subtle";
        color: "primary" | "critical" | "high" | "medium" | "low" | "info" | "neutral" | "success" | "warning" | "error";
    };
    style: ({ theme }: {
        theme: Theme;
    }) => {
        backgroundColor: string;
        color: string;
        border: string;
        '&:hover': {
            backgroundColor: string;
        };
        '& .MuiChip-deleteIcon': {
            color: string;
            '&:hover': {
                color: string;
            };
        };
    };
}[];
/**
 * Subtle + neutral.
 *
 * `chipColorMap.neutral` is the dark-theme `#AEAEAE`, and on white that is
 * 2.22:1 — the washed-out Cloud / unknown-entity look. Deriving from
 * `theme.palette.text.secondary` gives the same ink field chips and body
 * secondary already use (7.73:1 on white; `#AEAEAE` unchanged in dark).
 *
 * Registered after `subtleChipVariants` so this pair wins.
 */
export declare const neutralSubtleChipVariants: {
    props: {
        variant: "subtle";
        color: "neutral";
    };
    style: ({ theme }: {
        theme: Theme;
    }) => {
        backgroundColor: string;
        color: string;
        border: string;
        '&:hover': {
            backgroundColor: string;
        };
        '& .MuiChip-deleteIcon': {
            color: string;
            '&:hover': {
                color: string;
            };
        };
    };
}[];
/**
 * The chrome of an outlined input, worn by a chip: an `inputColors.background`
 * fill inside an `inputColors.border` outline, both deliberately quiet.
 *
 * This is what `category`, `metric`, `filter`, `picker` and `overflow` render
 * as -- every neutral pill, static or operable. The point is that a filter bar
 * is a row of form controls, so the pills in it should match the TextField and
 * the secondary Button beside them rather than announcing themselves as their
 * own kind of object. Sharing `inputColors` with `MuiOutlinedInput` means they
 * match by token, not by a coincidental hex that a later restyle would break.
 *
 * Interactivity is carried by affordances rather than by the border: a picker
 * has a chevron, an overflow chip reads `+N more`, a filter chip has an X. An
 * earlier draft gave the operable ones a brighter outline, which made a filter
 * chip and the picker beside it look like different species of pill when all
 * that differs is what you can do to them.
 *
 * `subtleChipVariants` tints with translucent white, which lifts a chip *off*
 * the surface -- correct for a status or severity pill that should catch the
 * eye, wrong for a tag the user is meant to read past.
 *
 * Both modes share `--ds-field` / `--ds-field-border` with OutlinedInput and
 * the secondary Button. Light falls back to `lightInputColors`, not the dark
 * `inputColors` hexes — those painted near-black pills on a light canvas.
 *
 * Note the trade-off this buys. The fill is close enough to the host that on
 * some rungs the border does nearly all the work of drawing the pill. The label
 * carries the AA obligation, so what stays quiet is the boundary, not the
 * content -- but that means these chips identify themselves by their text and
 * their X rather than by a crisp edge. Do not reach for this variant where the
 * outline is the only thing distinguishing two states.
 */
export declare const fieldChipVariants: {
    props: {
        variant: "field";
    };
    style: ({ theme }: {
        theme: Theme;
    }) => {
        backgroundColor: string;
        color: string;
        border: string;
        '&.MuiChip-clickable:hover, &.MuiChip-deletable:hover': {
            backgroundImage: string;
        };
        '& .MuiChip-deleteIcon': {
            color: string;
            '&:hover': {
                color: string;
            };
        };
    };
}[];
/**
 * No background or border. A leading colored dot + neutral label text.
 * Pure status indicator. The dot is rendered via a `::before` pseudo-element
 * on the chip root so callers don't need to pass an icon prop.
 * Equivalent to Astryx Badge `appearance="dot"`.
 *
 * The label uses `theme.palette.text.secondary`, not the flat dark-theme
 * `textColors.secondary` token: on white that token is 2.22:1, which is what
 * made the whole status row in the purpose ladder unreadable in light mode.
 */
export declare const dotChipVariants: {
    props: {
        variant: "dot";
        color: "primary" | "critical" | "high" | "medium" | "low" | "info" | "neutral" | "success" | "warning" | "error";
    };
    style: ({ theme }: {
        theme: Theme;
    }) => {
        backgroundColor: string;
        color: string;
        border: string;
        paddingLeft: string;
        '&::before': {
            content: string;
            display: string;
            width: number;
            height: number;
            borderRadius: string;
            backgroundColor: "#C9C9C9" | "#EB2D36" | "#00C4AC" | "#199F0F" | "#E99C16" | "#1266CC" | "#c80009" | "#D0C800" | "#EA5515";
            marginRight: number;
            marginLeft: number;
            flexShrink: number;
        };
        '& .MuiChip-label': {
            paddingLeft: number;
        };
        '&:hover': {
            backgroundColor: string;
        };
    };
}[];
/**
 * Filled chip styles for colors that MUI's palette doesn't cover
 * (neutral, critical, high, medium, low). Solid background, high-contrast
 * text — use sparingly for the most prominent states.
 */
export declare const filledChipColorVariants: {
    props: {
        variant: "filled";
        color: "primary" | "critical" | "high" | "medium" | "low" | "info" | "neutral" | "success" | "warning" | "error";
    };
    style: {
        backgroundColor: string;
        color: string;
        '&:hover': {
            backgroundColor: string;
        };
        '& .MuiChip-deleteIcon': {
            color: string;
            '&:hover': {
                color: string;
            };
        };
    };
}[];
/**
 * Outlined chip styles for non-palette colors. Transparent background,
 * 1px color border, colored text. Ink is mode-aware via `chipLabelInk` so
 * Low / Medium yellows clear AA on white instead of shipping the dark-theme
 * tokens flat (1.76:1 / 2.27:1), and so Critical is not lightened into a
 * pink that fails on the light surface.
 */
export declare const outlinedChipColorVariants: {
    props: {
        variant: "outlined";
        color: "primary" | "critical" | "high" | "medium" | "low" | "info" | "neutral" | "success" | "warning" | "error";
    };
    style: ({ theme }: {
        theme: Theme;
    }) => {
        backgroundColor: string;
        color: string;
        border: string;
        '&:hover': {
            backgroundColor: string;
        };
        '& .MuiChip-deleteIcon': {
            color: string;
            '&:hover': {
                color: string;
            };
        };
    };
}[];
/**
 * Outlined + neutral.
 *
 * No `purpose` renders as this any more -- `picker` and `overflow` moved to
 * `fieldChipVariants` so the whole filter family shares one chrome. It stays for
 * the legacy `variant`/`color` API, which consumers can still pass directly, and
 * because the contrast fix below is the reason it exists at all.
 *
 * `chipColorMap.neutral` is `textColors.secondary` (`#AEAEAE`), a dark-theme
 * token, and `outlinedChipColorVariants` applies it as a flat value in both
 * modes. On the light theme's white paper that is **2.22:1** for the label and
 * the same for the border -- under the 4.5:1 AA floor for text and under the
 * 3:1 floor for a non-text boundary. The overflow chip has shipped with this;
 * the picker chip is the one whose entire label is drawn in it, which is what
 * made it worth fixing rather than recording.
 *
 * Deriving from `theme.palette.text.secondary` gives 7.73:1 on white, and in
 * dark mode that palette entry *is* `#AEAEAE`, so the dark theme is unchanged
 * to the pixel. Same technique as `lifecycleChipVariants` below, and the same
 * reason: a flat token cannot be correct in two modes.
 *
 * Registered after `outlinedChipColorVariants` in `components.ts`, since both
 * match this pair and the later variant wins.
 */
export declare const neutralOutlinedChipVariants: {
    props: {
        variant: "outlined";
        color: "neutral";
    };
    style: ({ theme }: {
        theme: Theme;
    }) => {
        backgroundColor: string;
        color: string;
        border: string;
        '&:hover': {
            backgroundColor: string;
        };
        '& .MuiChip-deleteIcon': {
            color: string;
            '&:hover': {
                color: string;
            };
        };
    };
}[];
/**
 * Outlined + primary, the appearance behind `Chip purpose="lifecycle"`.
 *
 * MUI already styles this pair, but its label takes `primary.main` unmodified,
 * and in the light theme that teal on white is 4.32:1 -- under the 4.5:1 AA
 * floor for text this size. Darkening it 10% there brings it to 5.17:1 while
 * the dark theme keeps the brighter token at ~8:1. Deriving from the palette
 * rather than the `brand` token is what makes that per-mode difference
 * possible at all.
 *
 * No hover style: every lifecycle stage is static, and a hover response on a
 * chip that cannot be clicked is a promise the component does not keep.
 */
export declare const lifecycleChipVariants: {
    props: {
        variant: "outlined";
        color: "primary";
    };
    style: ({ theme }: {
        theme: Theme;
    }) => {
        backgroundColor: string;
        color: string;
        border: string;
    };
}[];
/**
 * Button variants - the design system's canonical emphasis ladder:
 *
 * - `primary` - the single most important action in a view (solid brand accent).
 * - `secondary` - the default; a bordered, neutral, low-chrome action. Reads as
 *   a sibling of a text field or select at the same height, so it is the right
 *   choice for toolbars and inline groups of actions.
 * - `ghost` - lowest emphasis; transparent until hovered.
 * - `destructive` - irreversible/dangerous actions (delete, isolate, simulate);
 *   always pair with a confirmation step.
 *
 * These are custom variants, so each fully specifies its own background, text,
 * border, hover and disabled styling (MUI's built-in variant styles do not
 * apply). `borderRadius`/`textTransform`/`fontWeight` come from the shared
 * `MuiButton.root` override in `components.ts`.
 */
export declare const buttonVariants: ({
    props: {
        variant: "primary";
    };
    style: ({ theme }: {
        theme: Theme;
    }) => {
        backgroundColor: string;
        color: string;
        border: string;
        '&:hover': {
            backgroundColor: string;
        };
        '&.Mui-disabled': {
            backgroundColor: string;
            color: string;
        };
    };
} | {
    props: {
        variant: "secondary";
    };
    style: ({ theme }: {
        theme: Theme;
    }) => {
        backgroundColor: string;
        color: string;
        border: string;
        '&:hover': {
            borderColor: "#3A3A3A" | "#ADADAD";
            backgroundImage: string;
        };
        '&.Mui-disabled': {
            backgroundColor: string;
            color: string;
            borderColor: string;
        };
    };
} | {
    props: {
        variant: "ghost";
    };
    style: ({ theme }: {
        theme: Theme;
    }) => {
        backgroundColor: string;
        color: string;
        border: string;
        '&:hover': {
            backgroundColor: string;
        };
        '&.Mui-disabled': {
            backgroundColor: string;
            color: string;
        };
    };
} | {
    props: {
        variant: "destructive";
    };
    style: ({ theme }: {
        theme: Theme;
    }) => {
        backgroundColor: "#EB2D36";
        color: string;
        border: string;
        '&:hover': {
            backgroundColor: "#c80009";
        };
        '&.Mui-disabled': {
            backgroundColor: string;
            color: string;
        };
    };
})[];
/**
 * Size styles for the custom button variants.
 *
 * MUI ships its own size padding, but every one of those rules is matched
 * against `variant: 'text' | 'outlined' | 'contained'`. The emphasis ladder
 * above replaces those variants entirely, so without this cross-product a
 * `small` and a `large` Button render at identical dimensions. Scoping to the
 * custom variants leaves MUI's built-in variants on their stock sizing.
 */
export declare const buttonSizeVariants: {
    props: {
        variant: "primary" | "secondary" | "ghost" | "destructive";
        size: "medium" | "large" | "small";
    };
    style: {
        lineHeight: 1.4;
        minHeight: 28;
        fontSize: 12;
        padding: `4px ${number}px`;
    } | {
        lineHeight: 1.4;
        minHeight: 36;
        fontSize: 14;
        padding: "4px 16px";
    } | {
        lineHeight: 1.4;
        minHeight: 44;
        fontSize: 16;
        padding: "8px 24px";
    };
}[];
/**
 * Chip rungs that MUI does not ship (`large` / `extraLarge`).
 *
 * `small` and `medium` stay on `MuiChip` styleOverrides so existing
 * call sites do not move. These variants are keyed only on `size`.
 */
export declare const chipSizeVariants: ({
    props: {
        size: "large";
    };
    style: {
        height: 36;
        fontSize: 14;
    };
} | {
    props: {
        size: "extraLarge";
    };
    style: {
        height: 44;
        fontSize: 16;
    };
})[];