@wtfalch/design 0.1.0

package/dist/components/Toggle.js

@@ -0,0 +1,189 @@
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+/**
+ * A setting that takes effect as it moves.
+ *
+ * **A checkbox and a switch are not the same control, and the difference is not
+ * visual.** A checkbox collects an answer: you tick it, and it applies when you
+ * press Save. A switch *is* the action — flipping it changes the thing, now,
+ * and there is nothing to confirm afterwards. That is why a switch reads as on
+ * or off rather than ticked or blank: the two states are both settled, and
+ * neither is a draft.
+ *
+ * Six settings in this app saved the moment they changed and were all drawn as
+ * tick boxes: whether an applet is enabled, whether it reaches the internet,
+ * whether a tool is granted, whether a server is trusted. Every one of them
+ * promised a Save button that does not
+ * exist. The header's status panel (gone since 2026-09-03) was the only one
+ * that had it right, in a comment nobody else read.
+ *
+ * **`role="switch"`, so it is announced as one.** A screen reader says "on" and
+ * "off" instead of "checked" and "not checked" — which is the same distinction
+ * in words, and the only signal a non-visual reader gets that pressing it does
+ * something immediately.
+ *
+ * **The label is the hit area.** A 30×18 target fails the minimum on its own,
+ * and reaching for the words is what people do anyway.
+ *
+ * **One switch, or several checkboxes.** A lone binary setting is a switch. A
+ * set you pick from is a list of checkboxes — fifteen switches in a column read
+ * as fifteen unrelated settings rather than one choice with fifteen parts. See
+ * `Checkbox`.
+ */
+import { useEffect, useRef, useState } from 'react';
+import { Switch } from 'react-aria-components';
+/** The knob's diameter per size, as `toggle.css` draws it. The drag needs it
+ *  to turn pixels into a position: the knob travels the track's inner width
+ *  less itself and its 2px of margin at each end. */
+const KNOB = { sm: 10, md: 12, lg: 16 };
+/** Under this many pixels of horizontal travel a press is a tap. It was 3,
+ *  and a plain click carries that much hand jitter -- so a click on the knob
+ *  became a drag, the knob twitched toward the pointer and settled by which
+ *  side it was on, and the switch felt as if it wanted to be dragged rather
+ *  than pressed. Six is over the jitter and still a third of the way across
+ *  the shortest track. */
+const SLOP = 6;
+export default function Toggle({ label, hint, checked, onChange, disabled, said, labelHidden, size = 'md', className, }) {
+    /* React Aria's `Switch` is the `<label>`: it owns a visually-hidden
+       `<input type="checkbox" role="switch">` and stamps `data-selected`,
+       `data-disabled`, `data-focus-visible` and `data-pressed` on the label. So
+       the track is no longer the input drawn with `appearance: none` -- it is a
+       plain span, and `toggle.css` reads the state off the row instead of off
+       `:checked`. The row is the label either way, which keeps the words as the
+       hit area. */
+    /* Dragging the knob.
+  
+       React Aria's `Switch` is a press: down and up on the label toggles, and a
+       pointer that wanders in between is still a press. A switch drawn as a
+       track and a knob invites the other gesture -- drag the knob across -- and
+       nothing answered it. So the track handles its own pointer: on down it
+       stops the event before the label's press begins and captures the pointer.
+       Under `SLOP` pixels of movement it is a tap and toggles on release; past
+       it, the knob follows the pointer through `--knob-x` and the side it is on
+       at release is the answer. Either way the click the browser fires afterwards
+       is swallowed, so the label does not toggle it a second time -- and it has
+       to be handled here rather than left to the label, because once the press
+       is stopped at the track a tap on the knob no longer reaches the input by
+       itself (measured, in `keyboard.spec.ts`).
+  
+       `onChange` is called once per gesture, or not at all if the knob was put
+       back where it started -- a consumer that saves on change must not see a
+       drag as two saves. The keyboard is untouched: the input is still the
+       switch. */
+    /* The optimistic half, copied from chef-monorepo's `Toggle` on 2026-09-05.
+  
+       A switch applies as it moves, and what it applies is usually a request.
+       Waiting for the reply before moving the knob makes every switch feel
+       broken for the length of a round trip; moving it and forgetting makes a
+       failed request look like a success. So: if `onChange` returns a promise,
+       the knob moves now and the row is busy -- `aria-busy` on the input, chef's
+       sweep around the rim of the track (`.toggle-sweep`), no second press --
+       until it settles. A rejection
+       puts the knob back. A resolution HOLDS the optimistic value until `checked`
+       changes, because a resolved save does not mean the caller's state has
+       caught up (a refetch is a second round trip), and clearing on resolve
+       would snap the knob back and forward again. An optimistic value can outlive
+       a successful save and never a failed one. `onChange` returning nothing is
+       the old contract, untouched. */
+    const [optimistic, setOptimistic] = useState(null);
+    const [pending, setPending] = useState(false);
+    const [seen, setSeen] = useState(checked);
+    if (checked !== seen) {
+        setSeen(checked);
+        if (optimistic !== null)
+            setOptimistic(null);
+    }
+    const shown = optimistic ?? checked;
+    const commit = (on) => {
+        const result = onChange(on);
+        if (!(result instanceof Promise))
+            return;
+        setOptimistic(on);
+        setPending(true);
+        result.then(() => setPending(false), () => {
+            setPending(false);
+            setOptimistic(null);
+        });
+    };
+    /* `aria-busy` on the input and `data-pending` on the row, set on the elements
+       because React Aria's `filterDOMProps` drops both in silence -- the trap
+       `Button` documents for `aria-busy`. */
+    const rowRef = useRef(null);
+    useEffect(() => {
+        const row = rowRef.current;
+        const input = row?.querySelector('input');
+        if (!row || !input)
+            return;
+        if (pending) {
+            row.setAttribute('data-pending', 'true');
+            input.setAttribute('aria-busy', 'true');
+        }
+        else {
+            row.removeAttribute('data-pending');
+            input.removeAttribute('aria-busy');
+        }
+    }, [pending]);
+    const [knob, setKnob] = useState(null);
+    const [held, setHeld] = useState(false);
+    const gesture = useRef(null);
+    const swallowClick = useRef(false);
+    const position = (track, g, x) => {
+        const travel = track.clientWidth - KNOB[size] - 4;
+        return Math.min(1, Math.max(0, g.from + (x - g.startX) / travel));
+    };
+    return (_jsxs(Switch, { ref: rowRef, className: `switch-row switch-${size}${className ? ` ${className}` : ''}`, isSelected: shown, onChange: commit, isDisabled: disabled, 
+        /* Read-only, not disabled, while a request is out: focus stays where it
+           is and the row does not dim, it just refuses a second answer until
+           the first has been taken. */
+        isReadOnly: pending, children: [_jsxs("span", { className: labelHidden ? 'sr-only' : 'switch-body', children: [_jsx("span", { className: "switch-label", children: label }), hint && _jsx("span", { className: "switch-hint", children: hint })] }), said && _jsx("span", { className: "switch-said mono", children: said }), _jsx("span", { className: "toggle", "aria-hidden": "true", "data-held": held || undefined, "data-dragging": knob === null ? undefined : true, style: knob === null ? undefined : { '--knob-x': knob }, onPointerDown: (e) => {
+                    if (disabled || pending || e.button !== 0)
+                        return;
+                    e.stopPropagation();
+                    e.currentTarget.setPointerCapture(e.pointerId);
+                    gesture.current = {
+                        id: e.pointerId,
+                        startX: e.clientX,
+                        startY: e.clientY,
+                        from: shown ? 1 : 0,
+                        moved: false,
+                    };
+                    setHeld(true);
+                }, onPointerMove: (e) => {
+                    const g = gesture.current;
+                    if (!g || e.pointerId !== g.id)
+                        return;
+                    if (!g.moved) {
+                        const dx = e.clientX - g.startX;
+                        const dy = e.clientY - g.startY;
+                        /* Mostly sideways and past the slop, or it is still a press. A
+                           drag begins where the threshold was crossed, not where the
+                           pointer first landed, so the knob starts from rest instead of
+                           jumping the slop's width the moment it engages. */
+                        if (Math.abs(dx) < SLOP || Math.abs(dx) <= Math.abs(dy))
+                            return;
+                        g.moved = true;
+                        g.startX = e.clientX;
+                    }
+                    setKnob(position(e.currentTarget, g, e.clientX));
+                }, onPointerUp: (e) => {
+                    const g = gesture.current;
+                    if (!g || e.pointerId !== g.id)
+                        return;
+                    gesture.current = null;
+                    setHeld(false);
+                    setKnob(null);
+                    swallowClick.current = true;
+                    const on = g.moved ? position(e.currentTarget, g, e.clientX) > 0.5 : !shown;
+                    if (on !== shown)
+                        commit(on);
+                }, onPointerCancel: () => {
+                    gesture.current = null;
+                    setHeld(false);
+                    setKnob(null);
+                }, onClick: (e) => {
+                    if (!swallowClick.current)
+                        return;
+                    swallowClick.current = false;
+                    e.preventDefault();
+                    e.stopPropagation();
+                }, children: pending && _jsx("span", { className: "toggle-sweep" }) })] }));
+}

package/dist/components/Tooltip.d.ts

@@ -0,0 +1,22 @@
+export default function Tooltip({ label, align, mark, className, children, }: {
+    label: string;
+    /** Which side the box extends towards. `right` for a mark on the left. */
+    align?: 'left' | 'right';
+    /**
+     * What you hover, when the `?` is not it.
+     *
+     * A capability mark on a model row is not a request for help about something
+     * else -- it *is* the thing, drawn small. So it becomes its own trigger, and
+     * the accessible name is the capability rather than "About …", which would
+     * announce a glyph as a footnote to itself.
+     *
+     * This exists because the native `title` attribute was not enough. The mark
+     * is an `<svg>` inside a `<span title>` inside a row that is a `<button>`;
+     * the pointer lands on a `<path>`, two tooltip sources compete, and what came
+     * up was nothing anybody could rely on. A tooltip the app draws itself shows
+     * on hover *and* on keyboard focus, which the native one never did.
+     */
+    mark?: React.ReactNode;
+    className?: string;
+    children: React.ReactNode;
+}): import("react").JSX.Element;

package/dist/components/Tooltip.js

@@ -0,0 +1,62 @@
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+/**
+ * A tooltip. It was called `Explain`, which named the intention rather than the
+ * thing -- so it sat in a catalogue beside Button and Callout as though it were
+ * a category of its own, and nobody looking for a tooltip would have found it.
+ *
+ * A `?` beside a setting, and the box it shows on hover.
+ *
+ * Same idea as the status dot's tooltip and built the same way: a positioned
+ * element revealed on hover, rather than a `title` attribute. The native one
+ * needs about a second and a half of waiting, renders newlines inconsistently
+ * and cannot be styled.
+ *
+ * **It stays open while the pointer is inside it**, because a box that vanishes
+ * the moment you move toward it cannot be read. `focus-within` opens it too, so
+ * it is reachable from the keyboard.
+ *
+ * The mark is a `<span>` rather than a `<button>`: the rows these sit in are
+ * usually a `<label>` wrapping a checkbox, and anything focusable or clickable
+ * in there ends up toggling the setting behind it.
+ *
+ * `align` is which way the box grows, and it has to be said rather than
+ * guessed: a mark at the right edge of a row must grow left, and one beside a
+ * section heading must grow right. Getting it wrong does not just look off --
+ * the box runs under the settings rail and its first few words are cut away.
+ */
+import { Tooltip as AriaTooltip, Focusable, TooltipTrigger } from 'react-aria-components';
+export default function Tooltip({ label, align = 'right', mark, className, children, }) {
+    /* What was wrong, and what this fixes.
+  
+       The old markup was `<span role="note" tabIndex={0} aria-label="About …">`
+       with the tip as a child span revealed by `:hover` and `:focus-within`. It
+       looked like a tooltip and was not one to anything that reads a page aloud:
+       `note` is not an interactive role, so a focusable note is a contradiction
+       the screen reader resolves by announcing the label and nothing else -- the
+       tip's text, the one thing worth reading, was never associated with the
+       trigger at all.
+  
+       React Aria's `TooltipTrigger` wires `aria-describedby` from the trigger to
+       a `<div role="tooltip">`, opens it on hover with intent and on keyboard
+       focus, and closes it on Escape and on pointer-out with a grace period so
+       a box that vanishes as you move towards it cannot happen.
+  
+       The mark stays a `<span>`, and `Focusable` is what makes that work. The
+       rows these sit in are `<label>`s wrapping a control, so anything that is a
+       `<button>` in there toggles the setting behind it -- the docblock's reason,
+       and still true. `Focusable` gives the span a tab stop and the focus and
+       hover handling a trigger needs without making it a button.
+  
+       The tip is portalled to `document.body` and positioned by React Aria, which
+       is also why `overflow: hidden` on any ancestor no longer clips it -- the
+       Permissions pane's horizontal scrollbar, found by hiding one class at a
+       time, was this box sitting in the scrollable overflow. */
+    return (_jsxs(TooltipTrigger, { delay: 0, closeDelay: 150, children: [_jsx(Focusable, { children: _jsx("span", { className: `explain explain-${align}${className ? ` ${className}` : ''}`, 
+                    /* A role, because a name on a role-less span is prohibited -- axe's
+                       `aria-prohibited-attr`, found the first time this was scanned. `img`
+                       rather than `button`: the mark is a glyph that reveals help, not a
+                       control that does something, and `button` would promise an action
+                       and -- inside the `<label>` rows these sit in -- invite a click that
+                       the label forwards to the setting behind it. */
+                    role: "img", "aria-label": mark ? label : `About ${label}`, children: mark ?? (_jsx("span", { className: "explain-mark", "aria-hidden": "true", children: "?" })) }) }), _jsx(AriaTooltip, { className: "explain-tip", placement: align === 'left' ? 'bottom end' : 'bottom start', offset: 8, crossOffset: align === 'left' ? 6 : -6, children: children })] }));
+}

package/dist/components/Tour.d.ts

@@ -0,0 +1,33 @@
+/**
+ * A short walk round the chrome, once, after onboarding.
+ *
+ * Onboarding answers "what does this need to run". It says nothing about the
+ * four controls somebody is then left alone with: two floating buttons in one
+ * corner, a cog in another, and a `+` beside the board name. Every one of them
+ * is an icon with a `title`, which is a tooltip you have to already suspect is
+ * there to go looking for.
+ *
+ * **It points at the real thing.** Each step finds its target by selector and
+ * cuts a hole in the scrim over it, so the control being described is the
+ * control you can see — not a screenshot of one, which goes stale the first
+ * time the button moves.
+ *
+ * **A step whose target is missing is skipped, not shown empty.** The chat
+ * launcher is not on the page while the dock is open, and the studio button
+ * changes what it does when a session is minimised. A tour that insists on
+ * pointing at something that is not there would be describing a different app.
+ *
+ * **Escape ends it and it never comes back on its own.** This is the least
+ * important thing on the screen and it is in the way of everything else; the
+ * one unforgivable version is the one you cannot get out of.
+ */
+export interface TourStop {
+    /** Where it points. Missing from the page means the stop is skipped. */
+    target: string;
+    title: string;
+    body: React.ReactNode;
+}
+export default function Tour({ stops, onDone }: {
+    stops: TourStop[];
+    onDone: () => void;
+}): import("react").ReactPortal | null;

package/dist/components/Tour.js

@@ -0,0 +1,108 @@
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+/**
+ * A short walk round the chrome, once, after onboarding.
+ *
+ * Onboarding answers "what does this need to run". It says nothing about the
+ * four controls somebody is then left alone with: two floating buttons in one
+ * corner, a cog in another, and a `+` beside the board name. Every one of them
+ * is an icon with a `title`, which is a tooltip you have to already suspect is
+ * there to go looking for.
+ *
+ * **It points at the real thing.** Each step finds its target by selector and
+ * cuts a hole in the scrim over it, so the control being described is the
+ * control you can see — not a screenshot of one, which goes stale the first
+ * time the button moves.
+ *
+ * **A step whose target is missing is skipped, not shown empty.** The chat
+ * launcher is not on the page while the dock is open, and the studio button
+ * changes what it does when a session is minimised. A tour that insists on
+ * pointing at something that is not there would be describing a different app.
+ *
+ * **Escape ends it and it never comes back on its own.** This is the least
+ * important thing on the screen and it is in the way of everything else; the
+ * one unforgivable version is the one you cannot get out of.
+ */
+import { useCallback, useEffect, useLayoutEffect, useMemo, useRef, useState } from 'react';
+import { createPortal } from 'react-dom';
+import Button from './Button';
+import { markTourSeen } from './tourMarker';
+export default function Tour({ stops, onDone }) {
+    const [at, setAt] = useState(0);
+    const [box, setBox] = useState(null);
+    const card = useRef(null);
+    /* Only the stops whose target is actually on the page.
+       
+       Keyed on `stops` rather than computed every render, because re-filtering
+       as the chrome moves would renumber "2 of 4" under somebody mid-walk -- the
+       chat launcher leaves the page when the dock opens, and the count must not
+       notice. `TOUR` is a module constant, so in a built app this runs once.
+  
+       It was a `useRef` for that reason, and a ref is a snapshot: editing a stop's
+       copy hot-updated the module and the open tour went on rendering the text it
+       was mounted with, which made the copy look like it had not saved. A `useMemo`
+       keeps the guarantee and lets a new `stops` array through, which is exactly
+       what Fast Refresh hands us. */
+    const live = useMemo(() => stops.filter((s) => document.querySelector(s.target)), [stops]);
+    /* A shorter list must not strand the index past the end -- that would read as
+       "no stop", which ends the tour. Only reachable in development. */
+    const stop = live[Math.min(at, Math.max(0, live.length - 1))];
+    const finish = useCallback(() => {
+        markTourSeen();
+        onDone();
+    }, [onDone]);
+    useLayoutEffect(() => {
+        if (!stop)
+            return finish();
+        const el = document.querySelector(stop.target);
+        if (!el)
+            return;
+        /* Half this chrome is invisible until you touch it. `.view-add` sits at
+           `opacity: 0` until the top bar is hovered, so the spotlight cut a hole
+           round nothing and the card described a button that was not there -- the
+           one stop most in need of explaining was the one you could not see.
+    
+           A class rather than an inline style: what "visible" means belongs to the
+           control, in the stylesheet with the rule that hid it. See `.tour-target`. */
+        el.classList.add('tour-target');
+        const measure = () => setBox(el.getBoundingClientRect());
+        measure();
+        // The chrome moves: the board scrolls, the window resizes, a FAB slides in.
+        window.addEventListener('resize', measure);
+        window.addEventListener('scroll', measure, true);
+        return () => {
+            // Before the next stop adds its own, and on the way out however we leave
+            // -- Escape and Skip included, or the button stays stuck on.
+            el.classList.remove('tour-target');
+            window.removeEventListener('resize', measure);
+            window.removeEventListener('scroll', measure, true);
+        };
+    }, [stop, finish]);
+    // biome-ignore lint/correctness/useExhaustiveDependencies: `at` is the trigger, not a value the body reads -- the card takes focus again on every step.
+    useEffect(() => {
+        card.current?.focus();
+    }, [at]);
+    if (!stop || !box)
+        return null;
+    const next = () => (at + 1 < live.length ? setAt(at + 1) : finish());
+    /* Above the target if there is room, below if not. The two FABs sit at the
+       bottom of the window, where a card underneath them would be off screen. */
+    const below = box.top < window.innerHeight / 2;
+    const style = {
+        top: below ? box.bottom + 14 : undefined,
+        bottom: below ? undefined : window.innerHeight - box.top + 14,
+        left: Math.max(16, Math.min(box.left + box.width / 2 - 170, window.innerWidth - 356)),
+    };
+    return createPortal(_jsxs("div", { className: "tour", onKeyDown: (e) => {
+            if (e.key === 'Escape')
+                finish();
+            if (e.key === 'Enter' || e.key === 'ArrowRight')
+                next();
+        }, children: [_jsx("div", { className: "tour-hole", style: {
+                    top: box.top - 6,
+                    left: box.left - 6,
+                    width: box.width + 12,
+                    height: box.height + 12,
+                } }), _jsxs("div", { ref: card, className: "tour-card", style: style, 
+                // biome-ignore lint/a11y/useSemanticElements: a <dialog> brings the top layer, ::backdrop and showModal() focus semantics; this is an anchored coach-mark card that positions itself and manages its own focus, so the role is the faithful choice.
+                role: "dialog", "aria-modal": "true", "aria-labelledby": "tour-title", tabIndex: -1, children: [_jsx("strong", { id: "tour-title", className: "tour-title", children: stop.title }), _jsx("p", { className: "tour-body", children: stop.body }), _jsxs("div", { className: "tour-actions", children: [_jsxs("span", { className: "tour-count mono", children: [at + 1, " of ", live.length] }), _jsx("span", { className: "grow" }), _jsx(Button, { kind: "ghost", size: "sm", onPress: finish, children: "Skip" }), _jsx(Button, { kind: "primary", size: "sm", onPress: next, children: at + 1 < live.length ? 'Next' : 'Done' })] })] })] }), document.body);
+}

package/dist/components/iconNames.d.ts

@@ -0,0 +1,18 @@
+/**
+ * Every icon name, in one place.
+ *
+ * **Its own module so `Icon.tsx` stays a Fast Refresh boundary.** React Fast
+ * Refresh can only swap a module in place when everything it exports is a
+ * component; one exported array is enough to disqualify the file, and Vite then
+ * pushes the update up to whoever imports it -- which for `Icon` is very nearly
+ * the whole app, so editing one glyph re-ran App. The names have no reason to
+ * sit beside the component anyway.
+ *
+ * The gallery used to hold its own list of fourteen and quietly omitted five --
+ * a catalogue page that documents less than the set it documents is how
+ * somebody concludes an icon does not exist and draws it again. `IconName` is
+ * derived from this, so the type, the glyph table and the gallery cannot
+ * disagree.
+ */
+export declare const ICON_NAMES: readonly ["chat", "settings", "refresh", "minimize", "code", "wifi", "wifi-off", "check", "close", "info", "warning", "error", "expand", "download", "image", "bolt", "speaker", "mic", "back", "spinner", "folder", "book", "eye", "eye-off", "palette", "stars", "wrench", "cloud", "file"];
+export type IconName = (typeof ICON_NAMES)[number];

package/dist/components/iconNames.js

@@ -0,0 +1,60 @@
+/**
+ * Every icon name, in one place.
+ *
+ * **Its own module so `Icon.tsx` stays a Fast Refresh boundary.** React Fast
+ * Refresh can only swap a module in place when everything it exports is a
+ * component; one exported array is enough to disqualify the file, and Vite then
+ * pushes the update up to whoever imports it -- which for `Icon` is very nearly
+ * the whole app, so editing one glyph re-ran App. The names have no reason to
+ * sit beside the component anyway.
+ *
+ * The gallery used to hold its own list of fourteen and quietly omitted five --
+ * a catalogue page that documents less than the set it documents is how
+ * somebody concludes an icon does not exist and draws it again. `IconName` is
+ * derived from this, so the type, the glyph table and the gallery cannot
+ * disagree.
+ */
+export const ICON_NAMES = [
+    'chat',
+    'settings',
+    'refresh',
+    'minimize',
+    'code',
+    'wifi',
+    'wifi-off',
+    'check',
+    'close',
+    'info',
+    'warning',
+    'error',
+    'expand',
+    'download',
+    'image',
+    'bolt',
+    'speaker',
+    'mic',
+    'back',
+    'spinner',
+    // Added for the Updates tab and the file-access card: `image` was standing
+    // in for npm packages and `code` for a folder of files, which are the wrong
+    // words with the right shape. Measured the same way as the rest -- see the
+    // `Glyph` docstring in `Icon.tsx`.
+    'folder',
+    'book',
+    // What a model can do, for the capability tags on a model row. Each one
+    // has to carry *direction*: `_tags` in `routes_models.py` records why
+    // `sees` and `draws` were rejected as names -- nobody could tell which
+    // way the picture went. An eye takes one in, a palette puts one out.
+    'eye',
+    // The same eye, struck through: the other half of a show/hide toggle.
+    // Not for a capability tag -- a model that cannot see has no tag.
+    'eye-off',
+    'palette',
+    'stars',
+    'wrench',
+    'cloud',
+    // The chat's attach button. A folder was the nearest thing in the set and
+    // is the wrong noun: you are handing over one file, not opening a place
+    // that holds several.
+    'file',
+];

package/dist/components/tourMarker.d.ts

@@ -0,0 +1,29 @@
+/**
+ * Whether this browser has been walked round the chrome.
+ *
+ * **Its own module so `Tour.tsx` stays a Fast Refresh boundary.** Three
+ * exported functions beside the component meant Vite could not swap the tour in
+ * place -- `Could not Fast Refresh ("markTourSeen" export is incompatible)` --
+ * and pushed every edit up to App instead. Editing the tour's copy is exactly
+ * the thing somebody does over and over, so it is the worst file in the app to
+ * have lost its boundary.
+ *
+ * These are also not React at all: three reads and writes of one string. They
+ * were only in the component file because that is where the tour was written.
+ */
+export declare function tourSeen(): boolean;
+/**
+ * Forget it, so the next completed onboarding shows it again.
+ *
+ * Called when the onboarding window *appears*, which is the whole fix: the
+ * marker lives in this browser and `config/` lives on disk, so clearing the
+ * config replayed onboarding and left the tour suppressed by a value nothing
+ * server-side could reach. Somebody re-bootstrapping to look at onboarding got
+ * the onboarding and not the thing that follows it, with no way to tell why.
+ *
+ * Keying off "onboarding is on screen" rather than off a stored timestamp keeps
+ * this a fact about one browser, which is what it is. If you are being asked
+ * these questions again, you have not seen the walk that comes after them.
+ */
+export declare function forgetTour(): void;
+export declare function markTourSeen(): void;

package/dist/components/tourMarker.js

@@ -0,0 +1,58 @@
+/**
+ * Whether this browser has been walked round the chrome.
+ *
+ * **Its own module so `Tour.tsx` stays a Fast Refresh boundary.** Three
+ * exported functions beside the component meant Vite could not swap the tour in
+ * place -- `Could not Fast Refresh ("markTourSeen" export is incompatible)` --
+ * and pushed every edit up to App instead. Editing the tour's copy is exactly
+ * the thing somebody does over and over, so it is the worst file in the app to
+ * have lost its boundary.
+ *
+ * These are also not React at all: three reads and writes of one string. They
+ * were only in the component file because that is where the tour was written.
+ */
+/** Remembered per browser: a reload in the middle should not start it again,
+ *  and neither should opening the app tomorrow.
+ *
+ *  Re-running onboarding clears it -- see `forgetTour`. There is still no way
+ *  to replay the tour on its own without doing that, which is worth a row in
+ *  Settings and is said here rather than left implied. */
+const SEEN = 'tf-tour-seen';
+export function tourSeen() {
+    try {
+        return localStorage.getItem(SEEN) === '1';
+    }
+    catch {
+        // A browser refusing storage is not a reason to refuse the tour.
+        return false;
+    }
+}
+/**
+ * Forget it, so the next completed onboarding shows it again.
+ *
+ * Called when the onboarding window *appears*, which is the whole fix: the
+ * marker lives in this browser and `config/` lives on disk, so clearing the
+ * config replayed onboarding and left the tour suppressed by a value nothing
+ * server-side could reach. Somebody re-bootstrapping to look at onboarding got
+ * the onboarding and not the thing that follows it, with no way to tell why.
+ *
+ * Keying off "onboarding is on screen" rather than off a stored timestamp keeps
+ * this a fact about one browser, which is what it is. If you are being asked
+ * these questions again, you have not seen the walk that comes after them.
+ */
+export function forgetTour() {
+    try {
+        localStorage.removeItem(SEEN);
+    }
+    catch {
+        /* nothing to do about it, and nothing that needs doing */
+    }
+}
+export function markTourSeen() {
+    try {
+        localStorage.setItem(SEEN, '1');
+    }
+    catch {
+        /* nothing to do about it, and nothing that needs doing */
+    }
+}

package/dist/contrast.d.ts

@@ -0,0 +1,18 @@
+/**
+ * The contrast measurement, as a function rather than a rule.
+ *
+ * "4.5:1 for text, 3:1 for a boundary" has been the house rule for as long as
+ * there have been themes, and it was held by nobody: the Night theme shipped
+ * its primary button at 2.72:1 because the rule was written down and the
+ * measurement was not. `test/contrast.test.ts` measures every built-in theme
+ * with these two functions. They are exported so an app can measure its own --
+ * the package ships themes as examples, and a theme somebody writes for their
+ * app is the one nobody here will ever look at.
+ *
+ * WCAG 2 relative luminance and contrast ratio, on six-digit hex. Nothing
+ * here parses `color-mix()` or `var()`: the derived tokens are computed from
+ * these, so measuring the inputs is measuring them.
+ */
+export declare function luminance(hex: string): number;
+/** The ratio between two colours, 1:1 up to 21:1, whichever is on top. */
+export declare function ratio(a: string, b: string): number;

package/dist/contrast.js

@@ -0,0 +1,27 @@
+/**
+ * The contrast measurement, as a function rather than a rule.
+ *
+ * "4.5:1 for text, 3:1 for a boundary" has been the house rule for as long as
+ * there have been themes, and it was held by nobody: the Night theme shipped
+ * its primary button at 2.72:1 because the rule was written down and the
+ * measurement was not. `test/contrast.test.ts` measures every built-in theme
+ * with these two functions. They are exported so an app can measure its own --
+ * the package ships themes as examples, and a theme somebody writes for their
+ * app is the one nobody here will ever look at.
+ *
+ * WCAG 2 relative luminance and contrast ratio, on six-digit hex. Nothing
+ * here parses `color-mix()` or `var()`: the derived tokens are computed from
+ * these, so measuring the inputs is measuring them.
+ */
+export function luminance(hex) {
+    const channel = (i) => {
+        const v = Number.parseInt(hex.slice(i, i + 2), 16) / 255;
+        return v <= 0.03928 ? v / 12.92 : ((v + 0.055) / 1.055) ** 2.4;
+    };
+    return 0.2126 * channel(1) + 0.7152 * channel(3) + 0.0722 * channel(5);
+}
+/** The ratio between two colours, 1:1 up to 21:1, whichever is on top. */
+export function ratio(a, b) {
+    const [hi, lo] = [luminance(a), luminance(b)].sort((x, y) => y - x);
+    return (hi + 0.05) / (lo + 0.05);
+}

package/dist/hooks/useTrapFocus.d.ts

@@ -0,0 +1,24 @@
+/**
+ * Keep focus inside a window, and put it back when the window goes away.
+ *
+ * `Modal` uses this, and so does anything that is modal without being shaped
+ * like a modal -- the applet studio is a full-screen workspace with its own
+ * header and its own idea of what closing means, and wrapping it in `Modal` to
+ * borrow the behaviour would mean pretending it is a dialog with a title and a
+ * footer. It is not. It just has the same obligation.
+ *
+ * **The obligation.** Everything behind a modal stays in the tab order:
+ * focusable, operable by keyboard, and invisible under the scrim. Tab past the
+ * last control and you are somewhere on the page you cannot see, pressing
+ * buttons you cannot read. No mouse ever finds this, which is why every one of
+ * the app's eight modals shipped without it.
+ */
+import { type RefObject } from 'react';
+export declare function useTrapFocus(box: RefObject<HTMLElement | null>, { active, onEscape, }?: {
+    /** False while the window is mounted but not showing -- the studio stays in
+     *  the tree when minimised, and trapping focus inside something invisible
+     *  is the same bug pointing the other way. */
+    active?: boolean;
+    onEscape?: () => void;
+}): (e: React.KeyboardEvent) => void;
+export default useTrapFocus;