@promptctl/rich-js 0.17.0 → 0.18.0

package/dist/themes/ramp.js

@@ -1,122 +0,0 @@
-/**
- * A color ramp: a number mapped onto a color through ordered stops.
- *
- * "What does 73 % spent look like" has no answer in a vocabulary of discrete
- * adjustments (`darken`, `mix`, `contrastOn`): each takes colors and returns a
- * color, and none takes a *measurement*. Without a ramp the answer gets
- * computed outside the theme system — a script emits a hex, a template
- * branches `if ge .pct 80 … else if ge .pct 50 …` — and that color decision
- * can no longer transpose with the palette it was meant to belong to. A ramp
- * is the one function whose input is a number, so the decision stays inside.
- *
- * A threshold cascade is a ramp too: the same stops with a `step` easing hold
- * each color until the next position, which is exactly `≥ threshold → hotter`
- * written as data. [LAW:one-type-per-behavior] One primitive; the easing is a
- * value, so a gradient and a cascade differ by one word, not by which function
- * was called.
- *
- * Interpolation is in OKLCH (`Oklch.mix`), so a `linear` ramp between two
- * theme colors passes through perceptually even steps rather than the muddy
- * midpoints of an sRGB blend.
- *
- * [LAW:one-way-deps] Imports `core/color` and `core/oklch` only; nothing here
- * knows what a palette is. Resolving stop *names* is the template binding's
- * job (`paletteFuncs`), which hands this module resolved colors.
- */
-import { Oklch } from "../core/oklch.js";
-/**
- * How a value between two stops maps to progress along them. Each easing is
- * a function on segment progress `t ∈ [0, 1)` — `linear` keeps it, `step`
- * holds the left stop for the whole segment.
- *
- * [LAW:dataflow-not-control-flow] The easing is looked up by name and applied
- * unconditionally; `at` runs the same code for a gradient and a cascade.
- */
-export const RAMP_EASINGS = {
-    linear: (t) => t,
-    step: () => 0,
-};
-export const RAMP_EASING_NAMES = Object.keys(RAMP_EASINGS);
-/**
- * The gate a spelled easing crosses. [LAW:parse-dont-validate] — returns the
- * narrowed name, so `ColorRamp` never re-checks. Unknown names throw naming
- * every legal one. [LAW:no-silent-failure]
- */
-export function parseRampEasing(name) {
-    if (!Object.hasOwn(RAMP_EASINGS, name)) {
-        throw new RangeError(`unknown ramp easing ${JSON.stringify(name)}; expected one of ` +
-            RAMP_EASING_NAMES.map((n) => JSON.stringify(n)).join(", "));
-    }
-    return name;
-}
-/**
- * An immutable ramp over stops sorted by position.
- *
- * [LAW:single-enforcer] The constructor is the one place a ramp's shape is
- * checked — at least one stop, every position finite, positions
- * non-decreasing — matching the `ColorRgba`/`Oklch` pattern. Positions are
- * required to arrive in order rather than being sorted here: a ramp whose
- * stops are read from configuration (`warning at 80, error at 50`) is an
- * authoring mistake, and sorting would quietly render a different ramp than
- * the one written. [LAW:no-silent-failure]
- *
- * Two stops may share a position: that is a hard edge, the later color
- * taking over at exactly that value (CSS gradients spell a hard stop the
- * same way).
- */
-export class ColorRamp {
-    easing;
-    stops;
-    constructor(easing, stops) {
-        this.easing = easing;
-        this.stops = stops;
-        if (stops.length === 0) {
-            throw new RangeError("a ColorRamp needs at least one stop");
-        }
-        for (const [i, stop] of stops.entries()) {
-            if (!Number.isFinite(stop.at)) {
-                throw new RangeError(`ColorRamp stop ${i} has a non-finite position ${stop.at}`);
-            }
-            const prev = stops[i - 1];
-            if (prev !== undefined && stop.at < prev.at) {
-                throw new RangeError(`ColorRamp stops must be in ascending position order; ` +
-                    `stop ${i} at ${stop.at} follows stop ${i - 1} at ${prev.at}`);
-            }
-        }
-    }
-    /**
-     * The color at `value`. Below the first stop it is the first color; at or
-     * above the last stop it is the last; between two stops it is `easing`
-     * of the way from the lower to the upper, so a value exactly on a stop is
-     * that stop's color, byte for byte.
-     *
-     * The two endpoint returns are the exactness contract, not a shortcut:
-     * the sRGB → OKLCH → sRGB round-trip can land a channel one unit off, and a
-     * ramp that does not hit its own stops exactly would make a `step` ramp
-     * paint a color the author never wrote.
-     */
-    at(value) {
-        if (!Number.isFinite(value)) {
-            throw new RangeError(`ColorRamp.at needs a finite value, got ${value}`);
-        }
-        const stops = this.stops;
-        // The last stop at or below `value`; -1 when `value` is below them all.
-        let lower = -1;
-        while (lower + 1 < stops.length && stops[lower + 1].at <= value)
-            lower++;
-        if (lower < 0)
-            return stops[0].color;
-        const from = stops[lower];
-        if (lower === stops.length - 1)
-            return from.color;
-        // `to.at > value >= from.at` by construction of `lower`, so the segment
-        // has positive width and `t ∈ [0, 1)`.
-        const to = stops[lower + 1];
-        const t = RAMP_EASINGS[this.easing]((value - from.at) / (to.at - from.at));
-        if (t <= 0)
-            return from.color;
-        if (t >= 1)
-            return to.color;
-        return Oklch.fromRgba(from.color).mix(Oklch.fromRgba(to.color), t).toRgba();
-    }
-}

package/dist/themes/registry.d.ts

@@ -1,43 +0,0 @@
-import { ColorRgba } from "../core/color.js";
-import { Palette } from "./palette.js";
-import { type ThemeName } from "./data/index.js";
-export type { ThemeName };
-/**
- * Returns the static list of available theme names. Pure and synchronous.
- */
-export declare function listThemePalettes(): readonly ThemeName[];
-/**
- * Returns the Palette for `name`, or `null` if unknown.
- *
- * Synchronous: theme data is bundled at compile time via the data barrel,
- * so no I/O happens here. The Palette itself (which requires hex-parsing
- * ~150 vars into ColorRgba values) is constructed lazily on first request
- * and cached — subsequent calls for the same name return the same instance.
- */
-export declare function getThemePalette(name: ThemeName): Palette;
-export declare function getThemePalette(name: string): Palette | null;
-/**
- * The eight base colors every theme must declare. Returned by
- * `getThemeBaseColors` for callers (notably `terminalThemes.ts`) that only
- * need the substrate and would otherwise pay the cost of hydrating the
- * full ~150-var palette and polluting the registry cache.
- */
-export interface ThemeBaseColors {
-    readonly name: string;
-    readonly dark: boolean;
-    readonly bg: ColorRgba;
-    readonly fg: ColorRgba;
-    readonly primary: ColorRgba;
-    readonly secondary: ColorRgba;
-    readonly accent: ColorRgba;
-    readonly success: ColorRgba;
-    readonly warning: ColorRgba;
-    readonly error: ColorRgba;
-}
-/**
- * Read just the eight base colors from a theme's data file. Cheap — parses
- * 8 hex strings, allocates no Palette, touches no cache. Use this when you
- * want a `TerminalTheme`-shaped substrate without forcing the full ~150-var
- * palette through the registry's hydration path.
- */
-export declare function getThemeBaseColors(name: ThemeName): ThemeBaseColors;

package/dist/themes/registry.js

@@ -1,82 +0,0 @@
-import { parseRgbHex, parseRgbaHex } from "../core/color.js";
-import { Palette } from "./palette.js";
-import { THEMES } from "./data/index.js";
-const THEME_NAMES = Object.freeze(Object.keys(THEMES).sort());
-const cache = new Map();
-/**
- * Returns the static list of available theme names. Pure and synchronous.
- */
-export function listThemePalettes() {
-    return THEME_NAMES;
-}
-export function getThemePalette(name) {
-    if (!isThemeName(name))
-        return null;
-    const cached = cache.get(name);
-    if (cached !== undefined)
-        return cached;
-    const palette = hydrate(THEMES[name]);
-    cache.set(name, palette);
-    return palette;
-}
-function isThemeName(name) {
-    return Object.hasOwn(THEMES, name);
-}
-/**
- * Read just the eight base colors from a theme's data file. Cheap — parses
- * 8 hex strings, allocates no Palette, touches no cache. Use this when you
- * want a `TerminalTheme`-shaped substrate without forcing the full ~150-var
- * palette through the registry's hydration path.
- */
-export function getThemeBaseColors(name) {
-    const data = THEMES[name];
-    return {
-        name: data.name,
-        dark: data.dark,
-        bg: requireBaseVar(data, "background"),
-        fg: requireBaseVar(data, "foreground"),
-        primary: requireBaseVar(data, "primary"),
-        secondary: requireBaseVar(data, "secondary"),
-        accent: requireBaseVar(data, "accent"),
-        success: requireBaseVar(data, "success"),
-        warning: requireBaseVar(data, "warning"),
-        error: requireBaseVar(data, "error"),
-    };
-}
-function requireBaseVar(data, key) {
-    const v = data.vars[key];
-    if (v === undefined) {
-        throw new Error(`Theme ${data.name}: required base var "${key}" missing from data file`);
-    }
-    return parseHex(v, data.name, key);
-}
-/**
- * Parse a `ThemePaletteData`'s hex strings into a Palette of ColorRgba.
- *
- * [LAW:single-enforcer] Hex → ColorRgba conversion for theme data lives
- * here, not on Palette. Keeping the parser in this module preserves the
- * `core/color → themes/palette` one-way edge (palette.ts must not import
- * ColorRgba as a value, or it cycles with core/color's own use of Palette
- * for INTERNAL_DEFAULT_THEME).
- */
-function hydrate(data) {
-    const map = new Map();
-    for (const [k, v] of Object.entries(data.vars)) {
-        map.set(k, parseHex(v, data.name, k));
-    }
-    return new Palette(data.name, data.dark, map);
-}
-// [LAW:single-enforcer] This is the loud-failure boundary for theme hex
-// data. `parseRgbHex`/`parseRgbaHex` in core/color.ts trust their input
-// shape (they assume the caller validated); here we are the caller from
-// the untrusted side (authored data files) and the place that has to
-// reject `"0G"`, `""`, `"#GGGGGG"`, etc.
-const HEX_RE = /^[0-9a-fA-F]+$/;
-function parseHex(value, theme, key) {
-    const hex = value.startsWith("#") ? value.slice(1) : value;
-    if ((hex.length !== 6 && hex.length !== 8) || !HEX_RE.test(hex)) {
-        throw new Error(`Theme ${theme}: var ${key} has invalid hex ${JSON.stringify(value)} ` +
-            `(expected #RRGGBB or #RRGGBBAA)`);
-    }
-    return hex.length === 6 ? parseRgbHex(hex) : parseRgbaHex(hex);
-}

package/dist/themes/terminalThemes.d.ts

@@ -1,54 +0,0 @@
-/**
- * Pre-built `TerminalTheme` constants — every theme in the registry has a
- * matching `<NAME>` export here. There is no inline-only theme; the data
- * file is the single source of truth for every theme's hex values.
- *
- * Editing `data/<name>.ts` updates both the registry's full ~150-var
- * palette (via `getThemePalette(name)`) AND the matching `TerminalTheme`
- * constant exported below (via `getThemeBaseColors(name)`, which pulls
- * just the 8 substrate keys). The two views never drift because both
- * derive from the same authored data.
- *
- * [LAW:one-source-of-truth] Hex values live in `data/<name>.ts`. This
- * module is a derived view that builds a `TerminalTheme` from each
- * theme's eight base colors via `buildPalette` for the substrate palette
- * and `STANDARD_TABLE` for the ANSI substrate.
- *
- * [LAW:one-type-per-behavior] Every theme has the same shape — name,
- * `dark` flag, full Palette in the registry, `TerminalTheme` constant
- * here. Consumers can pick any theme by name without branching on which
- * APIs work for it.
- *
- * [LAW:one-way-deps] `core/color → themes/palette` remains the only edge
- * into themes/. This file imports only sibling theme modules and core
- * color primitives; nothing in `core/` imports back.
- *
- * Note on `ansiColors`: every preset theme uses `STANDARD_TABLE`. Theme
- * identity lives in the semantic `palette`, not in the standard ANSI
- * 16/256 LUT — `ColorSpec.parse("red")` is intentionally canonical across
- * themes, matching Textual's model.
- */
-import { TerminalTheme } from "../core/color.js";
-export declare const DEFAULT_TERMINAL_THEME: TerminalTheme;
-export declare const SVG_EXPORT_THEME: TerminalTheme;
-export declare const MONOKAI: TerminalTheme;
-export declare const NORD: TerminalTheme;
-export declare const GRUVBOX: TerminalTheme;
-export declare const DRACULA: TerminalTheme;
-export declare const TOKYO_NIGHT: TerminalTheme;
-export declare const FLEXOKI: TerminalTheme;
-export declare const CYBERPUNK: TerminalTheme;
-export declare const CATPPUCCIN_MOCHA: TerminalTheme;
-export declare const CATPPUCCIN_LATTE: TerminalTheme;
-export declare const CATPPUCCIN_FRAPPE: TerminalTheme;
-export declare const CATPPUCCIN_MACCHIATO: TerminalTheme;
-export declare const SOLARIZED_DARK: TerminalTheme;
-export declare const SOLARIZED_LIGHT: TerminalTheme;
-export declare const ROSE_PINE: TerminalTheme;
-export declare const ROSE_PINE_MOON: TerminalTheme;
-export declare const ROSE_PINE_DAWN: TerminalTheme;
-export declare const ATOM_ONE_DARK: TerminalTheme;
-export declare const ATOM_ONE_LIGHT: TerminalTheme;
-export declare const TEXTUAL_DARK: TerminalTheme;
-export declare const TEXTUAL_LIGHT: TerminalTheme;
-export declare const TEXTUAL_ANSI: TerminalTheme;

package/dist/themes/terminalThemes.js

@@ -1,68 +0,0 @@
-/**
- * Pre-built `TerminalTheme` constants — every theme in the registry has a
- * matching `<NAME>` export here. There is no inline-only theme; the data
- * file is the single source of truth for every theme's hex values.
- *
- * Editing `data/<name>.ts` updates both the registry's full ~150-var
- * palette (via `getThemePalette(name)`) AND the matching `TerminalTheme`
- * constant exported below (via `getThemeBaseColors(name)`, which pulls
- * just the 8 substrate keys). The two views never drift because both
- * derive from the same authored data.
- *
- * [LAW:one-source-of-truth] Hex values live in `data/<name>.ts`. This
- * module is a derived view that builds a `TerminalTheme` from each
- * theme's eight base colors via `buildPalette` for the substrate palette
- * and `STANDARD_TABLE` for the ANSI substrate.
- *
- * [LAW:one-type-per-behavior] Every theme has the same shape — name,
- * `dark` flag, full Palette in the registry, `TerminalTheme` constant
- * here. Consumers can pick any theme by name without branching on which
- * APIs work for it.
- *
- * [LAW:one-way-deps] `core/color → themes/palette` remains the only edge
- * into themes/. This file imports only sibling theme modules and core
- * color primitives; nothing in `core/` imports back.
- *
- * Note on `ansiColors`: every preset theme uses `STANDARD_TABLE`. Theme
- * identity lives in the semantic `palette`, not in the standard ANSI
- * 16/256 LUT — `ColorSpec.parse("red")` is intentionally canonical across
- * themes, matching Textual's model.
- */
-import { STANDARD_TABLE, TerminalTheme, } from "../core/color.js";
-import { buildPalette } from "./buildPalette.js";
-import { getThemeBaseColors } from "./registry.js";
-function defineTheme(d) {
-    return new TerminalTheme(d.bg, d.fg, STANDARD_TABLE, buildPalette(d.name, d.dark, {
-        primary: d.primary,
-        secondary: d.secondary,
-        accent: d.accent,
-        success: d.success,
-        warning: d.warning,
-        error: d.error,
-        background: d.bg,
-        foreground: d.fg,
-    }));
-}
-export const DEFAULT_TERMINAL_THEME = defineTheme(getThemeBaseColors("default"));
-export const SVG_EXPORT_THEME = defineTheme(getThemeBaseColors("svg-export"));
-export const MONOKAI = defineTheme(getThemeBaseColors("monokai"));
-export const NORD = defineTheme(getThemeBaseColors("nord"));
-export const GRUVBOX = defineTheme(getThemeBaseColors("gruvbox"));
-export const DRACULA = defineTheme(getThemeBaseColors("dracula"));
-export const TOKYO_NIGHT = defineTheme(getThemeBaseColors("tokyo-night"));
-export const FLEXOKI = defineTheme(getThemeBaseColors("flexoki"));
-export const CYBERPUNK = defineTheme(getThemeBaseColors("cyberpunk"));
-export const CATPPUCCIN_MOCHA = defineTheme(getThemeBaseColors("catppuccin-mocha"));
-export const CATPPUCCIN_LATTE = defineTheme(getThemeBaseColors("catppuccin-latte"));
-export const CATPPUCCIN_FRAPPE = defineTheme(getThemeBaseColors("catppuccin-frappe"));
-export const CATPPUCCIN_MACCHIATO = defineTheme(getThemeBaseColors("catppuccin-macchiato"));
-export const SOLARIZED_DARK = defineTheme(getThemeBaseColors("solarized-dark"));
-export const SOLARIZED_LIGHT = defineTheme(getThemeBaseColors("solarized-light"));
-export const ROSE_PINE = defineTheme(getThemeBaseColors("rose-pine"));
-export const ROSE_PINE_MOON = defineTheme(getThemeBaseColors("rose-pine-moon"));
-export const ROSE_PINE_DAWN = defineTheme(getThemeBaseColors("rose-pine-dawn"));
-export const ATOM_ONE_DARK = defineTheme(getThemeBaseColors("atom-one-dark"));
-export const ATOM_ONE_LIGHT = defineTheme(getThemeBaseColors("atom-one-light"));
-export const TEXTUAL_DARK = defineTheme(getThemeBaseColors("textual-dark"));
-export const TEXTUAL_LIGHT = defineTheme(getThemeBaseColors("textual-light"));
-export const TEXTUAL_ANSI = defineTheme(getThemeBaseColors("textual-ansi"));

package/dist/themes/transpose.d.ts

@@ -1,87 +0,0 @@
-/**
- * Transpose a Palette to a new "key" — analogous to transposing a melody.
- *
- *   melody / chord progression  ::  Palette (relationships between colors)
- *                key (signature) ::  ThemeKey (hue / chroma / lightness deltas)
- *      "in C major" / "in D…"   ::  the resulting transposed Palette
- *
- * Because OKLCH is perceptually uniform, "+30° hue" looks like a
- * consistent jump everywhere on the color wheel — the way a perfect-fifth
- * interval sounds the same in every musical key. Transposition is closed
- * under composition: `transpose(transpose(p, k1), k2)` produces the same
- * colors as a single transpose with the combined deltas, modulo round-trip
- * quantization.
- *
- * [LAW:dataflow-not-control-flow] A single uniform per-color transform
- * runs for every var in the palette. Anchor protection selects *which*
- * `ThemeKey` to apply (data), not *whether* to apply one (branch).
- *
- * [LAW:one-source-of-truth] Anchor classification lives only in
- * `ANCHORED_ROOTS` below. The buildPalette derivation guarantees every
- * variant of a semantic root shares the root as its hyphen prefix
- * (`error`, `error-darken-1`, `error-lighten-2`, ...), so one set covers
- * the whole family.
- *
- * [LAW:one-way-deps] Imports flow `core/oklch → themes/transpose`;
- * nothing in core/ depends back on this file.
- */
-import { type ThemeKey } from "../core/oklch.js";
-import { Palette } from "./palette.js";
-/**
- * Semantic roots whose hue is locked under transposition. `error` must
- * look red-ish, `success` green-ish, `warning` amber-ish — rotating the
- * hue would make the UI lie about meaning. Lightness and chroma *still*
- * transform for these roles, so they invert correctly during dark↔light
- * flips and respond to chroma scaling alongside everything else.
- */
-export declare const ANCHORED_ROOTS: ReadonlySet<string>;
-/**
- * Whether a palette var's hue is locked under transposition. The single
- * predicate used by `transposePalette`. Exported so callers building
- * higher-level theme machinery can stay consistent with the locking rule.
- */
-export declare function isAnchored(varName: string): boolean;
-/**
- * Return a new `Palette` whose colors are the transposition of `palette`'s
- * colors by `key`. Pure. Identity (`IDENTITY`) returns a Palette with byte-exact
- * colors — fast-pathed so identity does not pay the sRGB↔OKLCH round-trip
- * quantization cost.
- *
- * The `dark` flag of the result is derived from the actual lightness of
- * the resulting `background` var (`Oklch.fromRgba(bg).l < 0.5`) — *not*
- * from the key's coefficients. The strongest theorem: "dark iff
- * background is dark." This is honest under every transform — pure
- * lightness shifts, mirror-inversions, hue rotations that don't touch L,
- * and combinations of all three. [LAW:types-are-the-program]
- *
- * The transposing path throws if the palette has no `background` var (the
- * `dark`-flag derivation has nothing to read). Failing loudly is preferred
- * over a silent fallback because the alternative — trusting the source
- * `palette.dark` after an arbitrary L-transform — produces flags that lie.
- * The identity fast-path is exempt: it preserves the source `dark` flag
- * verbatim (no derivation), so it needs no `background` and never throws.
- *
- * @param name Optional override for the resulting palette name. Defaults
- *   to the source palette's name. Callers building a family of transposed
- *   palettes (e.g. "gruvbox +60°") supply their own.
- */
-export declare function transposePalette(palette: Palette, key: ThemeKey, name?: string): Palette;
-/**
- * Build the `ThemeKey` that rotates `palette` so its *tonic* var lands on
- * `targetHueDeg`. The musical operation directly: a key is the set of
- * intervals from the tonic, so "play this theme in the key of <hue>" means
- * "shift every color by exactly the interval that carries the tonic's
- * current hue to the target." Pick the tonic's pitch and the rest follows.
- *
- * Returns a hue-only key (chroma and lightness untouched). Callers that also
- * want to scale chroma or shift lightness spread their own axes over the
- * result — those are independent transposition dimensions, not part of
- * choosing the key. [LAW:one-type-per-behavior] a degree-shift key and a
- * root-note key are the *same* transform; this is just a second constructor
- * for it, so `transposePalette` stays untouched.
- *
- * Throws if `tonicVar` is absent — the interval has no anchor to measure
- * from, so there is no honest key to return. Failing loudly beats inventing
- * a zero shift that would silently mean "no transposition."
- */
-export declare function themeKeyForRoot(palette: Palette, tonicVar: string, targetHueDeg: number): ThemeKey;

package/dist/themes/transpose.js

@@ -1,138 +0,0 @@
-/**
- * Transpose a Palette to a new "key" — analogous to transposing a melody.
- *
- *   melody / chord progression  ::  Palette (relationships between colors)
- *                key (signature) ::  ThemeKey (hue / chroma / lightness deltas)
- *      "in C major" / "in D…"   ::  the resulting transposed Palette
- *
- * Because OKLCH is perceptually uniform, "+30° hue" looks like a
- * consistent jump everywhere on the color wheel — the way a perfect-fifth
- * interval sounds the same in every musical key. Transposition is closed
- * under composition: `transpose(transpose(p, k1), k2)` produces the same
- * colors as a single transpose with the combined deltas, modulo round-trip
- * quantization.
- *
- * [LAW:dataflow-not-control-flow] A single uniform per-color transform
- * runs for every var in the palette. Anchor protection selects *which*
- * `ThemeKey` to apply (data), not *whether* to apply one (branch).
- *
- * [LAW:one-source-of-truth] Anchor classification lives only in
- * `ANCHORED_ROOTS` below. The buildPalette derivation guarantees every
- * variant of a semantic root shares the root as its hyphen prefix
- * (`error`, `error-darken-1`, `error-lighten-2`, ...), so one set covers
- * the whole family.
- *
- * [LAW:one-way-deps] Imports flow `core/oklch → themes/transpose`;
- * nothing in core/ depends back on this file.
- */
-import { Oklch, isIdentityKey } from "../core/oklch.js";
-import { Palette } from "./palette.js";
-/**
- * Semantic roots whose hue is locked under transposition. `error` must
- * look red-ish, `success` green-ish, `warning` amber-ish — rotating the
- * hue would make the UI lie about meaning. Lightness and chroma *still*
- * transform for these roles, so they invert correctly during dark↔light
- * flips and respond to chroma scaling alongside everything else.
- */
-// [LAW:types-are-the-program] The `ReadonlySet` type is the immutability
-// enforcement — typed code cannot call `add`/`delete`. (`Object.freeze` is
-// not used here because it is a no-op on Set membership; relying on it would
-// imply a runtime guarantee it does not provide.)
-export const ANCHORED_ROOTS = new Set([
-    "error",
-    "success",
-    "warning",
-]);
-function rootOf(varName) {
-    const dash = varName.indexOf("-");
-    return dash === -1 ? varName : varName.slice(0, dash);
-}
-/**
- * Whether a palette var's hue is locked under transposition. The single
- * predicate used by `transposePalette`. Exported so callers building
- * higher-level theme machinery can stay consistent with the locking rule.
- */
-export function isAnchored(varName) {
-    return ANCHORED_ROOTS.has(rootOf(varName));
-}
-/**
- * Return a new `Palette` whose colors are the transposition of `palette`'s
- * colors by `key`. Pure. Identity (`IDENTITY`) returns a Palette with byte-exact
- * colors — fast-pathed so identity does not pay the sRGB↔OKLCH round-trip
- * quantization cost.
- *
- * The `dark` flag of the result is derived from the actual lightness of
- * the resulting `background` var (`Oklch.fromRgba(bg).l < 0.5`) — *not*
- * from the key's coefficients. The strongest theorem: "dark iff
- * background is dark." This is honest under every transform — pure
- * lightness shifts, mirror-inversions, hue rotations that don't touch L,
- * and combinations of all three. [LAW:types-are-the-program]
- *
- * The transposing path throws if the palette has no `background` var (the
- * `dark`-flag derivation has nothing to read). Failing loudly is preferred
- * over a silent fallback because the alternative — trusting the source
- * `palette.dark` after an arbitrary L-transform — produces flags that lie.
- * The identity fast-path is exempt: it preserves the source `dark` flag
- * verbatim (no derivation), so it needs no `background` and never throws.
- *
- * @param name Optional override for the resulting palette name. Defaults
- *   to the source palette's name. Callers building a family of transposed
- *   palettes (e.g. "gruvbox +60°") supply their own.
- */
-export function transposePalette(palette, key, name) {
-    if (isIdentityKey(key)) {
-        return new Palette(name ?? palette.name, palette.dark, palette.vars);
-    }
-    // Anchors share *everything except* hue with the user's key. They still
-    // lightness-invert in a dark↔light flip; they still chroma-scale in a
-    // saturation sweep — only their hue is held.
-    const anchorKey = { ...key, hueShift: 0 };
-    const next = new Map();
-    for (const [varName, color] of palette.vars) {
-        const effective = isAnchored(varName) ? anchorKey : key;
-        next.set(varName, Oklch.fromRgba(color).applyKey(effective).toRgba());
-    }
-    const newBackground = next.get("background");
-    if (newBackground === undefined) {
-        throw new Error(`transposePalette: palette "${palette.name}" has no "background" ` +
-            `var; cannot derive the dark flag without a background color.`);
-    }
-    const newDark = Oklch.fromRgba(newBackground).l < 0.5;
-    return new Palette(name ?? palette.name, newDark, next);
-}
-/**
- * Build the `ThemeKey` that rotates `palette` so its *tonic* var lands on
- * `targetHueDeg`. The musical operation directly: a key is the set of
- * intervals from the tonic, so "play this theme in the key of <hue>" means
- * "shift every color by exactly the interval that carries the tonic's
- * current hue to the target." Pick the tonic's pitch and the rest follows.
- *
- * Returns a hue-only key (chroma and lightness untouched). Callers that also
- * want to scale chroma or shift lightness spread their own axes over the
- * result — those are independent transposition dimensions, not part of
- * choosing the key. [LAW:one-type-per-behavior] a degree-shift key and a
- * root-note key are the *same* transform; this is just a second constructor
- * for it, so `transposePalette` stays untouched.
- *
- * Throws if `tonicVar` is absent — the interval has no anchor to measure
- * from, so there is no honest key to return. Failing loudly beats inventing
- * a zero shift that would silently mean "no transposition."
- */
-export function themeKeyForRoot(palette, tonicVar, targetHueDeg) {
-    // Validate the numeric input at the boundary: a non-finite target would
-    // propagate as NaN to Oklch's constructor several calls downstream, where
-    // the error is far less actionable.
-    if (!Number.isFinite(targetHueDeg)) {
-        throw new RangeError(`themeKeyForRoot: targetHueDeg must be a finite number; got ${targetHueDeg}`);
-    }
-    const tonic = palette.get(tonicVar);
-    if (tonic === undefined) {
-        throw new Error(`themeKeyForRoot: palette "${palette.name}" has no "${tonicVar}" var ` +
-            `to use as the tonic; cannot measure the transposition interval.`);
-    }
-    const tonicHue = Oklch.fromRgba(tonic).h;
-    let hueShift = (targetHueDeg - tonicHue) % 360;
-    if (hueShift < 0)
-        hueShift += 360;
-    return { hueShift, chromaScale: 1, lightnessScale: 1, lightnessShift: 0 };
-}

package/dist/widgets/button.d.ts

@@ -1,49 +0,0 @@
-/**
- * Button widget — labeled action trigger with variant styling.
- * [LAW:dataflow-not-control-flow] rendering is a pure function of observable state.
- * [LAW:one-type-per-behavior] shared widget infrastructure lives on WidgetBase.
- *
- * Four visual states:
- *   normal  — variant colors from theme semantic palette (muted)
- *   hover   — full variant accent bg + on-accent fg (WCAG contrast)
- *   focus   — brackets [ label ] surrounding the button
- *   active  — same color pair as hover, plus bold (pressed cue)
- *
- * States compose: active > focus > hover > normal. Active and hover
- * deliberately share colors — active differentiates via bold rather
- * than fg/bg inversion, because inversion produces mostly-accent text
- * on bg-tinted surface, which is unreadable for accents whose contrast
- * partner depends on luminance.
- */
-import { Segment } from "../core/segment.js";
-import type { RenderOptions } from "../core/protocol.js";
-import type { TerminalTheme } from "../core/color.js";
-import { WidgetBase } from "./widget-base.js";
-import type { KeyEvent, WidgetMouseEvent } from "./types.js";
-export type ButtonVariant = "default" | "primary" | "success" | "warning" | "danger";
-export interface ButtonOptions {
-    label: string;
-    variant?: ButtonVariant;
-    id?: string;
-    disabled?: boolean;
-    theme?: TerminalTheme;
-}
-export declare class Button extends WidgetBase {
-    readonly id: string;
-    readonly focusable = true;
-    accessor label: string;
-    accessor variant: ButtonVariant;
-    private accessor _theme;
-    constructor(options: ButtonOptions);
-    setTheme(theme: TerminalTheme): void;
-    handleKey(event: KeyEvent): void;
-    handleMouse(event: WidgetMouseEvent): void;
-    setActive(value: boolean): void;
-    render(_options: RenderOptions): Iterable<Segment>;
-    measure(_options: RenderOptions): {
-        minimum: number;
-        maximum: number;
-    };
-    private resolveColors;
-    private resolvePalette;
-}