efficient-easel 0.0.0 → 0.96.0

package/dist/panel/index.d.ts

@@ -0,0 +1,1088 @@
+import * as react from 'react';
+import { ReactNode } from 'react';
+import { W as WordFit } from '../wordFit-9B9nqyf3.js';
+export { a as SETTINGS_BUCKETS, S as SettingsBucket } from '../buckets-1vRlQceY.js';
+
+/**
+ * The settings-panel primitives — the shared grammar BOTH editors' inspector
+ * panels are built from (owner-approved design, 2026-08-20).
+ *
+ * Every one is CONTROLLED and hook-free: the host owns which tab is active and
+ * which groups are open, exactly as the rail's host owns selection. That is what
+ * keeps this a directive-free leaf a Next-16 server component can import.
+ */
+/** One tab in the strip. `badge` shows a count (e.g. unsaved overrides). */
+interface SettingsTabItem {
+    /** What this tab IS, as `activeId` and `onSelect` name it. Not a DOM id. */
+    id: string;
+    /**
+     * What the tab is CALLED — and, since card 8810, its name in every tier.
+     *
+     * Required, and a plain string, on purpose. Give the tab an `icon` and a
+     * narrow panel takes this word off the screen, but never out of the tab: it
+     * stays in the markup and it is carried as `title` and `aria-label` on the
+     * button at every width. An icon-only control with no name is the exact
+     * defect card 8801 shipped and had to have caught in review, and a separate
+     * optional `ariaLabel` prop is how that happens again. Here it cannot — the
+     * name is the field the tab has always had, and it is not optional.
+     */
+    label: string;
+    /**
+     * An 18px glyph from `efficient-easel/icons`, so the tab can spend less width
+     * than its word needs when the panel is dragged narrow (card 8810).
+     *
+     * Optional, and the strip is unchanged without it: a tab with no glyph has
+     * nothing to fall back to, so it keeps its word at every width and the strip
+     * wraps for it exactly as it did before. Pass icons for ALL the tabs in a
+     * strip or none of them — a row that is half words and half glyphs below
+     * 270px reads as a rendering fault, not as a decision.
+     */
+    icon?: ReactNode;
+    badge?: number;
+    /**
+     * The DOM id of the element that shows this tab's settings — `aria-controls`.
+     *
+     * Without it a tab is announced as "tab, 1 of 4, selected" and there is no
+     * panel it is bound to, which is what `role="tab"` promises there will be.
+     * The shell cannot supply the id itself: only the host knows what element the
+     * settings land in, and in Puck's flat sibling list that element may be one
+     * the shell never rendered. Optional because a host that has no such element
+     * to point at should render NO attribute rather than one pointing nowhere.
+     */
+    panelId?: string;
+    /**
+     * A DOM id for the tab BUTTON, so the panel above can name itself with
+     * `aria-labelledby` and the pair is wired in both directions.
+     */
+    htmlId?: string;
+}
+interface SettingsTabsProps {
+    items: SettingsTabItem[];
+    /** The `id` of the tab currently shown. */
+    activeId: string;
+    onSelect: (id: string) => void;
+    ariaLabel?: string;
+    className?: string;
+}
+/**
+ * WHERE THIS STRIP'S WORDS STOP FITTING — the one thing the shell cannot know
+ * about a segmented control, measured by the consumer that owns the words.
+ *
+ * The same shape the top-bar rail hands the same rule (`WordFit`, in
+ * `src/fit/wordFit.ts`, where both numbers are described).
+ *
+ * MEASURE THEM, do not count letters. The chip's font resolves to SF on a Mac
+ * and Segoe UI on Windows, so one table of letter widths would be wrong on most
+ * machines; measured against real labels a letter-count guess is out by up to
+ * 7%, which is enough to drop a word that fits. Render the strip and read the
+ * label spans — `tests/fixtures/segmented-fit.html` does exactly that and
+ * prints both numbers. If a label is about to change and the number cannot be
+ * re-measured today, round it up.
+ */
+type SettingsSegmentedFit = WordFit;
+/**
+ * WHAT AN OPTION IS CALLED, and the one rule that governs it: EVERY option has a
+ * name, and the name is a string (card 66303).
+ *
+ * `label` is spent three ways — the visible mark, `title`, and `aria-label` — so
+ * it cannot simply be widened to a `ReactNode` and left there: a node reaches
+ * the two attributes as `[object Object]`, which is a tooltip that says nothing
+ * and a screen reader that says worse. Nor can it be split into `icon` + `label`
+ * and the word left to fall away at a threshold: both spans render, so a strip
+ * whose mark IS its label would draw the mark AND the word beside it.
+ *
+ * So the two cases are told apart in the type, and each carries its own name:
+ *
+ *   a WORDED option  `{ label: 'Left' }` — the word is the name. `title` is
+ *                    optional and almost never given; this is every option that
+ *                    exists today and none of them changes.
+ *   a DRAWN option   `{ label: <AlignGlyph/>, title: 'Left' }` — the mark cannot
+ *                    be read aloud, so `title` is REQUIRED and is the name.
+ *
+ * The part panel's Alignment row is the case that forced it: three alignments
+ * have no honest three-letter word between them, so the label is the rule
+ * itself. Case is the same shape one step milder — Aa / AA / aa are letterforms,
+ * not the words Normal / Uppercase / Lowercase that name them. Passing `title`
+ * beside a WORDED label is allowed and overrides the word, which is what a
+ * strip whose words are abbreviations wants.
+ *
+ * ── NO CONSUMER TODAY, AND CARRIED ON PURPOSE ────────────────────────────────
+ *
+ * Written down so the next reader does not find this unused and tidy it away.
+ * The rows above stopped needing it while this was being built: card 66246
+ * (`efficient-shop` 151afa212, merged 2026-08-31) moved the part panel's three
+ * tables onto `icon` + a real word — `{ id: "left", label: "Left", icon:
+ * <AlignLeftIcon/> }` — on the owner's ruling that an option says its name AND
+ * draws its glyph. Every `label` in the shop is now a string, and this arm has
+ * no caller anywhere. That is measured on merged main, not on a pending PR.
+ *
+ * It stays because it is the shape THE PACKAGE NEXT DOOR ALREADY USES.
+ * `efficient-shell` ships its own `Segmented`, and its `SegmentedOption` has
+ * carried `label: ReactNode` all along. Identical at the two copies installed on
+ * this desk — 4.63.0 under `editor-shell`, 4.67.0 under `efficient-shop`:
+ *
+ *     interface SegmentedOption<T extends string = string> {
+ *       value: T; label: ReactNode; icon?: ReactNode; disabled?: boolean;
+ *     }
+ *
+ * A shared control that refuses a shape its sibling accepts is a fork one level
+ * down, which is the fault this whole family of cards exists to stop. Matching
+ * it costs nothing while nothing calls it.
+ *
+ * ── WHERE THE TWO SHELLS CONVERGE, AND WHERE THEY DO NOT ─────────────────────
+ *
+ * Read this before repeating "the two shells are converged", because it is only
+ * true of three fields out of four, and the fourth is the one a caller touches
+ * most:
+ *
+ *                     efficient-shell          editor-shell
+ *     the label       label: ReactNode        label: ReactNode     converged
+ *     the glyph       icon?: ReactNode        icon?: ReactNode     converged
+ *     out of force    disabled?: boolean      disabled?: boolean   converged
+ *     ─────────────────────────────────────────────────────────────────────────
+ *     the VALUE       value: T                id: V                NOT converged
+ *                     T extends string        V unconstrained
+ *
+ * BOTH halves of that last row are deliberate.
+ *
+ * `id` and not `value`, because this field has been called `id` since the type
+ * existed and renaming it would move something for every caller already using
+ * it — which is the one thing card 66303 was not allowed to do.
+ *
+ * `V` UNCONSTRAINED and not `T extends string`, because the shop stores a
+ * choice as a boolean: `reverse` at `efficient-shop/lib/puck/config.tsx:6747` is
+ * `false` = image left and `true` = image right on every published page across
+ * every tenant. `T extends string` cannot hold it, and giving that row the house
+ * strip by storing "left"/"right" would be a migration of live customer data
+ * rather than a control change. So on the value type this package is the WIDER
+ * of the two, not the poorer — the opposite of the direction the rest of this
+ * note runs.
+ *
+ * ── AND WHERE WE DELIBERATELY GO FURTHER ─────────────────────────────────────
+ *
+ * That sibling declaration has NO name field beside its node label. A drawing
+ * that cannot name itself is exactly the defect the 2026-08-06 audit closed on
+ * the shop's strip, so the `title` here is REQUIRED — a guarantee, not a
+ * feature. The union makes a nameless drawing unconstructable rather than a
+ * documented risk; the sibling's shape permits one.
+ *
+ * One more thing that declaration settles, recorded because it was argued: its
+ * `disabled` is PER OPTION and it has no strip-level one at all. That is the
+ * independent support for the per-option field on
+ * `SettingsSegmentedOptionBase` — the sibling has shipped exactly that.
+ */
+type SettingsSegmentedLabel = {
+    label: string;
+    title?: string;
+} | {
+    label: ReactNode;
+    title: string;
+};
+interface SettingsSegmentedOptionBase<V = string> {
+    /**
+     * The VALUE this option writes, as `value` and `onChange` name it.
+     *
+     * `V` and not `string` since card 66303. A weight is a NUMBER — the storefront
+     * part panel's row is `[400, 500, 600, 700]` — and "Image side" is a BOOLEAN
+     * on every published page across every tenant, so giving those rows the house
+     * strip by storing "left"/"right" would be a migration of live customer data
+     * rather than a control change. `V` defaults to `string`, so every existing
+     * declaration means exactly what it did.
+     */
+    id: V;
+    /**
+     * A 16px glyph from `efficient-easel/icons`, so the option can spend less width
+     * than its word needs when the panel is dragged narrow.
+     *
+     * Optional, and the strip is unchanged without it: an option with no glyph
+     * has nothing to fall back to, so it keeps its word at every width. Pass
+     * glyphs for ALL the options or none of them — half words and half glyphs
+     * reads as a rendering fault, not as a decision.
+     *
+     * NOT the same thing as a DRAWN label. An `icon` is a glyph BESIDE the word,
+     * and the word is what it falls back from; a drawn label replaces the word
+     * altogether and is named by its `title`. An option wanting the second one
+     * puts the mark in `label`, not here.
+     */
+    icon?: ReactNode;
+    /**
+     * This choice exists but cannot be taken right now.
+     *
+     * Renders the button's own `disabled`, not a fade over it, and that is the
+     * whole point of it living here: this component owns the `<button>`, so a host
+     * dimming a parent instead leaves every segment focusable and announcing as
+     * ENABLED — the exact defect the 2026-08-06 audit and card 66034 closed.
+     *
+     * Dimmed, NEVER hidden, and the pressed segment still reads as pressed: the
+     * merchant's saved answer is still their answer, it simply is not in force.
+     * Defaults absent, so nothing an existing caller renders moves.
+     *
+     * NO CONSUMER TODAY, and it is carried on purpose rather than by oversight —
+     * so the next reader does not find it unused and tidy it away. The case it is
+     * for is one row away: card 66246 draws Weight as four letterform glyphs, and
+     * a merchant's typeface may only carry two real weights (measured there —
+     * Helvetica, Georgia, Verdana and Impact render Regular and Medium as the same
+     * letter, and Semibold and Bold as the same letter). That is a choice the
+     * strip CAN offer and the font cannot honour, which is this field and not the
+     * strip-level one beside it.
+     */
+    disabled?: boolean;
+}
+/** One option in a segmented control. */
+type SettingsSegmentedOption<V = string> = SettingsSegmentedOptionBase<V> & SettingsSegmentedLabel;
+/**
+ * A SEGMENTED CONTROL — the tab strip's chip, with the other promise.
+ *
+ * `SettingsTabs` is a TABLIST: its chips switch a panel, which is what
+ * `role="tab"` promises. These chips switch nothing. They write a value and the
+ * panel stays where it is, so they are pressed buttons in a group, and the
+ * marker is `aria-pressed` — the same one `efficient-shop`'s own `Segmented`
+ * has carried since the 2026-08-06 audit.
+ *
+ * NOT `radiogroup` / `aria-checked`, and the reason is the keyboard rather than
+ * the taxonomy. `role="radio"` promises roving focus: one Tab stop for the set,
+ * arrows moving between the options and selecting as they go. This is a
+ * hook-free controlled leaf — it owns no focus and runs no key handler, and a
+ * host cannot add one to a `<button>` it did not render. Radio roles over
+ * plain tab-stopped buttons would promise a keyboard that is not there, which
+ * is the same defect as `role="tab"` over no panel.
+ */
+interface SettingsSegmentedProps<V = string> {
+    /**
+     * `readonly` so a panel may declare its option table `as const` and keep the
+     * literal value types — which is how every one of them is already written.
+     * A widening only: a mutable array still binds.
+     */
+    options: readonly SettingsSegmentedOption<V>[];
+    /**
+     * The `id` of the option currently set.
+     *
+     * A value matching NO option presses nothing, and that is a state a caller
+     * relies on rather than an edge: the part panel hands `""` when the selection
+     * is mixed across several parts. The match is an EQUALITY and never a
+     * truthiness test — `false` is a real answer ("image left"), and `value ||
+     * fallback` collapses it into the other one.
+     */
+    value: V;
+    onChange: (next: V) => void;
+    /**
+     * What the group is called — "Weight", "Alignment". Required: a group of
+     * pressed buttons with no name is a set a screen reader cannot introduce.
+     */
+    ariaLabel: string;
+    /**
+     * Where this strip's words stop fitting. Optional, and WITHOUT IT NOTHING
+     * DROPS: an unmeasured strip keeps every word at every width, because the
+     * only alternative is guessing where to hide one. Give the options glyphs and
+     * this too, or the glyphs have nothing to fall back at.
+     */
+    fit?: SettingsSegmentedFit;
+    /**
+     * The whole strip exists but cannot apply right now, because another setting
+     * has taken the decision away — the Header's "Text colour at the top" under a
+     * pinned Background (card 66216).
+     *
+     * Every segment goes out of force AND the track says so, so the control goes
+     * quiet as one thing rather than as three identically faded chips. Per-option
+     * `disabled` is the other half of this: use that for a choice the strip cannot
+     * offer, and this for a strip the panel cannot offer.
+     *
+     * Dimmed, never hidden — a control that disappears reads as a feature that was
+     * removed, and leaves the merchant no way to see what to change to get it
+     * back. Defaults false, so every existing caller renders byte for byte as it
+     * did.
+     */
+    disabled?: boolean;
+    className?: string;
+}
+interface SettingsGroupProps {
+    /** The group's name — "Items", "Spacing", "Typeface". */
+    title: string;
+    /** Open state lives with the host, so it can persist it. */
+    open: boolean;
+    onToggle: (open: boolean) => void;
+    /**
+     * How many settings in this group differ from their default. Shown as a chip
+     * on the pill so a FOLDED group still admits it holds changes.
+     */
+    count?: number;
+    /** Ties the pill to its body for assistive tech (`aria-controls`). */
+    id?: string;
+    children: ReactNode;
+    className?: string;
+}
+/**
+ * A group heading with nothing folded under it — see `SettingsGroupHead`.
+ *
+ * Deliberately NOT `SettingsGroupProps` minus a few fields: a heading has no
+ * open state to own, nothing to toggle, and no count, because a heading hides
+ * nothing that a count would have to admit to.
+ */
+interface SettingsGroupHeadProps {
+    /** The heading's name — "Items", "Spacing", "Typeface". */
+    title: string;
+    /**
+     * Which heading level this is in the HOST's outline. Defaults to 3, the level
+     * a panel section sits at under a panel title; only the host knows what sits
+     * above it.
+     */
+    level?: 2 | 3 | 4 | 5 | 6;
+    /** A DOM id, so the rows it heads can point `aria-labelledby` at it. */
+    id?: string;
+    className?: string;
+}
+interface SettingsGroupSubProps {
+    /** The heading's name — "Content", "Background", "Image". */
+    title: string;
+    /**
+     * Which heading level this is in the HOST's outline. Defaults to 4 — one under
+     * `SettingsGroupHead`'s 3, because this tier sits under that pill. Only the
+     * host knows what is actually above it.
+     */
+    level?: 2 | 3 | 4 | 5 | 6;
+    /** A DOM id, so the rows it heads can point `aria-labelledby` at it. */
+    id?: string;
+    className?: string;
+}
+interface SettingsFieldProps {
+    label: string;
+    /**
+     * An `id` for the label text, so a control that cannot be reached by
+     * `htmlFor` can still be named by it.
+     *
+     * That is the boolean row: `htmlFor` associates a <label> with a form
+     * control, and a switch is a <button>. Give the label an id here and hand the
+     * same id to the switch's `ariaLabelledBy`, and the accessible name and the
+     * visible name are the same string.
+     */
+    labelId?: string;
+    /** An 18px glyph from `efficient-easel/icons` — one meaning, one SVG. */
+    icon?: ReactNode;
+    /** The current value, right-aligned on the label row ("34 px", "style"). */
+    value?: ReactNode;
+    /** One quiet line under the control. Use it instead of a clause-long label. */
+    hint?: ReactNode;
+    /** Marks the row as changed from its default: the label takes the accent. */
+    changed?: boolean;
+    /** Set when the control is a single form element, so the label points at it. */
+    htmlFor?: string;
+    /**
+     * A trailing control on the label row — a reset dot, a badge, or the SWITCH
+     * of a boolean row (card 8801, Option A: a yes-or-no setting is one line, not
+     * two, so the switch takes the spot a value like "34 px" normally sits in).
+     */
+    action?: ReactNode;
+    /**
+     * The control itself, on its own line under the label.
+     *
+     * OPTIONAL since card 8801, and only so a boolean row can put its switch in
+     * `action` and render no control line at all. Omitting it is not a way to
+     * draw a label on its own: a field with NO children and NO action has no
+     * control on either slot, so it renders nothing rather than leaving an empty
+     * row behind. Every field that passes a control is unaffected.
+     */
+    children?: ReactNode;
+    className?: string;
+}
+/**
+ * A switch has no text of its own, so without one of these it announces
+ * "switch, on" and nothing else. The union makes an unnamed switch a COMPILE
+ * error rather than a documented risk — both editors are about to grow six of
+ * these per panel, and every one is a chance to forget.
+ *
+ * Prefer `ariaLabelledBy` inside a `SettingsField`: point it at the field's
+ * `labelId` and the accessible name IS the visible label, one string doing two
+ * jobs, so the two cannot drift apart. `ariaLabel` is for a switch standing on
+ * its own with no visible label to point at.
+ *
+ * `?: never` on the other arm is what makes the two mutually exclusive while
+ * still letting the component destructure both names.
+ */
+type SettingsSwitchLabel = {
+    ariaLabel: string;
+    ariaLabelledBy?: never;
+} | {
+    ariaLabelledBy: string;
+    ariaLabel?: never;
+};
+interface SettingsSwitchBaseProps {
+    /** Whether the setting is on. The HOST owns it; the switch never flips itself. */
+    checked: boolean;
+    /** Asked to flip. `next` is the value the merchant wants, not the current one. */
+    onChange: (next: boolean) => void;
+    disabled?: boolean;
+    id?: string;
+    className?: string;
+}
+type SettingsSwitchProps = SettingsSwitchBaseProps & SettingsSwitchLabel;
+/**
+ * A DRILL-IN ROW — a name, a one-line preview, and a chevron that says pressing
+ * it takes the panel down a level (card 8819).
+ *
+ * The storefront editor's text editing becomes a drill-down: the section screen
+ * lists a section's text parts as these rows, and pressing one scopes the
+ * inspector to that one part's editor. It lives in the shell for the reason the
+ * rest of this grammar does — the campaign designer draws the same list, and a
+ * second hand-rolled copy is exactly how the two editors drift.
+ *
+ * CONTROLLED and hook-free like the other four: it holds no open/closed state of
+ * its own. Pressing it calls `onOpen`, and the HOST decides what drilling down
+ * means, because only the host owns the panel's navigation.
+ */
+interface SettingsDrillProps {
+    /** The part's name — the loud primary line ("Heading", "Slide name"). */
+    name: string;
+    /**
+     * One line of what the part reads as, shown quiet under the name and clipped
+     * with an ellipsis. Optional: a row can be a name alone, and an absent preview
+     * draws no empty second line rather than a blank one.
+     */
+    preview?: ReactNode;
+    /**
+     * Mark the PREVIEW as belonging to a part with no place on the page — an
+     * identifier the eye never draws (a `Slide name`), reachable only from this
+     * list. It reads quiet and italic. The mark is on the preview, not the row:
+     * the name still reads as a name.
+     */
+    offPage?: boolean;
+    /**
+     * A trailing glyph before the chevron — the "hidden on the page" eye is the
+     * standing case. A ReactNode, not a boolean, so the host owns the icon and its
+     * accessible name (a bare glyph says nothing to a screen reader on its own).
+     */
+    status?: ReactNode;
+    /** Asked to open. The host owns what drilling down does. */
+    onOpen: () => void;
+    /** A DOM id for the row button, so a host can point a label at it. */
+    id?: string;
+    className?: string;
+}
+/** One of the nine positions {@link SettingsPlacementProps} offers. */
+interface SettingsPlacementPoint {
+    /** What the host stores when this cell is pressed. Also the React key, so
+     *  the nine must be distinct. */
+    value: string;
+    /** The cell's accessible name — "Top left", "Centre". Read aloud on its own,
+     *  so it names the POSITION and never the value behind it. */
+    label: string;
+    /**
+     * This position cannot be chosen. The caller's arithmetic decides it (a
+     * position that already holds all it can draw), never this component.
+     * Disabled rather than absent: nine squares that became eight would read as
+     * a control that had broken.
+     */
+    disabled?: boolean;
+    /** Why, on hover. Falls back to {@link label}, so a plain cell still has a
+     *  tooltip and a closed one explains itself. */
+    title?: string;
+    /**
+     * Drawn IN PLACE OF the cell's dot, not beside it.
+     *
+     * The grid's default mark is a dot, because nine positions are answered by
+     * "which square", and a dot is the smallest thing that can say "this one".
+     * One control asks a different question with the same nine squares: the
+     * Scrolling Bar's `Scroll direction`, where four live cells mean a direction
+     * of TRAVEL and a dot cannot say which way. Those cells take an arrow.
+     *
+     * ⚠️ IT REPLACES THE DOT. A cell drawing both would put an arrow beside a dot
+     * inside a 26.67px square, and the dot would read as a second control. Leave
+     * it off and the cell renders exactly what it has always rendered — which is
+     * what keeps the five existing call sites byte-identical.
+     *
+     * Silent: the slot is `aria-hidden`, because the button around it already
+     * names the position and two voices in one cell is worse than one.
+     */
+    icon?: ReactNode;
+}
+/** One of the four corners {@link SettingsCornersProps} offers. */
+interface SettingsCornerPoint {
+    /** What the host stores when this corner is on. Also the React key and half
+     *  of the cell's class name, so the four must be distinct and CSS-safe. */
+    value: string;
+    /** The cell's accessible name — "Top left". Read aloud on its own, so it
+     *  names the CORNER and never the value behind it. */
+    label: string;
+    /**
+     * This corner cannot be chosen. The caller's arithmetic decides it (a box
+     * whose neighbour already rounds that edge), never this component. Disabled
+     * rather than absent: four cells that became three would read as a control
+     * that had broken.
+     */
+    disabled?: boolean;
+    /** Why, on hover. Falls back to {@link label}, so a plain cell still has a
+     *  tooltip and a closed one explains itself. */
+    title?: string;
+}
+interface SettingsCornersProps {
+    /** The group's accessible name. NOT drawn — the visible label belongs to the
+     *  `SettingsField` row around it, the same split `SettingsSwitch` makes. */
+    label: string;
+    /**
+     * The corners that are ON, already resolved by the host: this component has
+     * no opinion about what an absent or empty value means. An empty array is a
+     * real answer (every corner square), so a host that reads absence as "all
+     * four" resolves that before handing this in.
+     */
+    value: readonly string[];
+    /**
+     * The four cells. No default: a component that invented four corner values
+     * would be answering a question only the host can answer, and the order it
+     * stores them in is the host's too.
+     */
+    corners: readonly SettingsCornerPoint[];
+    /** The new set, in the order the cells were pressed. The host normalises. */
+    onChange: (next: string[]) => void;
+    /** A DOM id for the group, so a host can point a label at it. */
+    id?: string;
+    className?: string;
+}
+interface SettingsPlacementProps {
+    /** The radiogroup's accessible name. NOT drawn — the visible label belongs to
+     *  the `SettingsField` row around it, the same split `SettingsSwitch` makes. */
+    label: string;
+    /** The chosen position, already resolved by the host: this component has no
+     *  opinion about what an absent value means. */
+    value: string;
+    /**
+     * The nine cells, in reading order — top-left first, bottom-right last. No
+     * default: a component that invented nine positions would be answering a
+     * question only the host can answer, and the two callers ask different ones
+     * (a picture's focal point, a block's anchor).
+     */
+    points: readonly SettingsPlacementPoint[];
+    onChange: (next: string) => void;
+    /** A DOM id for the radiogroup, so a host can point a label at it. */
+    id?: string;
+    className?: string;
+}
+/**
+ * A FULL-WIDTH ACTION BUTTON that sits under a group's rows and COMMITS.
+ *
+ * "Apply to all cards" is the first caller: the merchant has styled one card and
+ * wants the other eleven to match. That is a WRITE, and a write is why this is
+ * not `SettingsDrill` with the chevron taken off — see the docblock on
+ * `SettingsAction` for the whole of that argument.
+ *
+ * Controlled and hook-free like every primitive here. The shell owns the look
+ * and the announcement; the host owns the words, the write and the timer that
+ * takes {@link SettingsActionBaseProps.done} back down.
+ */
+interface SettingsActionBaseProps {
+    /**
+     * What the button says — "Apply to all cards". The package supplies NO
+     * default, the way `SettingsCorners` invents no corner names: the words belong
+     * to the section that knows what it is about to rewrite.
+     */
+    label: ReactNode;
+    /** Pressed. The write is the host's; this component performs none of it. */
+    onPress: () => void;
+    /**
+     * The press is not available. A REAL `<button disabled>`, dimmed and still
+     * there — never hidden. A control that vanishes leaves a merchant looking for
+     * something they remember being there, and hiding it also takes away the one
+     * place the reason can be read. Say the reason in {@link
+     * SettingsActionNote.note}.
+     */
+    disabled?: boolean;
+    /**
+     * The confirmation state — the press has landed. The HOST owns it and owns the
+     * timer that takes it back down, because only the host knows when its write
+     * finished.
+     *
+     * The shell owns what it LOOKS like and, more importantly, that it is
+     * ANNOUNCED: this button rewrites things that are not on screen, so a host
+     * that only swapped its own label would get the words right and the
+     * announcement wrong. See `SettingsAction`'s `role="status"` region.
+     */
+    done?: boolean;
+    /**
+     * What the button says while {@link done} — "Applied to 12 cards". The host's
+     * words again, and the string the live region announces. Falls back to
+     * {@link label}, so a host that flips `done` without a second string still
+     * gets the state and the announcement rather than nothing.
+     */
+    doneLabel?: ReactNode;
+    /** A glyph before the words. `aria-hidden`: the label already names the press. */
+    icon?: ReactNode;
+    className?: string;
+}
+/**
+ * The note, and the id it needs to reach anybody.
+ *
+ * `note` is where "every card already matches" or "this rewrites all 12 cards"
+ * goes, and it is wired to the button by `aria-describedby` — which needs a DOM
+ * id, and this package is hook-free so it cannot invent one (no `useId`). The
+ * union makes the id a COMPILE error rather than a silent hole: pass a note and
+ * you must pass an `id`.
+ *
+ * ⚠️ THIS IS THE REASON THE CONTROL IS HERE RATHER THAN IN THE SHOP.
+ * `efficient-shop`'s own `components/AddChildRow.tsx` explains its disabled
+ * button with a `title`, and a `title` on a DISABLED button reaches no screen
+ * reader and no keyboard — the tooltip needs a hover the control no longer
+ * answers. That hole cannot be patched from the shop's side while the shop draws
+ * its own button, so the button moves here and brings the wiring with it.
+ *
+ * `?: never` on the other arm is what makes the two mutually exclusive while
+ * still letting the component destructure both names — the same shape
+ * {@link SettingsSwitchLabel} uses.
+ */
+type SettingsActionNote = {
+    note: ReactNode;
+    id: string;
+} | {
+    note?: never;
+    id?: string;
+};
+type SettingsActionProps = SettingsActionBaseProps & SettingsActionNote;
+
+/**
+ * The tab strip under the panel head.
+ *
+ * It replaces the old stack of fold headers a merchant had to open and hunt
+ * through: the buckets a section actually has become tabs, in one fixed order,
+ * so the panel keeps the same shape on every section. A section shows only the
+ * tabs it has — pass three items and three tabs render.
+ *
+ * Controlled: the host decides `activeId`. No hooks, no browser globals.
+ *
+ * A tab can be WIRED to what it shows (`panelId` / `htmlId` on the item). That
+ * is not decoration: `role="tab"` promises a panel, and a tab strip that names
+ * none announces "tab, 1 of 4, selected" over nothing. The shell cannot supply
+ * those ids — only the host knows the element the settings land in — but until
+ * card 8802.d it could not ACCEPT them either, so no host could fix it. A tab
+ * with nothing to point at renders no attribute at all; an empty
+ * `aria-controls` is worse than a missing one, because it names an element
+ * that does not exist instead of admitting there is none.
+ *
+ * A SEGMENTED CONTROL (card 66138). The strip is a grey track and the chosen
+ * bucket is a raised white chip on it. Lewis, looking at a real panel: the tab
+ * he is NOT on does not invite a click — it does not even look like a button.
+ * The track is the answer to that, because it makes every segment look
+ * pressable, where a mark under the chosen tab only ever made the chosen tab
+ * louder. It replaces the underline strip and card 8811's tint ground; see the
+ * long note on `.es-tab.is-active` in `panel.css`.
+ *
+ * A segment takes the width its OWN label needs and shares what is left over,
+ * rather than every segment taking the width of the widest label. Equal
+ * segments were measured and cost too much: three of them need a 267px track
+ * and four need 355px, against the 281px the shop's default panel gives.
+ *
+ * THE WORD DROPS WHERE IT STOPS FITTING. Natural widths fit two and three
+ * buckets across the whole panel-drag band; they do not fit four, where the
+ * last segment ends 39px past the panel edge. So given an `icon`, a segment can
+ * spend less width instead of more — the word goes and the glyph stays.
+ *
+ * Where that happens depends on HOW MANY buckets a section has, because with
+ * natural widths the question is about the sum of the labels:
+ *
+ *   two buckets     both words, at every width the panel drags to.
+ *   three buckets   words down to 240px, then glyph plus the chosen word.
+ *   four buckets    glyph plus the chosen word under 320px; glyphs under 200px.
+ *
+ * Which state is a CSS decision, taken against the PANEL's width — see the
+ * `@container` blocks in `panel.css`, and the wrapper below that gives them
+ * something to measure. React cannot know the answer at render time, and it
+ * does not need to: BOTH parts are always in the markup, and CSS shows the one
+ * that fits. The word is only ever hidden, never dropped, and the label rides
+ * along as `title` and `aria-label` on every tab in every state, so the glyph
+ * never has to speak for the tab.
+ *
+ * A tab with no icon is untouched at every width — it has nothing to fall back
+ * to, so it keeps its word.
+ */
+declare function SettingsTabs({ items, activeId, onSelect, ariaLabel, className, }: SettingsTabsProps): react.JSX.Element;
+
+/**
+ * A segmented control: one row of chips, one of them pressed.
+ *
+ * THE SAME CHIP AS `SettingsTabs`, AND A DIFFERENT PROMISE. Everything a
+ * merchant sees is shared — the grey track, the raised white chip for the one
+ * he is on, the glyph drawn at every width, the word that drops where it stops
+ * fitting. `panel.css` dresses both from one rule, so there is no second copy
+ * of the chip grammar to drift.
+ *
+ * What differs is what the control SAYS it does. `SettingsTabs` is a tablist
+ * and `role="tab"` promises that pressing a chip switches a panel. These chips
+ * switch nothing: they write a value and the panel stays where it is. So this
+ * is a group of pressed buttons, and its marker is `aria-pressed` — which is
+ * also what the storefront's own `Segmented` has carried since the 2026-08-06
+ * audit, so the two editors keep saying the same thing about the same control.
+ *
+ * That distinction is not decoration. Reach for `SettingsTabs` on a Weight row
+ * and a control that is correct today starts announcing "tab, 1 of 4, selected"
+ * over a panel that is not there — three times in one part panel. It is the
+ * same split the package already made between `SettingsGroup` and
+ * `SettingsGroupHead`: same pill, different promise, two components.
+ *
+ * Controlled: the host owns `value`. No hooks, no browser globals.
+ *
+ * ── WHERE THE WORD DROPS, AND WHY THE STRIP HAS TO SAY ───────────────────────
+ *
+ * The tab strip's tiers are keyed on how many tabs there are, which works
+ * because the shell knows those four words. It cannot work here. Measured
+ * (`tests/fixtures/segmented-fit.html`), Case — Normal / Uppercase / Lowercase
+ * — needs 296px for its words and Alignment — Left / Centre / Right — needs
+ * 221px. Both are three-option rows, and the panel drags between 181px and
+ * 281px, so a single three-option threshold is visibly wrong for one of them.
+ * Whether the words fit is a question about the SUM of the labels; the count is
+ * only a stand-in, and it stops standing in the moment a second strip arrives.
+ *
+ * So the strip carries its own measurement. `fit` is the width of its WORDS,
+ * nothing else — the chip's padding, glyph and gaps are the shell's, named on
+ * the panel root, and `panel.css` adds them. Those three custom properties
+ * (`wordFitVars`) are that measurement and the count, handed to the stylesheet, which
+ * compares them against the panel's live width in `calc()`. A container query
+ * could not: its condition takes a literal length, so it cannot ask a question
+ * whose answer is different for every strip.
+ *
+ * Without `fit` nothing drops — an unmeasured strip keeps every word at every
+ * width, which is exactly what a strip with no glyphs already does.
+ *
+ * ── WHAT CARD 66303 WIDENED, AND WHY IT HAD TO BE HERE ───────────────────────
+ *
+ * `efficient-shop` draws its own `Segmented` beside this one and could not stop:
+ * four things twelve live call sites need were missing here. Generic `V`
+ * (weights are numbers, "image side" is a boolean on every published page), a
+ * DRAWN label with its own `title`, and `disabled` — on one option or on the
+ * strip.
+ *
+ * The last two could not have been bridged by a wrapper the shop writes, which
+ * is the reason they are props and not a consumer's problem. This component
+ * renders the `<button>`s, so nothing outside it can disable them; dimming a
+ * parent instead leaves them focusable and announcing as ENABLED, which is the
+ * regression the 2026-08-06 audit and card 66034 closed. And `label` is spent as
+ * `title` and `aria-label` as well as the visible mark, so a node in it reaches
+ * both attributes as `[object Object]` — while splitting it into `icon` +
+ * `label` renders BOTH spans, and Alignment would draw the rule and the word
+ * "Left" beside it.
+ */
+declare function SettingsSegmented<V = string>({ options, value, onChange, ariaLabel, fit, disabled, className, }: SettingsSegmentedProps<V>): react.JSX.Element;
+
+/**
+ * A group of settings under a soft pill row that folds with − / +.
+ *
+ * The sign is drawn by `panel.css` from `aria-expanded`, so the open state has
+ * exactly one home (the attribute assistive tech already reads) instead of a
+ * second copy in the markup.
+ *
+ * `count` is the reason a fold here is safe: a folded group that holds changes
+ * still says so on its pill, so nothing a merchant changed can hide.
+ */
+declare function SettingsGroup({ title, open, onToggle, count, id, children, className, }: SettingsGroupProps): react.JSX.Element;
+
+/**
+ * A group heading with NO group under it — the pill on its own.
+ *
+ * It exists because Puck lays the inspector out as a FLAT sibling list: a field
+ * renders next to the heading above it, never inside it, so nothing here can
+ * wrap the rows that follow. Heading a run of settings is therefore a job for a
+ * component that heads and nothing else.
+ *
+ * `SettingsGroup` cannot do that job. It always renders its body div, and its
+ * pill is always a <button> carrying `aria-expanded`, `aria-controls` and the
+ * − / + sign. Used header-only it would draw a control that claims to expand
+ * something, does nothing when clicked, and tells a screen reader the same lie.
+ * A component that folds and a component that titles are two different things,
+ * and this is the one that titles.
+ *
+ * So it is a HEADING, not a control: a real <h3> (the level is the host's, since
+ * only the host knows the page outline around it) with no role bolted on, no
+ * expanded state, no sign, no body. In a flat list the heading list is the only
+ * structure a screen reader has left to navigate by, which is the whole reason
+ * this renders a heading element rather than a styled <div>.
+ *
+ * It wears `.es-group-head` — the same pill as a real group's — so a section
+ * that folds and a section that does not read as the same panel. `panel.css`
+ * scopes the cursor and the hover tint to `button.es-group-head`, so the
+ * heading does not offer a press it cannot honour.
+ *
+ * NO `count`. A folded group needs one because a fold can hide a change; a
+ * heading folds nothing, so nothing can hide behind it.
+ */
+declare function SettingsGroupHead({ title, level, id, className, }: SettingsGroupHeadProps): react.JSX.Element;
+
+/**
+ * The QUIET second tier — a heading one rung under `SettingsGroupHead`.
+ *
+ * It exists because a panel sometimes has two levels of heading and this package
+ * only ever drew one. `SettingsGroupHead` is a filled pill, and a pill cannot
+ * serve a tier AND its subordinate: two runs of settings under one pill each
+ * need a name, and giving them the same pill says they are siblings of the thing
+ * above them rather than parts of it.
+ *
+ * THE SHOP ALREADY DREW THIS LOOK, TWICE, WHICH IS WHY IT BELONGS HERE.
+ * `efficient-shop` hand-rolled `.sf-field-group` in the settings panel and
+ * `.sf-group-label` in the Layers tree, and they are the same type to the
+ * decimal — 10.5px / 600 / .07em / muted / uppercase. One look, hand-rolled in
+ * two panels of one editor, is the definition of a thing the shell should own.
+ *
+ * ⚠️ NOT THE PILL WITH ITS FILL SWITCHED OFF, and that is the whole reason this
+ * is a component and not a `variant` flag on the other one. The shop's own
+ * `WHY NOT SettingsGroupHead` docblock refused that shape in advance: a named
+ * look the shell draws, "not a boolean that switches the pill off. A flag whose
+ * job is to turn the design off moves the fork inside the shell instead of
+ * removing it." So there is no path from here to the pill's look and none back —
+ * two tiers, two looks, each one this package's own.
+ *
+ * WHY IT IS QUIET BY TYPE AND THE PILL IS LOUD BY GROUND. The pill separates
+ * itself from the settings around it with a fill; this separates itself with
+ * CASE and COLOUR and takes no ground at all. That is what lets the two sit in
+ * one panel without competing, and it is also why this tier can carry no rule:
+ * a hairline under a heading separates it from the rows it heads, which is the
+ * opposite of what a heading is for. Removing those rules is the change the
+ * owner asked for.
+ *
+ * A REAL HEADING, defaulting to `h4` — one under the pill's default `h3`,
+ * because that is where a subordinate heading sits when the pill above it took
+ * the 3. The host may say otherwise; only the host knows the outline around it.
+ * Puck lays an inspector out as a FLAT sibling list, so the heading list is the
+ * only structure a screen reader has left to navigate by.
+ *
+ * NO fold, no count, no sign, no body — the same discipline as
+ * {@link SettingsGroupHead}, and for the same reason: a component that folds and
+ * a component that titles are two different things, and this is one that titles.
+ */
+declare function SettingsGroupSub({ title, level, id, className, }: SettingsGroupSubProps): react.JSX.Element;
+
+/**
+ * One setting: a label row, then its control.
+ *
+ * The row is stacked rather than side-by-side so the control gets the panel's
+ * full width — a 308px panel cannot afford a label column AND a usable slider.
+ * The label reads small and quiet; the VALUE sits at the end of the same line in
+ * the text colour, which is what a merchant scans for. That contrast is the
+ * point: before this, label and value looked alike and the panel read as noise.
+ *
+ * `hint` is where a clause-long explanation goes. A label is a name, never a
+ * sentence.
+ *
+ * A BOOLEAN row is the one exception to "control on its own line" (card 8801,
+ * Option A, approved). A switch is small and it is the whole control, so it
+ * rides the label line in the `action` slot and the row costs one line instead
+ * of two — which is what lets a 308px panel show four settings where it used to
+ * show three. That is the only reason `children` is optional: a field with no
+ * children draws no control row, and its label line IS the row.
+ *
+ * A field with no children AND no action has no control on either slot. That is
+ * a mistake at the call site, so it renders NOTHING — an empty row would hide
+ * the mistake behind 20px of blank panel.
+ */
+declare function SettingsField({ label, labelId, icon, value, hint, changed, htmlFor, action, children, className, }: SettingsFieldProps): react.JSX.Element | null;
+
+/**
+ * The yes-or-no control — ONE shape, both editors (card 8801).
+ *
+ * Point 5 of the approved settings design says one switch style everywhere.
+ * Before this, the storefront editor drew a tick box and the campaign designer
+ * drew a green switch, so a merchant met two shapes for the same question and
+ * had to learn the control twice. Both now import this file, which is the only
+ * thing that stops them drifting apart again.
+ *
+ * It is a real <button>, and that is the whole keyboard story: a button is
+ * activated by Space and by Enter in every browser, and that activation IS a
+ * click — so the one `onClick` below serves mouse and keyboard alike. A div
+ * wearing `role="switch"` would need a key handler of our own. Do not add one.
+ * `type="button"` keeps it from submitting a form it happens to sit in.
+ *
+ * It cannot exist without a NAME. `SettingsSwitchProps` demands `ariaLabel` or
+ * `ariaLabelledBy` and forbids both at once, so an unnamed switch — which a
+ * screen reader reads out as "switch, on" and nothing more — is a compile error
+ * instead of something a docstring asks you to remember.
+ *
+ * ONE-WAY DEPENDENCY. `SettingsField` imports this module so it can recognise a
+ * switch in its `action` slot and hand it the field's label as a name. This
+ * module must NEVER import `SettingsField` back — that would close a cycle
+ * between two siblings in the same folder. It imports `./types` and nothing
+ * else, and `tests/settings-switch.test.tsx` (o) keeps it that way.
+ *
+ * CONTROLLED and hook-free like the other three: `checked` comes from the host
+ * and the switch only ever ASKS to be flipped. That is what keeps this module a
+ * directive-free leaf a Next-16 server component can import.
+ */
+declare function SettingsSwitch({ checked, onChange, disabled, id, ariaLabel, ariaLabelledBy, className, }: SettingsSwitchProps): react.JSX.Element;
+
+/**
+ * A DRILL-IN ROW — a name, a one-line preview, and a chevron (card 8819).
+ *
+ * The storefront editor's text editing becomes a panel drill-down: the section
+ * screen no longer holds a text box for every part; it LISTS the parts as these
+ * rows, and pressing one takes the inspector down a level to that part's own
+ * editor. A part the eye hid — or one that never draws on the page at all, like
+ * a `Slide name` — has no words on the canvas to click, so this list is the only
+ * way back to it. That is why the list exists, and why the row is the shell's,
+ * not the shop's: the campaign designer draws the same list.
+ *
+ * IT IS ONE BUTTON, not a control beside some text. The name and the preview are
+ * the button's own content, so they ARE its accessible name — a chevron floating
+ * next to unlabelled text would be a press a screen reader could not describe.
+ * The chevron is `aria-hidden` (pure direction); the status slot is NOT, because
+ * its meaning is the host's to name — it passes an icon carrying its own label
+ * (a `title`, a visually-hidden word), and hiding the slot would bury that.
+ *
+ * CONTROLLED and hook-free like the other four primitives: it owns no open state.
+ * Pressing it calls `onOpen`, and the host decides what drilling down means —
+ * which keeps this a directive-free leaf a Next-16 server component can import.
+ */
+declare function SettingsDrill({ name, preview, offPage, status, onOpen, id, className, }: SettingsDrillProps): react.JSX.Element;
+
+/**
+ * A 3×3 grid of positions, one of them lit — "which of these nine?".
+ *
+ * ONE CONTROL, TWO QUESTIONS THAT ARE THE SAME QUESTION. A merchant asks it of
+ * an image ("which part of this crop stays in view?") and of a block ("where on
+ * the thing behind it does this sit?"). Both are one of nine positions, both
+ * want the merchant to PRESS THE CORNER rather than read nine words out of a
+ * dropdown, and drawing them as two controls would be two things to keep
+ * looking alike for ever.
+ *
+ * ── WHY IT IS HERE NOW, AND WHY IT WAS NOT BEFORE ───────────────────────────
+ *
+ * It lived in `efficient-shop` as `FocalPicker`, and its own comment recorded
+ * the rule for moving it: card 66189 said *"the day a second section wants it,
+ * that is the card that promotes it"*. Card 66214 was that second caller and
+ * deliberately declined — the control was days old and had already changed
+ * signature once, so freezing its shape in a released package would have been
+ * early. That was right then.
+ *
+ * It is not right now: the shape has not moved since, and the sections that
+ * hold boxes take it past six call sites. A local copy with that many callers
+ * is the shape that becomes a second source, so it comes here — the rule its
+ * own author wrote, applied on the day it fires.
+ *
+ * ── WHAT IT DOES NOT DO ─────────────────────────────────────────────────────
+ *
+ * It renders the CONTROL only. The row around it — the glyph, the label, the
+ * caption — is `SettingsField`'s, exactly as `SettingsSwitch` splits. `label`
+ * is the radiogroup's accessible name, never a visible one.
+ *
+ * ── A CELL MAY DRAW A GLYPH INSTEAD OF ITS DOT ──────────────────────────────
+ *
+ * Nine positions are answered by "which square", and a dot is the smallest mark
+ * that says "this one". ONE control asks a different question with the same
+ * nine squares: the Scrolling Bar's `Scroll direction`, where four live cells
+ * mean a direction of TRAVEL — and a dot cannot say which way. Those cells pass
+ * an `icon` on the point, and it is drawn in place of the dot.
+ *
+ * THE GLYPH COMES FROM THE ICON LIBRARY, never from in here. `efficient-easel/icons`
+ * holds `direction-left`, `direction-right`, `direction-up` and `direction-down`
+ * for exactly this control. A shape drawn inside this component would be the
+ * second source of truth the whole package exists to prevent — the same rule
+ * that stops a panel drawing its own glyph one level up.
+ *
+ * It also holds no opinion about what a position MEANS. The host hands nine
+ * values and gets one back; whether that value becomes a CSS `object-position`
+ * or a grid anchor is the host's business, and keeping it that way is what lets
+ * one control answer both questions.
+ *
+ * Controlled and hook-free, like every primitive here, so a Next server
+ * component can import this module.
+ */
+declare function SettingsPlacement({ label, value, points, onChange, id, className, }: SettingsPlacementProps): react.JSX.Element;
+
+/**
+ * Four corners of a box, any number of them lit — "which of these corners?".
+ *
+ * ── WHY IT IS NOT {@link SettingsPlacement} WITH FOUR CELLS ──────────────────
+ *
+ * The nine-square asks WHICH ONE and gets one answer back; a radiogroup, and
+ * pressing a second cell releases the first. This asks WHICH ONES and gets a
+ * set: a merchant rounding a stack of boxes turns on the top two of the box at
+ * the top and the bottom two of the box at the bottom, so the run reads as one
+ * shape. Those are different questions with different keyboards — a radiogroup
+ * moves with the arrows and admits exactly one, a set is toggled with Space and
+ * admits any number — so they are two controls rather than one control with a
+ * `multiple` flag that changes what its own ARIA means.
+ *
+ * They still look like siblings, because a merchant meeting the second one
+ * should already know how to press it: the same track, the same chip, the same
+ * "the chosen thing is the darkest thing here" reading the placement grid and
+ * the segmented strip already share.
+ *
+ * ── THE CELL DRAWS THE ANSWER, NOT A DOT ────────────────────────────────────
+ *
+ * The placement grid's cell holds a dot, because a POSITION has no shape of its
+ * own to show. A corner does: each cell here holds a small square whose matching
+ * corner is rounded when the corner is on, and square when it is off. So the
+ * control is a picture of what the setting does rather than four labels a
+ * merchant has to hold in their head — and it stays readable for someone who
+ * cannot separate the accent from the ground, because the SHAPE carries the
+ * state as well as the fill.
+ *
+ * ── WHAT IT DOES NOT DO ─────────────────────────────────────────────────────
+ *
+ * It renders the CONTROL only. The row around it — the glyph, the label, the
+ * caption — is `SettingsField`'s, the same split `SettingsSwitch` and
+ * `SettingsPlacement` make. `label` is the group's accessible name, never a
+ * visible one.
+ *
+ * It also holds no opinion about what a corner MEANS. The host hands the four
+ * corners it wants offered and gets a set back; whether that set becomes a
+ * `border-radius` shorthand, four custom properties or a stored preset is the
+ * host's business, and keeping it that way is what lets one control serve a
+ * section box, a card and whatever asks next.
+ *
+ * ⚠️ IT HAS NO OPINION ABOUT "ALL FOUR" EITHER. An empty set is a real answer
+ * (every corner square) and so is a full one; a host that treats absence as
+ * "all four" resolves that BEFORE handing `value` in, exactly as the placement
+ * grid requires its value already resolved. A control that invented the default
+ * would be answering a question only the host can answer.
+ *
+ * Controlled and hook-free, like every primitive here, so a Next server
+ * component can import this module.
+ */
+declare function SettingsCorners({ label, value, corners, onChange, id, className, }: SettingsCornersProps): react.JSX.Element;
+
+/**
+ * A FULL-WIDTH BUTTON UNDER A GROUP'S ROWS THAT COMMITS A CHANGE.
+ *
+ * The storefront editor's first caller is "Apply to all cards": a merchant has
+ * styled one card and wants the other eleven to match. It sits at the bottom of
+ * the group whose rows it copies, it is one press wide, and pressing it WRITES.
+ *
+ * ── WHY IT IS NOT `SettingsDrill` RENAMED ───────────────────────────────────
+ *
+ * A DRILL NAVIGATES. Its row is a name, a one-line preview and a chevron; it
+ * commits nothing, and pressing it takes the panel down a level to the part's
+ * own editor. The chevron is the promise: something opens, nothing changes, and
+ * the way back is the way you came.
+ *
+ * THIS COMMITS AND STAYS PUT. No preview, because there is no value to preview —
+ * it holds none. No chevron, because nothing opens. A disabled state that
+ * explains ITSELF, which a drill has no need of: a row that only navigates is
+ * rarely unavailable, and this one is unavailable often (every card already
+ * matches, nothing to copy yet). And a CONFIRMATION state, which a drill has no
+ * concept of at all — a doorway does not report back.
+ *
+ * Pointing a drill at this would ship a row that LOOKS LIKE A DOORWAY and is
+ * actually a write. A merchant who has learnt that these rows open something
+ * would press it to look, and eleven cards would change.
+ *
+ * ── THE PRESS IS ANNOUNCED, NOT JUST DRAWN ──────────────────────────────────
+ *
+ * The whole point of this button is that it rewrites things that are NOT ON
+ * SCREEN — the other eleven cards, the sections below the fold. So the change
+ * has to arrive as words: the `role="status" aria-live="polite"` region is the
+ * shell's, and it is why `done` is a prop rather than a label swap the host
+ * could do on its own. A host that only swapped the label would get the words
+ * right and the announcement wrong, and nobody reviewing that diff would see the
+ * hole — which is the kind of thing this package exists to hold once.
+ *
+ * The region is rendered EMPTY until `done`, and the announcement is the text
+ * arriving in a region that was already there. A region that appears at the same
+ * moment as its text is not reliably announced.
+ *
+ * ── AND THE NOTE IS WHY IT IS HERE RATHER THAN IN THE SHOP ──────────────────
+ *
+ * `note` is wired to the button by `aria-describedby`. `efficient-shop`'s own
+ * `components/AddChildRow.tsx` explains its disabled button with a `title`, and
+ * a `title` on a disabled button reaches no screen reader and no keyboard — the
+ * tooltip wants a hover the control has stopped answering. The shop cannot patch
+ * that from its own side while it draws its own button.
+ *
+ * Controlled and hook-free, like every primitive here, so a Next-16 server
+ * component can import this module. The host owns the write, the `done` flag and
+ * the timer that takes it back down.
+ */
+declare function SettingsAction({ label, onPress, disabled, note, done, doneLabel, icon, id, className, }: SettingsActionProps): react.JSX.Element;
+
+export { SettingsAction, type SettingsActionBaseProps, type SettingsActionNote, type SettingsActionProps, type SettingsCornerPoint, SettingsCorners, type SettingsCornersProps, SettingsDrill, type SettingsDrillProps, SettingsField, type SettingsFieldProps, SettingsGroup, SettingsGroupHead, type SettingsGroupHeadProps, type SettingsGroupProps, SettingsGroupSub, type SettingsGroupSubProps, SettingsPlacement, type SettingsPlacementPoint, type SettingsPlacementProps, SettingsSegmented, type SettingsSegmentedFit, type SettingsSegmentedOption, type SettingsSegmentedProps, SettingsSwitch, type SettingsSwitchBaseProps, type SettingsSwitchLabel, type SettingsSwitchProps, type SettingsTabItem, SettingsTabs, type SettingsTabsProps };