@nonext/husk 0.2.3

package/dist/admin/ui.d.ts

@@ -0,0 +1,3013 @@
+import * as react from 'react';
+import { ReactNode, ButtonHTMLAttributes, Ref, InputHTMLAttributes, TextareaHTMLAttributes, TdHTMLAttributes, ThHTMLAttributes, ReactElement, KeyboardEvent, ComponentType } from 'react';
+import { LucideIcon } from 'lucide-react';
+import * as lucide from 'lucide';
+
+/**
+ * The avatar. Canonical source: .docs/styleguide/04-components.md section 9.
+ *
+ * Three sizes, nothing else. The fallback is initials rather than a generic silhouette,
+ * because a sidebar full of identical silhouettes tells a reader nothing.
+ */
+type AvatarSize = 20 | 24 | 32;
+interface AvatarProps {
+    /** The display name or email the initials come from, and the image's alt text. */
+    name: string;
+    src?: string;
+    size?: AvatarSize;
+}
+/** At most two letters, from the first two words, so a long name stays inside the circle. */
+declare function initials(name: string): string;
+declare function Avatar({ name, src, size }: AvatarProps): react.JSX.Element;
+
+/**
+ * The icon vocabulary as plain data, with no Lucide import.
+ *
+ * `icon.tsx` maps every name here to a glyph, and the admin only ever asks for a name. The
+ * list lives in its own module because things that are not components need it: the
+ * navigation builder resolves a content type's declared icon against this vocabulary, and
+ * it runs on the server, where dragging a React component module in would put the icon set
+ * into a bundle that never renders one.
+ *
+ * Canonical source: .docs/styleguide/05-icons.md section 1.3.
+ */
+declare const ICON_NAMES: readonly ["brand", "create", "edit", "delete", "save", "close", "search", "filter", "sort-asc", "sort-desc", "navigate-into", "page-previous", "page-next", "expand", "collapse", "selected", "indeterminate", "more-actions", "drag-handle", "locked", "dashboard", "collection", "singleton", "media", "settings", "users", "permissions", "content-types", "system", "success", "warning", "error", "info", "external-link", "upload", "copy", "retry", "open-navigation", "bold", "italic", "strikethrough", "link", "unlink", "bullet-list", "numbered-list", "quote", "undo", "redo"];
+type IconName = (typeof ICON_NAMES)[number];
+
+/**
+ * The only place in the admin that may import from lucide-react.
+ *
+ * Two things are enforced here rather than trusted to a reviewer. Stroke width is 1.5
+ * (Lucide defaults to 2), and size is one of the six the guide allows, so no screen can
+ * introduce a seventh by typing a number. Canonical source:
+ * .docs/styleguide/05-icons.md sections 1 and 1.1.
+ *
+ * Icons are keyed by concept, not by drawing. A screen asks for `delete`, not for
+ * `trash-2`, so the same concept cannot pick up two different glyphs in two places, and
+ * changing the glyph for a concept is one edit here instead of a search across the app.
+ */
+declare const ICONS: {
+    readonly brand: LucideIcon;
+    readonly create: LucideIcon;
+    readonly edit: LucideIcon;
+    readonly delete: LucideIcon;
+    readonly save: LucideIcon;
+    readonly close: LucideIcon;
+    readonly search: LucideIcon;
+    readonly filter: LucideIcon;
+    readonly "sort-asc": LucideIcon;
+    readonly "sort-desc": LucideIcon;
+    readonly "navigate-into": LucideIcon;
+    readonly "page-previous": LucideIcon;
+    readonly "page-next": LucideIcon;
+    readonly expand: LucideIcon;
+    readonly collapse: LucideIcon;
+    readonly selected: LucideIcon;
+    readonly indeterminate: LucideIcon;
+    readonly "more-actions": LucideIcon;
+    readonly "drag-handle": LucideIcon;
+    readonly locked: LucideIcon;
+    readonly dashboard: LucideIcon;
+    readonly collection: LucideIcon;
+    readonly singleton: LucideIcon;
+    readonly media: LucideIcon;
+    readonly settings: LucideIcon;
+    readonly users: LucideIcon;
+    readonly permissions: LucideIcon;
+    readonly "content-types": LucideIcon;
+    readonly system: LucideIcon;
+    readonly success: LucideIcon;
+    readonly warning: LucideIcon;
+    readonly error: LucideIcon;
+    readonly info: LucideIcon;
+    readonly "external-link": LucideIcon;
+    readonly upload: LucideIcon;
+    readonly copy: LucideIcon;
+    readonly retry: LucideIcon;
+    readonly "open-navigation": LucideIcon;
+    readonly bold: LucideIcon;
+    readonly italic: LucideIcon;
+    readonly strikethrough: LucideIcon;
+    readonly link: LucideIcon;
+    readonly unlink: LucideIcon;
+    readonly "bullet-list": LucideIcon;
+    readonly "numbered-list": LucideIcon;
+    readonly quote: LucideIcon;
+    readonly undo: LucideIcon;
+    readonly redo: LucideIcon;
+};
+
+/** 12 badge and check, 14 compact controls, 16 default, 18 section heading, 20 page header, 24 empty state. */
+type IconSize = 12 | 14 | 16 | 18 | 20 | 24;
+interface IconProps {
+    name: IconName;
+    size?: IconSize;
+    /**
+     * Set only where the icon is the whole message. An icon next to a text label is
+     * decorative and stays hidden from assistive technology.
+     */
+    label?: string;
+    className?: string;
+}
+declare function Icon({ name, size, label, className }: IconProps): react.JSX.Element;
+
+/**
+ * The badge. Canonical source: .docs/styleguide/04-components.md section 7.
+ *
+ * Not interactive, ever. A badge that needs a click is a button or a filter chip, and
+ * neither of those exists in this system yet.
+ */
+type BadgeVariant = "neutral" | "success" | "warning" | "danger" | "info" | "accent";
+/**
+ * Entry status maps fixed, so no screen decides for itself what colour Published is.
+ * Canonical source: .docs/styleguide/04-components.md section 7.
+ */
+declare const ENTRY_STATUS_VARIANT: {
+    readonly draft: "neutral";
+    readonly published: "success";
+    readonly archived: "warning";
+    readonly error: "danger";
+};
+/**
+ * How a status is written on screen. Stored lowercase, displayed capitalized, decided once
+ * so two screens cannot disagree about whether it is "Published" or "published".
+ */
+declare const ENTRY_STATUS_LABEL: {
+    readonly draft: "Draft";
+    readonly published: "Published";
+    readonly archived: "Archived";
+};
+interface BadgeProps {
+    children: ReactNode;
+    variant?: BadgeVariant;
+    icon?: IconName;
+}
+declare function Badge({ children, variant, icon }: BadgeProps): react.JSX.Element;
+/**
+ * The status dot. Canonical source: .docs/styleguide/04-components.md section 8.
+ * Never larger, never animated.
+ */
+type StatusTone = "neutral" | "success" | "warning" | "danger" | "info";
+interface StatusDotProps {
+    tone?: StatusTone;
+    /** Set only where the dot is the whole message; otherwise the text beside it says it. */
+    label?: string;
+}
+declare function StatusDot({ tone, label }: StatusDotProps): react.JSX.Element;
+
+/**
+ * The breadcrumb. Canonical source: .docs/styleguide/03-layout.md section 3.1.
+ *
+ * `caption`, `text-faint`, a `chevron-right` separator at 14px. It sits above the page
+ * title and is part of the page header, never a free-standing element: a trail with no
+ * destination under it is decoration.
+ *
+ * Items are data, not nodes, so the page header cannot be handed a styled link that
+ * disagrees with the trail beside it. The last item is the current page and is never a
+ * link, because a link to the page you are on is a dead control.
+ */
+interface BreadcrumbItem {
+    label: string;
+    /** Absent on the last item, and on any ancestor that has no screen of its own. */
+    href?: string;
+}
+interface BreadcrumbProps {
+    items: readonly BreadcrumbItem[];
+    className?: string;
+}
+declare function Breadcrumb({ items, className }: BreadcrumbProps): react.JSX.Element | null;
+
+/**
+ * The button, with the four variants and three sizes the style guide allows and nothing
+ * else. Canonical source: .docs/styleguide/04-components.md section 2.
+ *
+ * A screen that needs a fifth appearance is a style guide change, not a prop.
+ *
+ * The leading icon is named, not passed as a node, so a caller cannot hand it a 20px
+ * glyph or an icon outside the vocabulary. Size follows the button size: 14px at `sm`,
+ * 16px otherwise.
+ */
+type ButtonVariant = "primary" | "secondary" | "ghost" | "danger";
+type ButtonSize = "sm" | "md" | "lg";
+interface ButtonProps extends Omit<ButtonHTMLAttributes<HTMLButtonElement>, "type"> {
+    variant?: ButtonVariant;
+    size?: ButtonSize;
+    /** Replaces the leading icon with a spinner and takes the control out of the tab flow. */
+    loading?: boolean;
+    icon?: IconName;
+    type?: "button" | "submit" | "reset";
+    ref?: Ref<HTMLButtonElement>;
+}
+declare function Button({ variant, size, loading, icon, children, className, disabled, type, ref, ...rest }: ButtonProps): react.JSX.Element;
+
+/**
+ * The checkbox. Canonical source: .docs/styleguide/04-components.md section 3.4.
+ *
+ * Controlled only, and `checked` carries the third state rather than a separate
+ * `indeterminate` prop, because "indeterminate and unchecked" is not a state a table
+ * header selection can be in and a two-prop API lets a caller express it anyway.
+ *
+ * The visible box is a span; the real input stays in the accessibility tree and keeps the
+ * native label association, Space activation and form participation. Hiding it visually
+ * rather than replacing it is what makes the whole label a click target for free.
+ */
+interface CheckboxProps {
+    checked: boolean | "indeterminate";
+    onChange: (checked: boolean) => void;
+    /** Sits to the right of the box. Omit it only when a nearby cell header names the column. */
+    label?: string;
+    /** Required when there is no visible label, for example the selection cell in a table. */
+    ariaLabel?: string;
+    name?: string;
+    value?: string;
+    disabled?: boolean;
+    id?: string;
+    "aria-describedby"?: string | undefined;
+}
+declare function Checkbox({ checked, onChange, label, ariaLabel, name, value, disabled, id, "aria-describedby": describedBy, }: CheckboxProps): react.JSX.Element;
+
+/**
+ * The empty state. Canonical source: .docs/styleguide/04-components.md section 15.
+ *
+ * One icon, one heading, one description, at most one action. `action` is a single node
+ * rather than an array on purpose: the guide calls a second action a design error, and a
+ * type that cannot express it is cheaper than a review that has to catch it.
+ */
+interface EmptyStateProps {
+    icon?: IconName;
+    heading: string;
+    description?: string;
+    /** One primary or secondary button. */
+    action?: ReactNode;
+}
+declare function EmptyState({ icon, heading, description, action }: EmptyStateProps): react.JSX.Element;
+
+/**
+ * Field composition: label, 8px, control, 6px, help or error.
+ * Canonical source: .docs/styleguide/04-components.md section 3.1.
+ *
+ * The error replaces the help text rather than joining it, so a field never shows two
+ * competing sentences about the same value.
+ */
+interface FieldProps {
+    label: string;
+    /** Renders the `*` marker and wires `aria-required` on the control. */
+    required?: boolean;
+    /** Renders the right-aligned "Optional" marker. Ignored when `required` is set. */
+    optional?: boolean;
+    help?: string | undefined;
+    error?: string | undefined;
+    children: (control: {
+        id: string;
+        describedBy: string | undefined;
+        invalid: boolean;
+    }) => ReactNode;
+}
+declare function Field({ label, required, optional, help, error, children, }: FieldProps): react.JSX.Element;
+interface TextInputProps extends InputHTMLAttributes<HTMLInputElement> {
+    invalid?: boolean;
+    /**
+     * Inline validation in flight. Shows the spinner inside the trailing edge and takes the
+     * control read-only rather than disabled, so the value stays selectable and the label
+     * stays associated.
+     */
+    loading?: boolean;
+}
+declare function TextInput({ invalid, loading, className, readOnly, ...rest }: TextInputProps): react.JSX.Element;
+
+/**
+ * Form-level error: the failure that belongs to the submission rather than to one field.
+ * Canonical source: .docs/styleguide/04-components.md section 3.8.
+ *
+ * It is a live region because it usually appears after a submit, when focus is still on
+ * the button and nothing else on screen announces the refusal.
+ */
+declare function FormError({ children }: {
+    children: ReactNode;
+}): react.JSX.Element;
+
+declare const ROLES: readonly ["admin", "editor", "author"];
+type Role = (typeof ROLES)[number];
+/** Actions performed on the entries of one content type. */
+type EntryAction = "read" | "create" | "update" | "delete";
+/** Actions that are not scoped to a content type. */
+type AdminAction = "manage-schema" | "manage-users" | "manage-settings" | "manage-media";
+type Action = EntryAction | AdminAction;
+/**
+ * Who may do what with one content type. A missing action falls back to the role defaults
+ * in `can()`, so an empty matrix means "use the defaults", not "deny everything".
+ */
+type PermissionMatrix = Partial<Record<EntryAction, readonly Role[]>>;
+interface AuthUser {
+    uid: string;
+    email: string;
+    displayName: string | null;
+    role: Role;
+    disabled: boolean;
+}
+
+/**
+ * A reference from an entry to an item in the media library.
+ *
+ * Entries store the reference, not the media document, so renaming a file or editing its
+ * alt text does not require rewriting every entry that uses it. The denormalized `url` is
+ * a read convenience for the SDK and is refreshed by the adapter when the media item
+ * changes; `mediaId` is the source of truth.
+ */
+interface MediaReference {
+    mediaId: string;
+    url: string;
+}
+interface MediaItem {
+    id: string;
+    name: string;
+    /** MIME type, for example `image/webp`. */
+    type: string;
+    /** Bytes. */
+    size: number;
+    url: string;
+    /** Storage object path, relative to the bucket root. */
+    path: string;
+    alt: string | null;
+    /** Pixels. Null for non-images. */
+    width: number | null;
+    height: number | null;
+    createdAt: string;
+    createdBy: string;
+}
+
+declare const FIELD_TYPES: readonly ["text", "textarea", "number", "boolean", "select", "date", "slug", "richtext", "image", "file", "relation", "repeater"];
+type FieldType = (typeof FIELD_TYPES)[number];
+/**
+ * The full rule vocabulary. Every rule compiles to the same runtime validator, which the
+ * admin form and the adapter both run, so a rule can never be enforced in one place only.
+ */
+interface ValidationRules {
+    required?: boolean;
+    minLength?: number;
+    maxLength?: number;
+    min?: number;
+    max?: number;
+    /** Serialized as a string, not a RegExp, because rules travel through Firestore. */
+    pattern?: string;
+    /** Rejects a value already held by another entry of the same content type. */
+    unique?: boolean;
+}
+interface FieldCommon {
+    label: string;
+    description?: string;
+    placeholder?: string;
+    validation?: ValidationRules;
+    /** Hidden fields still store and validate; they are simply not rendered in the form. */
+    hidden?: boolean;
+    readonly?: boolean;
+}
+interface TextField extends FieldCommon {
+    type: "text";
+    defaultValue?: string;
+}
+interface TextareaField extends FieldCommon {
+    type: "textarea";
+    rows?: number;
+    defaultValue?: string;
+}
+interface NumberField extends FieldCommon {
+    type: "number";
+    step?: number;
+    defaultValue?: number;
+}
+interface BooleanField extends FieldCommon {
+    type: "boolean";
+    defaultValue?: boolean;
+}
+interface SelectOption$1<TValue extends string = string> {
+    value: TValue;
+    label: string;
+}
+interface SelectField<TValue extends string = string> extends FieldCommon {
+    type: "select";
+    options: readonly SelectOption$1<TValue>[];
+    multiple?: boolean;
+    defaultValue?: TValue;
+}
+interface DateField extends FieldCommon {
+    type: "date";
+    /** `date` stores `YYYY-MM-DD`; `datetime` stores a full ISO 8601 instant. */
+    precision?: "date" | "datetime";
+}
+interface SlugField extends FieldCommon {
+    type: "slug";
+    /** Field key the slug is derived from until the editor overrides it. */
+    from?: string;
+}
+/**
+ * Rich text is stored as a serialized document, not as an HTML string, so the editor choice
+ * (settled in M5) stays an implementation detail and the value can be re-rendered rather
+ * than re-parsed.
+ */
+interface RichTextValue {
+    format: "husk-richtext-v1";
+    content: unknown;
+}
+interface RichtextField extends FieldCommon {
+    type: "richtext";
+    /** Marks and blocks the toolbar offers. Absent means the default set. */
+    features?: readonly string[];
+}
+interface ImageField extends FieldCommon {
+    type: "image";
+    accept?: readonly string[];
+}
+interface FileField extends FieldCommon {
+    type: "file";
+    accept?: readonly string[];
+}
+interface RelationField<TTo extends string = string> extends FieldCommon {
+    type: "relation";
+    /** Slug of the referenced content type. */
+    to: TTo;
+    many?: boolean;
+}
+interface RepeaterField<TFields extends FieldMap = FieldMap> extends FieldCommon {
+    type: "repeater";
+    fields: TFields;
+    min?: number;
+    max?: number;
+}
+type FieldDefinition = TextField | TextareaField | NumberField | BooleanField | SelectField | DateField | SlugField | RichtextField | ImageField | FileField | RelationField | RepeaterField;
+type FieldMap = {
+    readonly [key: string]: FieldDefinition;
+};
+/** The value one field definition produces, before required-ness is applied. */
+type FieldValue<TField extends FieldDefinition> = TField extends TextField | TextareaField | SlugField ? string : TField extends NumberField ? number : TField extends BooleanField ? boolean : TField extends DateField ? string : TField extends SelectField<infer TOption> ? TField extends {
+    multiple: true;
+} ? TOption[] : TOption : TField extends RichtextField ? RichTextValue : TField extends ImageField | FileField ? MediaReference : TField extends RelationField ? TField extends {
+    many: true;
+} ? string[] : string : TField extends RepeaterField<infer TFields> ? FieldValues<TFields>[] : never;
+type IsRequired<TField extends FieldDefinition> = TField extends {
+    validation: {
+        required: true;
+    };
+} ? true : false;
+/**
+ * Read shape: every key is present. An optional field reads as `null` rather than
+ * `undefined`, so a consumer never has to distinguish "absent" from "empty".
+ */
+type FieldValues<TFields extends FieldMap> = {
+    [K in keyof TFields]: IsRequired<TFields[K]> extends true ? FieldValue<TFields[K]> : FieldValue<TFields[K]> | null;
+};
+
+type ContentTypeKind = "collection" | "singleton";
+/**
+ * A field that was removed from a content type while its stored values were kept.
+ *
+ * Removal is a state, not an absence. The definition is parked here instead of being
+ * deleted, so the admin can name the field in a warning, offer it back unchanged, and so a
+ * later purge knows what it is about to destroy. Nothing downstream of the registry reads
+ * this map: forms, validation, list columns and the SDK all read `fields`, which is why a
+ * removed field is inert everywhere without a single consumer having to filter it out.
+ */
+interface RemovedField {
+    /** Exactly the definition the field had at the moment it was removed. */
+    field: FieldDefinition;
+    /** ISO 8601. A plain string, because a stored content type is plain JSON. */
+    removedAt: string;
+    /** uid of whoever removed it. */
+    removedBy: string;
+}
+type RemovedFieldMap = {
+    readonly [key: string]: RemovedField;
+};
+/** Where a content type came from. Code always wins a slug conflict. See the registry. */
+type ContentTypeSource = "code" | "database";
+/**
+ * A content type with its field map erased to `FieldMap`.
+ *
+ * `ContentType<TFields>` is invariant in `TFields`, so a concrete content type produced by
+ * `defineContentType` is not assignable to `ContentType<FieldMap>`. Everything that handles
+ * content types generically (the registry, the adapter, the Schema Builder) takes this
+ * structural shape instead, which a concrete content type does satisfy. Authoring and
+ * inference keep the generic form.
+ */
+interface ContentTypeLike {
+    slug: string;
+    kind: ContentTypeKind;
+    label: string;
+    labelPlural?: string;
+    description?: string;
+    icon?: string;
+    fields: FieldMap;
+    /**
+     * The order the fields are shown in, as a list of field keys.
+     *
+     * It exists because `fields` is a map and a map does not keep an order once it has been
+     * through Firestore: a stored document returns its map keys sorted, not in the order they
+     * were written. A code-defined type never round trips and keeps its literal's order, so
+     * this key is absent there and the object order is used; the Schema Builder writes it on
+     * every save, which is what makes a reorder survive a reload.
+     *
+     * It is a hint, not a second source of truth. An unknown key in it is ignored and a field
+     * missing from it is appended, so a `fieldOrder` that has drifted from `fields` still
+     * renders every field exactly once.
+     */
+    fieldOrder?: readonly string[];
+    removedFields?: RemovedFieldMap;
+    locked?: boolean;
+    titleField?: string;
+    defaultSort?: {
+        field: string;
+        direction: "asc" | "desc";
+    };
+    permissions?: PermissionMatrix;
+    schemaVersion?: number;
+}
+type ContentTypeValues<TType extends {
+    fields: FieldMap;
+}> = FieldValues<TType["fields"]>;
+
+declare const ENTRY_STATUSES: readonly ["draft", "published", "archived"];
+type EntryStatus = (typeof ENTRY_STATUSES)[number];
+/**
+ * Everything the adapter owns on an entry. Written on every mutation, never by a form.
+ * Timestamps are ISO 8601 strings at this boundary; the Firestore converter turns them
+ * into Timestamps on the way in and back on the way out.
+ */
+interface EntryMeta {
+    id: string;
+    status: EntryStatus;
+    createdAt: string;
+    createdBy: string;
+    updatedAt: string;
+    updatedBy: string;
+    publishedAt: string | null;
+    schemaVersion: number;
+}
+/** What a read returns: the metadata plus the typed field values. */
+type Entry<TType extends AnyContentTypeShape = AnyContentTypeShape> = EntryMeta & ContentTypeValues<TType>;
+/**
+ * Structural stand-in for `ContentType<TFields>`. `ContentType` is invariant in its field
+ * map (it uses `keyof TFields` for titleField and defaultSort), so a concrete content type
+ * is not assignable to `ContentType<FieldMap>` and cannot be used as a constraint here.
+ */
+type AnyContentTypeShape = {
+    fields: FieldMap;
+};
+interface FieldError {
+    /** Dotted path, so a repeater reports `blocks.2.title` rather than `blocks`. */
+    path: string;
+    rule: string;
+    message: string;
+}
+
+/**
+ * The one error taxonomy the admin renders from.
+ *
+ * Before this existed the treatments were real but scattered: the entry editor routed a
+ * `ValidationError` to the offending field and fell back to a form-level message, the
+ * Schema Builder put every failure in one banner, the media screens put every failure in a
+ * toast, and a permission refusal read as "something went wrong" in all three. Each of
+ * those was defensible on its own and none of them agreed with the others.
+ *
+ * This module is not a second system layered over them. It is the first one, factored out:
+ * the M6 rule that a validation error lands on the field and only an unroutable path
+ * reaches the form is preserved exactly, as the `field` treatment, and every other screen
+ * now asks the same question instead of answering it privately.
+ *
+ * Five categories, one treatment each:
+ *
+ * | category     | treatment | what the user sees                                        |
+ * |--------------|-----------|-----------------------------------------------------------|
+ * | `validation` | `field`   | the message on the control that owns the path; never a bare toast |
+ * | `permission` | `banner`  | a form-level notice naming the action, the subject and the role |
+ * | `not-found`  | `state`   | an empty state with a way back; no alert, no red            |
+ * | `conflict`   | `resolve` | a banner that names both resolutions and offers them        |
+ * | `transport`  | `retry`   | a banner or state carrying the one action that can help     |
+ *
+ * `unknown` is the sixth, for a failure that fits none of them. It takes the `banner`
+ * treatment and says plainly that the cause is unknown, rather than guessing at a category
+ * and offering a retry that cannot work.
+ *
+ * The toast is deliberately not a treatment. It is the announcement channel for a failure
+ * whose surface has already closed (a dialog that dismissed itself, a background upload),
+ * and when it is used it prints this same `title` and `message`, so a failure can never be
+ * worded twice.
+ *
+ * No React and no Firebase here, so the classification is testable in the node project and
+ * callable from the adapter as well as from a render.
+ */
+declare const ERROR_CATEGORIES: readonly ["validation", "permission", "not-found", "conflict", "transport", "unknown"];
+type ErrorCategory = (typeof ERROR_CATEGORIES)[number];
+/** The chrome a category is rendered in. Exactly one per category; see the table above. */
+type ErrorTreatment = "field" | "banner" | "state" | "resolve" | "retry";
+interface ClassifiedError {
+    category: ErrorCategory;
+    treatment: ErrorTreatment;
+    /** A short heading. Used as the banner's first line and as a toast title. */
+    title: string;
+    /** One or two sentences: what happened, and what the user can do about it. */
+    message: string;
+    /**
+     * The field errors, for `validation` only. Every other category leaves this empty, which
+     * is what stops a non-validation failure from being routed onto a control.
+     */
+    fieldErrors: readonly FieldError[];
+    /** True only for `transport`. A retry of anything else repeats the same refusal. */
+    retryable: boolean;
+    /** What was thrown, kept for a boundary that wants to log it. Never rendered. */
+    cause: unknown;
+}
+
+/**
+ * What covers the failure a React error boundary cannot see.
+ *
+ * A boundary catches a throw during render, in an effect, or in a lifecycle. It does not
+ * catch a rejected promise, and almost everything the admin does is a rejected promise: an
+ * adapter call, an upload, a listener. Every one of those is inside a `try`/`catch` today,
+ * but "every one" is a property of the code as it stands, not a mechanism, and the first
+ * handler somebody forgets is a failure that reaches nobody. The browser's own answer to
+ * an unhandled rejection is a console line the user will never see.
+ *
+ * So the admin listens at the window. An unhandled rejection is classified through the same
+ * taxonomy as a caught one and raised as an error toast, which does not auto-dismiss.
+ * `preventDefault` stops the default console report, because the toast now owns it.
+ *
+ * `error` is listened to for the same reason: a throw inside a `setTimeout` or an event
+ * handler registered outside React is not on any component's stack either.
+ *
+ * This is a net, not a treatment. Anything it catches is a missing `catch` somewhere, and
+ * the toast says so in the one place that was not meant to have to.
+ */
+interface ErrorCaptureProps {
+    /**
+     * Called for every captured failure, before the toast. For a host that ships errors to
+     * a reporter; the admin itself does not, because it has no service to ship them to.
+     */
+    onCapture?: ((error: ClassifiedError) => void) | undefined;
+}
+declare function ErrorCapture({ onCapture }: ErrorCaptureProps): null;
+
+/**
+ * The in-place treatment for a classified error that is not a field error.
+ * Canonical source: .docs/styleguide/04-components.md section 19.
+ *
+ * One component for the `banner`, `resolve` and `retry` treatments, because they are one
+ * piece of chrome with a different actions slot, not three designs. Splitting them would
+ * be how a permission refusal and a transport failure end up looking like two products.
+ *
+ * `validation` never reaches here. Its treatment is the field itself, and the entry editor
+ * routes each error to the control that owns its path; only a path naming no rendered field
+ * falls back to a banner, which is the M6 rule this component inherits rather than replaces.
+ * `not-found` never reaches here either: it is a state, rendered by `ErrorScreen`.
+ */
+interface ErrorNoticeProps {
+    error: ClassifiedError;
+    /**
+     * The retry. Rendered only when the taxonomy says a retry is meaningful, so a screen
+     * cannot offer one for a refusal that will refuse again.
+     */
+    onRetry?: (() => void) | undefined;
+    /** The resolutions for a `conflict`, which has two and must name both. */
+    actions?: ReactNode;
+    className?: string;
+}
+declare function ErrorNotice({ error, onRetry, actions, className }: ErrorNoticeProps): react.JSX.Element;
+
+/**
+ * The animated half of the icon system. Canonical source:
+ * .docs/styleguide/05-icons.md section 2.
+ *
+ * Morphicons is not a second icon family: it animates between two Lucide drawings. It
+ * consumes icon *data* rather than components, which is why this is the one file that
+ * imports the vanilla `lucide` package as well as `lucide-react` in `icon.tsx`. Both are
+ * pinned to the same version, so a morph and the static icon next to it are the same
+ * drawing.
+ *
+ * A morph is allowed only in the cases section 2.1 lists, so the glyph map is a closed set
+ * of four names rather than the whole vocabulary: a screen cannot animate an icon the
+ * guide says should not move. Names are checked against the static vocabulary, so a morph
+ * pair can never drift onto a concept that does not exist.
+ */
+declare const MORPH_GLYPHS: {
+    readonly "open-navigation": lucide.IconNode;
+    readonly close: lucide.IconNode;
+    readonly "navigate-into": lucide.IconNode;
+    readonly expand: lucide.IconNode;
+    readonly copy: lucide.IconNode;
+    readonly save: lucide.IconNode;
+};
+type MorphIconName = keyof typeof MORPH_GLYPHS;
+interface MorphingIconProps {
+    name: MorphIconName;
+    /** The same six sizes the static icon allows. */
+    size?: 12 | 14 | 16 | 18 | 20 | 24;
+    /** Set only where the icon is the whole message; otherwise it stays decorative. */
+    label?: string;
+    className?: string;
+}
+declare function MorphingIcon({ name, size, label, className }: MorphingIconProps): react.JSX.Element;
+
+interface IconButtonBase extends Omit<ButtonHTMLAttributes<HTMLButtonElement>, "type" | "children" | "aria-label"> {
+    /** The accessible name, and the tooltip text unless `tooltip` overrides it. */
+    label: string;
+    tooltip?: string;
+    tooltipPlacement?: "top" | "bottom";
+    variant?: ButtonVariant;
+    size?: ButtonSize;
+    /**
+     * Turns the button into a toggle that reports a state: `aria-pressed` plus the pressed
+     * appearance from .docs/styleguide/04-components.md section 2.3. The guide allows it on the
+     * `ghost` variant only, which is the default here.
+     */
+    pressed?: boolean;
+    loading?: boolean;
+    ref?: Ref<HTMLButtonElement>;
+    type?: "button" | "submit" | "reset";
+}
+type IconButtonProps = IconButtonBase & ({
+    icon: IconName;
+    morph?: false;
+} | {
+    icon: MorphIconName;
+    morph: true;
+});
+declare function IconButton(props: IconButtonProps): react.JSX.Element;
+
+/**
+ * The dropdown menu. Canonical source: .docs/styleguide/04-components.md section 11.
+ *
+ * Items are data rather than children, because every menu in the admin is generated: the
+ * row actions come from what the user may do to that entry, the sidebar overflow comes
+ * from the registry. A children-based API would invite a screen to hand-build one.
+ *
+ * Keyboard behaviour follows the menu button pattern: the trigger opens on Enter, Space or
+ * ArrowDown, focus moves into the list, arrows move the highlight past disabled items and
+ * separators, Escape closes and returns focus to the trigger, and Tab closes without
+ * grabbing focus back so the page's tab order is preserved.
+ */
+type MenuEntry = {
+    kind: "item";
+    id: string;
+    label: string;
+    icon?: IconName;
+    /** Renders the trailing check from section 11. */
+    selected?: boolean;
+    destructive?: boolean;
+    disabled?: boolean;
+    /** Right-aligned hint, for example "Ctrl S". Display only; the menu binds nothing. */
+    shortcut?: string;
+} | {
+    kind: "separator";
+    id: string;
+} | {
+    kind: "section";
+    id: string;
+    label: string;
+};
+interface MenuProps {
+    items: readonly MenuEntry[];
+    onSelect: (id: string) => void;
+    /** The trigger's accessible name, and its tooltip when the trigger is icon-only. */
+    label: string;
+    /** Set to render a labelled trigger instead of the icon-only default. */
+    triggerLabel?: string;
+    triggerIcon?: IconName;
+    triggerVariant?: ButtonVariant;
+    triggerSize?: ButtonSize;
+    /** Which edge of the trigger the menu lines up with. */
+    align?: "start" | "end";
+    /**
+     * Which side of the trigger the menu opens toward. Defaults to `"bottom"`, unchanged from
+     * every existing call site. Set to `"top"` for a trigger pinned to the bottom of a
+     * scrollable region, for example the sidebar's account menu, so the panel opens into the
+     * viewport instead of past it.
+     */
+    side?: "top" | "bottom";
+}
+declare function Menu({ items, onSelect, label, triggerLabel, triggerIcon, triggerVariant, triggerSize, align, side, }: MenuProps): react.JSX.Element;
+
+/**
+ * The metric tile: one label, one number.
+ * Canonical source: .docs/styleguide/03-layout.md section 4.2, with the internal spacing
+ * added to that section in the same change that added this component.
+ *
+ * Three states, and the third is the point. A figure the data layer could not produce
+ * renders as `Unavailable` with the reason beside it, because a plausible-looking wrong
+ * number on a dashboard is worse than an admitted gap: nobody checks a number that looks
+ * right.
+ *
+ * The value row keeps the `metric-lg` line height in every state, so a tile that is
+ * loading, resolved or unavailable occupies the same box and the grid never reflows.
+ */
+interface MetricProps {
+    label: string;
+    /** Ignored while `loading`, and when `unavailable` is set. */
+    value?: string | number;
+    /** One line under the value: the unit, or what the number counts. */
+    caption?: string;
+    icon?: IconName;
+    loading?: boolean;
+    /** Why there is no figure. Replaces the value and is shown in place of the caption. */
+    unavailable?: string;
+    className?: string;
+}
+declare function Metric({ label, value, caption, icon, loading, unavailable, className, }: MetricProps): react.JSX.Element;
+
+/**
+ * The modal. Canonical source: .docs/styleguide/04-components.md section 12.
+ *
+ * The visual half is small; the behaviour is the component. Focus lands on the first
+ * interactive element, Tab cycles inside the dialog instead of walking out into the page
+ * behind it, Escape closes, closing returns focus to whatever opened it, and page scroll
+ * is locked while it is open.
+ *
+ * `dismissible` is false for destructive dialogs, which is what the guide means by "the
+ * backdrop click closes a non-destructive dialog only". Escape still works there: a user
+ * who wants out must always have a way out, and cancelling a delete is the safe outcome.
+ */
+type ModalWidth = "sm" | "md" | "lg" | "xl";
+interface ModalProps {
+    open: boolean;
+    onClose: () => void;
+    title: string;
+    description?: string;
+    width?: ModalWidth;
+    /** Whether a backdrop click closes. False for destructive confirmations. */
+    dismissible?: boolean;
+    /** Right-aligned actions: cancel as secondary, confirm last. */
+    footer?: ReactNode;
+    children?: ReactNode;
+}
+declare function Modal({ open, onClose, title, description, width, dismissible, footer, children, }: ModalProps): react.ReactPortal | null;
+
+/**
+ * The pagination row under a table.
+ * Canonical source: .docs/styleguide/04-components.md section 6.
+ *
+ * Cursor paging, not page numbers: the guide rules numbered page lists out, and Firestore
+ * cannot answer "page 7" anyway without reading the six pages before it. Previous and next
+ * are therefore the only moves, and the caller holds the cursors.
+ *
+ * The range reads "1-25 of 248" when the total is known and "1-25" when it is not. A total
+ * is a separate count read that can be refused on its own, and inventing one would mislead
+ * the reader about how much is behind the list.
+ */
+interface PaginationProps {
+    /** 1-based index of the first row on this page. */
+    from: number;
+    /** 1-based index of the last row on this page. */
+    to: number;
+    total?: number | undefined;
+    hasPrevious: boolean;
+    hasNext: boolean;
+    onPrevious: () => void;
+    onNext: () => void;
+    /** Names what is being paged, for the arrows' accessible names. */
+    label: string;
+}
+declare function Pagination({ from, to, total, hasPrevious, hasNext, onPrevious, onNext, label, }: PaginationProps): react.JSX.Element;
+
+/**
+ * The page header every admin screen opens with.
+ * Canonical source: .docs/styleguide/03-layout.md section 3.1.
+ *
+ * It owns the 24px gap to the first section, so a screen never restates it, and it is the
+ * only place the breadcrumb may appear. The title is an `h1`: one per document, and the
+ * shell around it contributes none.
+ *
+ * Title and description are strings rather than nodes. Every later screen is generated
+ * from the registry, and a header that accepts arbitrary markup is an invitation for one
+ * content type to look different from the rest.
+ */
+interface PageHeaderProps {
+    title: string;
+    description?: string;
+    /** The trail above the title. The last item is the current page. */
+    breadcrumb?: readonly BreadcrumbItem[];
+    /** Right side. Primary action last, per the guide. */
+    actions?: ReactNode;
+    className?: string;
+}
+declare function PageHeader({ title, description, breadcrumb, actions, className, }: PageHeaderProps): react.JSX.Element;
+
+/**
+ * The panel, in the two forms the system has.
+ * Canonical source: .docs/styleguide/03-layout.md sections 4.1, 4.2 and 4.3.
+ *
+ * Standard is the content container; `raised` is the metric tile. Neither carries a
+ * shadow, and the raised one always carries `border-subtle`, so a panel edge stays legible
+ * against `surface-base`.
+ *
+ * A panel is the second and last level of container the system allows. Nesting one inside
+ * another inside a third is a design error, not a layout choice.
+ */
+type PanelPadding = "none" | "compact" | "standard" | "large";
+interface PanelProps {
+    children: ReactNode;
+    /**
+     * `none` is for a body that supplies its own inset: a table, or a row list separated by
+     * `border-subtle`. Padding there would sit on top of the row padding and double it.
+     */
+    padding?: PanelPadding;
+    /** The raised metric panel from section 4.2. */
+    raised?: boolean;
+    className?: string;
+}
+declare function Panel({ children, padding, raised, className, }: PanelProps): react.JSX.Element;
+
+/**
+ * The upload progress bar.
+ * Canonical source: .docs/styleguide/04-components.md section 16.
+ *
+ * Uploads are the only thing in the system that gets one. Everywhere else the wait has no
+ * measurable length and a skeleton or a spinner is the honest control.
+ *
+ * The fill width is an inline style rather than a class, because it is a measured value
+ * and not a design decision: there is no token for "43 percent", and writing one as an
+ * arbitrary Tailwind class would be exactly the ad-hoc styling the lint rule forbids.
+ * Every other value on this element is a token.
+ */
+interface ProgressProps {
+    /** 0 to 1. Clamped, because a transferred byte count can briefly exceed the total. */
+    value: number;
+    /** Names what is progressing, for a reader who cannot see the bar. */
+    label: string;
+    className?: string;
+}
+declare function Progress({ value, label, className }: ProgressProps): react.JSX.Element;
+
+/**
+ * Sections and the vertical rhythm between them.
+ * Canonical source: .docs/styleguide/03-layout.md sections 3.1 and 3.2.
+ *
+ * The rhythm is owned in exactly two places: the page header carries the 24px to the first
+ * section, and `PageSections` carries the 32px between two sections. A `Section` therefore
+ * has no outer margin of its own, which is what stops a screen from adding one and drifting
+ * out of the system.
+ */
+declare function PageSections({ children, className, }: {
+    children: ReactNode;
+    className?: string;
+}): react.JSX.Element;
+interface SectionProps {
+    /** Omitted for a section that needs no heading; the rhythm is unchanged either way. */
+    heading?: string;
+    description?: string;
+    /** Section-level controls, right-aligned beside the heading. */
+    actions?: ReactNode;
+    children: ReactNode;
+    className?: string;
+}
+declare function Section({ heading, description, actions, children, className, }: SectionProps): react.JSX.Element;
+
+/**
+ * The select. Canonical source: .docs/styleguide/04-components.md section 3.3.
+ *
+ * It is a listbox rather than a native `<select>`, because the guide requires the trigger
+ * to match the text input exactly and the open list to be the menu surface from section
+ * 11 with a check on the selected option. A native select renders the operating system's
+ * popup, which no stylesheet reaches.
+ *
+ * That trade has a cost: everything the platform gives away for free (focus, typeahead,
+ * Escape, activedescendant) has to be implemented here, which is why the keyboard handler
+ * is the longest part of the file. A hidden input carries the value so the control still
+ * submits inside a plain form.
+ */
+interface SelectOption {
+    value: string;
+    label: string;
+    disabled?: boolean;
+}
+interface SelectProps {
+    options: readonly SelectOption[];
+    value: string | null;
+    onChange: (value: string) => void;
+    id?: string;
+    name?: string;
+    placeholder?: string;
+    invalid?: boolean;
+    disabled?: boolean;
+    "aria-describedby"?: string | undefined;
+    "aria-label"?: string | undefined;
+}
+declare function Select({ options, value, onChange, id, name, placeholder, invalid, disabled, "aria-describedby": describedBy, "aria-label": ariaLabel, }: SelectProps): react.JSX.Element;
+
+/**
+ * The search field. Canonical source: .docs/styleguide/04-components.md section 3.2,
+ * placed by .docs/styleguide/03-layout.md section 5.1.
+ *
+ * The text input with a leading `search` icon and a trailing clear button that appears
+ * once there is something to clear. It holds no state and runs no query: what a search
+ * means is the screen's business, and the screen is the one that has to be honest about
+ * what its query can match.
+ */
+interface SearchInputProps {
+    value: string;
+    onChange: (value: string) => void;
+    /** The accessible name. There is no visible label in a toolbar. */
+    label: string;
+    placeholder?: string;
+    disabled?: boolean;
+    /** Id of the caption that states what the search matches. */
+    describedBy?: string | undefined;
+    className?: string;
+}
+declare function SearchInput({ value, onChange, label, placeholder, disabled, describedBy, className, }: SearchInputProps): react.JSX.Element;
+
+/**
+ * The skeleton. Canonical source: .docs/styleguide/04-components.md section 16.
+ *
+ * Skeletons are the default loading treatment and spinners are the exception, so this
+ * component mirrors the shape of what it replaces rather than offering a generic grey
+ * box: a text line is as tall as its type token's line height, a block carries the radius
+ * of the component it stands in for.
+ *
+ * The pulse is behind `motion-safe`, because a reduced-motion user gets the layout
+ * without the animation, which is the whole benefit of a skeleton anyway.
+ */
+type SkeletonLine = "heading-md" | "heading-sm" | "body" | "body-sm" | "label" | "caption" | "micro" | "metric-lg" | "metric-md";
+declare const RADII: {
+    readonly xs: "rounded-xs";
+    readonly sm: "rounded-sm";
+    readonly md: "rounded-md";
+    readonly lg: "rounded-lg";
+    readonly full: "rounded-full";
+};
+interface SkeletonProps {
+    /** Renders a text line at the given type token's line height and `radius-xs`. */
+    line?: SkeletonLine;
+    /** Ignored when `line` is set, which always uses `radius-xs`. */
+    radius?: keyof typeof RADII;
+    /** Width and, for a block, height. Token utilities only. */
+    className?: string;
+    /**
+     * Announces the wait. Set it once per loading region, not once per skeleton, or a
+     * screen reader reads "Loading" for every line on the page.
+     */
+    label?: string;
+}
+declare function Skeleton({ line, radius, className, label }: SkeletonProps): react.JSX.Element;
+
+/**
+ * The only spinner in the system.
+ *
+ * A spinner is allowed where the final structure is unknown or the wait sits inside a
+ * control: skeletons cover everything else. See .docs/styleguide/04-components.md
+ * section 16.
+ */
+interface SpinnerProps {
+    /** 14px inside a field, 16px inside a button. The guide allows no other size. */
+    size?: 14 | 16;
+    label?: string;
+}
+declare function Spinner({ size, label }: SpinnerProps): react.JSX.Element;
+
+/**
+ * The switch. Canonical source: .docs/styleguide/04-components.md section 3.6.
+ *
+ * Use it only for a boolean that takes effect the moment it is flipped. A boolean that is
+ * saved with a form is a checkbox, because a switch promises the change already happened
+ * and a pending form has not.
+ *
+ * It is a button with `role="switch"`, not a checkbox: screen readers announce "on" and
+ * "off" for a switch and "checked" for a checkbox, and the difference is the whole point
+ * of the control.
+ */
+interface SwitchProps {
+    checked: boolean;
+    onChange: (checked: boolean) => void;
+    /** The accessible name. Required, since the track carries no text. */
+    label: string;
+    /** Renders `label` next to the track. Leave false where a field label already names it. */
+    showLabel?: boolean;
+    disabled?: boolean;
+    id?: string;
+    "aria-describedby"?: string | undefined;
+}
+declare function Switch({ checked, onChange, label, showLabel, disabled, id, "aria-describedby": describedBy, }: SwitchProps): react.JSX.Element;
+
+/**
+ * The multi-line text control.
+ * Canonical source: .docs/styleguide/04-components.md section 3.2.
+ *
+ * It repeats the input's box rather than reusing `INPUT_BASE`, because the guide gives the
+ * textarea a different height, block padding and resize behaviour, and a shared base string
+ * plus four overrides is harder to read than the eight declarations it replaces.
+ *
+ * Resize is vertical only: a control that can be dragged wider than its column breaks the
+ * form grid, and no editor has ever wanted that.
+ */
+interface TextareaProps extends TextareaHTMLAttributes<HTMLTextAreaElement> {
+    invalid?: boolean;
+}
+declare function Textarea({ invalid, className, readOnly, rows, ...rest }: TextareaProps): react.JSX.Element;
+
+/**
+ * The table shell. Canonical source: .docs/styleguide/04-components.md section 5.
+ *
+ * A shell, not a data grid: it fixes geometry, density and state styling, and knows
+ * nothing about content types, sorting logic or selection logic. The list view generated
+ * from the registry owns all of that and composes these parts.
+ *
+ * Density is fixed by the guide, so there is no size prop and no comfortable/compact
+ * toggle. The table carries no outer border either: it lives inside a panel and shares
+ * the panel's edge.
+ */
+interface TableProps {
+    children: ReactNode;
+    /** Names the table for screen readers when no caption is visible. */
+    label?: string;
+    className?: string;
+}
+declare function Table({ children, label, className }: TableProps): react.JSX.Element;
+declare function TableHead({ children }: {
+    children: ReactNode;
+}): react.JSX.Element;
+declare function TableBody({ children }: {
+    children: ReactNode;
+}): react.JSX.Element;
+type SortDirection = "asc" | "desc";
+interface TableHeaderCellProps extends Omit<ThHTMLAttributes<HTMLTableCellElement>, "onClick"> {
+    children?: ReactNode;
+    /** Numeric columns are right-aligned so their cells line up under the header. */
+    numeric?: boolean;
+    /** Fixed-width columns: the selection cell and the action cell. */
+    width?: "selection" | "action";
+    /** Passing this makes the header a sort button. `null` is the unsorted state. */
+    sort?: {
+        direction: SortDirection | null;
+        onSort: () => void;
+    };
+}
+declare function TableHeaderCell({ children, numeric, width, sort, className, ...rest }: TableHeaderCellProps): react.JSX.Element;
+interface TableRowProps {
+    children: ReactNode;
+    selected?: boolean;
+    disabled?: boolean;
+    /** Set only when the whole row performs one action; it is what earns the pointer cursor. */
+    onActivate?: () => void;
+    className?: string;
+}
+declare function TableRow({ children, selected, disabled, onActivate, className, }: TableRowProps): react.JSX.Element;
+interface TableCellProps extends TdHTMLAttributes<HTMLTableCellElement> {
+    children?: ReactNode;
+    /** The title column: brighter and medium weight. */
+    primary?: boolean;
+    /** Right-aligned, tabular figures. */
+    numeric?: boolean;
+    /** Muted, tabular figures. */
+    date?: boolean;
+    width?: "selection" | "action";
+}
+declare function TableCell({ children, primary, numeric, date, width, className, ...rest }: TableCellProps): react.JSX.Element;
+/** The empty state spanning the whole table body. */
+declare function TableEmptyRow({ colSpan, children, }: {
+    colSpan: number;
+    children: ReactNode;
+}): react.JSX.Element;
+
+/**
+ * Toasts. Canonical source: .docs/styleguide/04-components.md section 14.
+ *
+ * A provider plus a hook rather than a component a screen renders, because the thing that
+ * raises a toast is usually a save handler three levels down from the region that shows
+ * it, and threading state up through those levels is how toast stacks end up duplicated.
+ *
+ * Error toasts do not auto-dismiss and are announced as alerts. Everything else disappears
+ * after five seconds and is announced politely, so a background save does not interrupt
+ * what the user is reading.
+ */
+type ToastTone = "success" | "warning" | "error" | "info";
+interface ToastOptions {
+    title: string;
+    description?: string;
+    tone?: ToastTone;
+}
+interface ToastApi {
+    /** Returns the id, so a long-running action can dismiss its own toast when it finishes. */
+    notify: (options: ToastOptions) => string;
+    dismiss: (id: string) => void;
+}
+declare function useToast(): ToastApi;
+/**
+ * The toast API, or null when no provider is mounted.
+ *
+ * For a screen where a toast is the secondary channel rather than the message itself: the
+ * entry editor renders every failure it can attribute on the field that owns it and every
+ * other failure at form level, and raises a toast on top of that. A host that forgot the
+ * provider should lose the toast, not the screen.
+ */
+declare function useOptionalToast(): ToastApi | null;
+declare function ToastProvider({ children }: {
+    children: ReactNode;
+}): react.JSX.Element;
+
+interface TooltipProps {
+    content: string;
+    /** Placed above by default; `bottom` is for triggers near the top edge of the viewport. */
+    placement?: "top" | "bottom";
+    /** A single element that can receive `aria-describedby`, normally a button. */
+    children: ReactElement<{
+        "aria-describedby"?: string | undefined;
+    }>;
+}
+declare function Tooltip({ content, placement, children }: TooltipProps): react.JSX.Element;
+
+/**
+ * The unsaved-changes guard.
+ *
+ * Leaving an editor with unsaved work has two halves and they are two different
+ * mechanisms, so they are written separately here rather than pretended to be one thing:
+ *
+ *  - **Closing the tab or reloading** is `beforeunload`. The browser owns the wording, the
+ *    buttons and whether it asks at all; all a page can do is say that it has something to
+ *    lose. It is attached only while the form is dirty, because a listener that is always
+ *    attached makes every reload of a clean page ask a question nobody needed.
+ *  - **Navigating inside the admin** is ours. A sidebar link, the cancel button and any
+ *    other in-app route change are intercepted, the user is asked in the admin's own
+ *    dialog, and the navigation is resumed or dropped by their answer.
+ *
+ * The done criterion this exists to satisfy is exact: leaving a dirty form warns, leaving
+ * a clean form does not. Which means a save has to make the warning stop. It does, because
+ * `dirty` is a comparison against the values the adapter confirmed (`valuesChanged` in
+ * core/entry-form.ts) and not a flag somebody has to remember to clear: the save writes
+ * the new baseline, the comparison goes false, and both halves detach on the same render.
+ */
+/**
+ * Warns before the tab closes or reloads while there is unsaved work.
+ *
+ * Standalone, so an editor still guards the unload path in a host that mounted no
+ * provider. The listener exists only while `dirty` is true.
+ */
+declare function useBeforeUnloadWarning(dirty: boolean): void;
+interface UnsavedChangesProviderProps {
+    /**
+     * Resumes an intercepted link navigation. The admin cannot know the host's router, and
+     * a host that supplies none falls back to a full document load, which is correct but
+     * slower. The playground passes `router.push`.
+     */
+    navigate?: ((href: string) => void) | undefined;
+    children: ReactNode;
+}
+declare function UnsavedChangesProvider({ navigate, children, }: UnsavedChangesProviderProps): react.JSX.Element;
+/**
+ * Registers a form's dirty state with the guard, and warns on unload while it is set.
+ *
+ * Called by the editor with the same `dirty` the save bar reads, so the two can never
+ * disagree about whether there is anything to lose. Unmounting clears the registration:
+ * a form that is gone has nothing left unsaved, and leaving the flag set would make every
+ * later navigation ask.
+ */
+declare function useUnsavedChanges(dirty: boolean): void;
+/**
+ * The gate an in-app navigation goes through.
+ *
+ * Without a provider it is the identity: the navigation happens. A host that mounted no
+ * guard gets no dialog, not a broken button.
+ */
+declare function useConfirmLeave(): (proceed: () => void) => void;
+
+/** A database-defined type that failed validation. Surfaced, never silently dropped. */
+interface InvalidContentType {
+    slug: string;
+    reason: string;
+    definition: unknown;
+}
+interface RegistryEntry {
+    type: ContentTypeLike;
+    source: ContentTypeSource;
+    locked: boolean;
+    /**
+     * A database-defined type with the same slug as this code-defined one. Code wins, but the
+     * database copy is kept so the admin can show the collision instead of silently
+     * discarding what an editor created.
+     */
+    conflict?: {
+        source: "database";
+        type: ContentTypeLike;
+    };
+}
+interface Registry {
+    readonly types: readonly RegistryEntry[];
+    readonly conflicts: readonly RegistryEntry[];
+    readonly invalid: readonly InvalidContentType[];
+    get(slug: string): RegistryEntry | undefined;
+    require(slug: string): RegistryEntry;
+    has(slug: string): boolean;
+    /** Entries whose winning definition came from this source. */
+    bySource(source: ContentTypeSource): readonly RegistryEntry[];
+}
+
+/**
+ * The sidebar as data. Canonical source: .docs/styleguide/03-layout.md section 2.1.
+ *
+ * The whole point of the registry is that nothing in the interface knows the name of a
+ * content type. This builder is the only place navigation is decided, it reads the
+ * registry and `can()`, and it returns plain serializable data so a server component can
+ * compute it and hand it to the client shell. Adding a content type therefore changes
+ * data and nothing else: no route table, no switch, no new file.
+ *
+ * It is deliberately free of React, so the server entry can export it without pulling a
+ * component into a module graph that never renders one.
+ */
+interface AdminNavItem {
+    /** Stable across renders and unique inside the whole navigation. */
+    key: string;
+    label: string;
+    href: string;
+    icon: IconName;
+    /**
+     * Active on an exact path match only. The dashboard owns the admin root, so every
+     * deeper route would otherwise light it up as well.
+     */
+    exact?: boolean;
+}
+interface AdminNavGroup {
+    key: string;
+    /** Absent for the leading group and the static group, which carry no heading. */
+    label?: string;
+    items: readonly AdminNavItem[];
+}
+
+interface AdminShellProps {
+    navigation: readonly AdminNavGroup[];
+    user: AuthUser;
+    /** The sidebar footer's menu trigger. The host owns it: the session is the host's. */
+    accountMenu?: ReactNode;
+    children: ReactNode;
+}
+declare function AdminShell({ navigation, user, accountMenu, children }: AdminShellProps): react.JSX.Element;
+
+interface AdminSidebarProps {
+    navigation: readonly AdminNavGroup[];
+    /** The route the browser is on, for the active item. */
+    pathname: string;
+    user: AuthUser;
+    /** The footer row's menu trigger. The host owns it: signing out is the host's session. */
+    accountMenu?: ReactNode;
+    /** Display and position only. The shell decides whether this is a grid column or a drawer. */
+    className?: string;
+    /** Set while the sidebar is the open drawer, so Escape and Tab can be handled there. */
+    panelRef?: Ref<HTMLElement>;
+    /** Called when a navigation item is followed, so the drawer can close behind it. */
+    onNavigate?: () => void;
+    /** Set while the sidebar is the open drawer, to keep Tab inside it. */
+    onKeyDown?: (event: KeyboardEvent<HTMLElement>) => void;
+}
+declare function AdminSidebar({ navigation, pathname, user, accountMenu, className, panelRef, onNavigate, onKeyDown, }: AdminSidebarProps): react.JSX.Element;
+
+/**
+ * The seam between the CMS and its storage.
+ *
+ * Everything above this interface (the admin, the SDK, the registry, the validator) is
+ * written against `CmsAdapter` and knows nothing about Firestore. Everything below it lives
+ * under `src/firebase/**`, which is the only place the Firebase SDK may be imported. If a
+ * screen or an SDK method needs something this interface does not offer, the interface
+ * grows; it is never bypassed.
+ *
+ * Values crossing this boundary are already in their read shape: timestamps are ISO 8601
+ * strings, references are ids, and field values match what `FieldValues` describes. The
+ * converters on the Firestore side own the translation in both directions.
+ */
+type FilterOperator = "==" | "!=" | "<" | "<=" | ">" | ">=" | "in" | "not-in" | "array-contains" | "array-contains-any";
+interface EntryFilter {
+    field: string;
+    op: FilterOperator;
+    value: unknown;
+}
+interface SortSpec {
+    field: string;
+    direction: "asc" | "desc";
+}
+interface ListQuery {
+    filters?: readonly EntryFilter[];
+    sort?: SortSpec;
+    /**
+     * Free text matched against the content type's `titleField`, as a prefix.
+     *
+     * What it does, exactly, because a search box that promises more than it delivers is
+     * worse than one that says what it is: the adapter turns the term into a range scan
+     * (`>= term`, `<= term + U+F8FF`) over the title field. That matches from the beginning
+     * of the title and it is case sensitive, because Firestore compares strings by their
+     * UTF-8 bytes and offers no substring, no fuzzy and no case-insensitive operator.
+     * "Portfolio" is found by "Port", not by "port" and not by "folio".
+     *
+     * Two consequences a caller has to know about:
+     *
+     * - A range filter forces the first ordering onto the field it ranges over, so a search
+     *   is always ordered by title ascending and `sort` is ignored while one is active.
+     * - A content type with no `titleField` has nothing to match against, so the adapter
+     *   rejects the query instead of silently returning everything. Ask `canSearch()` in
+     *   core/list-view.ts before offering the box.
+     */
+    search?: string;
+    /** Page size. The adapter caps it; see DEFAULT_PAGE_SIZE and MAX_PAGE_SIZE. */
+    limit?: number;
+    /** Opaque cursor from a previous page. Never constructed by a caller. */
+    cursor?: string | null;
+    /**
+     * `"any"` reads every status and is the admin default. The public SDK passes
+     * `"published"`, which is what keeps drafts off a customer's website.
+     */
+    status?: EntryStatus | "any";
+}
+interface Page<TItem> {
+    items: readonly TItem[];
+    /** Pass back as `ListQuery.cursor` to read the next page. Null when the page is the last. */
+    cursor: string | null;
+    hasMore: boolean;
+}
+interface MediaQuery {
+    limit?: number;
+    cursor?: string | null;
+    /** MIME prefix, for example `image/`. */
+    type?: string;
+}
+interface MediaInput {
+    name: string;
+    type: string;
+    size: number;
+    url: string;
+    path: string;
+    alt?: string | null;
+    width?: number | null;
+    height?: number | null;
+}
+/**
+ * What the media library occupies, summed from the metadata documents.
+ *
+ * `bytes` is the sum of the `size` recorded on each media document, not a reading of the
+ * Storage bucket itself. Everything Husk uploads records its size, so the two agree; an
+ * object placed in the bucket by something other than Husk is not counted, because Husk
+ * has no document for it. Stated rather than hidden: a dashboard figure that silently
+ * means something narrower than its label is worse than no figure.
+ */
+interface MediaUsage {
+    /** Media documents. */
+    count: number;
+    /** Total bytes across those documents. */
+    bytes: number;
+}
+/**
+ * One entry that references a media item.
+ *
+ * `title` is what the warning prints. It is null when the entry's content type declares no
+ * title field, or when the value is empty: the dialog then prints the id, which is the one
+ * name that is always correct.
+ */
+interface MediaUsageReference {
+    contentType: string;
+    entryId: string;
+    title: string | null;
+}
+interface MediaUsageQuery {
+    /** How many referencing entries to name. Defaults to MEDIA_USAGE_LIMIT. */
+    limit?: number;
+}
+/** What a reference refresh managed to rewrite, and what it did not. */
+interface MediaRefreshResult {
+    updated: number;
+    /** Entries whose denormalized url could not be rewritten. Named, never swallowed. */
+    failed: readonly MediaUsageReference[];
+}
+interface MediaAdapter {
+    list(query?: MediaQuery): Promise<Page<MediaItem>>;
+    getById(mediaId: string): Promise<MediaItem | null>;
+    getMany(mediaIds: readonly string[]): Promise<readonly MediaItem[]>;
+    /**
+     * Allocates a media id without writing anything.
+     *
+     * The upload path needs the id before the document exists, because the Storage object
+     * path contains it and the bytes are written first. Nothing is reserved on the server:
+     * the id is generated locally, and an id that is never used costs nothing.
+     */
+    reserveId(): string;
+    /**
+     * Writes the metadata document. With `mediaId`, it is written at that id, which is how
+     * an upload's bytes and its document end up naming each other.
+     */
+    create(input: MediaInput, mediaId?: string): Promise<MediaItem>;
+    update(mediaId: string, patch: Partial<MediaInput>): Promise<MediaItem>;
+    delete(mediaId: string): Promise<void>;
+    /**
+     * Entries referencing this media item, so a delete can warn instead of breaking pages.
+     *
+     * Answered from the `mediaRefs` reverse index each entry write maintains, not from a
+     * scan: see core/media-references.ts for what that costs and where it is blind.
+     */
+    usages(mediaId: string, query?: MediaUsageQuery): Promise<readonly MediaUsageReference[]>;
+    /**
+     * Rewrites the denormalized `url` on every entry that references this media item.
+     *
+     * Only replace needs it. Overwriting the bytes of an existing item mints a new download
+     * URL, and the copy of the old one denormalized into each entry would otherwise stay
+     * until that entry is next saved. `mediaId` remains the source of truth either way, so a
+     * refresh that fails degrades a stale convenience rather than breaking a reference.
+     */
+    refreshReferences(mediaId: string, url: string): Promise<MediaRefreshResult>;
+    /**
+     * Count and total size of the whole library, for the dashboard's storage figure.
+     * One aggregate read, not a walk over every page of media.
+     */
+    usage(): Promise<MediaUsage>;
+}
+/**
+ * Schema operations act on `schemas/`, never on entries. A locked or code-defined type is
+ * rejected here as well as in the UI, so bypassing the Schema Builder changes nothing.
+ */
+interface SchemaAdapter {
+    list(): Promise<readonly ContentTypeLike[]>;
+    get(slug: string): Promise<ContentTypeLike | null>;
+    create(type: ContentTypeLike): Promise<ContentTypeLike>;
+    update(slug: string, type: ContentTypeLike): Promise<ContentTypeLike>;
+    delete(slug: string): Promise<void>;
+    /**
+     * Live view of every database-defined type, so the sidebar and the routes follow a
+     * structure change without a rebuild and without a reload.
+     *
+     * One listener for the whole collection, feeding `RegistryStore.setDatabaseTypes`. What
+     * it costs is written down on that interface. `onError` is called rather than thrown,
+     * because a listener that dies silently leaves an admin quietly stale.
+     */
+    watch(listener: (types: readonly ContentTypeLike[]) => void, onError?: (error: Error) => void): () => void;
+}
+interface FieldPurgeOptions {
+    /** How many entries to clear in one call. Capped at MAX_FIELD_PURGE. */
+    limit?: number;
+}
+interface FieldPurgeResult {
+    /** Entries whose stored value was deleted by this call. */
+    purged: number;
+    /** True when the cap was hit and another call is needed to finish. */
+    remaining: boolean;
+}
+/**
+ * The stored values of a **removed** field, which is the only data the Schema Builder is
+ * ever allowed to reach.
+ *
+ * It is a separate interface, and not two more methods on `SchemaAdapter`, so the M8
+ * guardrail is structural rather than a comment: `SchemaAdapter` has no method that can
+ * touch an entry, and this one refuses any key the content type still declares. The Schema
+ * Builder writes schemas; purging is a different, separately named, separately confirmed
+ * operation that happens to be reachable from the same screen.
+ */
+interface FieldDataAdapter {
+    /**
+     * How many entries of this content type hold a non-null value for this top-level field
+     * key, so the removal warning can say "14 entries" rather than "some entries".
+     *
+     * One count aggregation, not a walk: `where(key, "!=", null)` plus `count()`. Firestore
+     * indexes every top-level field automatically, so no composite index is needed, and an
+     * aggregation is billed per thousand matched index entries rather than per document.
+     *
+     * Two limits, stated rather than hidden. A key nested inside a repeater row is not a
+     * top-level field and cannot be counted this way, so `count` rejects one instead of
+     * answering zero. And an entry written before the field existed simply has no such key,
+     * which Firestore treats as not matching, which is the answer the warning wants.
+     */
+    count(slug: string, key: string): Promise<number>;
+    /**
+     * Deletes the stored values of a removed field. The only destructive schema operation.
+     *
+     * Refused unless the content type lists the key under `removedFields`: a key that is
+     * still live, or that the type has never heard of, is never purged. Admin only, and
+     * bounded per call.
+     */
+    purge(slug: string, key: string, options?: FieldPurgeOptions): Promise<FieldPurgeResult>;
+}
+/**
+ * One stored entry as the migration runner sees it: its id, the version it is stamped at,
+ * and its values in their stored form.
+ *
+ * Deliberately not an `Entry`. Reading an entry runs it through the content type's field
+ * specs, and the whole point of a migration is that the stored document does not match
+ * those specs yet, so converting it first would either fail or quietly drop the values the
+ * migration was written to move.
+ */
+interface StoredEntryRecord {
+    id: string;
+    schemaVersion: number;
+    values: Record<string, unknown>;
+}
+interface MigrationWrite {
+    /** The stored version the transform read. The write is refused if it has moved. */
+    expectedVersion: number;
+    nextVersion: number;
+}
+/**
+ * The storage half of the migration runner. See core/migrations.ts for the runner itself.
+ *
+ * Kept off `SchemaAdapter` for the same reason `FieldDataAdapter` is: a schema operation
+ * must not be able to reach an entry. A migration reaches every entry of a type, which is
+ * precisely why it is a separately named, separately permissioned port rather than two
+ * more methods on the interface the Schema Builder holds.
+ */
+interface MigrationAdapter {
+    /** How many entries are stamped below the target version. One aggregation. */
+    countBehind(slug: string, targetVersion: number): Promise<number>;
+    /** A page of entries stamped below the target version, oldest version first. */
+    listBehind(slug: string, targetVersion: number, query?: {
+        limit?: number;
+    }): Promise<Page<StoredEntryRecord>>;
+    /**
+     * Writes migrated values and restamps the entry, but only while the stored version is
+     * still the one the transform read.
+     *
+     * Returns false when it has moved, which is a second runner having got there first and
+     * is not an error. That conditional is what makes a migration safe to run twice and safe
+     * to run from two places at once.
+     */
+    applyMigration(slug: string, entryId: string, values: Record<string, unknown>, write: MigrationWrite): Promise<boolean>;
+}
+interface SettingsAdapter {
+    get(key: string): Promise<Record<string, unknown> | null>;
+    set(key: string, value: Record<string, unknown>): Promise<void>;
+}
+interface EntryInputData {
+    /** Field values, already validated by the caller and validated again by the adapter. */
+    values: Record<string, unknown>;
+    status?: EntryStatus;
+}
+interface CmsAdapter {
+    list(slug: string, query?: ListQuery): Promise<Page<Entry>>;
+    get(slug: string, entryId: string): Promise<Entry | null>;
+    /**
+     * Looks an entry up by the value of the content type's `slug` field, not by document id.
+     *
+     * `status` narrows the lookup at the storage layer rather than after it, and on a public
+     * website that is not an optimization. A visitor's read is unauthenticated, and the
+     * security rules only let an unauthenticated query through when the query itself says
+     * `status == "published"`; a lookup that asked for any status and filtered afterwards
+     * would be refused outright. Defaults to `"any"`, which is the admin's uniqueness check.
+     */
+    getBySlug(slug: string, value: string, options?: Pick<ListQuery, "status">): Promise<Entry | null>;
+    /** Reads the one entry of a singleton. Rejects a collection. */
+    getSingle(slug: string): Promise<Entry | null>;
+    create(slug: string, input: EntryInputData): Promise<Entry>;
+    update(slug: string, entryId: string, input: EntryInputData): Promise<Entry>;
+    delete(slug: string, entryId: string): Promise<void>;
+    /**
+     * How many entries the same narrowing would return. Takes `search` as well, so the
+     * list view's "1-25 of 248" counts the rows the reader is actually paging through.
+     */
+    count(slug: string, query?: Pick<ListQuery, "filters" | "status" | "search">): Promise<number>;
+    readonly media: MediaAdapter;
+    readonly schemas: SchemaAdapter;
+    readonly fieldData: FieldDataAdapter;
+    readonly migrations: MigrationAdapter;
+    readonly settings: SettingsAdapter;
+}
+
+/**
+ * What a collection list is, derived from a content type.
+ *
+ * The screen renders this; it never decides it. Columns, the sortable set, the filter
+ * controls and the query that reads a page are all computed here from the schema, which is
+ * what makes a new content type a data change and not a screen change.
+ *
+ * Nothing in this file imports React, Firebase or the field registry, so it is domain
+ * logic: it runs in the node test project, in the SDK, and in a server component.
+ */
+/** How a column's cells are typeset. The cell itself never inspects the field type. */
+type ColumnAlign = "text" | "numeric" | "date";
+
+/**
+ * Bytes as a short human-readable string: `0 B`, `940 B`, `1.5 KB`, `12 MB`.
+ *
+ * One decimal below ten so a small library does not round to a flat `1 MB`, none above it
+ * where the extra digit is noise in a dashboard tile.
+ */
+declare function formatBytes(bytes: number): string;
+/**
+ * An ISO 8601 timestamp as a date and time.
+ *
+ * An unparsable value comes back unchanged instead of as `Invalid Date`: a timestamp the
+ * adapter could not convert is a data problem, and showing the raw value is what lets
+ * somebody diagnose it.
+ */
+declare function formatDateTime(iso: string): string;
+/**
+ * A date value as a reader sees it, at the precision it was stored with.
+ *
+ * A day-only value is formatted as a day: turning `2026-09-18` into a time would invent a
+ * midnight nobody chose, and would move the date across a timezone boundary.
+ */
+declare function formatDate(value: string): string;
+/**
+ * One field value as one table cell, decided by the value it got rather than by the field
+ * type that produced it.
+ *
+ * This is why the list view has no `switch (field.type)`: the column already knows how it
+ * is typeset (core/list-view.ts decides that once, from the schema), and the cell only has
+ * to turn whatever the adapter returned into a line of text. A value the column cannot
+ * render, and a value that was never set, both come back as `null`, which the cell renders
+ * as its "not set" state rather than as a blank nobody can interpret.
+ */
+declare function formatCellValue(value: unknown, align: ColumnAlign): string | null;
+
+interface CollectionListProps {
+    adapter: CmsAdapter;
+    type: ContentTypeLike;
+    /** The signed-in user, for the permission answers behind the actions. */
+    user: AuthUser;
+    /** Opens an entry. Absent means the list is read-only in this host. */
+    onOpen?: (entryId: string) => void;
+    /** Starts a new entry. Shown only when `can()` allows creating one. */
+    onCreate?: () => void;
+    /**
+     * Deletes entries. The list never deletes anything itself: it collects the selection,
+     * checks the permission per entry, and hands the ids to the host's confirmation flow.
+     */
+    onDelete?: (entryIds: readonly string[]) => void;
+    /**
+     * Re-reads the current page when it changes.
+     *
+     * A delete happens outside this screen (the confirmation dialog is the host's to mount,
+     * because only the host knows where the flow lands), so the list needs a way to be told
+     * that what it is showing is stale. A changed token re-runs the same query with the same
+     * cursor, which is the honest refresh: remounting would silently drop the reader's
+     * search, filters and page.
+     */
+    refreshToken?: unknown;
+    pageSize?: number;
+}
+declare function CollectionList({ adapter, type, user, onOpen, onCreate, onDelete, refreshToken, pageSize, }: CollectionListProps): react.JSX.Element;
+
+/**
+ * The destructive confirmation for deleting entries.
+ * Canonical source: .docs/styleguide/04-components.md section 12, "Destructive
+ * confirmation".
+ *
+ * One dialog for every content type and for both the row action and the bulk selection,
+ * because the only thing that differs between them is what is printed and how many
+ * documents the adapter is asked to remove.
+ *
+ * What it is deliberate about:
+ *
+ *  - **The phrase.** One entry asks for its name (its title, or its id when it has no
+ *    usable title); several ask for the count and the content type. `core/delete-
+ *    confirmation.ts` decides both and decides what counts as typing them.
+ *  - **The way out.** `dismissible` is false, so a stray backdrop click cannot start a
+ *    delete flow's only irreversible step. Escape still closes, because cancelling a
+ *    delete is the safe outcome and a user must always have a way out.
+ *  - **Partial failure.** Several deletes are several writes, and the second can fail
+ *    after the first succeeded. What did go through is reported to the caller anyway, so
+ *    the list does not keep showing rows that are gone, and the dialog stays open naming
+ *    what did not.
+ */
+interface DeleteEntriesDialogProps {
+    adapter: CmsAdapter;
+    type: ContentTypeLike;
+    /** The entries to delete. Empty means the dialog is closed. */
+    entryIds: readonly string[];
+    onCancel: () => void;
+    /**
+     * The ids the adapter actually removed, and whether that was the whole batch.
+     *
+     * A batch is several writes and the second can fail after the first succeeded, so what
+     * did go through is reported either way: the caller drops those rows, and leaves the
+     * dialog open when `complete` is false, because it is still naming what did not.
+     */
+    onDeleted: (entryIds: readonly string[], complete: boolean) => void;
+    /** The signed-in role, so a refused delete can name who was refused. */
+    role?: Role | undefined;
+}
+declare function DeleteEntriesDialog({ adapter, type, entryIds, onCancel, onDeleted, role, }: DeleteEntriesDialogProps): react.JSX.Element | null;
+/**
+ * Whether this content type may be deleted at all.
+ *
+ * A singleton exists exactly once and its absence is not a state the schema describes, so
+ * it has no delete flow. The domain guard `assertDeletable` refuses the write as well;
+ * this only keeps the admin from offering a button the adapter would reject.
+ */
+declare function isDeletableType(type: ContentTypeLike): boolean;
+
+/** Props every admin field input receives. Field types never read from a store directly. */
+interface FieldInputProps<TValue, TField extends FieldDefinition = FieldDefinition> {
+    /** Dotted path, unique within the form: `title`, `blocks.2.heading`. */
+    path: string;
+    field: TField;
+    value: TValue | null;
+    onChange: (value: TValue | null) => void;
+    onBlur?: (() => void) | undefined;
+    errors: readonly FieldError[];
+    disabled?: boolean | undefined;
+    readonly?: boolean | undefined;
+}
+type FieldInputComponent<TValue, TField extends FieldDefinition = FieldDefinition> = ComponentType<FieldInputProps<TValue, TField>>;
+/** Everything a validator may know without touching the database. */
+interface ValidateCtx {
+    path: string;
+    contentType: AnyContentTypeShape;
+    /** All values of the entry being validated, for cross-field rules. */
+    entry: Record<string, unknown>;
+}
+/**
+ * Recursion, for the two field types that contain other fields.
+ *
+ * `repeater` holds a whole field map, and it cannot convert or name what is inside it
+ * without applying the same field type contract one level down. It must not reach for the
+ * registry itself: the registry imports every spec, so a spec that imports the registry
+ * closes a cycle. The caller that already holds the registry passes the recursion in
+ * instead, and both members below are optional, so a spec that nests nothing ignores them
+ * and a caller that has no registry still gets a working round trip.
+ */
+interface NestedConverter {
+    toStored(fields: FieldMap, values: Record<string, unknown>): Record<string, unknown>;
+    fromStored(fields: FieldMap, data: Record<string, unknown>): Record<string, unknown>;
+}
+/** Names the SDK-facing type of any field definition, one level down. */
+type TsTypeResolver = (field: FieldDefinition) => string;
+/**
+ * Layer 5, as a value or as a function of the field.
+ *
+ * A plain string is the common case and stays exactly as it was. A function is what lets a
+ * field type whose SDK type depends on its own options say so: `select` narrows on
+ * `multiple`, `relation` on `many`, and `repeater` names the object its rows actually
+ * hold. `FieldValue<TField>` in types/field.ts already narrows all three for a code-defined
+ * type; this is what codegen can say for a type created in the Schema Builder, where the
+ * field definition exists only at runtime.
+ */
+type FieldTsType<TField extends FieldDefinition = FieldDefinition> = string | ((field: TField, resolve: TsTypeResolver) => string);
+/**
+ * How one per-type option is edited in the Schema Builder.
+ *
+ * A control, not a field type: `"choice"` is a fixed list of values, `"content-type"` is a
+ * slug picked from the live registry, `"field-key"` is a sibling field of the same level.
+ * The field editor implements this small vocabulary once, and every field type describes
+ * its own options in it, which is what keeps `switch (field.type)` out of the screen.
+ */
+type FieldOptionControl = "text" | "number" | "boolean" | "choice" | "select-options" | "content-type" | "field-key" | "string-list" | "fields";
+interface FieldOptionDescriptor {
+    /** The property this option writes on the field definition. */
+    key: string;
+    label: string;
+    control: FieldOptionControl;
+    help?: string;
+    /** A field of this type is incomplete until the option has a value. */
+    required?: boolean;
+    /** The values a `"choice"` control offers. */
+    choices?: readonly {
+        value: string;
+        label: string;
+    }[];
+}
+/**
+ * Layer 7: what the Schema Builder may configure on this field type, and what it starts as.
+ *
+ * It exists so that the field editor is generated from the registry exactly as every other
+ * admin screen is. Without it, one screen would hold a list of which options belong to
+ * which field type, and a field type added later would render as a bare label until
+ * somebody remembered to edit that list.
+ */
+interface FieldEditorSpec {
+    /** Name shown in the field type picker. */
+    label: string;
+    /** One line, shown under the name in the picker. */
+    description: string;
+    /** The shared validation rules this field type honours. See VALIDATION_RULE_CONTROLS. */
+    rules: readonly (keyof ValidationRules)[];
+    /** The per-type options, in the order the editor shows them. */
+    options: readonly FieldOptionDescriptor[];
+    /**
+     * Everything a new field of this type needs besides `type` and `label`.
+     *
+     * A select with no options and a repeater with no nested fields are both invalid, so a
+     * newly added field cannot start as `{ type, label }` alone.
+     */
+    defaults: Record<string, unknown>;
+}
+/**
+ * The seven-layer contract. A field type is not "added" until every member here is
+ * implemented; a partial field type is a field type that behaves differently in the form
+ * than it does on the server.
+ *
+ *   1. `name`         schema definition: the discriminator a content type writes
+ *   2. `toStored` /
+ *      `fromStored`   stored shape: the round trip through Firestore
+ *   3. `Input`        admin input component
+ *   4. `validate`     validation, run identically by the form and by the adapter
+ *   5. `tsType`       SDK-facing type, used by codegen and by the Developer area
+ *   6. `defaultValue` registration data: what a new entry starts with
+ *   7. `editor`       Schema Builder data: the options, rules and defaults of the type
+ */
+interface FieldTypeSpec<TValue, TField extends FieldDefinition = FieldDefinition> {
+    name: FieldType;
+    toStored(value: TValue | null, field: TField, nested?: NestedConverter): unknown;
+    fromStored(raw: unknown, field: TField, nested?: NestedConverter): TValue | null;
+    Input: FieldInputComponent<TValue, TField>;
+    validate(value: TValue | null, rules: ValidationRules, ctx: ValidateCtx, field: TField): FieldError[];
+    tsType: FieldTsType<TField>;
+    defaultValue(field: TField): TValue | null;
+    editor: FieldEditorSpec;
+}
+/**
+ * A spec whose value and field types have been erased, for storage in the registry.
+ *
+ * The registry is heterogeneous by construction: one spec per field type, each with a
+ * different value type. The erasure stops at this alias; every consumer goes back through
+ * the typed `FieldTypeSpec` for the field it is actually handling.
+ */
+type AnyFieldTypeSpec = FieldTypeSpec<any, any>;
+interface FieldTypeRegistry {
+    get(name: string): AnyFieldTypeSpec | undefined;
+    require(name: string): AnyFieldTypeSpec;
+    has(name: string): boolean;
+    readonly names: readonly FieldType[];
+}
+
+/**
+ * What the status control may offer, and to whom.
+ *
+ * Status is the one piece of entry metadata an editor writes, so it is not a display: it
+ * is a set of transitions out of the status the entry is in, each one answered by `can()`
+ * against the entry itself. A denied transition keeps its reason rather than disappearing,
+ * because "you cannot publish this" is information and an empty panel is not.
+ *
+ * Hiding or disabling a transition here is presentation. The adapter validates the write
+ * and the security rules check the same matrix again, so a user who reaches past this list
+ * gains nothing.
+ */
+interface StatusTransition {
+    to: EntryStatus;
+    /** Imperative label for the control: "Publish", "Unpublish", "Archive". */
+    label: string;
+    /** What it does to the public site, in one sentence. */
+    effect: string;
+    allowed: boolean;
+    /** Why it is not offered. Null when it is. */
+    reason: string | null;
+}
+
+/**
+ * The entry editor metadata sidebar.
+ * Canonical source: .docs/styleguide/03-layout.md section 5.2.1.
+ *
+ * Everything on it is owned by the adapter rather than by the form: status, the three
+ * timestamps, and the uid that created the entry. The one control is the status
+ * transition, and it is a control rather than a display because status is the single piece
+ * of entry metadata an editor writes.
+ */
+/** What the admin can say about a uid. Enough to name someone, and nothing more. */
+interface AuthorInfo {
+    uid: string;
+    displayName?: string | null;
+    email?: string | null;
+}
+/**
+ * Resolves a uid to a person.
+ *
+ * An entry stores who created it as a uid, and a uid is not a name. Turning one into a
+ * name is a read against the user documents, which the `CmsAdapter` does not expose and
+ * the Users area (M9) owns. So it is a seam: a host that can answer supplies this, and a
+ * host that cannot simply does not.
+ */
+type AuthorLookup = (uid: string) => Promise<AuthorInfo | null>;
+interface EntryMetadataProps {
+    user: AuthUser;
+    /** Null while the entry has not been created yet. */
+    entry: Entry | null;
+    /** The stored status. The badge reports what is saved, never what is intended. */
+    status: EntryStatus;
+    /**
+     * The status the next save will write, when that is not the stored one. Set only after a
+     * transition was refused by validation, so the editor can see why the badge has not
+     * moved.
+     */
+    pending?: EntryStatus | null;
+    transitions: readonly StatusTransition[];
+    onTransition: (to: EntryStatus) => void;
+    /** A write is in flight, so no transition may start a second one. */
+    busy?: boolean;
+    resolveAuthor?: AuthorLookup | undefined;
+    /**
+     * The destructive actions, below the rule. A seam: the delete flow supplies the button,
+     * and a host without one renders no section rather than a button that does nothing.
+     */
+    actions?: ReactNode;
+}
+declare function EntryMetadata({ user, entry, status, pending, transitions, onTransition, busy, resolveAuthor, actions, }: EntryMetadataProps): react.JSX.Element;
+
+/**
+ * The entry editor, generated from the content type.
+ * Canonical source: .docs/styleguide/03-layout.md section 5.2.
+ *
+ * One screen shape serves creating and editing, because they differ in exactly two things:
+ * whether there is an entry behind the form, and which adapter method the save calls.
+ * Everything else (which fields exist, what they start at, what is valid, what the status
+ * control offers) is read from the schema and from `can()`.
+ *
+ * There is no `switch (field.type)` here and there never may be. A field is rendered by
+ * looking its spec up in the registry and mounting `spec.Input`, so a field type added in
+ * `src/fields/index.ts` works in this form the day it is registered.
+ *
+ * Three things it is deliberate about:
+ *
+ *  - **Where an error lands.** The shared validator and the adapter both report a
+ *    `FieldError` with a dotted path, and every input is mounted at its path, so an error
+ *    is routed to the control that owns it, including one inside a repeater row. Only an
+ *    error naming a field this form does not render reaches the form-level message, and
+ *    only a failure that is not about a field at all reaches a toast.
+ *  - **Which error is newer.** A client error is recomputed on every keystroke; a server
+ *    error is a verdict about what was submitted and no keystroke can retract it. See
+ *    `mergeIssues` in core/entry-form.ts.
+ *  - **Draft versus published.** A draft skips `required` and nothing else, and that is the
+ *    same option the adapter passes to the same validator on the write path.
+ *
+ * A singleton is the same screen with two answers changed, not a second screen. It reads
+ * through `getSingle` instead of `get`, and a singleton that was never saved is a form with
+ * no entry behind it rather than a missing-entry state: the document simply does not exist
+ * yet, and the first save is the `create` that brings it into being at the id
+ * `singletonEntryId` derives from the slug. It offers no delete, because `assertDeletable`
+ * refuses one, and no list to go back to, because `assertListable` refuses that too.
+ *
+ * One thing is optimistic and it is named here so the rest is known not to be: a status
+ * transition paints the new badge before the adapter answers, and a failure puts the exact
+ * stored status back. See `optimistic` in EntryForm.
+ */
+interface EntryEditorProps {
+    adapter: CmsAdapter;
+    type: ContentTypeLike;
+    user: AuthUser;
+    /** Absent for a create screen. Present for an edit screen. */
+    entryId?: string | undefined;
+    /** Called after a successful write, so the host can route from create to edit. */
+    onSaved?: ((entry: Entry, created: boolean) => void) | undefined;
+    onCancel?: (() => void) | undefined;
+    /** The seam the unsaved-changes guard attaches to. */
+    onDirtyChange?: ((dirty: boolean) => void) | undefined;
+    /** The seam the delete flow attaches to. No callback means no destructive action. */
+    onDelete?: ((entryId: string) => void) | undefined;
+    resolveAuthor?: AuthorLookup | undefined;
+    /** Resolves a relation target slug, for the relation picker. */
+    getType?: ((slug: string) => ContentTypeLike | undefined) | undefined;
+    /** The field type registry. Defaults to the one every field type registers into. */
+    registry?: FieldTypeRegistry | undefined;
+}
+declare function EntryEditor({ adapter, type, user, entryId, onSaved, onCancel, onDirtyChange, onDelete, resolveAuthor, getType, registry, }: EntryEditorProps): react.JSX.Element;
+
+interface DashboardProps {
+    adapter: CmsAdapter;
+    /**
+     * The content types this user may read. The caller filters with `can()`; a tile counting
+     * something the adapter will refuse is a broken promise, not a preview.
+     */
+    types: readonly ContentTypeLike[];
+    /** How many recent entries to list. */
+    recentLimit?: number;
+}
+declare function Dashboard({ adapter, types, recentLimit }: DashboardProps): react.JSX.Element;
+
+/**
+ * What the dashboard reads, and how.
+ *
+ * Separated from the component on purpose: this is the only part of the dashboard with a
+ * data path, it goes through `CmsAdapter` and nothing else, and it is testable against a
+ * stub adapter without rendering anything.
+ *
+ * Nothing here knows the name of a content type. The tiles and the recent list
+ * are derived from the types it is handed, so a new content type changes the dashboard by
+ * appearing in the registry and in no other way.
+ */
+interface DashboardCount {
+    slug: string;
+    label: string;
+    kind: ContentTypeKind;
+    icon: IconName;
+    count: number;
+}
+interface DashboardRecentEntry {
+    /** Unique across content types, which an entry id alone is not. */
+    key: string;
+    entryId: string;
+    title: string;
+    typeSlug: string;
+    typeLabel: string;
+    status: EntryStatus;
+    updatedAt: string;
+}
+interface DashboardData {
+    counts: readonly DashboardCount[];
+    recent: readonly DashboardRecentEntry[];
+    /**
+     * Null when the adapter could not answer. The tile then says the figure is unavailable
+     * rather than showing a zero that reads like an empty library.
+     */
+    media: MediaUsage | null;
+}
+interface LoadDashboardOptions {
+    /** How many recent entries the list shows. */
+    recentLimit?: number;
+}
+declare const DEFAULT_RECENT_LIMIT = 8;
+/**
+ * Reads everything the dashboard shows.
+ *
+ * Counts are one aggregate read per content type, including singletons: a singleton counts
+ * 0 or 1, which is exactly the "is it filled in yet" answer its tile is asking.
+ *
+ * Recent entries are one small page per collection, merged and re-sorted here. The adapter
+ * has no cross-content-type query and should not grow one for a dashboard: entries live in
+ * a subcollection per type, so a single query over all of them would need a collection
+ * group index and a shape the security rules cannot gate per type. Singletons are excluded
+ * because they cannot be listed at all.
+ *
+ * A failure in any count or list rejects, and the screen shows its error state. A
+ * dashboard that silently drops the one content type the reader came to check is worse
+ * than one that says it could not load.
+ */
+declare function loadDashboard(adapter: CmsAdapter, types: readonly ContentTypeLike[], { recentLimit }?: LoadDashboardOptions): Promise<DashboardData>;
+
+/**
+ * How the media library starts an upload, without knowing that Storage exists.
+ *
+ * The same seam as `RelationSource` for the relation picker, and for the same reason: the
+ * screen lives under `src/admin/**`, where the Firebase SDK may not be imported, and it
+ * still has to offer progress, cancel and retry. The host builds one with
+ * `createMediaUploader` from `@nonext/husk/firebase` and hands it in.
+ *
+ * Every member below mirrors what `createMediaUpload` already returns, so the real
+ * implementation is a pass-through and a test implementation is a few lines.
+ */
+type MediaUploadPhase = "idle" | "uploading" | "storing" | "done" | "cancelled" | "failed";
+interface MediaUploadProgress {
+    phase: MediaUploadPhase;
+    bytesTransferred: number;
+    totalBytes: number;
+    /** 0 to 1. Exactly 1 only once every byte is acknowledged. */
+    fraction: number;
+    /** 1 for the first run, 2 for the first retry, and so on. */
+    attempt: number;
+}
+interface MediaUploadHandle {
+    readonly mediaId: string;
+    readonly path: string;
+    readonly fileName: string;
+    progress(): MediaUploadProgress;
+    start(): Promise<MediaItem>;
+    /** Runs it again to the same id and the same path, so remains are overwritten. */
+    retry(): Promise<MediaItem>;
+    cancel(): void;
+}
+interface MediaUploadRequest {
+    onProgress?: (progress: MediaUploadProgress) => void;
+    alt?: string | null;
+}
+interface MediaUploader {
+    create(file: File, options?: MediaUploadRequest): MediaUploadHandle;
+    /**
+     * New bytes for an item that already exists, keeping its id and its object path.
+     *
+     * The MIME type may not change: the path is fixed for the life of the item and the rules
+     * tie the path's extension to the declared type. The implementation refuses a mismatch
+     * with a sentence rather than letting it surface as a permission error.
+     */
+    replace(existing: MediaItem, file: File, options?: MediaUploadRequest): MediaUploadHandle;
+}
+
+/**
+ * The media library, and the body of the media picker.
+ * Canonical source: .docs/styleguide/03-layout.md section 5.3.
+ *
+ * One screen serves both because they differ in exactly two things: whether choosing an
+ * item does anything, and whether a field's `accept` narrows what is offered. Everything
+ * else (the grid, the upload rows, the detail panel, the delete flow) is the same code, so
+ * the picker cannot fall behind the library or offer something the library would not.
+ *
+ * `accept` is honoured here and not only passed along. Every page the picker renders is
+ * filtered through `pickableItems`, so a file of the wrong type is never on screen to be
+ * clicked. The field re-checks the item that comes back, and that check is a backstop for
+ * a picker somebody else supplied, not the thing that catches this one.
+ *
+ * Orphans are surfaced, never swept. "Unused only" runs a usage lookup for each item the
+ * grid has loaded and marks the ones nothing references. Nothing is deleted as a
+ * consequence, and nothing is deleted on a schedule: a file that no entry uses today may
+ * be what tomorrow's entry needs, and that is not a judgement a CMS gets to make.
+ */
+interface MediaLibraryProps {
+    adapter: CmsAdapter;
+    user: AuthUser;
+    /** Absent means the library is read-only: no upload, no replace. */
+    uploader?: MediaUploader | undefined;
+    /** Picker mode: the MIME patterns this slot accepts. */
+    accept?: readonly string[] | undefined;
+    /** Picker mode: choosing a tile calls this instead of opening the detail panel. */
+    onPick?: ((item: MediaItem) => void) | undefined;
+    /** Names a content type in a usage list. Defaults to the raw slug. */
+    contentTypeLabel?: ((slug: string) => string) | undefined;
+}
+declare function MediaLibrary({ adapter, user, uploader, accept, onPick, contentTypeLabel, }: MediaLibraryProps): react.JSX.Element;
+
+/**
+ * The real media picker, over the adapter and the library UI.
+ *
+ * The `image` and `file` field types have been written against `MediaPickerApi` since M5,
+ * with an absent provider as a deliberate, rendered state. This is the implementation that
+ * makes the seam real:
+ *
+ *  - `resolve` is `adapter.media.getMany`. Ids with no document are simply absent from the
+ *    result, which is exactly how the control learns a reference is broken.
+ *  - `pick` opens the library in a modal and resolves when a tile is chosen, or with null
+ *    when the editor closes it. The promise is settled exactly once in either direction,
+ *    so a field that awaited it never hangs: the deferred is cleared the moment it is
+ *    settled, and closing the modal settles it.
+ *
+ * `accept` is honoured by the library itself, which filters every page it renders through
+ * `pickableItems`. The field re-checks the item that comes back, and that check exists for
+ * a picker somebody else supplied; against this one it can never be the thing that catches
+ * a wrong type, because a wrong type was never on screen.
+ */
+interface AdminMediaPickerProviderProps {
+    adapter: CmsAdapter;
+    user: AuthUser;
+    /** Absent means the picker can choose but not upload. */
+    uploader?: MediaUploader | undefined;
+    contentTypeLabel?: ((slug: string) => string) | undefined;
+    children: ReactNode;
+}
+declare function AdminMediaPickerProvider({ adapter, user, uploader, contentTypeLabel, children, }: AdminMediaPickerProviderProps): react.JSX.Element;
+
+/**
+ * The destructive confirmation for deleting a media item.
+ * Canonical source: .docs/styleguide/04-components.md section 12, "Destructive
+ * confirmation".
+ *
+ * It differs from the entry version in the one way that matters: a media item can be
+ * referenced from somewhere else, and deleting it breaks whatever referenced it. The
+ * dialog therefore reads the reverse index before it offers the button, and names every
+ * entry it finds. A file with references is not refused, because sometimes removing it is
+ * exactly the intention; it is made impossible to do by accident.
+ *
+ * Two things it says out loud rather than implies:
+ *
+ *  - Where the list comes from. The count is the `mediaRefs` index each entry write
+ *    maintains, so an entry that has not been saved since the index existed will not be in
+ *    it. Claiming an unqualified "nothing uses this" would be a stronger statement than
+ *    the data supports.
+ *  - What deleting does not do. It removes the library record. The bytes in Storage are a
+ *    separate object with its own rules, and the caller is told whether that part also
+ *    went through.
+ *
+ * The typed confirmation is the file name, the same mechanic the entry dialog uses.
+ */
+interface MediaDeleteDialogProps {
+    adapter: CmsAdapter;
+    /** The item to delete. Null means the dialog is closed. */
+    item: MediaItem | null;
+    onCancel: () => void;
+    onDeleted: (mediaId: string) => void;
+    contentTypeLabel?: ((slug: string) => string) | undefined;
+}
+declare function MediaDeleteDialog({ adapter, item, onCancel, onDeleted, contentTypeLabel, }: MediaDeleteDialogProps): react.JSX.Element | null;
+
+/**
+ * One media item, opened from the grid.
+ * Canonical source: .docs/styleguide/03-layout.md section 5.3.
+ *
+ * A modal rather than a third column, because the grid is already the widest thing on the
+ * page and a column would squeeze the tiles below their minimum measure.
+ *
+ * What it is deliberate about:
+ *
+ *  - **Alt text is the only editable field.** Everything else about a media item is a fact
+ *    about the file: changing the name, the type or the size here would describe bytes
+ *    that did not change. Replacing the bytes is a separate, named action.
+ *  - **Usage is read once, when the panel opens, and shown whether or not it is zero.**
+ *    An orphan is surfaced, never swept: a file nothing references today may be exactly
+ *    what tomorrow's entry needs, and the CMS does not get to decide that for an editor.
+ *  - **Copy reports what happened.** `navigator.clipboard` is absent outside a secure
+ *    context and rejects on a refused permission, so the button says "Copied" only when
+ *    the clipboard confirmed it, and points at the URL field otherwise.
+ */
+interface MediaDetailProps {
+    adapter: CmsAdapter;
+    user: AuthUser;
+    item: MediaItem;
+    onClose: () => void;
+    /** Called with the updated item after alt text is saved. */
+    onUpdated: (item: MediaItem) => void;
+    /** Opens the destructive confirmation. Absent when this account may not delete. */
+    onDelete?: ((item: MediaItem) => void) | undefined;
+    /** Starts a replace. Absent when no uploader was supplied. */
+    onReplace?: ((item: MediaItem) => void) | undefined;
+    /** Names a content type in the usage list. Defaults to the raw slug. */
+    contentTypeLabel?: ((slug: string) => string) | undefined;
+}
+declare function MediaDetail({ adapter, user, item, onClose, onUpdated, onDelete, onReplace, contentTypeLabel, }: MediaDetailProps): react.JSX.Element;
+
+/**
+ * One item in the media grid.
+ * Canonical source: .docs/styleguide/03-layout.md section 5.3.
+ *
+ * The whole tile is one button, not a card with a button in it: the only thing a tile does
+ * is open the item, and a click target that is smaller than the thing it represents is a
+ * click target people miss.
+ *
+ * The preview is the original file. Husk stores originals only and resizes at render time
+ * through `next/image` on a customer's site (see .docs/decisions/2026-09-18-media-variants.md),
+ * so there is no thumbnail to point at here. `loading="lazy"` is what keeps a grid of
+ * originals from being a page of full-size downloads.
+ */
+interface MediaTileProps {
+    item: MediaItem;
+    selected?: boolean;
+    /** True when a usage check ran and found no entry referencing this item. */
+    unused?: boolean;
+    onOpen: (item: MediaItem) => void;
+}
+declare function MediaTile({ item, selected, unused, onOpen, }: MediaTileProps): react.JSX.Element;
+
+/**
+ * The entries that reference a media item, by name.
+ *
+ * Shared by the detail panel and the delete confirmation, because a warning that lists
+ * three entries and a panel that lists four would be two different claims about the same
+ * question.
+ *
+ * An entry with no usable title prints its id. A content type the registry no longer knows
+ * prints its slug. Neither case is hidden: a reference the admin cannot name is still a
+ * reference, and "one of these is somewhere" is more useful than a shorter list.
+ */
+interface UsageListProps {
+    usages: readonly MediaUsageReference[];
+    contentTypeLabel?: ((slug: string) => string) | undefined;
+}
+declare function UsageList({ usages, contentTypeLabel }: UsageListProps): react.JSX.Element | null;
+
+/**
+ * Copying a string to the clipboard, and admitting when it did not happen.
+ *
+ * `navigator.clipboard` is not always there. It is undefined outside a secure context,
+ * which includes a customer previewing their admin over plain http on a LAN address, and
+ * `writeText` rejects when the document is not focused or when the browser's permission
+ * prompt is refused. A "Copied" toast in any of those cases is a lie the reader only
+ * discovers after pasting nothing, so the result is reported instead of assumed.
+ *
+ * The fallback is the old `document.execCommand("copy")` path over an off-screen textarea.
+ * It is deprecated and it is still the only thing that works without the async API, so it
+ * is tried second rather than not at all. When both fail the caller is told, and the
+ * library shows the URL in a field the reader can select by hand.
+ */
+type ClipboardOutcome = "copied" | "unavailable";
+declare function copyText(text: string): Promise<ClipboardOutcome>;
+
+/**
+ * The decisions the media library makes that are not rendering.
+ *
+ * They live outside the components so each one can be tested without a DOM, and so the
+ * picker and the standalone library cannot answer the same question two different ways.
+ */
+/**
+ * The `accept` attribute for the library's file input, narrowed by what a field asks for.
+ *
+ * Two constraints meet here and both are real: `core/media-constraints.ts` says what the
+ * product accepts at all, and a field's `accept` says what this particular slot accepts.
+ * The intersection is what the browser's file chooser should offer. An intersection that
+ * comes out empty falls back to the full product allowlist rather than to `accept=""`,
+ * which browsers read as "anything": a chooser that offers everything and a refusal
+ * afterwards is friendlier than a chooser that offers nothing and explains nothing.
+ */
+declare function uploadAccept(accept: readonly string[] | undefined): string;
+/**
+ * The MIME prefix the adapter can narrow its query by, or undefined when it cannot.
+ *
+ * `MediaQuery.type` is a prefix range, which is the only "starts with" Firestore offers, so
+ * it can serve `image/*` and nothing else. A field accepting exactly `image/jpeg`, or a mix
+ * of families, gets no server-side narrowing and is filtered per page instead.
+ *
+ * This is an optimization and never the enforcement. `pickableItems` filters every page it
+ * renders, whatever the query did, which is why a field's own re-check on the way back is
+ * never the thing that catches a wrong type.
+ */
+declare function queryTypeFilter(accept: readonly string[] | undefined): string | undefined;
+/**
+ * The items a picker may offer, out of a page it just read.
+ *
+ * The filter is applied to what is rendered rather than to what is chosen, so a field's
+ * `accept` is honoured by the picker rather than merely passed to it. A page that filters
+ * down to nothing is a short page, not an error: the cursor still points past it and the
+ * next page is read on demand.
+ */
+declare function pickableItems(items: readonly MediaItem[], accept: readonly string[] | undefined): readonly MediaItem[];
+/** Whether the tile shows an image preview or its concept icon. */
+declare function isImageItem(item: MediaItem): boolean;
+/**
+ * Whether this account may delete library items.
+ *
+ * Mirrors `allow delete: if isEditor()` in firestore.rules. Hiding the button is
+ * presentation only; the rules refuse the write regardless of what the UI renders.
+ */
+declare function canDeleteMedia(user: AuthUser): boolean;
+/**
+ * Whether this account may put new bytes over an existing item.
+ *
+ * Mirrors `mayWrite` in storage.rules: an editor may overwrite any object, an author only
+ * one whose custom metadata names them, which for a Husk upload is the account that
+ * created the media document.
+ */
+declare function canReplaceMedia(user: AuthUser, item: MediaItem): boolean;
+/** `1600 x 900`, or null for an item whose dimensions were never recorded. */
+declare function formatDimensions(item: MediaItem): string | null;
+/**
+ * What the usage list says, in one sentence.
+ *
+ * The count is deliberately phrased as "at least" once the list hit its limit, because the
+ * lookup stopped counting there and claiming an exact number it did not count would be the
+ * one thing a delete warning must not do.
+ */
+declare function describeUsage(usages: readonly MediaUsageReference[], limit?: number): string;
+/**
+ * The type filter the library toolbar offers.
+ *
+ * Each value is a MIME prefix, which is what `MediaQuery.type` narrows by: a range scan is
+ * the only "starts with" Firestore has. The categories are the ones `ALLOWED_MEDIA_TYPES`
+ * actually contains, so no option can come back empty for a structural reason.
+ */
+declare const MEDIA_FILTERS: readonly {
+    value: string;
+    label: string;
+}[];
+
+/**
+ * A registry that can change while the admin is running.
+ *
+ * Creating a content type in the Schema Builder has to put it in the sidebar, give it
+ * routes and give it working CRUD without a rebuild and without a reload. The code half of
+ * the registry is fixed for the lifetime of the process; only the database half moves, so
+ * this holds the code half and swaps the database half.
+ *
+ * **How the change arrives, and what it costs.** `SchemaAdapter.watch` opens one Firestore
+ * listener on the whole `schemas` collection and hands every snapshot to `setDatabaseTypes`.
+ * One listener per open admin tab. It bills the documents of the initial snapshot once, then
+ * one document read per changed schema document, and nothing at all while nobody is editing
+ * structure. `schemas` holds one small document per database-defined content type, so a
+ * customer with twenty of them pays twenty reads when an admin tab opens.
+ *
+ * The alternative considered was refetching the collection on every navigation inside the
+ * admin. It needs no listener, but it bills the whole collection again on every screen
+ * change, which for one editor clicking through twenty screens in an hour is already an
+ * order of magnitude more reads than the listener, and it is still stale in the tab where
+ * nobody navigated. The listener is both cheaper in the steady state and the only one of
+ * the two that actually refreshes without an interaction. See
+ * .docs/decisions/2026-09-18-schema-field-removal.md.
+ *
+ * A snapshot that produces an identical registry is dropped rather than published, because
+ * Firestore replays a local write as a second snapshot once the server acknowledges it and
+ * a re-render of every admin screen for a change nobody made is a visible cost.
+ */
+interface RegistryStore {
+    /** The current registry. Replaced, never mutated, so a React snapshot stays stable. */
+    readonly registry: Registry;
+    /**
+     * Swaps the database half. Returns true when the registry actually changed, which is what
+     * the caller subscribes for.
+     */
+    setDatabaseTypes(types: readonly ContentTypeLike[]): boolean;
+    /** Notified after every real change. Returns the unsubscribe. */
+    subscribe(listener: (registry: Registry) => void): () => void;
+    /**
+     * Changes counter, monotonic. `useSyncExternalStore` compares it instead of deep
+     * comparing the registry, and a server render can send it to the client to detect that
+     * the two disagree.
+     */
+    readonly revision: number;
+}
+
+/**
+ * The React half of the live registry. The store itself is in core and knows no React.
+ *
+ * This is what makes the M8 promise concrete: a content type created in the Schema Builder
+ * reaches the sidebar, the routes and every screen of every open tab without a rebuild and
+ * without a reload, because the registry the admin renders from is a subscription rather
+ * than a value computed once on the server.
+ *
+ * Firebase does not appear here. `watch` arrives as an argument, exactly as the media
+ * uploader and the relation source do, so nothing under `src/admin/**` imports the SDK.
+ */
+/** The shape of `SchemaAdapter.watch`, without naming the adapter. */
+type SchemaWatch = (listener: (types: readonly ContentTypeLike[]) => void, onError?: (error: Error) => void) => () => void;
+interface LiveRegistry {
+    registry: Registry;
+    /**
+     * Whether the database half has been read at least once.
+     *
+     * It matters for exactly one question, and it is the question a generated admin has to
+     * get right: a slug that is in no content type yet may be an unknown route or may be a
+     * database-defined type whose first snapshot has not landed. Answering 404 before the
+     * listener has spoken would show a not-found screen for a content type that exists.
+     * True immediately when no listener is running, because then there is nothing to wait for.
+     */
+    synced: boolean;
+    /**
+     * The last listener error, or null.
+     *
+     * Surfaced rather than swallowed: a dead listener leaves the admin quietly stale, which
+     * looks exactly like a working admin until somebody wonders where their content type
+     * went.
+     */
+    error: Error | null;
+}
+/**
+ * Subscribes to a registry store, and feeds it from a schema listener when one is given.
+ *
+ * `watch` must be stable across renders (memoize it, or take it from a memoized adapter):
+ * a new function every render would close and reopen the Firestore listener every render.
+ */
+declare function useLiveRegistry(store: RegistryStore, watch?: SchemaWatch): LiveRegistry;
+
+/**
+ * The Developer area's Content Types list.
+ *
+ * Every content type the admin knows about, from either source, in one table. The two
+ * columns that only exist here are the point of the screen: **source** says whether a
+ * definition lives in git or in the database, and **lock** says whether the Schema Builder
+ * may touch it. Both are answered by the registry, never by the row.
+ *
+ * Two things that are easy to hide and must not be:
+ *
+ * - A slug defined in both sources. Code wins, the database definition is preserved on
+ *   `entry.conflict`, and the editor who created it is told it exists, is not live, and
+ *   why.
+ * - A stored definition that failed validation. It is in `registry.invalid` rather than in
+ *   the table, and a definition that silently disappeared is indistinguishable from one
+ *   that was deleted.
+ */
+interface ContentTypesScreenProps {
+    registry: Registry;
+    adapter: CmsAdapter;
+    user: AuthUser;
+    /** Opens one content type. Read-only for a code-defined one; the screen says so. */
+    onOpen: (slug: string) => void;
+    /** Called with the slug of a freshly created type, so the host can route to it. */
+    onCreated?: (slug: string) => void;
+    /**
+     * A listener error from the live registry, if the host is running one.
+     *
+     * Shown here rather than swallowed, because this screen is where somebody creates a type
+     * and then waits for it to appear.
+     */
+    liveError?: Error | null;
+}
+declare function ContentTypesScreen({ registry, adapter, user, onOpen, onCreated, liveError, }: ContentTypesScreenProps): react.JSX.Element;
+
+/**
+ * One content type in the Schema Builder: its settings, its fields, and what it has lost.
+ *
+ * `isSchemaReadOnly` is the single question this screen asks about whether it may edit
+ * anything, and it is true for every code-sourced type, not only the ones marked `locked`.
+ * A read-only type renders as a read-only type: the lock icon, a banner that says which of
+ * the two reasons applies, no drag handles, no inputs, no remove buttons. The adapter
+ * refuses the same writes independently, so the UI half is presentation and the rule lives
+ * below it.
+ *
+ * Everything else on this screen is generated. The field list, the per-type options and the
+ * validation controls all come from the field type registry, so this file names no field
+ * type.
+ */
+interface ContentTypeEditorProps {
+    adapter: CmsAdapter;
+    registry: Registry;
+    entry: RegistryEntry;
+    user: AuthUser;
+    /** Where the Content Types list is, for the breadcrumb. */
+    backHref?: string;
+}
+declare function ContentTypeEditor({ adapter, registry, entry, user, backHref, }: ContentTypeEditorProps): react.JSX.Element;
+
+interface CreateContentTypeDialogProps {
+    open: boolean;
+    registry: Registry;
+    adapter: CmsAdapter;
+    onClose: () => void;
+    onCreated: (slug: string) => void;
+}
+declare function CreateContentTypeDialog(props: CreateContentTypeDialogProps): react.JSX.Element | null;
+
+interface PermissionMatrixEditorProps {
+    /** The content type being edited. Only `permissions` and the labels are read. */
+    type: ContentTypeLike;
+    /** True for a code-defined or locked type, and for a user without manage-schema. */
+    readOnly: boolean;
+    /** The next matrix, already normalized. `undefined` means "back to the role defaults". */
+    onChange: (next: PermissionMatrix | undefined) => void;
+}
+declare function PermissionMatrixEditor({ type, readOnly, onChange, }: PermissionMatrixEditorProps): react.JSX.Element;
+
+/**
+ * The field editor as data: the order fields are shown in, what a new field starts as,
+ * whether a key may be used, and which options are still unanswered.
+ *
+ * Nothing here renders and nothing here writes. The Schema Builder screen calls it to
+ * decide what to show and what to enable, and the same functions are callable from a test
+ * or a script without a DOM.
+ *
+ * None of it switches on a field type. The per-type answers come from each field type's own
+ * `editor` spec through the registry, which is why adding a thirteenth field type adds it
+ * to the Schema Builder with no edit in this file and none in any screen.
+ */
+interface FieldRow {
+    key: string;
+    field: FieldDefinition;
+}
+type FieldKeyRejection = "invalid" | "reserved" | "live" | "removed";
+interface FieldKeyAvailability {
+    available: boolean;
+    reason?: FieldKeyRejection;
+    /** Ready to print, and it names what is in the way. */
+    message?: string;
+}
+interface FieldOptionIssue {
+    /** The option key the issue belongs to, so the control can show it. */
+    option: string;
+    message: string;
+}
+
+/**
+ * The field editor: one list of fields, reorderable, each expanding into its own options.
+ *
+ * It renders no field type. It renders **descriptors**: every per-type option and every
+ * validation rule on this screen comes from the field type's own `editor` spec through the
+ * registry, and the only switch in this file is over the small control vocabulary those
+ * descriptors are written in. Adding a thirteenth field type therefore adds its options
+ * here with no edit to this file, which is the same rule that makes the list views and the
+ * entry forms generated rather than written.
+ *
+ * Reordering works from the pointer and from the keyboard, and neither is a fallback for
+ * the other: the handle is a real button, the arrow keys move the field, focus travels with
+ * the row because the rows are keyed by field key, and every move is announced.
+ *
+ * A read-only field list has no handles, no inputs and no remove buttons. Not disabled
+ * controls that still look like controls: a code-defined type is not edited here at all,
+ * and the banner above the list says why.
+ */
+interface FieldRowsProps {
+    rows: readonly FieldRow[];
+    registry: FieldTypeRegistry;
+    /** Relation targets, from the live registry. The editor never reads the registry itself. */
+    contentTypes: readonly SelectOption[];
+    readOnly: boolean;
+    /**
+     * Whether a row can be moved.
+     *
+     * False for a repeater's nested fields: their order has nowhere to be stored, because
+     * `fieldOrder` describes a content type and a nested map is part of one field.
+     */
+    reorderable?: boolean;
+    /** Whether a key may be used here. Differs at the top level and inside a repeater. */
+    checkKey: (key: string) => FieldKeyAvailability;
+    onChange: (rows: readonly FieldRow[]) => void;
+    /**
+     * Removal, when it is not a plain list edit.
+     *
+     * At the top level it never is: removing a field has to go through the warning that
+     * counts the entries holding a value, so the owner handles it. Inside a repeater the row
+     * simply leaves the list.
+     */
+    onRemove?: (key: string) => void;
+    /** Names the group for assistive technology, and the add button. */
+    label: string;
+    issues?: readonly (FieldOptionIssue & {
+        key: string;
+    })[];
+}
+declare function FieldRows({ rows, registry, contentTypes, readOnly, reorderable, checkKey, onChange, onRemove, label, issues, }: FieldRowsProps): react.JSX.Element;
+
+/**
+ * The removal warning, with a number in it.
+ *
+ * "Some entries may hold data" is not a warning, it is a shrug. `fieldData.count` asks
+ * Firestore how many entries of this content type actually hold a value for this key, and
+ * the dialog prints that number, because it is also exactly the number a later purge would
+ * destroy: count and purge describe the same population by construction. See
+ * .docs/decisions/2026-09-18-schema-field-removal.md.
+ *
+ * The promise the copy makes is the one the code keeps: removing a field changes the
+ * definition and touches no entry. Deleting the values is a separate, separately confirmed
+ * action, which is why there is no checkbox here that does it in passing.
+ */
+interface RemoveFieldDialogProps {
+    adapter: CmsAdapter;
+    type: ContentTypeLike;
+    /** The field to remove. Null means the dialog is closed. */
+    fieldKey: string | null;
+    onCancel: () => void;
+    /** The definition change is the caller's: this dialog reads and confirms, never writes. */
+    onConfirm: (fieldKey: string) => void;
+}
+declare function RemoveFieldDialog(props: RemoveFieldDialogProps): react.JSX.Element | null;
+
+/**
+ * Deleting the stored values of a removed field. The only destructive schema operation.
+ *
+ * It is its own dialog, reached from its own place, with its own typed confirmation. That
+ * separation is the design: removal and purge are two decisions with as much time between
+ * them as the user wants, and no single confirmation can take a field from "this exists" to
+ * "its data is gone".
+ *
+ * One bounded call clears at most `MAX_FIELD_PURGE` entries and reports whether more
+ * remain, so a large purge is resumed rather than run as one unbounded write. The dialog
+ * says how many went and offers the next pass rather than looping silently.
+ */
+interface PurgeFieldDialogProps {
+    adapter: CmsAdapter;
+    type: ContentTypeLike;
+    /** The removed field whose values are being deleted. Null means the dialog is closed. */
+    fieldKey: string | null;
+    onCancel: () => void;
+    /** Every value is gone: the caller drops the parked definition and saves. */
+    onPurged: (fieldKey: string) => void;
+}
+declare function PurgeFieldDialog(props: PurgeFieldDialogProps): react.JSX.Element | null;
+
+interface ErrorScreenProps {
+    error: ClassifiedError;
+    /** Shown above the panel. Omitted inside a boundary that already sits under a header. */
+    title?: string | undefined;
+    /** Rendered only when the taxonomy says a retry can help. */
+    onRetry?: (() => void) | undefined;
+    /** One action at most, per the empty-state rule: a link back, or a sign-out. */
+    children?: ReactNode;
+}
+declare function ErrorScreen({ error, title, onRetry, children }: ErrorScreenProps): react.JSX.Element;
+
+/**
+ * The body of an admin route's error boundary.
+ * Canonical source: .docs/styleguide/04-components.md section 19.
+ *
+ * A host mounts it from an `error.tsx`, which is where Next puts the boundary; this is the
+ * fallback the boundary renders, classified through the same taxonomy as an error a screen
+ * caught for itself. The host supplies one `error.tsx` per route segment so a failure in
+ * the media library does not blank the whole admin, plus a `global-error.tsx` for the one
+ * case a segment boundary cannot cover: a throw in the root layout itself.
+ *
+ * Two things it deliberately does not do:
+ *
+ *  - **It never prints a stack trace or a raw digest string on its own line.** A boundary
+ *    that shows a blank page is bad; one that shows a stack is worse, because it looks
+ *    like the product broke open. In production Next replaces a server error's message
+ *    with a generic one and a digest, and the digest is appended to the sentence as a
+ *    reference rather than displayed as an error.
+ *  - **It never offers a retry the taxonomy refuses.** `reset` re-renders the segment,
+ *    which resolves a dropped connection and does nothing at all for a permission refusal.
+ *    Only a `transport` failure gets the button; everything else gets the way back the
+ *    host passed in, and the sidebar, which a route boundary keeps.
+ */
+interface RouteErrorProps {
+    /** Exactly what Next hands an `error.tsx`. */
+    error: Error & {
+        digest?: string;
+    };
+    /** Next's re-render of the failed segment. */
+    reset: () => void;
+    /** Shown above the panel. Name the area, so a boundary says where it fired. */
+    title?: string | undefined;
+    /** The signed-in role, so a permission refusal can name who was refused. */
+    role?: Role | undefined;
+    /** One way out, for a failure a retry cannot fix. A link back to the dashboard. */
+    children?: ReactNode;
+}
+declare function RouteError({ error, reset, title, role, children }: RouteErrorProps): react.JSX.Element;
+
+/**
+ * The 404 inside the admin.
+ *
+ * It renders inside the shell, with the sidebar still there, because a missing admin page
+ * is a wrong turn inside the product and not an exit from it. Dropping someone onto a bare
+ * framework error page takes away the one thing they need, which is a way back.
+ *
+ * Built from the empty state, centered in a panel, per .docs/styleguide/03-layout.md
+ * section 5.5. The description deliberately says nothing about what does exist: a 404 is
+ * also what an unauthenticated probe gets, and a list of real routes is an answer.
+ */
+interface NotFoundScreenProps {
+    /** One action: a link back to the dashboard. */
+    children?: ReactNode;
+}
+declare function NotFoundScreen({ children }: NotFoundScreenProps): react.JSX.Element;
+
+/**
+ * The Husk login screen.
+ *
+ * It owns no auth. The host passes `onSignIn`, which is expected to reject with an error
+ * whose message can be shown, so the same screen serves the emulator, a real project, and
+ * a test double without branching.
+ *
+ * Errors arrive from two directions and are rendered differently on purpose: a missing
+ * field is the field's problem, a refused credential is the form's.
+ */
+interface LoginCredentials {
+    email: string;
+    password: string;
+}
+interface LoginScreenProps {
+    onSignIn: (credentials: LoginCredentials) => Promise<void>;
+    /** Set when the guard bounced an expired session here, so the user is told why. */
+    expired?: boolean;
+}
+declare function LoginScreen({ onSignIn, expired }: LoginScreenProps): react.JSX.Element;
+
+interface UnauthorizedScreenProps {
+    /** The permission that was denied, used only to phrase the sentence. */
+    action?: Action;
+    /** The signed-in role, so the user can tell an access problem from a wrong account. */
+    role?: string;
+    /** One action at most: a link back, or a sign-out. */
+    children?: ReactNode;
+}
+declare function UnauthorizedScreen({ action, role, children }: UnauthorizedScreenProps): react.JSX.Element;
+
+/**
+ * Where the `relation` field type gets its entries.
+ *
+ * The field type never touches Firestore, and it never touches the `CmsAdapter` directly
+ * either: it asks this interface, and the admin supplies an implementation. That is what
+ * lets the picker be rendered in a test, in the Schema Builder preview, or against a
+ * different backend without the field type knowing.
+ */
+/** One row in the picker: the entry as it is named on screen, not the entry itself. */
+interface RelationOption {
+    id: string;
+    title: string;
+    status: EntryStatus;
+}
+interface RelationSearchRequest {
+    contentType: string;
+    /** Free text. An empty string asks for the first page unfiltered. */
+    search: string;
+    limit?: number;
+    cursor?: string | null;
+}
+interface RelationTypeInfo {
+    /** Singular label of the target type, for "Choose an Article". */
+    label: string;
+    /**
+     * Whether `search` narrows the result server-side. False when the target type declares
+     * no `titleField`, because there is then no field to match against and the picker must
+     * say so rather than silently ignore what was typed.
+     */
+    searchable: boolean;
+    /** False when the schema names a content type that does not exist. */
+    known: boolean;
+}
+interface RelationSource {
+    describe(contentType: string): RelationTypeInfo;
+    search(request: RelationSearchRequest): Promise<Page<RelationOption>>;
+    /**
+     * Resolves stored ids to their display titles. Ids with no entry are absent from the
+     * result, which is how the control learns a reference is broken.
+     */
+    resolve(contentType: string, ids: readonly string[]): Promise<readonly RelationOption[]>;
+}
+interface RelationSourceOptions {
+    adapter: CmsAdapter;
+    /** The content type registry, as a lookup. Unknown slugs return undefined. */
+    getType: (slug: string) => ContentTypeLike | undefined;
+}
+/**
+ * The real source, over the adapter.
+ *
+ * Two things it deliberately does not do.
+ *
+ * It never lists a whole content type. Every read is one bounded page with a cursor, so a
+ * picker over a type with fifty thousand entries costs the same as one over ten. The
+ * search is a prefix range on the type's `titleField`, which Firestore answers from the
+ * automatic single-field index; it is therefore case-sensitive and matches from the start
+ * of the title, and `describe()` reports when it cannot narrow at all so the picker can say
+ * so instead of appearing to ignore the box.
+ *
+ * It never resolves more ids than it was given. A single relation asks about one id and a
+ * `many` relation asks about the ids already stored on the entry, which the field's
+ * `maxLength` bounds. Nothing here fans out per customer project.
+ */
+declare function relationSourceFromAdapter({ adapter, getType, }: RelationSourceOptions): RelationSource;
+
+interface RelationSourceProviderProps {
+    value: RelationSource;
+    children: ReactNode;
+}
+declare function RelationSourceProvider({ value, children }: RelationSourceProviderProps): react.JSX.Element;
+declare function useRelationSource(): RelationSource | null;
+
+/**
+ * What a field input may know about the form around it.
+ *
+ * `FieldInputProps` deliberately carries only one field's value, because a field type that
+ * reaches into the form is a field type that cannot be rendered anywhere else. Two field
+ * types genuinely need more than their own value: `slug` derives from a sibling, and any
+ * field carrying `unique` needs someone who can ask the database. Both arrive through this
+ * context rather than through props, so every other field type keeps its narrow surface.
+ *
+ * The context has a working default: no sibling values, no uniqueness check. A field type
+ * rendered without a provider degrades to manual entry rather than throwing.
+ */
+/** Resolves to `true` when no other entry of this content type holds the value. */
+type UniqueCheck = (path: string, value: string) => Promise<boolean>;
+interface FieldFormContextValue {
+    /** Current values of the entry being edited, keyed by field key. */
+    values: Record<string, unknown>;
+    /** The content type's fields, so a field can name the sibling it derives from. */
+    fields?: FieldMap | undefined;
+    checkUnique?: UniqueCheck | undefined;
+}
+interface FieldFormProviderProps {
+    value: FieldFormContextValue;
+    children: ReactNode;
+}
+declare function FieldFormProvider({ value, children }: FieldFormProviderProps): react.JSX.Element;
+declare function useFieldForm(): FieldFormContextValue;
+
+/**
+ * The label, help text and error wrapper every field type renders.
+ *
+ * It is one component rather than five copies of the same six lines, so the composition
+ * from .docs/styleguide/04-components.md section 3.1 cannot drift between field types.
+ * Only the control inside it differs.
+ *
+ * The first error wins: the guide allows exactly one sentence under a field, and a field
+ * that is both too short and badly formatted is not clearer for saying so twice.
+ */
+interface FieldShellProps {
+    field: FieldDefinition;
+    errors: readonly FieldError[];
+    /** Replaces `field.description`, for a field type that has something better to say. */
+    help?: string | undefined;
+    children: FieldProps["children"];
+}
+declare function FieldShell({ field, errors, help, children }: FieldShellProps): react.JSX.Element;
+
+/**
+ * The seam between the `image` and `file` field types and the media library.
+ *
+ * The library itself is M7. The field types are M5, and they must be complete before it
+ * exists, so they are written against this interface rather than against Storage, the
+ * `MediaAdapter`, or a screen. Two consequences, both deliberate:
+ *
+ * 1. The field type never learns that Firebase exists. It asks for an item by id and asks
+ *    someone else to open a picker; whoever supplies the context decides how.
+ * 2. Until M7 supplies one, the context is absent, and the control renders the
+ *    "library not available" state instead of a dead button. A stored reference is still
+ *    shown and still saved, so an entry edited in that window loses nothing.
+ */
+interface MediaPickRequest {
+    /** MIME patterns the field accepts, for example `["image/*"]`. Absent means anything. */
+    accept?: readonly string[] | undefined;
+}
+interface MediaPickerApi {
+    /**
+     * Resolves stored references. Ids with no media document are simply absent from the
+     * result, which is how the control learns a reference is broken.
+     */
+    resolve(mediaIds: readonly string[]): Promise<readonly MediaItem[]>;
+    /** Opens the library and resolves to the chosen item, or null when the editor cancels. */
+    pick(request: MediaPickRequest): Promise<MediaItem | null>;
+}
+interface MediaPickerProviderProps {
+    value: MediaPickerApi;
+    children: ReactNode;
+}
+declare function MediaPickerProvider({ value, children }: MediaPickerProviderProps): react.JSX.Element;
+/** The installed picker, or null while the media library has not been mounted. */
+declare function useMediaPicker(): MediaPickerApi | null;
+/**
+ * What the control knows about the item behind the stored reference.
+ *
+ * `missing` and `loading` are separate states for one reason: a control that showed
+ * "missing" while the lookup was still in flight would accuse every reference of being
+ * broken for as long as the network takes.
+ */
+type MediaLookup = {
+    kind: "empty";
+} | {
+    kind: "unavailable";
+} | {
+    kind: "loading";
+} | {
+    kind: "found";
+    item: MediaItem;
+} | {
+    kind: "missing";
+};
+/**
+ * Resolves one stored reference to its media item.
+ *
+ * The resolved item is never written back into the value. A lookup is a read, and a field
+ * whose lookup failed must save exactly what it was given: see the `missing` state in
+ * `media-input.tsx`, which keeps the reference and never calls `onChange`.
+ */
+declare function useMediaLookup(reference: MediaReference | null): MediaLookup;
+
+/**
+ * The one registration point.
+ *
+ * The admin looks a field up here and renders `spec.Input`; it never switches on a field
+ * name. Adding a field type means adding it to this array and nowhere else, and a screen
+ * that needs `switch (field.type)` is telling you the abstraction has failed.
+ *
+ * Every field type the MVP promises is now here, which is what makes the rule checkable
+ * rather than aspirational.
+ *
+ * `repeater` imports this module back, because it renders its nested fields through the
+ * registry. The cycle is deliberate and safe: see the note in `repeater/input.tsx`.
+ */
+declare const fieldTypes: FieldTypeRegistry;
+
+export { AdminMediaPickerProvider, type AdminMediaPickerProviderProps, AdminShell, type AdminShellProps, AdminSidebar, type AdminSidebarProps, type AuthorInfo, type AuthorLookup, Avatar, type AvatarProps, type AvatarSize, Badge, type BadgeProps, type BadgeVariant, Breadcrumb, type BreadcrumbItem, type BreadcrumbProps, Button, type ButtonProps, type ButtonSize, type ButtonVariant, Checkbox, type CheckboxProps, type ClipboardOutcome, CollectionList, type CollectionListProps, ContentTypeEditor, type ContentTypeEditorProps, ContentTypesScreen, type ContentTypesScreenProps, CreateContentTypeDialog, type CreateContentTypeDialogProps, DEFAULT_RECENT_LIMIT, Dashboard, type DashboardCount, type DashboardData, type DashboardProps, type DashboardRecentEntry, DeleteEntriesDialog, type DeleteEntriesDialogProps, ENTRY_STATUS_LABEL, ENTRY_STATUS_VARIANT, EmptyState, type EmptyStateProps, EntryEditor, type EntryEditorProps, EntryMetadata, type EntryMetadataProps, ErrorCapture, type ErrorCaptureProps, ErrorNotice, type ErrorNoticeProps, ErrorScreen, type ErrorScreenProps, Field, type FieldFormContextValue, FieldFormProvider, type FieldFormProviderProps, type FieldProps, FieldRows, type FieldRowsProps, FieldShell, type FieldShellProps, FormError, ICONS, Icon, IconButton, type IconButtonProps, type IconName, type IconProps, type IconSize, type LiveRegistry, type LoadDashboardOptions, type LoginCredentials, LoginScreen, type LoginScreenProps, MEDIA_FILTERS, MediaDeleteDialog, type MediaDeleteDialogProps, MediaDetail, type MediaDetailProps, MediaLibrary, type MediaLibraryProps, type MediaLookup, type MediaPickRequest, type MediaPickerApi, MediaPickerProvider, type MediaPickerProviderProps, MediaTile, type MediaTileProps, type MediaUploadHandle, type MediaUploadPhase, type MediaUploadProgress, type MediaUploadRequest, type MediaUploader, Menu, type MenuEntry, type MenuProps, Metric, type MetricProps, Modal, type ModalProps, type ModalWidth, type MorphIconName, MorphingIcon, type MorphingIconProps, NotFoundScreen, type NotFoundScreenProps, PageHeader, type PageHeaderProps, PageSections, Pagination, type PaginationProps, Panel, type PanelPadding, type PanelProps, PermissionMatrixEditor, type PermissionMatrixEditorProps, Progress, type ProgressProps, PurgeFieldDialog, type PurgeFieldDialogProps, type RelationOption, type RelationSearchRequest, type RelationSource, type RelationSourceOptions, RelationSourceProvider, type RelationSourceProviderProps, type RelationTypeInfo, RemoveFieldDialog, type RemoveFieldDialogProps, RouteError, type RouteErrorProps, type SchemaWatch, SearchInput, type SearchInputProps, Section, type SectionProps, Select, type SelectOption, type SelectProps, Skeleton, type SkeletonLine, type SkeletonProps, type SortDirection, Spinner, type SpinnerProps, StatusDot, type StatusDotProps, type StatusTone, Switch, type SwitchProps, Table, TableBody, TableCell, type TableCellProps, TableEmptyRow, TableHead, TableHeaderCell, type TableHeaderCellProps, type TableProps, TableRow, type TableRowProps, TextInput, type TextInputProps, Textarea, type TextareaProps, type ToastApi, type ToastOptions, ToastProvider, type ToastTone, Tooltip, type TooltipProps, UnauthorizedScreen, type UnauthorizedScreenProps, type UniqueCheck, UnsavedChangesProvider, type UnsavedChangesProviderProps, UsageList, type UsageListProps, canDeleteMedia, canReplaceMedia, copyText, describeUsage, fieldTypes, formatBytes, formatCellValue, formatDate, formatDateTime, formatDimensions, initials, isDeletableType, isImageItem, loadDashboard, pickableItems, queryTypeFilter, relationSourceFromAdapter, uploadAccept, useBeforeUnloadWarning, useConfirmLeave, useFieldForm, useLiveRegistry, useMediaLookup, useMediaPicker, useOptionalToast, useRelationSource, useToast, useUnsavedChanges };