efficient-easel 0.101.0 → 0.102.0

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

@@ -0,0 +1,72 @@
+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 };

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

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

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

@@ -0,0 +1,20 @@
+import { Data } from '../../../blocks/index.js';
+import { TreeItem } from './content-tree.js';
+import 'react';
+import '../../../types-E3HrTPg2.js';
+import '../../../data/index.js';
+import '../../../types-41704JE4.js';
+import '../../../resolve-D68pb3Bx.js';
+import '../../../plan-DChbUXdS.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).
+ */
+declare function cloneNodeWithFreshIds(node: TreeItem): TreeItem;
+
+export { cloneNodeWithFreshIds, docToNode, nodeToDoc };

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

@@ -0,0 +1 @@
+export{cloneNodeWithFreshIds,docToNode,nodeToDoc}from"../../../chunk-AKFJK65Z.js";import"../../../chunk-FUDHI5I4.js";

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

@@ -0,0 +1,186 @@
+/**
+ * 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(child: SlotChild, compLabel: (type: string) => string, plainText: (copy: string) => string, wheelName?: (code: string) => string | undefined): 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;
+/**
+ * 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.
+ */
+declare function rootRowName(node: SlotChild, fallback: string): string;
+
+export { type SlotChild, rootRowName, slotChildName, slotChildRenameProp, slotChildRowName };

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

@@ -0,0 +1 @@
+export{rootRowName,slotChildName,slotChildRenameProp,slotChildRowName}from"../../../chunk-HWW4XJOH.js";import"../../../chunk-DUVRZ456.js";import"../../../chunk-6W7WLPZH.js";

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

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

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

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

package/dist/screen/lib/puck/slot-section-spec.d.ts

@@ -0,0 +1,96 @@
+/**
+ * A component type's own `defaultProps`, looked up in the Puck config.
+ *
+ * Handed IN rather than imported: `lib/puck/config` imports the seed
+ * registry's neighbours, and a seed registry that reached back into the config
+ * would close the loop. Both callers of `seeds()` already hold the config
+ * (`components/ScreenChrome`, `components/StandaloneSectionEditor`),
+ * so the lookup travels the short way.
+ *
+ * ⚠️ IT IS OPTIONAL, AND THE FIVE SPECS THAT PREDATE IT IGNORE IT. They
+ * seed ONE flat child whose every field is content, so a missing default changes
+ * nothing they draw. Image & Text Columns seeds a Box holding blocks, and a Box
+ * without its `direction` / `justify` / `align` / `wrap` is a different shape on
+ * the page — see `boxColumnSeed` in lib/puck/slot-specs.
+ */
+type NodeDefaults = (type: string) => Record<string, unknown>;
+interface SlotSectionSpec {
+    /** The primary slot field on the section (e.g. Hero's `slides`). */
+    slot: string;
+    /** The child component type the slot holds. */
+    childType: string;
+    /** The "Add …" affordance label. */
+    addLabel: string;
+    /**
+     * The children ARE the section, and no surface offers to add one.
+     *
+     * ⚠️ NOT THE SAME THING AS `addBlocked`, AND THE DIFFERENCE IS WHY IT EXISTS.
+     * `addBlocked` is a reason adding is impossible RIGHT NOW — a hero anchor
+     * already holds four — so the row stays, greyed, with the sentence on it, and
+     * the merchant can act on it (re-place a group and Add comes back). A fixed
+     * set has no such state: the row would be permanently dead furniture, and
+     * `NodeContextMenu`'s own rule says it plainest — a row must never be a button
+     * that does nothing.
+     *
+     * Both surfaces that draw an Add row read this. `addBlocked` is still declared
+     * beside it, because the DROP path asks that one and never this.
+     */
+    fixed?: boolean;
+    /** Children render as a HORIZONTAL slider (selection must advance it). */
+    slider?: boolean;
+    /**
+     * Prop bags for the default children a fresh section is seeded with.
+     *
+     * `defaultsFor` is {@link NodeDefaults} — present when the caller holds the
+     * config, absent otherwise, and every spec that seeds a plain content child
+     * simply declines it.
+     */
+    seeds: (defaultsFor?: NodeDefaults) => Record<string, unknown>[];
+    /**
+     * Convert a section's LEGACY props (an older inline-array field) into slot
+     * children at load-time — the chrome-only migration for pages saved before the
+     * field became a slot. Returns [] when there's nothing to migrate, in which
+     * case the seeder falls back to `seeds()`.
+     */
+    legacy?: (props: Record<string, unknown>) => Record<string, unknown>[];
+    /**
+     * Why this section cannot take another child right now — a sentence the
+     * merchant reads — or `null` when it can (card 66189).
+     *
+     * Optional, and only the Hero slide answers it today: a group is placed on one
+     * of nine anchors, an anchor stacks at most four, and a fifth would be drawn
+     * ON TOP of the fourth. The rule lives on the SPEC rather than inside
+     * `SlotChildRows` because the list is shared by five sections and this is one
+     * section's arithmetic — the list asks, the spec answers.
+     */
+    addBlocked?: (children: readonly unknown[], incoming?: unknown) => string | null;
+    /**
+     * Why this section must NOT be seeded at all, read off its OWN stored props.
+     *
+     * The seeder's existing guard is "the slot already has children" — right for a
+     * section whose only shape is the slot, and blind to a section that still
+     * carries an OLDER one. Image & Text Columns is the first of those: its
+     * columns used to be a `steps` ARRAY, the owner ruled on 2026-09-05 that
+     * nothing is migrated, and a stored page therefore has a full `steps` and an
+     * empty `boxes`. Without this the seeder would drop three fresh Boxes into a
+     * published page that already draws three columns, and the merchant would find
+     * six.
+     *
+     * Deliberately a question about the PARENT'S props, not about the slot — the
+     * slot is what the existing guard already reads, and answering "is there an
+     * older shape here" from the same place is what makes this a second question
+     * rather than a second opinion on the first.
+     */
+    skipSeed?: (props: Record<string, unknown>) => boolean;
+    /**
+     * What the list says about the children it ALREADY holds, or `null`.
+     *
+     * The counterpart to `addBlocked`, and deliberately a second question rather
+     * than a second answer from the first: `addBlocked` is about a group that has
+     * not arrived yet, this is about the ones that are already here and cannot all
+     * be drawn. A section that cannot get into that state simply declares neither.
+     */
+    notice?: (children: readonly unknown[]) => string | null;
+}
+
+export type { NodeDefaults, SlotSectionSpec };

package/dist/screen/lib/puck/style-clipboard.d.ts

@@ -0,0 +1,78 @@
+import { StyleRow } from '../../../style-clipboard/index.js';
+import { panelFieldsOf } from './panel-fields.js';
+import '../../../types-Djdq6Xkd.js';
+import 'react';
+import '../../../words-CnnHb9jo.js';
+
+/**
+ * lib/puck/style-clipboard.ts — COPY STYLE / PASTE STYLE in the website editor
+ * (card [ADD] Copy Style And Paste Style, owner 2026-09-19).
+ *
+ * The clipboard, the matching rule, the menu rows, the words and the shortcut
+ * test are `efficient-easel/style-clipboard`'s — written once for both editors;
+ * the campaign designer draws the same two rows from the same module. This file
+ * answers only the two questions that are the website editor's own:
+ *
+ *   1. WHICH ROWS of a node are its look — {@link nodeStyleRows};
+ *   2. WHAT KIND each row is — {@link shopFieldKind}.
+ *
+ * ── WHICH ROWS ──────────────────────────────────────────────────────────────
+ * Owner's rule 3: the Style and Layout tabs, never Content. The panel after
+ * `assignSectionGroups` is a flat list in which each bucket header
+ * (`BUCKET_KEY`) opens its run — the same reading the tab strip hides rows by —
+ * so a row belongs to the header above it. Animation is not copied.
+ *
+ * Left out even on those tabs (the list GG approved on 2026-09-19):
+ *   · every picture (`__media`) — Media folded into Style on 2026-09-14, and a
+ *     picture is Content;
+ *   · words and links (`__text`, `__link`);
+ *   · headings, bucket headers and notes — `__fold`, and every `_`-key (the
+ *     panel's own furniture, as in the campaign designer) — which store nothing;
+ *   · the Anchor rows — a deep-link id must be unique on the page;
+ *   · slots (Boxes, children) — structure, not a look;
+ *   · a picture's focal point (`focal`, `imageFocal`) — a point ON ONE picture,
+ *     meaningless on another, like the campaign logo's colour map.
+ * A text part's own look (`partStyles`) is no row at all, so it is never read.
+ *
+ * ── THE PHONE VALUE ─────────────────────────────────────────────────────────
+ * Stored as its own row (`<key>Phone`, ./phone-override), on the same tab, so it
+ * travels like any row. It is not COUNTED: the merchant sees one row per
+ * device, and the number is the rows they see.
+ */
+
+type Props = Record<string, unknown>;
+type NodeLike = {
+    type: string;
+    props: Props;
+};
+type ConfigLike = Parameters<typeof panelFieldsOf>[0];
+/** The clipboard's scope: one site (GG, 2026-09-19) — across its pages. */
+declare function siteStyleScope(siteId: string | null | undefined): string;
+/**
+ * The kind of one website-editor row.
+ *
+ *   · a tag (a shared builder's `section:<key>`, ../controls `sharedStyleKinds`)
+ *     wins, on the gate or on the control it wraps;
+ *   · a CHOICE row (it declares `options`) is `choice:` plus its sorted values;
+ *   · anything else is the shell's reading, which answers `null` for an
+ *     untagged custom control: it pastes only onto the same section type.
+ */
+declare function shopFieldKind(field: unknown): string | null;
+/** A node's look, as rows the shell's clipboard can hold and match. */
+declare function nodeStyleRows(config: ConfigLike, node: NodeLike): StyleRow[];
+/** Copy one node's look into the site's clipboard. */
+declare function copyNodeStyle(config: ConfigLike, scope: string, node: NodeLike, label: string): void;
+/**
+ * What a paste onto this node would do: the new props, and the words the
+ * merchant reads. Null when nothing is held for this site. The caller writes
+ * `props` through its one replace op only when `changed`, and always shows
+ * `message` — "nothing matched" is an answer, not a silence.
+ */
+declare function planNodePaste(config: ConfigLike, scope: string, node: NodeLike, label: string): {
+    props: Props;
+    changed: boolean;
+    pasted: number;
+    message: string;
+} | null;
+
+export { copyNodeStyle, nodeStyleRows, planNodePaste, shopFieldKind, siteStyleScope };

package/dist/screen/lib/puck/style-clipboard.js

@@ -0,0 +1 @@
+export{copyNodeStyle,nodeStyleRows,planNodePaste,shopFieldKind,siteStyleScope}from"../../../chunk-PP44LCJM.js";import"../../../chunk-PWZOS45R.js";import"../../../chunk-7F52SZOI.js";import"../../../chunk-R2HLPNQF.js";import"../../../chunk-ZE7I3PLX.js";import"../../../chunk-DUVRZ456.js";import"../../../chunk-BSPCSC45.js";import"../../../chunk-57DJOKXT.js";import"../../../chunk-6WY6ZXJG.js";import"../../../chunk-L5KW4HG5.js";

package/dist/screen/lib/puck/text-control-kinds.d.ts

@@ -0,0 +1,71 @@
+/**
+ * text-control-kinds — the authored-text control kinds, and the ONE fact about
+ * each that three separate lists used to hold by hand (card 66286).
+ *
+ * A LEAF ON PURPOSE: it imports nothing. `lib/puck/controls` is nine hops deep in
+ * a require cycle back to `lib/puck/part-text`
+ * (controls → MediaUploadField → ScreenDocumentContext →
+ * catalog-default-layout → ProductGridSection → goldPhrases → PartStyledText →
+ * part-styles → part-rows → part-text), so a list defined in `controls` and read
+ * at another module's INIT time throws "Cannot access before initialization".
+ * The cycle never bit before because the values `part-text` takes from `controls`
+ * — `TEXT_FIELD_MARKER`, `readHidable` — are only read inside functions. A
+ * single source has to be readable at init, so it lives here, on its own, where
+ * nothing can be in flight ahead of it.
+ *
+ * `lib/puck/controls` re-exports every name below, because that is where the rest
+ * of the text-field vocabulary lives (`TEXT_FIELD_MARKER`, `TextFieldMeta`, the
+ * builders) and every existing caller already reads it from there. The
+ * definitions are here and only here.
+ */
+/**
+ * Every authored-text control kind, as recorded on `TEXT_FIELD_MARKER`
+ * (`lib/puck/controls`),
+ * and the one fact three separate lists used to hold by hand (card 66286):
+ * whether the kind's value is ONE string a merchant edits as a single box
+ * (`"scalar"`), or N of them a control adds, removes and reorders (`"list"`).
+ *
+ * ⚠️ THIS IS THE SOURCE. {@link TextControlKind} and {@link SCALAR_TEXT_CONTROLS}
+ * are both read off it, so a sixth kind cannot be added without answering the
+ * scalar/list question once, here, where the answer is. Until this card it was
+ * answered THREE times in three files, kept in step by a comment asking the next
+ * reader to remember: which parts get an entry row on the section screen
+ * (`ENTRY_CONTROLS`), which copy boxes move to the drill (`DRILL_TEXT_CONTROLS`),
+ * and which parts a caret may be opened in (`TYPE_IN_PLACE_KINDS`). All three
+ * were the same question and nothing went red when they disagreed — card 66282
+ * added `copyText` to one of them first and the drift surfaced afterwards as
+ * `1 unreachable: altName`.
+ *
+ * `control` also fixes the STORED VALUE SHAPE the neutralizer must preserve, so
+ * each kind names its own shape beside it.
+ */
+declare const TEXT_CONTROL_KINDS: {
+    readonly text: "scalar";
+    readonly textarea: "scalar";
+    readonly plainText: "scalar";
+    readonly copyText: "scalar";
+    readonly plainTextarea: "scalar";
+    readonly textList: "list";
+};
+/** The authored-text control kinds — the keys of {@link TEXT_CONTROL_KINDS}. */
+type TextControlKind = keyof typeof TEXT_CONTROL_KINDS;
+/** The kinds whose value is ONE string, as a type — so a caller may hold one of
+ *  those and not the list kind, which the compiler then keeps it to. */
+type ScalarTextControlKind = {
+    [K in TextControlKind]: (typeof TEXT_CONTROL_KINDS)[K] extends "scalar" ? K : never;
+}[TextControlKind];
+/**
+ * THE SCALAR CONTROLS, derived — one string each, so one box, so one row.
+ *
+ * The three lists this replaces all named exactly these and each stated the same
+ * reason for leaving `textList` out: its control manages ROW STRUCTURE (add,
+ * remove, reorder), which a per-row box cannot, so it keeps its place on the
+ * section screen. That reason is now the `"list"` beside it above, stated once.
+ *
+ * Order is declaration order, and the section screen's rows are built by walking
+ * a section's FIELDS rather than this list, so nothing merchant-facing reads it
+ * as an ordering.
+ */
+declare const SCALAR_TEXT_CONTROLS: readonly ScalarTextControlKind[];
+
+export { SCALAR_TEXT_CONTROLS, type ScalarTextControlKind, TEXT_CONTROL_KINDS, type TextControlKind };

package/dist/screen/lib/puck/text-control-kinds.js

@@ -0,0 +1 @@
+var a={text:"scalar",textarea:"scalar",plainText:"scalar",copyText:"scalar",plainTextarea:"scalar",textList:"list"},t=Object.entries(a).filter(([,a])=>"scalar"===a).map(([a])=>a);export{t as SCALAR_TEXT_CONTROLS,a as TEXT_CONTROL_KINDS};

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

@@ -0,0 +1,62 @@
+/** Puck's index-based address, as `use-section-ops` spells it (zone omitted at root). */
+type Selector = {
+    index: number;
+    zone?: string;
+} | null;
+/**
+ * Do these two addresses name the same node?
+ *
+ * `ops.select` omits the zone for a top-level node (Puck's reducer falls back to
+ * the root zone), while `getSelectorForId` always fills it in — so the two
+ * spellings of one top-level node differ, and the comparison has to normalise
+ * before it can answer. Exported for `scripts/test-tree-reveal.ts`.
+ */
+declare function sameSelector(a: Selector, b: Selector, rootZone: string): boolean;
+/**
+ * Bring the selected Layers row into view. Returns whether a row was found —
+ * false whenever the panel is collapsed or on another view, which is a no-op and
+ * not a failure. A row that is already fully visible is found and left alone:
+ * the return says "there is a row", not "the panel moved".
+ */
+declare function revealSelectedTreeRow(doc?: Document | undefined): boolean;
+/**
+ * Which node's Layers row is the MARKED one — the row that draws `is-selected`,
+ * and so the row {@link revealSelectedTreeRow} scrolls to.
+ *
+ * TWO SOURCES, ONE ANSWER. Normally it is the Puck selection. While a PART
+ * panel is open it is that part's OWNER, because `usePartBridge` deliberately
+ * leaves the Puck selection where it was — "the Layers tree, undo, redo and
+ * autosave therefore see nothing at all", which is that bridge's own cheapest
+ * proof that they still behave. The chrome asked `isPuckMode && selectedItem`
+ * instead, and `isPuckMode` is false in part mode, so opening a part put the
+ * mark out on EVERY row at once: a merchant who clicked a run of text in the
+ * canvas was left looking at a Layers list with nothing lit, which had also not
+ * moved (owner, 2026-09-09 — the "SHOP" tag on a Collections card). The bridge
+ * has returned `openPartId` for exactly this since card 66268 and no shell ever
+ * read it.
+ *
+ * EVERY OTHER OVERRIDE STILL ANSWERS `null` — Header, Website, Live chat and the
+ * ticker. Those panels are not about a node in this tree at all, and the rows
+ * that DO mark them (`inspectorMode.kind === "header"`, `tickerHeroId === secId`,
+ * …) read their own state, which is why widening this to them would light two
+ * rows for one panel.
+ *
+ * ⚠️ THE HERO'S `Text` / `Background` WERE ON THIS LIST AND ARE GONE
+ * ([ADD] The Hero Takes Boxes). They were two SYNTHETIC rows standing for the
+ * section's own copy and media; the owner put the background back in the hero's
+ * settings on 2026-09-09 and deleted the built-in copy, so both panels and both
+ * `…SectionId` derivations went with them. The example above named
+ * `heroTextSectionId`, a variable that no longer exists — corrected to the ticker
+ * rather than dropped, because the RULE it illustrates is unchanged and this is
+ * the only place that states it.
+ *
+ * The mode is taken structurally rather than as `InspectorMode`: that union
+ * lives in a component (SectionEditor) and this is `lib`, so a named import
+ * here would point the dependency the wrong way for one field.
+ */
+declare function markedTreeNodeId(mode: {
+    kind: string;
+    nodeId?: string;
+}, selectedId: string | null | undefined): string | null;
+
+export { markedTreeNodeId, revealSelectedTreeRow, sameSelector };

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

@@ -0,0 +1 @@
+export{markedTreeNodeId,revealSelectedTreeRow,sameSelector}from"../../../chunk-FGNR22NY.js";