efficient-easel 21.0.0 → 21.1.0

package/dist/screen/lib/puck/panel-no-control-mark.d.ts

@@ -1,74 +1,2 @@
-import { ReactElement } from 'react';
-
-/**
- * panel-no-control-mark — what a settings field draws when it draws NO CONTROL
- * on the screen it is on (card 66178).
- *
- * WHY A FIELD HAS TO SAY THIS OUT LOUD. Puck lays the inspector out as a FLAT
- * list and owns the wrapper around every top-level field, and its own stylesheet
- * rules the gap between two of them:
- *
- *   ._PuckFields--wrapFields_ ._PuckFields-field_ + ._PuckFields-field_ {
- *     border-top: 1px solid var(--puck-color-grey-09); margin-top: 8px; }
- *
- * That rule is right — a line between two adjacent rows. But a field whose
- * `render` returns `null` still gets the wrapper, still takes its `16px 16px
- * 12px` of padding and still draws the line, so the panel shows a hairline with
- * nothing on one side of it. Measured on the Collections Content tab before this
- * card: two 29px-tall wrappers whose whole content was
- * `<div class="_InputWrapper_"></div>`, and three rules stacked with only blank
- * space between them. Across the catalogue it was 338 such rows in 74 panels.
- *
- * We cannot stop Puck emitting the wrapper, so the wrapper is collapsed from the
- * outside: the field renders this zero-size marker and ONE declarative rule in
- * `components/storefront-editor.css` takes the wrapper out of the layout
- * entirely — `display: none`, so the row leaves the accessibility tree with it
- * rather than lingering as an unlabelled blank. That is exactly the shape the
- * bucket boundary markers (`data-sf-bucket`) and the device-gated fields
- * (`data-sf-device-hidden`) already use, and it is declarative for the same
- * reason: it cannot race the tab pass.
- *
- * IT IS NOT A WAY TO HIDE A SETTING. A field that draws nothing here must still
- * be reachable somewhere — as an entry row in the section screen's TEXT group,
- * or through another control on the same panel. `scripts/test-panel-no-empty-rows.tsx`
- * §2 fails a field that draws no control and has no way back to it, which is how
- * the lost "Anchor name" box was found.
- */
-
-/** The attribute the marker carries — the single source, read by the stylesheet
- *  rule and by the guard that proves the rule is there. */
-declare const NO_CONTROL_ATTR = "data-sf-no-control";
-/** The marker itself. `hidden` as well as the CSS rule, so a field that renders
- *  it in a context the editor stylesheet has not reached (a test harness, a
- *  bundled preview) still draws nothing rather than an empty inline box. */
-declare function NoControlMark(): ReactElement;
-/**
- * …AND THE SAME FACT SAID ON THE FIELD OBJECT (card 66201).
- *
- * The attribute above is drawn, so only a render can see it. The pass that drops
- * a heading standing over nothing runs in `resolveFields`, where there is no DOM
- * and no React — it has a field list and nothing else. So a field that draws no
- * control has to say so twice, in the two places the answer is asked, and both
- * are stamped by the ONE `if` that decides it: see `textField` in
- * `lib/puck/controls`, which wraps the render and stamps the marker together.
- *
- * The two reasons are not the same shape, hence a word rather than a boolean:
- *   • `"always"` — it draws nothing wherever it appears. A device scope note, a
- *     key whose one control is a row elsewhere on the same panel.
- *   • `"authored-copy"` — a scalar copy box card 8819 moved to the DRILL screen.
- *     It draws nothing on the section screen unless its prop is STRUCTURAL, which
- *     is the one question `SuppressibleText` also asks at render time.
- */
-declare const NO_CONTROL_FIELD: "__noControl";
-/** The payload on {@link NO_CONTROL_FIELD}. */
-type NoControlFieldMeta = "always" | "authored-copy";
-/** Read a field's no-control payload, or `null` when it draws a control of its
- *  own. The ONE place that knows the marker's shape. */
-declare function noControlMetaOf(field: unknown): NoControlFieldMeta | null;
-/** Stamp {@link NO_CONTROL_FIELD} on a field. The cast is here and nowhere else:
- *  Puck's field types have no slot for a marker, so an object literal carrying
- *  one trips the excess-property check at every call site otherwise — the same
- *  reason `group()` and the text/link markers have their own builders. */
-declare function noControlField<F>(field: F, reason: NoControlFieldMeta): F;
-
-export { NO_CONTROL_ATTR, NO_CONTROL_FIELD, type NoControlFieldMeta, NoControlMark, noControlField, noControlMetaOf };
+export { NO_CONTROL_ATTR, NO_CONTROL_FIELD, NoControlFieldMeta, NoControlMark, noControlField, noControlMetaOf } from '../document/panel-no-control-mark.js';
+import 'react';

package/dist/screen/lib/puck/panel-no-control-mark.js

@@ -1 +1 @@
-export{NO_CONTROL_ATTR,NO_CONTROL_FIELD,NoControlMark,noControlField,noControlMetaOf}from"../../../chunk-7F52SZOI.js";
+export{NO_CONTROL_ATTR,NO_CONTROL_FIELD,NoControlMark,noControlField,noControlMetaOf}from"../../../chunk-INRERJU4.js";

package/dist/screen/lib/puck/part-id.d.ts

@@ -1,23 +1 @@
-/**
- * lib/puck/part-id.ts — how one PART of a section is named: `"<nodeId>::<propKey>"`.
- *
- * A part is one authored text of a node (a heading, a button label) that the
- * editor's inspector can drill into. Its id is read on both sides of the
- * preview: the section's render marks each part with it, and the screen's part
- * bridge (components/usePartBridge) opens the part it names. The codec moved
- * here from lib/puck/text-parts (which re-exports it) so the screen reads it
- * without the text walk, and moves into efficient-easel with it (doc/adr/0004).
- */
-/** Separates the node id from the prop key inside a part id. A doubled colon:
- *  a Puck node id is `<Type>-<uuid>` and a compound zone is `<parentId>:<slot>`,
- *  so a single colon is already taken. */
-declare const PART_SEP = "::";
-/** `"<nodeId>::<propKey>"`, or `"<nodeId>::"` for "the whole section". */
-declare function encodePartId(nodeId: string, propKey: string | null): string;
-/** Inverse of {@link encodePartId}. `propKey: null` means the whole section. */
-declare function decodePartId(partId: string): {
-    nodeId: string;
-    propKey: string | null;
-} | null;
-
-export { PART_SEP, decodePartId, encodePartId };
+export { PART_SEP, decodePartId, encodePartId } from '../document/part-id.js';

package/dist/screen/lib/puck/part-id.js

@@ -1 +1 @@
-export{PART_SEP,decodePartId,encodePartId}from"../../../chunk-IYT6NN2J.js";
+export{PART_SEP,decodePartId,encodePartId}from"../../../chunk-R4AUZVA3.js";

package/dist/screen/lib/puck/preview-click.d.ts

@@ -1,49 +1 @@
-/**
- * "Did this come from a click INSIDE the preview?" — the one fact that decides
- * whether the editor is allowed to scroll its canvas.
- *
- * Every in-preview selection bridge (a section's text PARTS, and a Hero's
- * ticker / Background / Text) shares ONE handler with the matching row in the
- * Layers tree. The handler ends in `scrollPreviewToSection`, and only one of its
- * two callers should travel:
- *
- *   · from the LAYERS TREE — scroll. A row in a list can name a section that is
- *     off-screen, and taking the merchant there is the whole point of clicking it.
- *   · from a CLICK IN THE PREVIEW — do not. The merchant is already looking at
- *     the thing they clicked, so moving the canvas under them is motion they did
- *     not ask for (card 66392: "after clicking, the screen moves; cancel this
- *     sliding motion" — measured at 409px of travel in the phone preview).
- *
- * The two callers are told apart HERE rather than at each of the eight call
- * sites, because the difference is one rule and a rule spelled eight times is a
- * rule that drifts. `useSelectHandler` (lib/puck/preview-selection-context) is
- * the single entry point every in-preview click already goes through — it is
- * invoked from inside the portaled preview iframe — so wrapping it once covers
- * both editor shells and all four bridges, and the tree keeps calling the same
- * handlers directly and unchanged.
- *
- * ⚠️ AMBIENT, AND DELIBERATELY SO. Threading a "did this come from the preview"
- * argument through the bridges would mean editing every handler and every one of
- * its callers — exactly the call-site patching that left the last fix half-done.
- * The cost is that the fact lives in a module variable, so two things are load-
- * bearing: the flag is only ever read SYNCHRONOUSLY (see `scrollPreviewToSection`,
- * which must not defer the check into its `requestAnimationFrame`), and it is
- * restored in a `finally` so a throwing handler cannot leave the canvas
- * permanently unable to scroll. Both are pinned by
- * `scripts/test-preview-click-does-not-scroll.tsx`.
- *
- * No imports on purpose: `preview-dom` reads this and `preview-selection-context`
- * writes it, and the latter is reached from inside the preview iframe — putting
- * the flag in `preview-dom` would close a cycle back through HeroSection.
- */
-/**
- * Run `handler` as work caused by a click INSIDE the preview, so anything it
- * reaches knows not to move the canvas. Returns whatever `handler` returns; the
- * fact is restored even if it throws.
- */
-declare function runAsPreviewClick<T>(handler: () => T): T;
-/** True while a `runAsPreviewClick` handler is on the stack. Read it
- *  SYNCHRONOUSLY — deferred work runs after the click has already returned. */
-declare function isPreviewClick(): boolean;
-
-export { isPreviewClick, runAsPreviewClick };
+export { isPreviewClick, runAsPreviewClick } from '../document/preview-click.js';

package/dist/screen/lib/puck/preview-click.js

@@ -1 +1 @@
-export{isPreviewClick,runAsPreviewClick}from"../../../chunk-R5L2E7JX.js";
+export{isPreviewClick,runAsPreviewClick}from"../../../chunk-MGVI67QV.js";

package/dist/screen/lib/puck/preview-dom.d.ts

@@ -1,8 +1 @@
-declare const previewFrame: () => HTMLIFrameElement | null;
-declare function scrollPreviewToSection(id: string): void;
-declare function gotoPreviewSlide(heroId: string, index: number): void;
-declare function scrollPreviewToTop(): void;
-declare function pinPreviewToSection(id: string): () => void;
-declare function pinPreviewToBottom(onPinned?: () => void): () => void;
-
-export { gotoPreviewSlide, pinPreviewToBottom, pinPreviewToSection, previewFrame, scrollPreviewToSection, scrollPreviewToTop };
+export { gotoPreviewSlide, pinPreviewToBottom, pinPreviewToSection, previewFrame, scrollPreviewToSection, scrollPreviewToTop } from '../document/preview-dom.js';

package/dist/screen/lib/puck/preview-dom.js

@@ -1 +1 @@
-export{gotoPreviewSlide,pinPreviewToBottom,pinPreviewToSection,previewFrame,scrollPreviewToSection,scrollPreviewToTop}from"../../../chunk-2E2SXDYQ.js";import"../../../chunk-IQ5TA7AM.js";import"../../../chunk-LF3FUSCQ.js";import"../../../chunk-R5L2E7JX.js";
+export{gotoPreviewSlide,pinPreviewToBottom,pinPreviewToSection,previewFrame,scrollPreviewToSection,scrollPreviewToTop}from"../../../chunk-DDH2DYQP.js";import"../../../chunk-AJ2SUSET.js";import"../../../chunk-LF3FUSCQ.js";import"../../../chunk-MGVI67QV.js";

package/dist/screen/lib/puck/preview-events.d.ts

@@ -1,25 +1 @@
-/**
- * lib/puck/preview-events.ts — events the editor's screen sends INTO the preview.
- *
- * Moved from components/HeroSection (which re-exports them) so the screen's
- * preview bridge (lib/puck/preview-dom) can send them without importing a
- * section, and moves into efficient-easel with the screen (doc/adr/0004). A
- * section listens for its own; the name is the contract between the two.
- */
-/**
- * Event the editor chrome dispatches INTO the preview iframe to jump a Hero's
- * slider to a slide by index. The chrome (section tree + "Add slide") lives
- * outside this iframe and can't reach the slider's React state, and Puck's
- * selection overlay is portaled to the iframe `<body>` (not inside `.hero-track`),
- * so selection alone can't be observed from here — this is the explicit bridge.
- * See {@link ScreenChrome} `selectChild` / `addChild`.
- */
-declare const HERO_SLIDER_GOTO_EVENT = "hero-slider:goto";
-interface HeroSliderGotoDetail {
-    /** Target Hero's stable Puck id (`data-puck-component`); omit to hit all Heroes. */
-    id?: string;
-    /** Zero-based slide index to show. */
-    index: number;
-}
-
-export { HERO_SLIDER_GOTO_EVENT, type HeroSliderGotoDetail };
+export { HERO_SLIDER_GOTO_EVENT, HeroSliderGotoDetail } from '../document/preview-events.js';

package/dist/screen/lib/puck/preview-events.js

@@ -1 +1 @@
-export{HERO_SLIDER_GOTO_EVENT}from"../../../chunk-IQ5TA7AM.js";
+export{HERO_SLIDER_GOTO_EVENT}from"../../../chunk-AJ2SUSET.js";

package/dist/screen/lib/puck/preview-selection-context.d.ts

@@ -1,72 +1,2 @@
-import * as react from 'react';
-import { ReactNode } from 'react';
-
-/**
- * Shared machinery for the editor preview's "selection bridges" — the click-to-
- * select plumbing every piece of site CHROME needs because it is NOT a Puck node
- * and so can't route through Puck's own selection. The header, the chat bubble,
- * and a Hero's ticker / background / text overlay each expose the SAME two-way
- * bridge, and all built it by hand until this file:
- *
- *  - `select(…)` / `setSelectHandler(fn)` — a ref-backed handler the chrome
- *    registers (it opens the matching inspector panel), invoked from inside the
- *    portaled preview iframe when the element is clicked. It lives behind a ref so
- *    the chrome can re-register without re-rendering the preview; `select` itself
- *    stays stable. See {@link useSelectHandler}.
- *  - a mirrored SELECTION the preview reads to draw its own "selected" outline.
- *
- * Two entry points reuse the bridge:
- *  - {@link useSelectHandler} — just the ref-backed `select` / `setSelectHandler`
- *    pair, for the header + chat bridges. They keep a plain boolean `selected` and
- *    layer their own live-config state around it, so they compose this hook rather
- *    than the whole context factory.
- *  - {@link createPreviewSelectionContext} — a whole context + provider + hook for
- *    an ID-SCOPED bridge (a Hero's ticker / background / text), where the mirrored
- *    selection is "which sibling id is selected" (`selected<Thing>Id`), scoped by
- *    id so sibling heroes never cross-select. The three such contexts differ ONLY
- *    in that field's name, so they are each one call to this factory.
- */
-/**
- * The ref-backed `select` / `setSelectHandler` pair shared by every selection
- * bridge. `Args` is the click payload the chrome's handler receives — `[]` for a
- * lone toggle (header / chat) or `[id: string]` for an id-scoped bridge (ticker /
- * hero media / hero text). `select` is stable across renders; registering a new
- * handler never re-renders the portaled preview.
- */
-declare function useSelectHandler<Args extends unknown[]>(): {
-    select: (...args: Args) => void;
-    setSelectHandler: (fn: (...args: Args) => void) => void;
-};
-/**
- * The context value of an id-scoped selection bridge, keyed by the id field's
- * name `Key` (e.g. `"selectedHeroId"`): the mirrored id + its `set…` setter, plus
- * the shared `select(id)` / `setSelectHandler` pair. Keeping the field name in the
- * type is what lets one factory reproduce each context's exact public API.
- */
-type PreviewIdSelection<Key extends string> = {
-    [P in Key]: string | null;
-} & {
-    [P in Key as `set${Capitalize<P>}`]: (id: string | null) => void;
-} & {
-    select: (id: string) => void;
-    setSelectHandler: (fn: (id: string) => void) => void;
-};
-/**
- * Build a complete id-scoped selection-bridge context — the shared body of
- * PreviewTickerContext / PreviewHeroMediaContext / PreviewHeroTextContext, which
- * differ only in the id field's NAME. Pass that field name and the returned
- * `Provider` + `useSelection` expose exactly `{ [idKey], set<IdKey>, select,
- * setSelectHandler }`, so each context's existing consumers read unchanged.
- *
- * @example
- * export const { Provider: PreviewTickerProvider, useSelection: usePreviewTicker } =
- *   createPreviewSelectionContext("selectedHeroId");
- */
-declare function createPreviewSelectionContext<Key extends string>(idKey: Key): {
-    Provider: ({ children }: {
-        children: ReactNode;
-    }) => react.JSX.Element;
-    useSelection: () => PreviewIdSelection<Key>;
-};
-
-export { type PreviewIdSelection, createPreviewSelectionContext, useSelectHandler };
+export { PreviewIdSelection, createPreviewSelectionContext, useSelectHandler } from '../document/preview-selection-context.js';
+import 'react';

package/dist/screen/lib/puck/preview-selection-context.js

@@ -1 +1 @@
-export{createPreviewSelectionContext,useSelectHandler}from"../../../chunk-GOTN2KY4.js";import"../../../chunk-R5L2E7JX.js";
+export{createPreviewSelectionContext,useSelectHandler}from"../../../chunk-TIAWIOGD.js";import"../../../chunk-MGVI67QV.js";

package/dist/screen/lib/puck/section-doc.d.ts

@@ -1,24 +1,9 @@
-import { Data } from '../../../blocks/index.js';
-import { TreeItem } from './content-tree.js';
+export { cloneNodeWithFreshIds, docToNode, nodeToDoc } from '../document/section-doc.js';
+import '../../../blocks/index.js';
 import 'react';
 import '../../../types-Cq53lL8d.js';
 import '../../../data/index.js';
 import '../../../types-41704JE4.js';
 import '../../../resolve-D68pb3Bx.js';
 import '../../../plan-CZS902DV.js';
-
-declare function nodeToDoc(node: TreeItem): Data;
-declare function docToNode(data: Data): TreeItem | null;
-/**
- * Deep-copy a stored section node with FRESH ids — the node's own and every
- * inline slot child's, recursively — so inserting the same template twice never
- * lands two nodes with colliding ids (Puck keys selection/replace on id, and
- * React keys render on it).
- *
- * `strip` (0.106.0) sees each copied node once its children are copied, and
- * answers it as the copy should hold it — the layer's `blockRules.stripCopy`,
- * which takes out what only an original may hold. It keeps the fresh id.
- */
-declare function cloneNodeWithFreshIds(node: TreeItem, strip?: (node: TreeItem) => TreeItem): TreeItem;
-
-export { cloneNodeWithFreshIds, docToNode, nodeToDoc };
+import '../document/content-tree.js';

package/dist/screen/lib/puck/section-doc.js

@@ -1 +1 @@
-export{cloneNodeWithFreshIds,docToNode,nodeToDoc}from"../../../chunk-2GVCAIPX.js";import"../../../chunk-PLVEGYK6.js";
+export{cloneNodeWithFreshIds,docToNode,nodeToDoc}from"../../../chunk-BDSLF5BR.js";import"../../../chunk-TCAAOYQY.js";

package/dist/screen/lib/puck/slot-child-name.d.ts

@@ -1,225 +1 @@
-/**
- * What a slot child is CALLED — the ONE rule, and the only place it is written
- * (card 66194).
- *
- * A slot-backed section (Hero Slideshow, Collections, Product Grid, Customer
- * Photo Grid, Gallery) keeps its children on its own props, and three surfaces
- * have to put a word on each of them: the page editor's Sections tree
- * (`ScreenChrome`), the standalone section editor's tree
- * (`SectionScreenShell`) — which also feeds the list drawn inside the section's
- * own settings panel through `SlotChildActionsContext` — and `CollectionCard`'s
- * own render, which puts the SAME word on the published card.
- *
- * Before this card the rule was written out three times. Card 66186 wrote the
- * second copy, card 66190 had to edit both to add the Collection Card step and
- * discovered the third while doing it. Three copies of a five-rung precedence is
- * a rule that looks right until the day two of them disagree — and a merchant
- * would meet that as a tree row and a card that name the same thing differently.
- *
- * ── THE PRECEDENCE, most specific first ──────────────────────────────────────
- *   1. `props.name`       an explicit identifier the author typed (Hero Slide's
- *                         "Slide name", Gallery Item's "Heading").
- *   2. `props.altName`    a card-local override of the name below it
- *                         (Collection Card's "Alt name").
- *   3. `props.collection` the LINKED category's snapshot name — the source the
- *                         override above overrides.
- *   3b. `props.source`    the LINKED post's snapshot headline (Post card). The
- *                         SAME rung as `collection` and deliberately beside it:
- *                         both are "the thing this block is linked to, named by
- *                         its own snapshot", and both are overridable by the two
- *                         rungs above. A Post card is the first slot child that
- *                         links to a post — Featured cover and Long read link to
- *                         one too, but they are top-level sections and never
- *                         reach this rule — so without it four cards in a Box
- *                         all read "Post card" and a merchant cannot tell which
- *                         one they are dragging.
- *   4. `props.code`       a catalog slug (Product Ref stores only this), resolved
- *                         through `wheelName` when a caller supplies one.
- *   5. the caller's own fallback — see {@link slotChildRowName}.
- *
- * `name` and `altName` may be hidable values (`{text,hidden}`) rather than bare
- * strings, so both read through `hidableText`: an object reaching a tree row
- * crashes it ("Objects are not valid as a React child").
- *
- * Rungs 1–3 are authored copy and may carry the shop's editorial marks. A TREE
- * ROW unwraps them ({@link slotChildRowName}); the published card does not, and
- * must not — that rung's own comment carries the reasoning (card 66202). How a
- * mark is unwrapped is the grammar's, so the row is handed the function that
- * does it, as it is handed the catalog: this module goes into efficient-easel
- * with the screen (doc/adr/0004), and the grammar is the layer's.
- *
- * ── WHY THE CATALOG RESOLVER IS AN ARGUMENT ──────────────────────────────────
- * The two trees genuinely differ at rung 4, and always have: the page editor has
- * the product catalog loaded and shows a Product Ref as "Turbine II", while the
- * standalone shell has no catalog and shows the raw slug `turbine-ii`. That
- * asymmetry shipped with card 66186 and is real behaviour, NOT a defect this
- * module quietly repairs. Taking the resolver as a parameter makes it an
- * explicit argument instead of an accident: the shell passes none, so it shows
- * the slug, and a reader sees that on the call line rather than discovering it.
- * (Same reasoning as `content-tree.ts`, which takes the config as an argument
- * rather than importing it.)
- *
- * `scripts/test-slot-child-name.tsx` pins the behaviour — the precedence, the
- * resolver contract, and that every existing row name is unchanged.
- * `scripts/test-slot-child-lists.tsx` §5 pins that this stays the ONE home.
- */
-/**
- * A Puck content node as this rule reads it. Deliberately looser than
- * `TreeItem` (no required `id`): `CollectionCard.render` names itself from the
- * props it was handed, and never has a node in hand.
- */
-type SlotChild = {
-    type: string;
-    props: Record<string, unknown>;
-};
-/**
- * The name a slot child carries in its OWN data — rungs 1–4 above — or `""` when
- * it carries none.
- *
- * `wheelName` resolves a `props.code` catalog slug to a wheel's design name; a
- * caller with no catalog omits it and the slug stands.
- *
- * Callers that need a word for an unnamed child add their own last rung; they do
- * not agree on what it should be, which is exactly why it is not in here. The
- * two trees fall back to the component's label ({@link slotChildRowName}), while
- * `CollectionCard.render` falls back to an editor-only placeholder — an unlinked
- * card must not publish the words "Collection Card".
- */
-declare function slotChildName(child: SlotChild, wheelName?: (code: string) => string | undefined): string;
-/**
- * The full five-rung rule as a TREE ROW reads it: {@link slotChildName} with its
- * markup unwrapped, else the component's friendly label. `compLabel` is the
- * host's own config-backed lookup (`config.components[type].label ?? type`) —
- * passed in, because this module has no config and importing one would make the
- * editor's naming rule a dependency of the config that describes it.
- *
- * `plainText` unwraps the markup: the plain words of authored copy in the
- * layer's grammar, which the screen holds as `ScreenBlockLook.plainText`
- * (lib/screen-parts). The website's is lib/markup `stripMarkup`. Passed in for
- * the reason `compLabel` is: the grammar is the layer's, and an email's is not
- * a website's.
- *
- * ── WHY THE STRIP IS HERE AND NOT ONE RUNG DOWN (card 66202) ─────────────────
- * A slot child's name is AUTHORED COPY. Rungs 1–3 are boxes a merchant types
- * into, so they may carry any mark in the shop's grammar, and a tree row printed
- * them verbatim: `Precision== Forged==` in a list that is plain text end to end.
- * It reads as broken, and it is expensive — `.sf-subtree` costs 25px a nesting
- * level, so a depth-2 row has roughly 172px of a 288px panel to spell a name in
- * and truncates. Four delimiters come out of that budget before a word does.
- *
- * `slotChildName` deliberately does NOT strip, and that asymmetry is the whole
- * point of putting this on the row rung instead. Its third caller is
- * `CollectionCard.render`, which puts the word on a customer's LIVE page, where
- * `<CollectionCard/>` routes `name` through `renderHeadline` — so `==phrase==`
- * there is the merchant's accent colour, not noise. Stripping one rung lower
- * would have flattened it on every published card that uses one. A tree row is
- * the surface that cannot draw a mark; it is the surface that drops it.
- *
- * Through the grammar's own stripper (the website's `stripMarkup`), never by
- * deleting delimiter characters: that unwraps a PAIR and leaves a lone
- * delimiter exactly where the renderer leaves it, so a half-typed name — which
- * is what mid-edit data actually looks like — keeps its whole line. It also
- * means a mark the grammar grows is handled here with no edit, because this
- * file names no delimiter of its own.
- *
- * The fallback still fires only for a genuinely nameless child: the grammar
- * needs at least one character between a pair, so a name that is non-empty
- * cannot strip to nothing and be renamed into its component's label.
- */
-declare function slotChildRowName<N extends SlotChild>(child: N, compLabel: (type: string) => string, plainText: (copy: string) => string, wheelName?: (code: string) => string | undefined, rowName?: RowNameRule<N>): string;
-/**
- * THE LAYER'S LAST WORD (0.103.0) — `ScreenBlockLook.rowName`
- * (lib/screen-parts), the rung a layer may stand above the whole precedence:
- * handed the node, the level it is named at and what the rule here answered,
- * it answers the row's name. The campaign designer names its rows by its own
- * labels, and needs none of the website's rungs.
- *
- * An argument and not a rung written here, for the reason the grammar and the
- * catalog are: this module has no layer. Absent, the rule here is the name, as
- * it was before the member existed.
- */
-type RowNameRule<N extends SlotChild = SlotChild> = (node: N, level: "section" | "block", fallback: string) => string;
-/**
- * WHICH PROP A RENAME WRITES — the write side of the rule above, and here for
- * the reason the read side is: naming a slot child has ONE home (card 66194).
- * A rename that picked its own prop would be a sixth opinion about what a child
- * is called, and the day it disagreed a merchant would rename a row and watch
- * the row not change.
- *
- * Returns the prop key, or `null` when this component has no name to write —
- * and a `null` is what takes `Rename` out of the menu, rather than a menu item
- * that does nothing.
- *
- * ── ONLY A DECLARED IDENTIFIER, AND THIS IS THE WHOLE TRAP ───────────────────
- * `GalleryItem.name` is keyed `name`, it IS what its Layers row says, and it is
- * an ordinary `Heading` a merchant writes — copy, printed on the page. A rename
- * keyed on the prop NAME would quietly rewrite that heading from a menu item
- * called "Rename". So the field must DECLARE itself an identifier
- * (`withIdentifier`, see `lib/puck/controls`), which is the same declaration the
- * settings panel reads to keep these rows out of the copy list.
- *
- * `fields` is taken as an argument rather than imported, exactly like the
- * `wheelName` resolver above: this module has no config, and importing one would
- * make the editor's naming rule a dependency of the config that describes it.
- *
- * The order matches {@link slotChildName}'s precedence, so the prop a rename
- * writes is the prop the row then reads. `altName` before `name` cannot happen
- * in today's config — no component declares both — and the order is written out
- * anyway so the answer does not depend on that staying true.
- */
-declare function slotChildRenameProp(fields: Record<string, unknown> | undefined): "name" | "altName" | null;
-/**
- * WHICH PROP A SECTION'S RENAME WRITES (0.105.0) — the write side of
- * {@link rootRowName} below, as {@link slotChildRenameProp} is the write side of
- * a slot child's name, and here for the same reason: one home for what a node
- * is called.
- *
- * Owner ruling R11 (Victor Mau, 2026-10-09): Rename works on top-level sections
- * in both editors. A section's row reads rung 1 and nothing below it — its own
- * `name`, else its type's label — so `name` is what a rename writes, and the row
- * then reads it back. Until the ruling a root node had no Rename at all: its row
- * was taken to say only its type, which stopped being true the day the row
- * started reading the `name` the presets seed ("Brand Text", a split's
- * "<Section> section"), and that name had no way to be changed.
- *
- * ── `name` IS WRITTEN UNLESS IT IS COPY — the slot child's trap, at the root ──
- * A section whose fields do not declare `name` carries it only as the editor's
- * label for it: the presets write it, the Layers row reads it, and no page draws
- * it. One that declares it an identifier (`withIdentifier`) is the same. But a
- * field keyed `name` that is ordinary copy — `GalleryItem.name` is a Heading
- * printed on the page — is not a name, and a menu item called "Rename" must not
- * rewrite it: null, and the section gets no Rename. No section of the website's
- * registry declares `name` at all today, so every one of them is renamed.
- */
-declare function sectionRenameProp(fields: Record<string, unknown> | undefined): "name" | null;
-/**
- * What a ROOT-level node is called in the trees — rung 1 of the same precedence
- * above, and nothing below it.
- *
- * A root node is not a slot child: it has no linked collection, no card-local
- * override and no catalog slug, so four of the five rungs have nothing to say
- * about it. What it CAN carry is rung 1 — an explicit name the author (or the
- * seeding) wrote — and before this function nothing at the root read it.
- *
- * ⚠️ THE DEFECT THAT PUT THIS HERE. `addSection` seeds a split pair as a Box
- * carrying `name: "<Section> section"`, and the comment beside that line says
- * the rename seam reads `name`. At the root both trees named a node by its TYPE
- * alone, and a Box's type name at section level is the literal "Blank section" —
- * so every pair a merchant added arrived in Layers as "Blank section", with the
- * stored name read by nobody. A value written and never read is the same defect
- * as a control that reaches nothing.
- *
- * It lives HERE, beside the rule it is a rung of, rather than in the chrome that
- * calls it: two files deciding what a node is called is exactly what card 66194
- * collapsed into this module, and a root rule written in the component would be
- * the fourth copy.
- *
- * `fallback` is the caller's type-level label (`sectionLabel(type)`), which is
- * what every published page reads today and what an unnamed node keeps reading.
- *
- * `rowName` is the layer's last word ({@link RowNameRule}), asked at the
- * SECTION level with what this rung answered.
- */
-declare function rootRowName<N extends SlotChild>(node: N, fallback: string, rowName?: RowNameRule<N>): string;
-
-export { type RowNameRule, type SlotChild, rootRowName, sectionRenameProp, slotChildName, slotChildRenameProp, slotChildRowName };
+export { RowNameRule, SlotChild, rootRowName, sectionRenameProp, slotChildName, slotChildRenameProp, slotChildRowName } from '../document/slot-child-name.js';

package/dist/screen/lib/puck/slot-child-name.js

@@ -1 +1 @@
-export{rootRowName,sectionRenameProp,slotChildName,slotChildRenameProp,slotChildRowName}from"../../../chunk-BHRC3ASL.js";import"../../../chunk-6W7WLPZH.js";import"../../../chunk-DUVRZ456.js";
+export{rootRowName,sectionRenameProp,slotChildName,slotChildRenameProp,slotChildRowName}from"../../../chunk-SSRYU3YG.js";import"../../../chunk-ANPOR6EY.js";import"../../../chunk-6UAEFOJ4.js";

package/dist/screen/lib/puck/slot-heal.d.ts

@@ -1,5 +1,2 @@
-import { TreeItem } from './content-tree.js';
-
-declare function dedupeSlotChildren(item: TreeItem, slots: string[]): TreeItem["props"] | null;
-
-export { dedupeSlotChildren };
+export { dedupeSlotChildren } from '../document/slot-heal.js';
+import '../document/content-tree.js';

package/dist/screen/lib/puck/slot-heal.js

@@ -1 +1 @@
-export{dedupeSlotChildren}from"../../../chunk-26OOWIJJ.js";
+export{dedupeSlotChildren}from"../../../chunk-7OCEPOEJ.js";