efficient-easel 20.2.1 → 21.1.0

package/dist/screen/index.js

@@ -1 +1 @@
-import"../chunk-GZO72N3Q.js";export{DocumentScreen,ScreenMount}from"../chunk-7YVEYQDE.js";import"../chunk-GXQCZJOP.js";import"../chunk-XJ2WXGFJ.js";import"../chunk-2GVCAIPX.js";import"../chunk-26OOWIJJ.js";import"../chunk-JBOSEHIX.js";import"../chunk-FGNR22NY.js";import"../chunk-LER7RKTO.js";import"../chunk-FGYJ5DJY.js";import"../chunk-7F52SZOI.js";import"../chunk-MQNBD6AB.js";import"../chunk-TNGOL65V.js";import"../chunk-I7BROL77.js";import"../chunk-KCBEE2MC.js";import"../chunk-C56MPJBH.js";import"../chunk-MEHLY5Q4.js";import"../chunk-WEIE2FBC.js";import"../chunk-PY7OOQEZ.js";import"../chunk-RKTF5XLP.js";export{ScreenStoreProvider}from"../chunk-JQXD3TDE.js";import"../chunk-5545A3PC.js";import"../chunk-R5KEFI55.js";import"../chunk-PA3PNTVV.js";import"../chunk-5ZBY24K7.js";import"../chunk-BVN33R76.js";import"../chunk-43AEUUNQ.js";import"../chunk-SINAM2IT.js";import"../chunk-UMDQ6CLQ.js";import"../chunk-M2Z775ZC.js";export{SELECTION_MODE,ScreenCanvasTargetProvider,ScreenPartsProvider,isPinnedFirst,isPinnedLast,isSlotMode,sameInspectorMode,screenSlotsOf,useScreenBlockLook,useScreenBlockRules,useScreenBridges,useScreenCanvasDrag,useScreenCanvasFrame,useScreenCanvasHead,useScreenCanvasTarget,useScreenDevices,useScreenDocumentLabel,useScreenDocumentPass,useScreenInspectorPanel,useScreenLeftView,useScreenNodeKeys,useScreenNotify,useScreenOwnerName,useScreenParts,useScreenPickFollowsSelection,useScreenPinned,useScreenSaveSwitch,useScreenStorageNamespace,useScreenStyleClipboard,useStandaloneScreenBridges}from"../chunk-PAOZMXEI.js";import"../chunk-2G6MAXPY.js";import"../chunk-6FWAE2RN.js";import"../chunk-UJ46J7QW.js";import"../chunk-276MBG5P.js";import"../chunk-77IWWW6X.js";import"../chunk-ERR437B5.js";import"../chunk-UNVKPVZW.js";import"../chunk-GMCZXMOV.js";export{NO_DOCUMENT_ADDRESSING}from"../chunk-RLBXE4EU.js";import"../chunk-HNKB2ZYR.js";import"../chunk-CLOS6SSX.js";import"../chunk-U66YKDAR.js";import"../chunk-LOMEH6DG.js";import"../chunk-KCOBHPN6.js";import"../chunk-FHCKFOCD.js";export{EaselSessionProvider,useEaselSession}from"../chunk-O7Q4DDJT.js";export{EFFICIENT_BACKEND,activateEaselSession,backendOf,createEaselSession,currentEaselSession,deactivateEaselSession,efficientClientOpen,isEfficientBackend,provideDefaultBackend,resetAmbientEaselSession,sessionRegistry,setSessionBridgedSite,setSessionDocumentSite}from"../chunk-RSCMJIWS.js";export{DETACHED_EASEL_HOST,EaselHostContext,EaselHostProvider,createEaselHost,useEaselHost,useHostEscape}from"../chunk-MQA7OFRA.js";import"../chunk-XFYFKITX.js";import"../chunk-23DYNW6S.js";import"../chunk-V7U33NF2.js";import"../chunk-6WY6ZXJG.js";import"../chunk-EFHV56BO.js";import"../chunk-TBY3DFKS.js";import"../chunk-7LYKFL3Q.js";import"../chunk-BPXEFVSQ.js";import"../chunk-A6Z4SD3I.js";import"../chunk-K56YDHYQ.js";import"../chunk-ZEH6QLBH.js";import"../chunk-IWCKVZHS.js";import"../chunk-ZKY45F5G.js";import"../chunk-FIVU2COQ.js";import"../chunk-RC25EGHD.js";import"../chunk-KFV7N2DJ.js";import"../chunk-P5VYGWYO.js";import"../chunk-WK3AFPXY.js";import"../chunk-BSHIQIZC.js";import"../chunk-NDRZP6YR.js";import"../chunk-H6DDIBQ4.js";import"../chunk-23VM4PMV.js";import"../chunk-KRL3IUV3.js";import"../chunk-ZOBSIXRD.js";import"../chunk-QAJAEWCZ.js";import"../chunk-WRFD4EXD.js";import"../chunk-VANKQVOW.js";import"../chunk-ZG6PVMC3.js";import"../chunk-MJM6SFD3.js";import"../chunk-AJSDWWJW.js";import"../chunk-2OAZYSWJ.js";import"../chunk-THWO5YVZ.js";import"../chunk-RE4LP46F.js";import"../chunk-MFIRYGHW.js";import"../chunk-LQV5FZTQ.js";import"../chunk-KAML3KQH.js";import"../chunk-3S5N4HLJ.js";import"../chunk-P2VEMZH5.js";import"../chunk-K7BTCBWD.js";import"../chunk-L55YIXDC.js";import"../chunk-QIDRJH3S.js";import"../chunk-BSPCSC45.js";import"../chunk-I54UCYOU.js";import"../chunk-GOTN2KY4.js";import"../chunk-R5L2E7JX.js";import"../chunk-BHRC3ASL.js";import"../chunk-6W7WLPZH.js";import"../chunk-IQ5TA7AM.js";import"../chunk-DUVRZ456.js";import"../chunk-IYT6NN2J.js";import"../chunk-PLVEGYK6.js";import"../chunk-LF3FUSCQ.js";
+import"../chunk-GZO72N3Q.js";export{DocumentScreen,ScreenMount}from"../chunk-I67UW5UG.js";import"../chunk-GXQCZJOP.js";import"../chunk-YVFYWAYU.js";import"../chunk-BDSLF5BR.js";import"../chunk-7OCEPOEJ.js";import"../chunk-SWBADIQT.js";import"../chunk-U5DNBT63.js";import"../chunk-5XL2RXFU.js";import"../chunk-KWLHKKZO.js";import"../chunk-INRERJU4.js";import"../chunk-3QB2ZQXK.js";import"../chunk-DDH2DYQP.js";import"../chunk-DNQ7AF6K.js";import"../chunk-KCBEE2MC.js";import"../chunk-C56MPJBH.js";import"../chunk-67HCYOW4.js";import"../chunk-MLQKNED6.js";import"../chunk-PY7OOQEZ.js";import"../chunk-RKTF5XLP.js";export{ScreenStoreProvider}from"../chunk-GWYNMSIP.js";import"../chunk-5545A3PC.js";import"../chunk-2C7W64S5.js";import"../chunk-VKPOH6MK.js";import"../chunk-CPL43ZLJ.js";import"../chunk-N7E6264U.js";import"../chunk-N3MJOHAG.js";import"../chunk-SINAM2IT.js";import"../chunk-UMDQ6CLQ.js";import"../chunk-RUQOIQWI.js";export{SELECTION_MODE,ScreenCanvasTargetProvider,ScreenPartsProvider,isPinnedFirst,isPinnedLast,isSelectionMode,isSlotMode,sameInspectorMode,screenSlotsOf,useScreenBlockLook,useScreenBlockRules,useScreenBridges,useScreenCanvasDrag,useScreenCanvasFrame,useScreenCanvasHead,useScreenCanvasTarget,useScreenDevices,useScreenDocumentLabel,useScreenDocumentPass,useScreenInspectorPanel,useScreenLeftView,useScreenNodeKeys,useScreenNotify,useScreenOwnerName,useScreenParts,useScreenPickFollowsSelection,useScreenPinned,useScreenSaveSwitch,useScreenStorageNamespace,useScreenStyleClipboard,useStandaloneScreenBridges}from"../chunk-OHZHYROJ.js";import"../chunk-PRHBWA5V.js";import"../chunk-2G6MAXPY.js";import"../chunk-2L6KWUBC.js";import"../chunk-ZOSEBPAI.js";import"../chunk-BTDI7JAA.js";import"../chunk-77IWWW6X.js";import"../chunk-ERR437B5.js";import"../chunk-UNVKPVZW.js";import"../chunk-GMCZXMOV.js";export{NO_DOCUMENT_ADDRESSING}from"../chunk-RLBXE4EU.js";import"../chunk-HNKB2ZYR.js";import"../chunk-CLOS6SSX.js";import"../chunk-BIK3AO2V.js";import"../chunk-LOMEH6DG.js";import"../chunk-KCOBHPN6.js";import"../chunk-FHCKFOCD.js";export{EaselSessionProvider,useEaselSession}from"../chunk-YM4UEGBV.js";export{EFFICIENT_BACKEND,activateEaselSession,backendOf,createEaselSession,currentEaselSession,deactivateEaselSession,efficientClientOpen,isEfficientBackend,provideDefaultBackend,resetAmbientEaselSession,sessionRegistry,setSessionBridgedSite,setSessionDocumentSite}from"../chunk-SNF5764Q.js";export{DETACHED_EASEL_HOST,EaselHostContext,EaselHostProvider,createEaselHost,useEaselHost,useHostEscape}from"../chunk-MQA7OFRA.js";import"../chunk-XFYFKITX.js";import"../chunk-EB6NI2VK.js";import"../chunk-V7U33NF2.js";import"../chunk-6WY6ZXJG.js";import"../chunk-SSRYU3YG.js";import"../chunk-AJ2SUSET.js";import"../chunk-ANPOR6EY.js";import"../chunk-6UAEFOJ4.js";import"../chunk-R4AUZVA3.js";import"../chunk-TCAAOYQY.js";import"../chunk-TUXLORVR.js";import"../chunk-TBY3DFKS.js";import"../chunk-PFFH7ASD.js";import"../chunk-BPXEFVSQ.js";import"../chunk-ZEH6QLBH.js";import"../chunk-FM6JO4WF.js";import"../chunk-KFV7N2DJ.js";import"../chunk-WHS6Y55E.js";import"../chunk-K56YDHYQ.js";import"../chunk-IWCKVZHS.js";import"../chunk-ZKY45F5G.js";import"../chunk-FIVU2COQ.js";import"../chunk-P5VYGWYO.js";import"../chunk-WK3AFPXY.js";import"../chunk-BSHIQIZC.js";import"../chunk-NDRZP6YR.js";import"../chunk-H6DDIBQ4.js";import"../chunk-ZG6PVMC3.js";import"../chunk-MJM6SFD3.js";import"../chunk-AJSDWWJW.js";import"../chunk-2OAZYSWJ.js";import"../chunk-THWO5YVZ.js";import"../chunk-RE4LP46F.js";import"../chunk-MZ5GSSZ3.js";import"../chunk-KRL3IUV3.js";import"../chunk-Y2T3JX7K.js";import"../chunk-KFWNGPW3.js";import"../chunk-S3DUFDQ6.js";import"../chunk-JACEEVVF.js";import"../chunk-MFIRYGHW.js";import"../chunk-WJJ7H42G.js";import"../chunk-TQ5Y6S2X.js";import"../chunk-3S5N4HLJ.js";import"../chunk-P2VEMZH5.js";import"../chunk-4FD7TAOE.js";import"../chunk-LF3FUSCQ.js";import"../chunk-K7BTCBWD.js";import"../chunk-L55YIXDC.js";import"../chunk-BSPCSC45.js";import"../chunk-467WWV4I.js";import"../chunk-TIAWIOGD.js";import"../chunk-MGVI67QV.js";

package/dist/screen/lib/admin-bridge.d.ts

@@ -14,7 +14,7 @@ import 'efficient-shell/ui';
 import './document-contract.js';
 import './document-hooks.js';
 import './section-template-types.js';
-import './puck/content-tree.js';
+import './document/content-tree.js';
 import './shared-section-types.js';
 
 /** The `storefront-editor:auth` payload the admin portal bridges in. */

package/dist/screen/lib/admin-bridge.js

@@ -1 +1 @@
-export{NO_BRIDGED_CAPABILITIES,applyAuthGrant,useAdminBridge}from"../../chunk-U66YKDAR.js";import"../../chunk-LOMEH6DG.js";import"../../chunk-O7Q4DDJT.js";import"../../chunk-RSCMJIWS.js";import"../../chunk-MQA7OFRA.js";
+export{NO_BRIDGED_CAPABILITIES,applyAuthGrant,useAdminBridge}from"../../chunk-BIK3AO2V.js";import"../../chunk-LOMEH6DG.js";import"../../chunk-YM4UEGBV.js";import"../../chunk-SNF5764Q.js";import"../../chunk-MQA7OFRA.js";

package/dist/screen/lib/content/view-tiers.d.ts

@@ -25,7 +25,7 @@ declare function viewTierForWidth(width: number): ViewTier;
  *  Derived, so the pair can never be spelled two ways. */
 declare function tabletKey(desktopKey: string): string;
 /** The key a PHONE value is stored under: `paddingTop` → `paddingTopPhone`.
- *  The same key web-builder's `lib/puck/phone-override` stores today, so every
+ *  The same key web-builder's `lib/document/phone-override` stores today, so every
  *  stored phone value keeps its meaning; that copy goes once web-builder reads
  *  this one. */
 declare function phoneKey(desktopKey: string): string;
@@ -85,6 +85,16 @@ interface AutoRule {
  * Example: padding 80 → 60 → 40; 120 → 88 → 60; gap 32 → 24 → 16.
  */
 declare const AUTO_RULES: Record<ViewValueKind, AutoRule>;
+/**
+ * The rules a page drew by before the auto rules (web-builder's rule version
+ * "v1"): an empty view takes its parent's value UNCHANGED, for every kind.
+ * Tablet = Desktop, Phone = Tablet. With no Tablet values stored, that is
+ * exactly what every page draws today (an empty phone value follows the
+ * desktop one). The switch to {@link AUTO_RULES} is web-builder's, made once
+ * for every site (Lewis 2026-10-23); both tables are here so the rules are
+ * spelled once.
+ */
+declare const FOLLOW_RULES: Record<ViewValueKind, AutoRule>;
 /** What each view draws. */
 interface ViewValues<T> {
     desktop: T;
@@ -96,10 +106,12 @@ interface ViewValues<T> {
  * through `AUTO_RULES[kind]`. Phone's parent is Tablet (stored or auto);
  * Tablet's parent is Desktop. A desktop value nobody set stays unset in every
  * auto view, so the host's default applies there as it does on Desktop.
+ * `rules` is the rule set the page draws by: {@link AUTO_RULES} (the default)
+ * or {@link FOLLOW_RULES}.
  *
  * DISPLAY ONLY: never store what this returns for an auto view — that turns
  * auto into a copy that stops following its parent.
  */
-declare function resolveViewValue<T>(kind: ViewValueKind, desktop: T, tablet?: T | null, phone?: T | null): ViewValues<T>;
+declare function resolveViewValue<T>(kind: ViewValueKind, desktop: T, tablet?: T | null, phone?: T | null, rules?: Record<ViewValueKind, AutoRule>): ViewValues<T>;
 
-export { AUTO_RULES, type AutoRule, VIEW_DESKTOP_MIN, VIEW_TABLET_MIN, VIEW_TIERS, VIEW_TIER_LABEL, type ViewTier, type ViewValueKind, type ViewValues, isAuto, phoneKey, resolveViewValue, tabletKey, viewTierForWidth };
+export { AUTO_RULES, type AutoRule, FOLLOW_RULES, VIEW_DESKTOP_MIN, VIEW_TABLET_MIN, VIEW_TIERS, VIEW_TIER_LABEL, type ViewTier, type ViewValueKind, type ViewValues, isAuto, phoneKey, resolveViewValue, tabletKey, viewTierForWidth };

package/dist/screen/lib/content/view-tiers.js

@@ -1 +1 @@
-export{AUTO_RULES,VIEW_DESKTOP_MIN,VIEW_TABLET_MIN,VIEW_TIERS,VIEW_TIER_LABEL,isAuto,phoneKey,resolveViewValue,tabletKey,viewTierForWidth}from"../../../chunk-HK6I3NVO.js";
+export{AUTO_RULES,FOLLOW_RULES,VIEW_DESKTOP_MIN,VIEW_TABLET_MIN,VIEW_TIERS,VIEW_TIER_LABEL,isAuto,phoneKey,resolveViewValue,tabletKey,viewTierForWidth}from"../../../chunk-E52W3M5I.js";

package/dist/screen/lib/document/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/document/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/document/add-target-types.js

@@ -0,0 +1 @@
+import"../../../chunk-YIUE4US7.js";

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

@@ -0,0 +1,64 @@
+/**
+ * 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/document/container-blocks.ts`, which is the only assembler that sets one.
+ */
+type BlockChoice = {
+    type: string;
+    label: string;
+    group?: string;
+    /**
+     * RETIRED: Add does not offer it, and a node of it already in a slot still
+     * belongs there (card [MERGE] One Text Block And Click Through Parts). The
+     * website's Heading and Eyebrow blocks: the Text block took their job, so
+     * nobody starts a new one, and every stored one still draws, edits, moves
+     * and pastes. Read through {@link offeredChoices} wherever a list is shown
+     * to ADD from; the whole list is still the slot's answer to "does this slot
+     * take it?", so a move or a paste reads it unfiltered.
+     */
+    retired?: boolean;
+};
+/** The choices Add offers: every one that is not {@link BlockChoice.retired}, in order. */
+declare function offeredChoices<C extends BlockChoice>(choices: readonly C[]): C[];
+/**
+ * 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/document/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/document/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, offeredChoices };

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

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

package/dist/screen/lib/document/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/document/block-types-in.js

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

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

@@ -0,0 +1,222 @@
+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[];
+/**
+ * What a component type's config ALLOWS of the two actions that make another
+ * node or take one away (0.103.0): its `permissions.duplicate` and
+ * `permissions.delete`, each true unless the config says false — the reading
+ * Puck gave a config that carried none. The campaign designer's Product keeps
+ * its Price line this way (`{ delete: false, duplicate: false }`).
+ *
+ * The screen's tree rows, its menu and the inspector head it hands this to
+ * (`ScreenInspectorPanelProps.nodeActions`) all ask HERE, so the three cannot
+ * come to disagree about one block. Only the config's own, never the
+ * easel-wide permissions the edit lock sets: a document somebody else holds is
+ * refused at the writes, as it always was, and draws the rows it drew.
+ *
+ * A type the config does not know allows both, as one with no `permissions`.
+ */
+declare function blockNodeActions(config: SlotConfigView, type: string): {
+    duplicate: boolean;
+    delete: boolean;
+};
+/**
+ * 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[];
+/**
+ * The children of ONE slot of `item`, addressed as {@link childSlotsOf}
+ * addresses them (0.105.0): what the Layers tree draws under a slot it draws
+ * as a row of its own (`ScreenBlockRules.slotsOf`). A slot the node holds
+ * nothing in, or no array in, has none.
+ */
+declare function slotChildrenIn(item: TreeItem, slot: string): 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, blockNodeActions, childSlotsOf, locateNode, missingPinnedTypes, nestsInTree, newNodeId, pinnedDuplicateIds, pinnedDuplicateIndices, slotChildrenIn, slotFieldsOf };

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

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

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

@@ -0,0 +1,128 @@
+import { ReactElement } from 'react';
+import { PreviewDevice } from '../../components/PreviewDeviceContext.js';
+import '../content/view-tiers.js';
+
+/**
+ * lib/document/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 this package's `screen.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 this package's `screen.css`, which
+ *  every host that mounts the screen loads (it sat in the website's sheet until
+ *  0.103.0, so a second host's hidden rows kept their space). */
+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/document/device-fields.js

@@ -0,0 +1 @@
+export{DEVICE_FIELD_MARKER,DEVICE_HIDDEN_ATTR,DEVICE_NOTE,deviceField,deviceMetaOf,deviceNote,shownTier,withoutDeviceGate}from"../../../chunk-KWLHKKZO.js";import"../../../chunk-INRERJU4.js";import"../../../chunk-EB6NI2VK.js";import"../../../chunk-MFIRYGHW.js";import"../../../chunk-BSPCSC45.js";