/**
 * Frozen at v1. Hardcoded literal so repo edits to derivation logic can't
 * silently re-namespace existing tenants. The `__namespace_root_is_frozen`
 * test asserts this matches `uuidv5(DNS, "registry.sitecoreai.dev")`.
 */
export declare const NAMESPACE_ROOT = "d6c28e9f-21f3-56ee-ada3-f2a947c3d475";
export declare const NAMESPACE_TEMPLATE: string;
export declare const NAMESPACE_RENDERING: string;
export declare const NAMESPACE_PARTIAL_DESIGN: string;
export declare const NAMESPACE_PAGE_DESIGN: string;
export declare const NAMESPACE_SITE_BRANCH: string;
export declare const NAMESPACE_CONTENT_ITEM: string;
export declare const NAMESPACE_SITE: string;
export declare const NAMESPACE_ENUMERATION: string;
/** Internal: lets the test prove `NAMESPACE_ROOT` matches its derivation. */
export declare const _deriveNamespaceRoot: () => string;
export declare const templateId: (site: string, handle: string) => string;
export declare const renderingId: (site: string, handle: string) => string;
export declare const designParametersTemplateId: (site: string, handle: string) => string;
export declare const partialDesignId: (site: string, handle: string) => string;
export declare const pageDesignId: (site: string, handle: string) => string;
export declare const siteBranchId: (handle: string) => string;
export declare const contentItemId: (site: string, handle: string) => string;
/**
 * Page item identity — a `PageRecipe`'s concrete page in the site
 * content tree. Distinct namespace from `contentItemId`: a page is a
 * navigable item conforming to a page template, not a shared datasource
 * item, and `datasourceId(pageItemId(...), slot)` scopes page-local
 * datasources beneath it. Site-scoped seed like the rest of the family.
 */
export declare const NAMESPACE_PAGE: string;
export declare const pageItemId: (site: string, handle: string) => string;
/**
 * Recipe-internal refKey for a `SiteRecipe`'s site item. The actual
 * Sitecore site itemId is server-assigned by the Sites API at
 * `createSite` time; this refKey is the IR's identity for cross-op
 * resolution (dictionary phrases, taxonomy tags scoped under the site
 * inherit it).
 */
export declare const siteId: (handle: string) => string;
/**
 * Recipe-internal refKey for a dictionary phrase item under a site.
 * Two emission paths land on this identity:
 *
 *   1. `SiteRecipe.dictionaryOverrides` — overrides an existing
 *      `<site>/Dictionary/<phraseName>` item. The executor seeds the
 *      refKey via cross-recipe path lookup after
 *      `CreateSiteFromTemplate` materialises the site's content tree
 *      and any DictionaryRecipes have landed.
 *   2. `compileDictionaryRecipe` — emits a `CreateItem` for each
 *      phrase entry under the dictionary's folder, parented to
 *      `dictionaryFolderId(siteHandle, recipeName)`.
 *
 * Both produce the same uuidv5 so override SetFields and the original
 * CreateItem agree on identity even when authored from different
 * recipes.
 */
export declare const dictionaryPhraseId: (siteHandle: string, phraseName: string) => string;
/**
 * Recipe-internal refKey for a `DictionaryRecipe`'s top-level
 * Dictionary Folder item. Lands at `<site>/Dictionary/<recipeName>/`
 * — sibling of the per-phrase Entry items. Per-DictionaryRecipe
 * grouping means multiple dictionaries can target the same host site
 * without colliding (each lands under its own subfolder).
 */
export declare const dictionaryFolderId: (siteHandle: string, recipeName: string) => string;
/**
 * Recipe-internal refKey for a taxonomy folder (root) under a site.
 * Mirror of `dictionaryPhraseId` for the taxonomy tree — late-seeded
 * after the site materialises.
 */
export declare const taxonomyFolderId: (siteHandle: string, rootName: string) => string;
/**
 * Recipe-internal refKey for a taxonomy tag item under a site's
 * taxonomy folder. Used when a SiteRecipe override list adds tags
 * beyond the SiteTemplate defaults — those become CreateItem ops
 * parented to the late-seeded taxonomy folder refKey.
 */
export declare const taxonomyTagId: (siteHandle: string, rootName: string, tagName: string) => string;
/**
 * Stable refKey for the SXA Page Designs root item (the tenant-existing
 * item that holds the `TemplatesMapping` field). The orchestrator
 * pipeline-step seeds `crossRecipeRefs[<this>] = pageDesignsRoot` at
 * execute time so SetField ops targeting the mapping resolve correctly.
 *
 * Not a Sitecore concept — purely a refKey our IR uses to coordinate
 * with the executor's pre-seed mechanism.
 */
export declare const PAGE_DESIGNS_ROOT_REF_KEY: string;
/** Sections are scoped under their (site-scoped) template; seed `section:<name>`. */
export declare const sectionId: (site: string, handle: string, sectionName: string) => string;
/** Fields are scoped under their (site-scoped) template; the seed is the field name. */
export declare const fieldId: (site: string, handle: string, fieldName: string) => string;
/** Sections of the parameters template scope under (site-scoped) `designParametersTemplateId`. */
export declare const designParametersSectionId: (site: string, handle: string, sectionName: string) => string;
/** Fields of the parameters template scope under (site-scoped) `designParametersTemplateId`. */
export declare const designParameterFieldId: (site: string, handle: string, fieldName: string) => string;
/**
 * Per-rendering Headless Variants folder. Lives at
 * `<headlessVariantsRoot>/<section>/<RenderingName>/` and conforms to
 * SXA's `HeadlessVariants` template. The refKey seed is unchanged
 * from the legacy "under the rendering item" location (`__variants`
 * scoped to the rendering's id) so existing caches continue to
 * resolve — only the path/template changed.
 */
export declare const variantsFolderId: (site: string, handle: string) => string;
/**
 * Each Variant Definition item lives under the per-rendering
 * Headless Variants folder. Conforms to SXA's `Variant Definition`
 * template.
 */
export declare const variantId: (site: string, handle: string, variantName: string) => string;
/**
 * Standard values is a child of the template whose template-of is the
 * template's own ID. The GUID is derived from the (site-scoped) template
 * ID with the `__standard-values` seed.
 */
export declare const standardValuesId: (site: string, handle: string) => string;
/**
 * Standard values for a parameters template. Same `__standard-values`
 * seed pattern as `standardValuesId` but scoped under
 * `designParametersTemplateId(site, handle)` so params-template SV items don't
 * collide with the component-template SV under the same handle.
 */
export declare const designParametersStandardValuesId: (site: string, handle: string) => string;
/**
 * Enumeration root item — backs an `EnumerationRecipe`. Lives at
 * `<enumerationsRoot>/<EnumName>` per-site. Children are the enum's
 * value items (see `enumValueId`). Site-scoped seed `<site>::<handle>`
 * matches the rest of the per-component derivations so cross-site
 * pushes don't collide.
 */
export declare const enumerationFolderId: (site: string, handle: string) => string;
/**
 * Deterministic refKey for a single enumeration value item. Scopes
 * under the EnumerationRecipe's `enumerationFolderId(site, handle)` so
 * the same value name (`primary`, `default`, etc.) produces distinct
 * GUIDs across enums.
 */
export declare const enumValueId: (parentRefKey: string, valueName: string) => string;
/**
 * Per-site `Enumerations Folder` template. The folder layers in an
 * enumeration tree (root, per-section grouping, per-enum) all conform
 * to this template instead of Sitecore's generic Folder, so the SXA
 * editor recognises the layout and stamps the right icon. Site-scoped
 * because each site owns its own per-Project templates tree.
 */
export declare const enumerationsFolderTemplateId: (site: string) => string;
/**
 * Deterministic refKey for one segment of an
 * `EnumerationRecipe.location.folder` grouping path under
 * `<enumerationsRoot>/<…segments…>`. Conforms to the per-site
 * `Enumerations Folder` template. Site-scoped + keyed on the segment's
 * cumulative path so two recipes in the same push pointing at
 * `folder: "Theme/Color"` reuse the `Theme` and `Theme/Color` folders
 * rather than colliding.
 *
 * Pass the cumulative path (e.g. `"Theme"` then `"Theme/Color"`) — not
 * just the leaf segment — so each level gets its own GUID seeded by its
 * full position in the tree. This keeps two folders named `Color`
 * (one under `Theme`, one under `Layout`) distinct.
 *
 * Same `NAMESPACE_PROJECT` family as section folders / Component
 * Folders buckets — all "site organisational folders" with the same
 * identity model.
 */
export declare const enumerationsGroupingFolderId: (site: string, cumulativePath: string) => string;
/**
 * Per-site `Enumeration` template. The per-enum container items
 * (`Color Scheme`, `Heading Size`, `Background Themes`, etc.) conform
 * to this template — i.e. each enumeration is itself an `Enumeration`,
 * and its leaf values live below it as `Enumeration Value` children.
 * Carries an inner `Enumeration` Section + `Value` Single-Line Text
 * shared field so each per-enum container item can store its
 * canonical default (driven by `EnumerationRecipe.default`). Site-
 * scoped for the same reason as `enumerationsFolderTemplateId`.
 */
export declare const enumerationTemplateId: (site: string) => string;
/**
 * The single Template Section under the per-site `Enumeration`
 * template, named `"Enumeration"` (mirrors the Enumeration Value
 * template's inner section so the field path on both templates is
 * structurally identical: `<template>/Enumeration/Value`).
 */
export declare const enumerationContainerSectionId: (site: string) => string;
/**
 * The `Value` Template Field under the per-site `Enumeration` template's
 * `Enumeration` section. Stores each per-enum container item's default
 * value (`"primary"` for Color Scheme, `"md"` for Heading Size, etc.) —
 * driven by `EnumerationRecipe.default` at compile time. Edge consumers
 * reading the container directly resolve the default via this field.
 */
export declare const enumerationContainerValueFieldId: (site: string) => string;
/**
 * Per-site `__Standard Values` item under the `Enumeration` template
 * definition. Linked via `SetStandardValues` so its Insert Options
 * propagate to every per-enum container item conforming to the
 * Enumeration template — authors can right-click `Color Scheme` →
 * Insert → Enumeration Value to add a new value without picking
 * templates from a long list.
 */
export declare const enumerationTemplateStandardValuesId: (site: string) => string;
/**
 * Per-site `Enumeration Value` template. The leaf value items (like
 * `primary`, `accent`, `lg`, `shooting-star`) conform to this template,
 * NOT to the `Enumeration` template — `Enumeration` is for the per-enum
 * container; `Enumeration Value` is for the leaves. Carries the inner
 * `Enumeration` Template Section + `Value` Template Field (defined
 * below) so each value item stores its actual enumeration string on
 * the `Value` shared field. Site-scoped.
 */
export declare const enumerationValueTemplateId: (site: string) => string;
/**
 * The single Template Section under the per-site `Enumeration Value`
 * template, named `"Enumeration"` (matches the canonical
 * `click-click-launch/Presentation/Enumeration Value/Enumeration`).
 * Holds the `Value` field below. Scoped under
 * `enumerationValueTemplateId(site)` so the GUID is stable per-site
 * without colliding across sites.
 *
 * Function name retained for backwards compatibility with the prior
 * (broken) layout where this section lived under the Enumeration
 * template; the GUID it derives is now under the value template.
 */
export declare const enumerationTemplateSectionId: (site: string) => string;
/**
 * The `Value` Template Field under the per-site `Enumeration Value`
 * template's `Enumeration` section. Stores the actual enumeration
 * value (`"primary"`, `"shooting-star"`, etc.) on every value item
 * conforming to the Enumeration Value template. Scoped under
 * `enumerationValueTemplateId(site)` for stability.
 *
 * Function name retained for backwards compatibility — see
 * `enumerationTemplateSectionId` note above.
 */
export declare const enumerationTemplateValueFieldId: (site: string) => string;
/**
 * Datasource items are scoped to a page recipe's id, keyed on slot path —
 * redeploys with regenerated mock content overwrite the same item.
 * These aren't emitted yet; defined here for forward-compat parity with
 * the planning doc.
 */
export declare const datasourceId: (pageItemId: string, slotPath: string) => string;
/**
 * Project namespace — used for site-scoped folder identities (section
 * folders under `Components/<site>/Components/<section>`, etc.). Distinct
 * from the per-template namespaces because section folders are owned by
 * the *site*, not by any single template.
 */
export declare const NAMESPACE_PROJECT: string;
/**
 * Deterministic refKey for a section folder under a site's
 * `Components/` bucket. Emitted as a `CreateOnly` `CreateItem` so
 * re-pushing a recipe set materialises the section once and is a
 * no-op thereafter. Identity scheme follows
 * `plans/recipe-site-folder-layout.md` § "Deterministic GUID
 * extensions".
 */
export declare const sectionFolderId: (site: string, section: string) => string;
/**
 * Deterministic refKey for the renderings-side section folder under
 * `<renderingsRoot>/<section>/`. Distinct seed from the templates-side
 * section folder so the two don't share an identity (they are separate
 * Sitecore items in separate trees).
 */
export declare const renderingsSectionFolderId: (site: string, section: string) => string;
/**
 * Deterministic refKey for an SXA Headless Variants section grouping
 * under `<headlessVariantsRoot>/<section>/`. Distinct from the
 * templates-side and renderings-side section folder seeds — separate
 * tree, separate Sitecore items, separate identity. Conforms to the
 * `HeadlessVariantsGrouping` template.
 */
export declare const headlessVariantsSectionFolderId: (site: string, section: string) => string;
/**
 * Deterministic refKey for an SXA Available Renderings section item
 * (`<availableRenderingsRoot>/<section>`). Conforms to the
 * `AVAILABLE_RENDERINGS` template; aggregates every component-template
 * recipe in the section into one Renderings field. Idempotent across
 * runs — same `(site, section)` → same refKey forever.
 */
export declare const availableRenderingsSectionId: (site: string, section: string) => string;
/**
 * Deterministic refKey for a "Component Folders" subfolder under a
 * site's `Components/<section>/` — an idempotent parent for the
 * generated `<Component> Folder` templates.
 */
export declare const componentFoldersBucketId: (site: string, section: string) => string;
/**
 * Deterministic refKey for a "Presentation Parameters" subfolder under
 * a site's `Components/<section>/` — an idempotent parent for
 * standalone (and synthesised) Parameters templates.
 */
export declare const presentationDesignParametersBucketId: (site: string, section: string) => string;
/**
 * Deterministic refKey for a `<Component> Folder` template emitted when
 * a `ComponentTemplateRecipe` declares `children:`. The Sitecore item
 * lands at `Components/<section>/Component Folders/<Component> Folder`;
 * the seed is `<componentHandle>::folder`, namespaced under
 * `NAMESPACE_TEMPLATE` so it shares the template-id family without
 * colliding with the component's own template id.
 */
export declare const componentFolderTemplateId: (site: string, componentHandle: string) => string;
/**
 * Standard-values item refKey for a component folder template. Same
 * derivation pattern as `standardValuesId` (seed `__standard-values`,
 * scope under the folder template's id) but differentiated by the
 * folder template's distinct namespace.
 */
export declare const componentFolderStandardValuesId: (site: string, componentHandle: string) => string;
/**
 * Deterministic refKey for a Content Models group folder under a
 * site's `Content Models/<group>/`. Materialised once via a CreateOnly
 * CreateItem when any content template in the recipe set carries
 * `meta.tax.group` matching this name.
 */
export declare const contentModelsGroupFolderId: (site: string, group: string) => string;
/**
 * Deterministic refKey for a page-template group folder under a site's
 * `<pageTemplatesRoot>/<group>/`. Materialised once via a CreateOnly
 * CreateItem when any `PageTemplateRecipe` in the set carries
 * `meta.tax.group` matching this name. Same identity family as
 * `contentModelsGroupFolderId` — a site-owned organisational folder.
 */
export declare const pageTemplatesGroupFolderId: (site: string, group: string) => string;
/**
 * Per-site shared Data Folder under `<contentItemsRoot>/<subfolder>`.
 * Emitted as a CreateOnly item by `compileComponentTemplateRecipe` when
 * a recipe declares a `site`-scoped datasource location with a
 * `subfolder`. Multiple recipes with the same subfolder share the
 * folder (idempotent emission via the `emittedFolders` set).
 */
export declare const siteDataFolderId: (site: string, subfolder: string) => string;
/**
 * Deterministic refKey for an organisational folder segment under
 * `<contentItemsRoot>/<folderPath>` — the home of a `ContentItemRecipe`
 * that declares a `folder`. `folderPath` is the slash-joined cumulative
 * path (`Cocktails`, `Data/Cocktails`), so every nesting level has its
 * own identity and multiple content items sharing a folder converge on
 * one CreateOnly op per recipe set (deduped via `emittedFolders`).
 *
 * Deliberately a DISTINCT seed from `siteDataFolderId` (the
 * datasource-location pool at the same base): if a datasource pool and
 * a content-item folder target the same path, both ops emit and the
 * later one no-ops at apply via the already-exists fallback — the
 * rank-0 pool folder (with its Insert-Options-bearing template) wins
 * over this rank-1 generic folder, never the reverse.
 */
export declare const contentItemsFolderId: (site: string, folderPath: string) => string;
/**
 * Per-component Data Folder TEMPLATE emitted when a recipe declares a
 * site-scoped datasource location. Lands at
 * `Components/<section>/Data Folders/<Component> Data Folder`. The
 * Sitecore folder ITEM(s) at `<contentItemsRoot>/<subfolder>` conform
 * to this template (instead of the generic `Folder`) so its
 * `__Standard Values`'s Insert Options can restrict children to the
 * component's own datasource template — i.e. a "Badges" folder only
 * accepts Badge datasources when an author right-clicks → Insert.
 *
 * One template per recipe-handle (idempotent across multiple
 * site-scoped subfolders that share the same recipe). Mirrors
 * `componentFolderTemplateId` for `children:` declarations, but
 * keyed under a distinct seed so the two templates don't collide.
 */
export declare const siteDataFolderTemplateId: (site: string, recipeHandle: string) => string;
/**
 * Standard-values item refKey for a per-component Data Folder template.
 * Same derivation pattern as `standardValuesId` and
 * `componentFolderStandardValuesId` — seed `__standard-values` under
 * the folder template's own id.
 */
export declare const siteDataFolderStandardValuesId: (site: string, recipeHandle: string) => string;
/**
 * Per-(recipe, subfolder) Data Folder template — used when a recipe
 * declares site-scoped locations with DIFFERENT `allowedTemplates`
 * lists (the avatar-block case: page-Avatars accepts `avatar-block@1`,
 * site-Authors accepts `author@1`). One Insert Options list per
 * subfolder can't fit on a single per-recipe template, so each
 * location gets its own template + standard-values.
 *
 * Keyed by `(site, recipeHandle, subfolder)` to keep it distinct from
 * the per-recipe `siteDataFolderTemplateId` (single uniform Insert
 * Options) and the cross-recipe `sharedDataFolderTemplateId` (coalesces
 * multiple recipes' contributions to one subfolder).
 */
export declare const siteDataFolderTemplateIdForLocation: (site: string, recipeHandle: string, subfolder: string) => string;
export declare const siteDataFolderStandardValuesIdForLocation: (site: string, recipeHandle: string, subfolder: string) => string;
/**
 * SHARED Data Folder template — keyed on `(site, subfolder)` instead of
 * `(site, recipeHandle)`. Emitted by `compileRecipeSet` when two or
 * more recipes target the same site-scoped `subfolder` (the shared-
 * pool design-system pattern: Badge + StatusPill + Tag all populating
 * `Site Shared UI/Badges`). The shared template's `__Standard Values`
 * Insert Options field aggregates every contributing recipe's
 * datasource template, so a CMS author right-clicking → Insert sees
 * all the shapes that legitimately belong in that pool.
 *
 * Per-recipe `siteDataFolderTemplateId` stays in use for the
 * SINGLETON case (one recipe → one subfolder). The choice between the
 * two is made by the cross-recipe coalescer in `compileRecipeSet`:
 * count refs per `(site, subfolder)`; ≥2 → shared template;
 * exactly 1 → per-recipe template.
 */
export declare const sharedDataFolderTemplateId: (site: string, subfolder: string) => string;
/**
 * Identity helpers for `SiteTemplateRecipe`-emitted artifacts.
 *
 * The site template's own item identity is `templateId(site, handle)` —
 * a site template is a Sitecore template item, same identity family as
 * regular templates. The helpers below derive companion items the
 * site-template compile emits alongside it: media uploads (thumbnail /
 * image), the tenant-rooted SXA Module root, and each setup-action
 * child under the Module root. All seeds scope under the site
 * template's own GUID so two recipes with the same handle in different
 * sites don't collide.
 */
/**
 * Recipe-internal refKey for a thumbnail media item emitted by
 * `MediaUploadOp` when a `SiteTemplateRecipe` populates `thumbnail`.
 * Pairs 1:1 with the SetField op that writes the `__Thumbnail` media
 * XML on the site template item — the SetField value's
 * `kind: "media-xml-ref"` references this same refKey, which the
 * executor substitutes at apply time for the captured media itemId.
 */
export declare const thumbnailMediaId: (site: string, handle: string) => string;
/**
 * Recipe-internal refKey for a media item materialised from an
 * external-URL image field value (content-item / page-datasource field
 * or a template's Standard Values image default). Pairs 1:1 with the
 * `kind: "media-xml-ref"` field value that references it — the executor
 * substitutes the uploaded media item's server-assigned GUID at apply
 * time, yielding the `<image mediaid="{GUID}" />` form the Layout
 * Service actually renders (bare `src=`/`mediapath=` attributes never
 * surface as a renderable `src` in XM Cloud).
 *
 * Seeded with the source URL so a story whose versions swap the image
 * gets one media item per distinct URL, while repeated emissions of
 * the same (field, URL) pair across languages/versions dedupe to one
 * upload.
 */
export declare const mediaFieldId: (site: string, handle: string, fieldName: string, sourceUrl: string) => string;
/**
 * Recipe-internal refKey for the tenant-rooted SXA Module item
 * synthesised by `compileSiteTemplateRecipe`. Conforms to
 * `HEADLESS_SITE_SETUP_ROOT`; lands at
 * `<siteTemplatesRoot>/Modules/<RecipeName>`. The site template's
 * `Site Modules` field aggregates this refKey alongside the hardcoded
 * `FOUNDATION_SITE_MODULES` GUIDs.
 */
export declare const siteTemplateModuleId: (site: string, handle: string) => string;
/**
 * Recipe-internal refKey for one setup-action child item under a
 * recipe-synthesised SXA Module root. Each `pageTemplates[i]`,
 * `pageDesigns[i]`, `insertOptionsMatrix[k]`, etc. expands to a
 * separate action-child item; the seed encodes both the action
 * "kind" (which the compiler picks per source field) and the
 * referenced handle so two pageTemplates entries get distinct refKeys.
 */
export declare const siteTemplateModuleActionId: (site: string, handle: string, actionKind: string, targetHandle: string) => string;
/**
 * Standard-values item refKey for a shared per-subfolder Data Folder
 * template. Same `__standard-values` seed pattern as the rest of the
 * SV family.
 */
export declare const sharedDataFolderStandardValuesId: (site: string, subfolder: string) => string;
/**
 * Recipe-internal refKey for the site Data folder ROOT's
 * `__Standard Values` item (one per site). The ITEM at
 * `<contentItemsRoot>` itself is tenant-pre-existing or
 * lazy-created; scai writes the SV directly under it via a
 * CreateOnly CreateItem op.
 */
export declare const siteDataRootStandardValuesId: (site: string) => string;
/**
 * Recipe-internal refKey for the enumerations root ITEM (one per site
 * — the `<enumerationsRoot>` content tree node, e.g.
 * `<site>/Presentation/Enumerations`). The path-walker would otherwise
 * auto-create this as the generic `Folder` template with the default
 * folder icon when child ops first land; scai emits an explicit
 * CreateAndUpdate CreateItem against this refKey so the item exists
 * with the enumeration glyph icon, matching the per-site enumeration
 * templates' icon.
 */
export declare const enumerationsRootId: (site: string) => string;
/**
 * Recipe-internal refKey for the enumerations root's
 * `__Standard Values` item (one per site). Mirror of
 * `siteDataRootStandardValuesId` for the enumerations tree — scai
 * writes the SV directly under the root via a CreateOnly CreateItem op
 * so authors' right-click → Insert UX is restricted to enumeration
 * folders + the generic Folder template.
 */
export declare const enumerationsRootStandardValuesId: (site: string) => string;
/**
 * Per-site `__Standard Values` item under the `Enumerations Folder`
 * template definition (NOT under each data folder). Linked to the
 * template via `SetStandardValues` so its `Insert Options` propagates
 * to every item conforming to Enumerations Folder — both the
 * grouping-folder items under `<enumerationsRoot>` and the per-enum
 * data folders themselves get the same Insert UX without an SV item
 * polluting each data folder's children.
 *
 * Replaces the old `enumerationFolderStandardValuesId` (per-recipe SV
 * under each data folder), which was non-functional anyway — it set
 * Insert Options on the SV item without `SetStandardValues` linking,
 * so the field had no effect, but the SV item itself appeared in the
 * Droplink picker as a sibling of the enum value items.
 */
export declare const enumerationsFolderTemplateStandardValuesId: (site: string) => string;
/**
 * Placeholder Settings item identity.
 *
 * A Placeholder Settings item is the gate for "what renderings can be
 * dropped into this slot" — it carries a `Placeholder Key` and an
 * `Allowed Controls` whitelist. Its identity is the **placeholder key**,
 * not a recipe handle: one key = one settings item. A standalone
 * `PlaceholderRecipe` and an inline `ComponentTemplateRecipe.placeholders`
 * entry that name the same key therefore derive the *same* GUID — which
 * is correct (they describe the same Sitecore item) and lets the
 * cross-recipe validator flag the ambiguous double-declaration.
 *
 * Site-scoped like the rest of the per-Project item family, so the same
 * recipe set pushed to two sites yields two distinct Placeholder
 * Settings items under each site's Presentation tree.
 */
export declare const NAMESPACE_PLACEHOLDER: string;
export declare const placeholderSettingsId: (site: string, key: string) => string;
/**
 * Deterministic refKey for one segment of a placeholder `folder`
 * grouping path under `<placeholderSettingsRoot>/<…segments…>`. Conforms
 * to the SXA `Placeholder Settings Folder` template. Site-scoped + keyed
 * on the segment's CUMULATIVE path so two recipes naming the same folder
 * (`"Partial Design/Header"`) reuse the `Partial Design` and
 * `Partial Design/Header` folders rather than colliding — pass the
 * cumulative path, not the leaf segment.
 *
 * Same `NAMESPACE_PROJECT` "site organisational folder" family as
 * section folders and the enumeration grouping folders.
 */
export declare const placeholderSettingsFolderId: (site: string, cumulativePath: string) => string;
/**
 * Deterministic refKey for a system template referenced by content-tree
 * path (workflow/webhook/etc. system templates whose GUIDs aren't
 * published). Same identity for the same path forever — the push
 * pipeline seeds `crossRecipeRefs[<this refKey>] = path`; the executor
 * batches a single `getItemsByPaths` lookup and the planner resolves
 * `templateOf: ref-path` ops through the existing `capturedItemIds`
 * map.
 */
export declare const NAMESPACE_TEMPLATE_BY_PATH: string;
export declare const templatePathRefKey: (path: string) => string;
/**
 * Deterministic refKey for a content-tree ITEM referenced by path —
 * typically pre-existing tenant scaffolding the recipe set doesn't
 * create but needs to mutate (e.g. a page's parent item receiving an
 * Insert Options append). Same identity for the same path forever; the
 * emitting op carries `latePath: <path>` so the executor resolves the
 * itemId on demand when the captured map has no entry.
 */
export declare const NAMESPACE_ITEM_BY_PATH: string;
export declare const itemPathRefKey: (path: string) => string;
/**
 * Deterministic refKey for the `__Standard Values` item under a
 * tenant-existing template referenced by content-tree path. Used by
 * `WorkflowRecipe.bindings.templates` entries that point at an absolute
 * template path (not an intra-recipe handle): the compiler emits a
 * `SetField` op with `latePath: "<templatePath>/__Standard Values"`,
 * and the executor's late-path resolution walks the path to seed the
 * captured-itemId map before planning the field write. Same identity
 * for the same path forever.
 */
export declare const NAMESPACE_STANDARD_VALUES_BY_PATH: string;
export declare const standardValuesPathRefKey: (templatePath: string) => string;
/**
 * Workflow recipe identities.
 *
 * Workflows live at `/sitecore/system/Workflows/[<group>/]<name>` and
 * are tenant-wide (not site-scoped), so GUIDs derive from the recipe
 * handle directly. Sub-items (states, commands, actions) nest under
 * the workflow's GUID to keep the hierarchy stable across renames at
 * deeper levels.
 */
export declare const NAMESPACE_WORKFLOW: string;
export declare const workflowId: (handle: string) => string;
export declare const workflowStateId: (handle: string, stateKey: string) => string;
export declare const workflowCommandId: (handle: string, stateKey: string, commandKey: string) => string;
/** Webhook submit/validation action under a workflow STATE's `Actions` folder. */
export declare const workflowStateActionId: (handle: string, stateKey: string, index: number) => string;
/** Webhook validation action under a workflow COMMAND's `Actions` folder. */
export declare const workflowCommandValidationId: (handle: string, stateKey: string, commandKey: string, index: number) => string;
/** Workflow group folder under /sitecore/system/Workflows (when meta.tax.group is set). */
export declare const workflowGroupFolderId: (group: string) => string;
/**
 * Webhook Authorization recipe identity. Items live at
 * `/sitecore/system/Settings/Webhooks/Authorizations/<name>` — flat,
 * tenant-wide. Used by workflow webhook actions + event handlers to
 * carry credentials.
 */
export declare const NAMESPACE_WEBHOOK_AUTHORIZATION: string;
export declare const webhookAuthorizationId: (handle: string) => string;