efficient-easel 0.101.0 → 0.102.0

package/dist/screen/lib/puck/add-target-types.d.ts

@@ -0,0 +1,55 @@
+import { BlockChoice } from './block-choice.js';
+import { SlotSectionSpec } from './slot-section-spec.js';
+
+/** Which registry answered — the discriminator three of the four decisions read. */
+type AddTargetSource = "section" | "footer" | "container";
+/**
+ * What a parent can take, and everything the four decisions below need to act on
+ * it.
+ *
+ * ⚠️ THE LOOKUP DECIDES FOUR THINGS, NOT ONE. Wiring only the choice list ships
+ * a menu with wrong row names, wrong handlers, and unreachable on an empty
+ * container — which is why this returns a record rather than a list:
+ *
+ *   1  the CHOICE LIST — {@link AddTarget.choices}, what the Add menu offers, or
+ *      `null` where the parent adds ONE child type from a button instead.
+ *   2  the ROW NAME    — `rowNamerFor` (components/SlotChildRows) reads
+ *      {@link AddTarget.source} to pick the FOOTER's block-label rule over
+ *      lib/puck/slot-child-name.ts. It must ask "is this a FOOTER block", NOT
+ *      "does this parent use a menu": a Box adds from a menu too and
+ *      keeps the slot-child rule, or its Headings, Texts and Buttons all fall
+ *      through to a rule that reads a heading, a bound menu and first-words.
+ *   3  WHICH HANDLERS  — SectionScreenShell's adapter reads `source` to choose
+ *      which pair of host handlers a row presses. Keyed the other way round it
+ *      answered null for a Box, whose rows then pressed and did nothing.
+ *   4  REACHABILITY    — `Boolean(canAddTo(type))` feeds `nestState`, and a row
+ *      folds open only if it has children OR an add affordance. An EMPTY
+ *      container with no caret cannot be opened to reach its own menu — and
+ *      empty is exactly the state a merchant is in when adding the first block.
+ */
+interface AddTarget {
+    /** Which of the three registries answered. */
+    source: AddTargetSource;
+    /**
+     * The slot this parent keeps its children on.
+     *
+     * RETURNED rather than defaulted, so a caller can never reach it by falling
+     * through another mechanism's constant — the rule container-blocks states for
+     * its own lookup, kept here because this is now the one that is asked. A Flex
+     * listed on the Footer's `blocks` would draw its rows off `undefined`.
+     */
+    slot: string;
+    /** The registry's own choice list, or `null` for a single-type "Add …" button. */
+    choices: BlockChoice[] | null;
+    /**
+     * The section's own spec — its `addLabel`, `childType`, `seeds`, `addBlocked`,
+     * `notice` and `slider`. Non-null exactly when `source === "section"`.
+     *
+     * Carried so a caller that needs a section's own arithmetic (the Hero slide's
+     * anchor cap, the seed-on-load effect) reaches it through this one seam rather
+     * than importing the registry beside it and gaining a second opinion.
+     */
+    spec: SlotSectionSpec | null;
+}
+
+export type { AddTarget, AddTargetSource };

package/dist/screen/lib/puck/block-choice.d.ts

@@ -0,0 +1,52 @@
+/**
+ * One row of an "Add block" menu.
+ *
+ * `group` is OPTIONAL and is the menu's own heading, not a property of the
+ * block: the same `ImageBlock` is grouped in a Box's menu and ungrouped in a
+ * Slide box's, because grouping is a fact about the LIST a merchant is reading,
+ * not about the component. A list whose choices carry no group renders flat, so
+ * every menu that shipped before this stays exactly as it was.
+ *
+ * It is set at BUILD time by whichever module assembles the list, from the
+ * source each choice came from — never hand-written per row. See
+ * `lib/puck/container-blocks.ts`, which is the only assembler that sets one.
+ */
+type BlockChoice = {
+    type: string;
+    label: string;
+    group?: string;
+};
+/**
+ * One run of consecutive choices sharing a `group` — what a menu draws under one
+ * heading.
+ *
+ * ⚠️ ONE FUNCTION, BOTH SURFACES, and that is the whole reason it is a function.
+ * A Box's menu is drawn twice — the dropdown in `components/AddBlockRow`
+ * (reached from the Layers tree and from the box's own settings panel) and the
+ * chip row at the top of the Add panel (`components/AddSectionPanel`). They draw
+ * ONE list, so "where does a heading start" must be ONE answer; two `map`s each
+ * comparing with the previous item is how the two surfaces begin dividing the
+ * same list differently. That is the exact defect `lib/puck/add-target.ts`'s
+ * docblock is an essay about, one tier down.
+ *
+ * ⚠️ AND THE MENU'S CLASS NAME IS DELIBERATELY NOT WRITTEN IN THIS FILE.
+ * `test-footer-block-lists` §8 counts the files mentioning it to prove the menu
+ * has exactly ONE home, and it reads prose the same way it reads code — naming
+ * the class in a comment here makes this module look like a second menu. The
+ * markup lives in `components/AddBlockRow`; this is only the arithmetic.
+ *
+ * It preserves ORDER and never sorts: the list arrives in the order its assembler
+ * chose (`lib/puck/container-blocks.ts` says why that order is what it is), and a
+ * renderer is not the place to have a second opinion about it.
+ *
+ * A list whose choices carry NO group comes back as a single run with
+ * `group: undefined` — so a caller written for runs draws an ungrouped list
+ * exactly the way it drew it before groups existed, with no branch of its own.
+ */
+type BlockChoiceRun = {
+    group?: string;
+    items: BlockChoice[];
+};
+declare function blockRuns(choices: BlockChoice[]): BlockChoiceRun[];
+
+export { type BlockChoice, type BlockChoiceRun, blockRuns };

package/dist/screen/lib/puck/block-choice.js

@@ -0,0 +1 @@
+export{blockRuns}from"../../../chunk-HQ4VVRIC.js";

package/dist/screen/lib/puck/block-types-in.d.ts

@@ -0,0 +1,39 @@
+/**
+ * Every block type a saved layout uses — the top-level sections and whatever
+ * sits in their slots, to any depth.
+ *
+ * WHAT IT IS FOR. A host chooses which blocks its editor offers
+ * (`WebsiteEditor`'s `blocks`), and that choice hides them in the palette, the
+ * slot menus and the drop targets. It is not a boundary: a saved page is a JSON
+ * document, and whoever can call the host's save endpoint can send one holding
+ * any type. So the host's SERVER reads the layout it was handed with this, and
+ * refuses a type it does not allow.
+ *
+ * READ BY SHAPE, WITH NO REGISTRY. A node is `{ type: string, props: {…} }`,
+ * and a slot is an array of nodes kept on a prop of its parent — directly, or
+ * inside an object or a list item. This walks every value under `props` and
+ * takes each array item of that shape as a node. It asks no block registry which
+ * props are slots, because the caller is a server that must not have to load
+ * one: this module imports nothing.
+ *
+ * That makes it wider than the editor's own walk in one direction only: a prop
+ * that merely LOOKS like a node (an object with a string `type` and an object
+ * `props`, inside an array) is counted. It does not ask for the `id` the engine
+ * gives every node, because the renderer draws a node without one and a request
+ * written by hand can leave it out. Wider is the safe side for an allow-list —
+ * it can refuse a page it might have accepted, never accept one it should have
+ * refused.
+ *
+ * `zones` — the engine's older place for slot children, which this editor has
+ * never written — is walked too, so a document from elsewhere hides nothing
+ * there.
+ */
+/**
+ * The block types in `layout`, each once, sorted. `layout` is the page document
+ * a `WebsiteBackend` stores (`PageLayout`: `content`, `root`, `zones`); a single
+ * node — a section template's — is read the same way. Anything else answers
+ * an empty list: it holds no block.
+ */
+declare function blockTypesIn(layout: unknown): string[];
+
+export { blockTypesIn };

package/dist/screen/lib/puck/block-types-in.js

@@ -0,0 +1 @@
+export{blockTypesIn}from"../../../chunk-5ZBY24K7.js";

package/dist/screen/lib/puck/content-tree.d.ts

@@ -0,0 +1,196 @@
+type TreeItem = {
+    type: string;
+    props: {
+        id: string;
+        [key: string]: unknown;
+    };
+};
+type SlotConfigView = {
+    components?: Record<string, unknown>;
+};
+/**
+ * Which of a component type's props are SLOTS — the prop names that hold child
+ * Blocks, read off the config's field map.
+ *
+ * Puck 0.20 stores slot children INLINE on the parent's props
+ * (`props.<slotName> = [{type,props}, …]`), NOT in `data.zones` — so a walker
+ * that wants a section's children has to know which prop names to look under.
+ * That set is per-component and lives in exactly one place, `config.components`:
+ * `Grid`/`Flex` call theirs `content`, but `Hero` calls it `slides`,
+ * `Collections` `cards`, `GalleryB` `items`, `ProductGrid` `products` and
+ * `Footer`/`FooterGroup` `blocks`.
+ *
+ * This is the ONE reader of that set. Hard-coding `"content"` instead is how the
+ * heading/SEO audit came to be blind to every heading nested in a Hero slide
+ * (card 66067): the walker recursed on a prop name only two of the eight slots
+ * happen to use, so a page with two H1s reported as fine. A type the config does
+ * not know has no slots — and cannot render either, so there is nothing to walk.
+ */
+declare function slotFieldsOf(config: SlotConfigView, type: string): string[];
+/**
+ * A slot child, addressed the way the Layers tree selects it: the node, the
+ * compound zone key "<parentId>:<slotName>" Puck's ops take, and its index in
+ * that slot.
+ */
+type SlotChild = {
+    child: TreeItem;
+    zone: string;
+    index: number;
+};
+/**
+ * Every slot child of `item`, across EVERY slot field its type declares — so a
+ * type with two slots reports both, and nesting is general: the result's `child`
+ * is itself an item this function accepts.
+ *
+ * Puck 0.20 stores slot children INLINE on the parent's props, so this reads the
+ * arrays rather than `data.zones` (which stays empty for slots).
+ */
+declare function childSlotsOf(config: SlotConfigView, item: TreeItem): SlotChild[];
+/**
+ * WHERE a node sits in the document — the node itself, the zone key its own
+ * array is addressed by, and its index in that array. Exactly the three
+ * arguments a Puck `replace` / `remove` / `reorder` op takes.
+ */
+type NodeLocation = {
+    item: TreeItem;
+    zone: string;
+    index: number;
+};
+/**
+ * Find a node by id and say WHERE IT IS, anywhere in the document — the root
+ * list or any slot at any depth.
+ *
+ * ── WHY A PANEL NEEDS THIS ──────────────────────────────────────────────────
+ * `useEasel((s) => s)` hands a field the SELECTED node and, in `ui.itemSelector`, the
+ * zone and index of that node. A control that has to rewrite the node's PARENT
+ * — "Apply to all cards" writes the whole Collections node once, so one press is
+ * one undo step — gets only half of what it needs: the selector's zone is the
+ * compound `"<parentId>:cards"`, which names the parent but says nothing about
+ * where the PARENT itself lives. Without that, the write has nowhere to go.
+ *
+ * ⚠️ IT IS NOT `enclosingSectionProps`, AND THE DIFFERENCE IS NOT COSMETIC.
+ * That one answers "which TOP-LEVEL section is this inside", returns props, and
+ * deliberately returns `null` for the immediate parent when the parent is not a
+ * root section. This one answers "where is THIS node", returns an address, and
+ * is happy to name a node nested inside a Box inside a Box. Its own docblock
+ * asks for a third question to be a third function rather than a third shape
+ * returned by the same walker; this is that function.
+ *
+ * ⚠️ AND IT IS NOT `childSlotsOf` WITH A FILTER. That lists one node's children;
+ * this searches a whole document. It is BUILT on `childSlotsOf` so the set of
+ * slot prop names stays read in exactly one place — hard-coding `"content"`
+ * instead is how the heading audit went blind to every heading nested in a Hero
+ * slide (card 66067), and the reason is written out on `slotFieldsOf`.
+ *
+ * ⚠️ THE CHROME ALREADY ANSWERS THIS, AND THAT IS NOT A DUPLICATE OF THIS.
+ * `ScreenChrome` memoises a Map of EVERY node's address (plus each
+ * zone's whole sibling list) and hands the lookup to the context menu as
+ * `locate`. That map is built once per document for a surface that needs all of
+ * it; this finds ONE node and is reachable from a Puck field, which the map is
+ * not — it lives in a component's closure and rides no context. What must not
+ * be two things is the set of SLOT PROP NAMES, and it is not: both walk through
+ * `childSlotsOf`, so an address here and an address there cannot disagree.
+ * Puck's own `getSelectorForId` is a third reader of the same fact, and the one
+ * a live store already offers — it is a hook-bound function, so a guard cannot
+ * call it, which is the whole reason this one is written pure.
+ *
+ * PURE, and takes the config as an argument, so a guard can assert against it
+ * without a Puck store, a React tree or a hook.
+ *
+ * `null` when no node carries the id — the honest answer for a stale selection,
+ * and every caller treats it as "there is nothing to write".
+ */
+declare function locateNode(config: SlotConfigView, content: ReadonlyArray<TreeItem>, id: string): NodeLocation | null;
+/**
+ * How many levels of slot children the Layers tree draws below a top-level row.
+ *
+ * The tree is a ~288px panel that already scrolls and each level costs 10px of
+ * indent (`.sf-subtree`'s `padding-left`, storefront-editor.css — it was 25px
+ * until card 66199 took the drag grip out of the flow and moved the caret to the
+ * row's right end), so the depth is capped rather than unbounded: `Grid.content`
+ * is an open slot that accepts a Grid, so a document CAN nest without limit and a
+ * tree that followed it would run out of width.
+ *
+ * ⚠️ 3 SINCE CARD 66273, and the level it buys is the one a merchant was stuck
+ * on. A hero group's blocks are the THIRD level — Hero → slide → group → blocks
+ * — and at 2 a group row was a LEAF: no `.sf-subtree` was rendered under it, so
+ * the "Add block" row that lives inside that subtree had nowhere to go, and a
+ * merchant who made a group in the tree could not put anything into it. The
+ * number was 2 because the Footer's chain (Footer → blocks → Group → blocks) was
+ * the only one that existed when the cap was named; the hero's is one level
+ * deeper.
+ *
+ * The Footer is unaffected, measured rather than hoped: `FooterGroup.blocks`
+ * allows FooterText / FooterEmailSignup / FooterMenu / FooterDivider and none of
+ * those owns a slot, so no footer row grows a third level. What DOES gain one is
+ * a container nested inside a container (a Box in a Box) —
+ * blocks a merchant can already build and could not see.
+ */
+declare const TREE_MAX_DEPTH = 6;
+/**
+ * Does the Layers tree draw a subtree under a node of `type` sitting at `depth`?
+ * True only when the type owns at least one slot AND the level is inside the cap.
+ * `depth` is 1 for a section's own children (the first `.sf-subtree`).
+ *
+ * The ONE place the cap is decided — both tree renderers and the "collapse all"
+ * gather read it here, so a row that folds and a row that draws children can
+ * never disagree about which rows those are.
+ */
+declare function nestsInTree(config: SlotConfigView, type: string, depth: number): boolean;
+declare const newNodeId: (type: string) => string;
+declare const HEADER_TYPE = "Header";
+declare const FOOTER_TYPE = "Footer";
+declare const ROOT_ZONE = "root:default-zone";
+/**
+ * Indices of the DUPLICATE pinned chrome sections in a top-level content array —
+ * every Header/Footer node PAST the first of its type, in ascending order. Empty
+ * when the array already holds at most one of each (the healthy case), so a caller
+ * can skip the rewrite. Keeping the FIRST of each type matches exactly what the
+ * Sections tree shows (footerIndex/findIndex), so healing never surprises the
+ * author by dropping the copy they were looking at. Accepts a loose node shape so
+ * both the editor's `TreeItem[]` and the published render's untyped content pass.
+ */
+declare function pinnedDuplicateIndices(content: ReadonlyArray<{
+    type?: string;
+}>): number[];
+/**
+ * Ids of the DUPLICATE pinned chrome sections — the id-anchored counterpart of
+ * pinnedDuplicateIndices, derived FROM it so the two can never disagree about
+ * which copy is the keeper (the first of each type).
+ *
+ * A LIVE store must be edited by identity, never by position: an index computed
+ * from a render snapshot addresses whatever has since shifted into that slot,
+ * which is how the old editor heal deleted real sections. Ids survive that skew
+ * — the worst a stale read can do is name a node that is no longer there. A
+ * duplicate carrying no id is skipped (it cannot be named in a remove); the
+ * published render's index-based dedupe still drops it.
+ */
+declare function pinnedDuplicateIds(content: ReadonlyArray<{
+    type?: string;
+    props?: {
+        id?: unknown;
+    };
+}>): string[];
+/**
+ * Which pinned chrome types a document is MISSING, and a load-time seed must
+ * therefore create. A type counts as missing only when it is absent from BOTH:
+ *
+ *   - `live` — the editor's Puck store, read at the moment of the write; and
+ *   - `persisted` — the document exactly as it was LOADED from the backend.
+ *
+ * Requiring both is what makes seeding idempotent, and neither check can be
+ * dropped. Trusting `live` alone was the duplicate-Header bug: a remount re-armed
+ * the seed's per-mount guard while a snapshot that lagged the store reported "no
+ * Header", so a second one was appended next to the first. Trusting `persisted`
+ * alone would re-seed a node this session has already inserted but not yet saved.
+ *
+ * Returned in no particular order — the CALLER owns the insert order, because
+ * only it knows that the Footer is pinned last and the Header first.
+ */
+declare function missingPinnedTypes(live: ReadonlyArray<{
+    type?: string;
+}>, persisted: ReadonlyArray<{
+    type?: string;
+}>): string[];
+
+export { FOOTER_TYPE, HEADER_TYPE, type NodeLocation, ROOT_ZONE, type SlotChild, type SlotConfigView, TREE_MAX_DEPTH, type TreeItem, childSlotsOf, locateNode, missingPinnedTypes, nestsInTree, newNodeId, pinnedDuplicateIds, pinnedDuplicateIndices, slotFieldsOf };

package/dist/screen/lib/puck/content-tree.js

@@ -0,0 +1 @@
+export{FOOTER_TYPE,HEADER_TYPE,ROOT_ZONE,TREE_MAX_DEPTH,childSlotsOf,locateNode,missingPinnedTypes,nestsInTree,newNodeId,pinnedDuplicateIds,pinnedDuplicateIndices,slotFieldsOf}from"../../../chunk-FUDHI5I4.js";

package/dist/screen/lib/puck/device-fields.d.ts

@@ -0,0 +1,126 @@
+import { ReactElement } from 'react';
+import { PreviewDevice } from '../../components/PreviewDeviceContext.js';
+import '../content/view-tiers.js';
+
+/**
+ * lib/puck/device-fields.tsx — show the setting for the device the merchant is
+ * currently looking at, and only that one.
+ *
+ * THE PROBLEM. A section that can be sized differently on a phone stores TWO
+ * props and the panel drew BOTH, side by side, told apart only by a "(desktop)"
+ * / "(mobile)" suffix on the label. The canvas already knows which device is on
+ * screen; the panel ignored it, so the merchant read labels to find the control
+ * that matched what they were looking at.
+ *
+ * THE MECHANISM, and why this one. A Puck `resolveFields` cannot do it: in this
+ * Puck version the fields slice re-resolves only when the selected node's DATA
+ * changes (`useRegisterFieldsSlice` subscribes to `state.indexes.nodes[id]`), and
+ * switching device changes no data — the panel would keep whatever field set the
+ * last edit produced. So the decision is made where it can re-render freely: in
+ * the FIELD ITSELF, off the React context the editor chrome already publishes
+ * (`components/PreviewDeviceContext`, which the per-view Footer controls read
+ * for the same reason). One context, no prop threaded anywhere, and every house
+ * control is already a `type: "custom"` render, so wrapping one costs nothing.
+ *
+ * ⚠️ HIDDEN IS NOT DELETED. {@link deviceField} returns the SAME field object
+ * with the same markers (`__media`, `__text`, …) and the same key; only its
+ * paint is gated. Both props keep existing, keep their keys, keep their values
+ * and keep their `defaultProps`. Switch to Phone, type a size, switch back — the
+ * desktop size is exactly where it was, because nothing ever wrote to it.
+ * `scripts/test-device-fields.tsx` pins that round trip.
+ *
+ * TABLET (owner ruling, card 66066). There are no tablet-specific stored values
+ * today, and inventing them would mean a new stored prop on every section — a
+ * different card. So tablet shows the DESKTOP values and the panel SAYS SO
+ * ({@link DEVICE_NOTE}); it never presents desktop values as if they were
+ * tablet's. {@link shownTier} is the single place that ruling is written down.
+ *
+ * WHY THE HIDDEN FIELD LEAVES NO GAP. Puck wraps every top-level field in its
+ * own padded `_PuckFields-field_` box before it calls `render`, so a field that
+ * renders nothing would still cost ~37px of empty panel. The gate instead paints
+ * a zero-size marker and `components/storefront-editor.css` collapses the
+ * wrapper that contains one — the same "reach the wrapper Puck owns" trick the
+ * fold reflow in `controls.tsx` already relies on, expressed as one CSS rule
+ * instead of a second DOM pass (so it cannot race the fold's).
+ */
+
+/** The two tiers a stored value can belong to. Tablet is not one — see
+ *  {@link shownTier}. */
+type DeviceTier = "desktop" | "mobile";
+/**
+ * Which tier's stored values the panel shows for a given preview device.
+ *
+ * The owner ruling in one expression: phone shows the phone values, everything
+ * else — desktop AND tablet — shows the desktop values.
+ */
+declare function shownTier(device: PreviewDevice): DeviceTier;
+/**
+ * The quiet line the panel puts above a section's settings, so a merchant can
+ * always tell WHICH device's value they are editing without reading the canvas.
+ *
+ * Desktop says nothing: it is the resting state, and a banner that is always
+ * there is a banner nobody reads. Tablet says the ruling out loud rather than
+ * letting the desktop values pass for tablet's own.
+ */
+declare const DEVICE_NOTE: Readonly<Record<PreviewDevice, string | null>>;
+/** The attribute the stylesheet looks for to collapse a gated-off field's Puck
+ *  wrapper. Declared here, matched once in `components/storefront-editor.css`. */
+declare const DEVICE_HIDDEN_ATTR = "data-sf-device-hidden";
+/** A house control's render, seen from outside: the builders in `controls.tsx`
+ *  each type their own props, so the gate takes the widest shape that can be
+ *  passed straight back through. */
+type FieldRender = (props: Record<string, unknown>) => ReactElement;
+/** Any house control — every one of them is a `type: "custom"` field whose
+ *  `render` is a plain function of its props. */
+type AnyCustomField = {
+    type: "custom";
+    render: FieldRender;
+};
+/** Marker carried by every gated field, in the same style as
+ *  {@link import("./controls").FOLD_FIELD_MARKER}: the tier and the field it
+ *  wraps live ON the field object, never only inside the render closure. Without
+ *  it a gated control is opaque to every static walk — and the fold guard in
+ *  `scripts/test-section-groups.ts` genuinely needs to see the header underneath
+ *  to check its label against what it draws. Puck ignores extra keys. */
+declare const DEVICE_FIELD_MARKER: "__device";
+/** The payload on {@link DEVICE_FIELD_MARKER}. */
+type DeviceFieldMeta = {
+    tier: DeviceTier;
+    inner: unknown;
+};
+/** Read a field's device payload, or null when it is not gated. The ONE place
+ *  that knows the marker's shape. */
+declare function deviceMetaOf(field: unknown): DeviceFieldMeta | null;
+/** The field a gate wraps, or the field itself when it wraps nothing — what a
+ *  static walk wants to look at. */
+declare function withoutDeviceGate(field: unknown): unknown;
+/**
+ * Paint `field` only while the canvas is showing `tier`.
+ *
+ * Everything else about the field is preserved by identity-spread — its `type`,
+ * its manifest markers, its data keys — so the media and neutralization walks,
+ * the field-key census and every stored prop see exactly what they saw before.
+ */
+declare function deviceField<F extends {
+    type: "custom";
+    render: (p: never) => ReactElement;
+}>(tier: DeviceTier, field: F): F;
+/**
+ * The panel's device indicator — one quiet line, and only when there is
+ * something to say (see {@link DEVICE_NOTE}).
+ *
+ * Declared as a FIELD rather than painted by the chrome so it sits inside the
+ * settings panel it describes, above the first group, and so a section that has
+ * no device-varying control never shows it. It edits nothing: like `group()` /
+ * `section()` it is a header, with no prop behind it.
+ *
+ * …WHICH IS WHY IT SAYS SO ON THE FIELD (card 66201). A note is not a control, so
+ * a heading with nothing but this under it is a heading over nothing — and it is
+ * the whole reason the Hero's Content tab was empty: `_dDevice` is the section's
+ * first field, so it opened the implicit leading Content run and gave the panel a
+ * Content tab with only a banner in it, while the hero's actual copy is edited in
+ * the Text sub-panel.
+ */
+declare function deviceNote(): AnyCustomField;
+
+export { DEVICE_FIELD_MARKER, DEVICE_HIDDEN_ATTR, DEVICE_NOTE, type DeviceFieldMeta, type DeviceTier, deviceField, deviceMetaOf, deviceNote, shownTier, withoutDeviceGate };

package/dist/screen/lib/puck/device-fields.js

@@ -0,0 +1 @@
+export{DEVICE_FIELD_MARKER,DEVICE_HIDDEN_ATTR,DEVICE_NOTE,deviceField,deviceMetaOf,deviceNote,shownTier,withoutDeviceGate}from"../../../chunk-PWZOS45R.js";import"../../../chunk-7F52SZOI.js";import"../../../chunk-BSPCSC45.js";

package/dist/screen/lib/puck/field-buckets.d.ts

@@ -0,0 +1,22 @@
+import { S as SettingsBucket } from '../../../buckets-CuLM47h9.js';
+
+/**
+ * lib/puck/field-buckets.ts — the four settings buckets a section's fields are
+ * sorted into, and the field key each bucket's header is emitted under.
+ *
+ * Moved out of lib/puck/field-groups (which re-exports both) so the editor's
+ * screen can read a bucket header's key — the style clipboard copies a look by
+ * the buckets it sits in — without importing the field builders that sort a
+ * section's fields (doc/adr/0004). The reasoning behind the buckets themselves
+ * stays in field-groups, beside the pass that applies them.
+ */
+
+type Bucket = SettingsBucket;
+/**
+ * The field key each bucket's header is emitted under. `_s*` because these are
+ * level-1 headers (`section()`), matching the `_s*` convention the sections that
+ * already carry level-1 headers use (`_sText`, `_sImage`, `_sSetup`, …).
+ */
+declare const BUCKET_KEY: Record<Bucket, string>;
+
+export { BUCKET_KEY, type Bucket };

package/dist/screen/lib/puck/field-buckets.js

@@ -0,0 +1 @@
+export{BUCKET_KEY}from"../../../chunk-R2HLPNQF.js";