import { z } from "zod";
/**
 * Multi-segment folder path accepted by `location.folder` /
 * `placeholder.folder`. Two wire shapes:
 *
 *   Array form (canonical):    `["Theme", "Color"]`
 *   Slash-string form (legacy): `"Theme/Color"`
 *
 * Both normalize to `string[]` after parsing. The registry moved its
 * recipe schema to array form because the slash-string was implicit
 * and fragile to author through Agent Studio (no IDE help for the
 * segments inside the string); scai accepts both so old recipes keep
 * working and new ones use the explicit shape. Empty segments
 * (`""` / `"a//b"`) after split + trim are filtered out so callers
 * don't have to remember to clean them.
 *
 * Downstream consumers (compile/enumeration, compile/placeholder,
 * read-current) all see `string[]` and don't need to split anything
 * themselves.
 */
export declare const FolderPath: z.ZodPipe<z.ZodPipe<z.ZodUnion<readonly [z.ZodString, z.ZodArray<z.ZodString>]>, z.ZodTransform<string[], string | string[]>>, z.ZodArray<z.ZodString>>;
/**
 * The `handle` is load-bearing forever — a uuidv5 derives every item GUID
 * from it (see `guids.ts`), so renaming a handle creates a *different*
 * template.
 */
export declare const HANDLE_PATTERN: RegExp;
/**
 * The picker-scope source ("Sitecore's Source field") expressed as a
 * discriminated union over the three real modes:
 *
 *   - `filter` — composable structured fields. `types` is a picker
 *     filter restricting which recipe-defined templates appear; `query`
 *     is a Sitecore Query; `scope` is a fixed content-tree path. They
 *     combine, e.g. `scope + types` → `DataSource=<path>&IncludeTemplatesForSelection=...`.
 *   - `raw` — verbatim Source string, the escape hatch. Use when the
 *     structured surface doesn't fit (e.g. a bare path Treelist source
 *     like `/sitecore/content/Tags`).
 *   - `plugin` — Sitecore Marketplace plugin slug. Paired with
 *     `sitecore.type: "Plugin"`. The compiler emits the slug verbatim
 *     into the field's `Source`; the Marketplace shell looks it up
 *     against its installed-plugins catalog to mount the iframe.
 *
 * Previously the four fields were peers on `SitecoreFieldAugment` with
 * a `.refine` enforcing the mutex; the union makes the constraint
 * structural so JSON Schema's `oneOf` expresses it natively and Agent
 * Studio can't emit an invalid combination. See
 * `docs/recipe-schema-audit.md` (A1).
 */
export declare const SitecoreFieldSourceSchema: z.ZodDiscriminatedUnion<[z.ZodObject<{
    kind: z.ZodLiteral<"filter">;
    types: z.ZodOptional<z.ZodArray<z.ZodString>>;
    query: z.ZodOptional<z.ZodString>;
    scope: z.ZodOptional<z.ZodString>;
}, z.core.$strip>, z.ZodObject<{
    kind: z.ZodLiteral<"raw">;
    value: z.ZodString;
}, z.core.$strip>, z.ZodObject<{
    kind: z.ZodLiteral<"plugin">;
    id: z.ZodString;
    defaultAppId: z.ZodString;
}, z.core.$strip>], "kind">;
export type SitecoreFieldSource = z.infer<typeof SitecoreFieldSourceSchema>;
/**
 * A per-locale field default: a map of locale code → value, e.g.
 * `{ en: "Get in touch", de: "Kontakt aufnehmen", fr: "Contactez-nous" }`.
 *
 * Materialises as one `__Standard Values` field version per locale, so a
 * template-specific default *content* string localises without leaning on
 * the shared `core-ui-labels` dictionary. Only meaningful on
 * text / rich-text fields — the compiler rejects a locale map on any
 * other shape (a GUID reference / image / boolean default can't vary by
 * language). The map MUST include the primary language (`en`) as the base
 * version; every other locale becomes an additional language version.
 *
 * Non-primary keys are resolved (case-insensitively) against the
 * environment's registered languages at push time (Sites API
 * `listLanguages`). A key may be a **base language** (`de`, `ar`, `ja`)
 * or a full **regional code** (`de-DE`, `pt-BR`): a base key fans out to
 * every registered regional variant of that language, each carrying the
 * base value, so you author one translation per language rather than one
 * per region; an explicit regional key overrides the base for that exact
 * locale (handy for the `zh-CN` vs `zh-TW` / `pt-BR` vs `pt-PT` splits).
 * A locale that matches no registered language is dropped. A standalone
 * compile (no live environment) emits every authored key verbatim.
 */
export declare const LocalizedDefaultSchema: z.ZodRecord<z.ZodString, z.ZodString>;
export type LocalizedDefault = z.infer<typeof LocalizedDefaultSchema>;
/**
 * A field/parameter default — either a single string (primary-language
 * only, unchanged) or a {@link LocalizedDefaultSchema} locale map.
 */
export declare const FieldDefaultSchema: z.ZodUnion<readonly [z.ZodString, z.ZodRecord<z.ZodString, z.ZodString>]>;
export type FieldDefault = z.infer<typeof FieldDefaultSchema>;
export declare const SitecoreFieldAugmentSchema: z.ZodObject<{
    type: z.ZodOptional<z.ZodEnum<{
        number: "number";
        integer: "integer";
        tags: "tags";
        lookup: "lookup";
        date: "date";
        file: "file";
        image: "image";
        datetime: "datetime";
        "single-line-text": "single-line-text";
        "multi-line-text": "multi-line-text";
        "rich-text": "rich-text";
        "general-link": "general-link";
        checkbox: "checkbox";
        droplist: "droplist";
        droplink: "droplink";
        treelist: "treelist";
        "treelist-with-search": "treelist-with-search";
        Plugin: "Plugin";
    }>>;
    source: z.ZodOptional<z.ZodDiscriminatedUnion<[z.ZodObject<{
        kind: z.ZodLiteral<"filter">;
        types: z.ZodOptional<z.ZodArray<z.ZodString>>;
        query: z.ZodOptional<z.ZodString>;
        scope: z.ZodOptional<z.ZodString>;
    }, z.core.$strip>, z.ZodObject<{
        kind: z.ZodLiteral<"raw">;
        value: z.ZodString;
    }, z.core.$strip>, z.ZodObject<{
        kind: z.ZodLiteral<"plugin">;
        id: z.ZodString;
        defaultAppId: z.ZodString;
    }, z.core.$strip>], "kind">>;
    hint: z.ZodOptional<z.ZodString>;
    required: z.ZodOptional<z.ZodBoolean>;
    defaultValue: z.ZodOptional<z.ZodUnion<readonly [z.ZodString, z.ZodRecord<z.ZodString, z.ZodString>]>>;
    enumHandle: z.ZodOptional<z.ZodString>;
    sortOrder: z.ZodOptional<z.ZodNumber>;
    section: z.ZodOptional<z.ZodString>;
    storage: z.ZodOptional<z.ZodEnum<{
        unversioned: "unversioned";
        shared: "shared";
        versioned: "versioned";
    }>>;
}, z.core.$loose>;
export type SitecoreFieldAugment = z.infer<typeof SitecoreFieldAugmentSchema>;
export declare const FieldDefinitionSchema: z.ZodObject<{
    name: z.ZodString;
    shape: z.ZodEnum<{
        number: "number";
        boolean: "boolean";
        link: "link";
        integer: "integer";
        enum: "enum";
        date: "date";
        text: "text";
        richText: "richText";
        image: "image";
        datetime: "datetime";
        reference: "reference";
    }>;
    values: z.ZodOptional<z.ZodArray<z.ZodString>>;
    multiple: z.ZodOptional<z.ZodBoolean>;
    default: z.ZodOptional<z.ZodUnion<readonly [z.ZodString, z.ZodRecord<z.ZodString, z.ZodString>]>>;
    role: z.ZodOptional<z.ZodString>;
    sitecore: z.ZodOptional<z.ZodObject<{
        type: z.ZodOptional<z.ZodEnum<{
            number: "number";
            integer: "integer";
            tags: "tags";
            lookup: "lookup";
            date: "date";
            file: "file";
            image: "image";
            datetime: "datetime";
            "single-line-text": "single-line-text";
            "multi-line-text": "multi-line-text";
            "rich-text": "rich-text";
            "general-link": "general-link";
            checkbox: "checkbox";
            droplist: "droplist";
            droplink: "droplink";
            treelist: "treelist";
            "treelist-with-search": "treelist-with-search";
            Plugin: "Plugin";
        }>>;
        source: z.ZodOptional<z.ZodDiscriminatedUnion<[z.ZodObject<{
            kind: z.ZodLiteral<"filter">;
            types: z.ZodOptional<z.ZodArray<z.ZodString>>;
            query: z.ZodOptional<z.ZodString>;
            scope: z.ZodOptional<z.ZodString>;
        }, z.core.$strip>, z.ZodObject<{
            kind: z.ZodLiteral<"raw">;
            value: z.ZodString;
        }, z.core.$strip>, z.ZodObject<{
            kind: z.ZodLiteral<"plugin">;
            id: z.ZodString;
            defaultAppId: z.ZodString;
        }, z.core.$strip>], "kind">>;
        hint: z.ZodOptional<z.ZodString>;
        required: z.ZodOptional<z.ZodBoolean>;
        defaultValue: z.ZodOptional<z.ZodUnion<readonly [z.ZodString, z.ZodRecord<z.ZodString, z.ZodString>]>>;
        enumHandle: z.ZodOptional<z.ZodString>;
        sortOrder: z.ZodOptional<z.ZodNumber>;
        section: z.ZodOptional<z.ZodString>;
        storage: z.ZodOptional<z.ZodEnum<{
            unversioned: "unversioned";
            shared: "shared";
            versioned: "versioned";
        }>>;
    }, z.core.$loose>>;
}, z.core.$strip>;
export type FieldDefinition = z.infer<typeof FieldDefinitionSchema>;
export declare const DesignParameterSchema: z.ZodObject<{
    name: z.ZodString;
    shape: z.ZodEnum<{
        number: "number";
        boolean: "boolean";
        link: "link";
        integer: "integer";
        enum: "enum";
        date: "date";
        text: "text";
        richText: "richText";
        image: "image";
        datetime: "datetime";
        reference: "reference";
    }>;
    values: z.ZodOptional<z.ZodArray<z.ZodString>>;
    default: z.ZodOptional<z.ZodUnion<readonly [z.ZodString, z.ZodRecord<z.ZodString, z.ZodString>]>>;
    sitecore: z.ZodOptional<z.ZodObject<{
        type: z.ZodOptional<z.ZodEnum<{
            number: "number";
            integer: "integer";
            tags: "tags";
            lookup: "lookup";
            date: "date";
            file: "file";
            image: "image";
            datetime: "datetime";
            "single-line-text": "single-line-text";
            "multi-line-text": "multi-line-text";
            "rich-text": "rich-text";
            "general-link": "general-link";
            checkbox: "checkbox";
            droplist: "droplist";
            droplink: "droplink";
            treelist: "treelist";
            "treelist-with-search": "treelist-with-search";
            Plugin: "Plugin";
        }>>;
        source: z.ZodOptional<z.ZodDiscriminatedUnion<[z.ZodObject<{
            kind: z.ZodLiteral<"filter">;
            types: z.ZodOptional<z.ZodArray<z.ZodString>>;
            query: z.ZodOptional<z.ZodString>;
            scope: z.ZodOptional<z.ZodString>;
        }, z.core.$strip>, z.ZodObject<{
            kind: z.ZodLiteral<"raw">;
            value: z.ZodString;
        }, z.core.$strip>, z.ZodObject<{
            kind: z.ZodLiteral<"plugin">;
            id: z.ZodString;
            defaultAppId: z.ZodString;
        }, z.core.$strip>], "kind">>;
        hint: z.ZodOptional<z.ZodString>;
        required: z.ZodOptional<z.ZodBoolean>;
        defaultValue: z.ZodOptional<z.ZodUnion<readonly [z.ZodString, z.ZodRecord<z.ZodString, z.ZodString>]>>;
        enumHandle: z.ZodOptional<z.ZodString>;
        sortOrder: z.ZodOptional<z.ZodNumber>;
        section: z.ZodOptional<z.ZodString>;
        storage: z.ZodOptional<z.ZodEnum<{
            unversioned: "unversioned";
            shared: "shared";
            versioned: "versioned";
        }>>;
    }, z.core.$loose>>;
}, z.core.$strip>;
export type DesignParameter = z.infer<typeof DesignParameterSchema>;
/**
 * Variants-lite shape: bare Variant item per `name`, no internal
 * structure. Could grow per-variant template-card bindings for full
 * SXA NVELOPe authoring as a follow-up.
 *
 * `name` MUST be PascalCase. The Sitecore Content SDK looks up variants
 * at render time via case-sensitive `component[name]` indexing on the
 * component module's named exports, and React convention requires
 * exported component identifiers to be PascalCase. Using lowercase or
 * kebab-case here makes the SDK's variant lookup return `undefined` —
 * Pages then renders the missing-component fallback.
 *
 * The `Default` variant is special-cased by the SDK
 * (`DEFAULT_EXPORT_NAME = "Default"`): when `params.FieldNames` matches
 * that, the SDK falls through to `component.default || component.Default
 * || component`, so any of those export shapes work for the default
 * variant. All OTHER variant names require an exact-match named export
 * in the component file (e.g. `name: "FullWidth"` → `export function
 * FullWidth(...)`).
 */
export declare const VARIANT_NAME_PATTERN: RegExp;
export declare const RenderingVariantDefinitionSchema: z.ZodObject<{
    name: z.ZodString;
}, z.core.$strip>;
export type RenderingVariantDefinition = z.infer<typeof RenderingVariantDefinitionSchema>;
/**
 * An inline placeholder slot a container component EXPOSES for child
 * renderings to drop into. The hybrid placeholder model's component-owned
 * half: a Section / Grid / Tabs component declares the slots it owns
 * here; site-level chrome slots (`/header`, `/footer`) that belong to no
 * single component are authored as a standalone `PlaceholderRecipe`
 * instead.
 *
 * Both forms compile to the same artifact — one Sitecore Placeholder
 * Settings item per unique `key` — emitted by the cross-recipe
 * `buildPlaceholderSettingsAggregate` (see `compile.ts`). Identity is the
 * `key`, so an inline slot and a `PlaceholderRecipe` MUST NOT name the
 * same key; `validateRecipeSet` flags the collision.
 */
export declare const PlaceholderDefinitionSchema: z.ZodObject<{
    key: z.ZodString;
    displayName: z.ZodOptional<z.ZodString>;
    folder: z.ZodOptional<z.ZodPipe<z.ZodPipe<z.ZodUnion<readonly [z.ZodString, z.ZodArray<z.ZodString>]>, z.ZodTransform<string[], string | string[]>>, z.ZodArray<z.ZodString>>>;
    dynamic: z.ZodOptional<z.ZodBoolean>;
    allowedComponents: z.ZodOptional<z.ZodArray<z.ZodString>>;
    allowedRenderingHandles: z.ZodOptional<z.ZodArray<z.ZodString>>;
}, z.core.$strip>;
export type PlaceholderDefinition = z.infer<typeof PlaceholderDefinitionSchema>;
/**
 * Normalise the two-name surface (`allowedComponents` /
 * `allowedRenderingHandles`) into a single ordered list. Either may be
 * set; if both are set their union is returned (de-duped, source
 * order). Use everywhere the compiler reads the slot-side allowed
 * list so the rename stays a no-op for downstream code.
 */
export declare const resolveAllowedHandles: (slot: PlaceholderDefinition) => readonly string[];
/**
 * Where a recipe's external-URL images land in the media library —
 * the media-library twin of {@link RenderingDatasourceLocationSchema}.
 * External-URL image field values (and SV image defaults) compile to a
 * `MediaUpload` + `<image mediaid="{GUID}" />`; this declaration
 * controls the upload's destination folder:
 *
 *   - `page` → mirrors the page's own directory: the page item's path
 *     relative to `pagesRoot` becomes a folder path under the media
 *     root (`<mediaLibraryRoot>/<page-relative-path>/<subfolder?>`).
 *     Only valid on a `PageRecipe` — content items and templates have
 *     no host page, and the compiler rejects the scope there.
 *   - `site` → the site-wide media pool:
 *     `<mediaLibraryRoot>/<subfolder?>`.
 *
 * `<mediaLibraryRoot>` is the env profile's `recipeRoots.mediaLibrary`
 * (or `/sitecore/media library/RecipeImages/<site>` when unset). When
 * a mediaLocation is declared, the default `<recipeName>/` nesting is
 * skipped — the author owns the layout. A per-image
 * `mediaLibraryFolder` on the field value still overrides everything.
 */
export declare const MediaLocationSchema: z.ZodDiscriminatedUnion<[z.ZodObject<{
    scope: z.ZodLiteral<"page">;
    subfolder: z.ZodOptional<z.ZodString>;
}, z.core.$strip>, z.ZodObject<{
    scope: z.ZodLiteral<"site">;
    subfolder: z.ZodOptional<z.ZodString>;
}, z.core.$strip>], "scope">;
export type MediaLocation = z.infer<typeof MediaLocationSchema>;
/**
 * One entry in the modern semantic-scope datasource locations list.
 *
 * Each entry compiles to a single Sitecore Source segment; the compiler
 * pipe-joins entries into the rendering's `Datasource Location` field so
 * one rendering can offer authors per-page auto-creation AND a shared
 * site-level pool of datasources to pick from.
 *
 *   - `page` → relative `./Data` (no subfolder) or `./Data/<subfolder>`.
 *     SXA materialises the `Data` and `<subfolder>` items lazily on first
 *     datasource creation; no extra CreateItem op is emitted.
 *   - `site` → absolute `<contentItemsRoot>` (no subfolder) or
 *     `<contentItemsRoot>/<subfolder>`. With `subfolder` the compiler
 *     emits a `CreateOnly` `CreateItem` for the data folder so the
 *     shared pool exists before any rendering tries to read from it.
 */
export declare const RenderingDatasourceLocationSchema: z.ZodDiscriminatedUnion<[z.ZodObject<{
    scope: z.ZodLiteral<"page">;
    subfolder: z.ZodOptional<z.ZodString>;
    allowedTemplates: z.ZodOptional<z.ZodArray<z.ZodObject<{
        handle: z.ZodString;
    }, z.core.$strip>>>;
}, z.core.$strip>, z.ZodObject<{
    scope: z.ZodLiteral<"site">;
    subfolder: z.ZodOptional<z.ZodString>;
    allowedTemplates: z.ZodOptional<z.ZodArray<z.ZodObject<{
        handle: z.ZodString;
    }, z.core.$strip>>>;
}, z.core.$strip>], "scope">;
export type RenderingDatasourceLocation = z.infer<typeof RenderingDatasourceLocationSchema>;
/**
 * Top-level datasource block on `ComponentTemplateRecipe`. Captures
 * everything the rendering needs to know about its datasource:
 *
 *   - **template**: optional reference to a single
 *     `ContentTemplateRecipe`. Shortcut for the common single-template
 *     case; equivalent to `templates: [{handle}]` with one entry. When
 *     unset (and `templates` is unset, and the recipe has no inline
 *     `fields:`), the rendering has no Datasource Template at all.
 *   - **templates**: multiple compatible datasource templates — the
 *     "compatible-datasources" pattern. The compiler pipe-joins each
 *     template's GUID into the rendering's `Datasource Template`
 *     shared field, so the Pages picker surfaces items conforming to
 *     *any* of the listed templates. Mutually exclusive with `template`.
 *   - **autoCreate**: toggles `IsAutoDatasourceRendering=true` in the
 *     rendering's `OtherProperties` URL-encoded blob. Default true.
 *     With `templates`, default to `false` at the recipe level — the
 *     compiler can't pick one template unambiguously, so the dropping
 *     author should be prompted to choose via the datasource picker.
 *   - **openPropertiesAfterAdd**: opens the rendering parameters
 *     dialog right after the rendering is dropped on a page. Default
 *     false.
 *   - **locations**: semantic page/site scope entries — each compiles
 *     to one Sitecore Source segment (a relative `./Data/...` path or
 *     an absolute `<contentItemsRoot>/...` path).
 *   - **query**: raw Sitecore Source segments — included verbatim.
 *     Use `"query:$site/*[@@name='Data']/CustomPath"`-style entries for
 *     authors who need a Source shape that doesn't fit the semantic
 *     `locations` model.
 *
 * The compiler pipe-joins `locations` (resolved to paths) and `query`
 * (verbatim) into the rendering's `Datasource Location` field.
 */
export declare const RecipeDatasourceSchema: z.ZodObject<{
    template: z.ZodOptional<z.ZodObject<{
        handle: z.ZodString;
    }, z.core.$strip>>;
    templates: z.ZodOptional<z.ZodArray<z.ZodObject<{
        handle: z.ZodString;
    }, z.core.$strip>>>;
    autoCreate: z.ZodDefault<z.ZodBoolean>;
    openPropertiesAfterAdd: z.ZodDefault<z.ZodBoolean>;
    locations: z.ZodDefault<z.ZodArray<z.ZodDiscriminatedUnion<[z.ZodObject<{
        scope: z.ZodLiteral<"page">;
        subfolder: z.ZodOptional<z.ZodString>;
        allowedTemplates: z.ZodOptional<z.ZodArray<z.ZodObject<{
            handle: z.ZodString;
        }, z.core.$strip>>>;
    }, z.core.$strip>, z.ZodObject<{
        scope: z.ZodLiteral<"site">;
        subfolder: z.ZodOptional<z.ZodString>;
        allowedTemplates: z.ZodOptional<z.ZodArray<z.ZodObject<{
            handle: z.ZodString;
        }, z.core.$strip>>>;
    }, z.core.$strip>], "scope">>>;
    query: z.ZodDefault<z.ZodArray<z.ZodString>>;
}, z.core.$strip>;
export type RecipeDatasource = z.infer<typeof RecipeDatasourceSchema>;
/**
 * Optional taxonomy metadata, mirroring the registry's `meta.tax.*`
 * namespace. `group` is the only field the compiler currently consumes
 * — it drives `Content Models/<group>/<name>` nesting for content
 * templates. Other fields (`section`, `subgroup`, `tag`) are accepted
 * so registry → recipe pipelines can pass them through without
 * losing data, but they're not load-bearing for compilation.
 */
export declare const RecipeMetaTaxSchema: z.ZodOptional<z.ZodObject<{
    section: z.ZodOptional<z.ZodOptional<z.ZodString>>;
    group: z.ZodOptional<z.ZodOptional<z.ZodString>>;
    subgroup: z.ZodOptional<z.ZodOptional<z.ZodString>>;
    tag: z.ZodOptional<z.ZodOptional<z.ZodString>>;
}, z.core.$strip>>;
export declare const RecipeMetaSchema: z.ZodOptional<z.ZodObject<{
    tax: z.ZodOptional<z.ZodOptional<z.ZodObject<{
        section: z.ZodOptional<z.ZodOptional<z.ZodString>>;
        group: z.ZodOptional<z.ZodOptional<z.ZodString>>;
        subgroup: z.ZodOptional<z.ZodOptional<z.ZodString>>;
        tag: z.ZodOptional<z.ZodOptional<z.ZodString>>;
    }, z.core.$strip>>>;
}, z.core.$strip>>;
export type RecipeMeta = z.infer<typeof RecipeMetaSchema>;
/**
 * Content-affinity dimensions a page declares — the tags Sitecore
 * Personalize should associate with a visitor who views this page.
 *
 * This facet is a page-recipe concept, NOT a Sitecore item field — the
 * compiler does not emit a Sitecore field for it. Downstream, the demo
 * orchestrator consumes it two ways. (1) Its synthetic-event generator
 * projects it into the CDP event `ext` custom-data object on the page's
 * VIEW events, so a guest's affinity *emerges* from the pages they walk —
 * each axis is a tag list, and the generator stamps the primary tag of each
 * axis as a flat `ext` value (arrays are unsupported on the CDP wire), with
 * multi-interest pages modelled by the page graph rather than arrays on one
 * event. (2) It registers the facet with the CDP **affinities API**
 * (`PUT /v2/tenants/affinities`, keyed site → page → tags) at install, so
 * affinity is also stored tenant config, not only event data.
 *
 * `dimensions` is an **open, brand-authored taxonomy**: each key is an
 * axis name and its value that axis's tag list. Because axis names become
 * flat CDP `ext.<axis>` attribute keys, they must be camelCase (lower-first,
 * alphanumeric). There is no fixed axis set — `category` / `topic` are the
 * common defaults, `brand` is used only for multi-brand tenants, and a
 * brand may add its own (`material`, `lifeStage`, …).
 */
export declare const PageAffinityFacetSchema: z.ZodObject<{
    dimensions: z.ZodRecord<z.ZodString, z.ZodArray<z.ZodString>>;
    weight: z.ZodOptional<z.ZodNumber>;
}, z.core.$strict>;
export type PageAffinityFacet = z.infer<typeof PageAffinityFacetSchema>;