import { z } from 'zod';
import type { FieldRow } from '../db/schema.js';
/**
 * Whether a field is shown, given its siblings' values.
 *
 * **One implementation, called by both sides.** The item editor decides what to render and
 * `validateItemData` decides what to require, and those two answering differently is a field an
 * editor cannot see and cannot save without. Same argument as `resolveSeo` living in core so the
 * preview and the published page cannot disagree, and `canChangeStatus` so a dropdown cannot offer
 * a status the boundary then refuses.
 *
 * Pure, with no database handle, so the editor island can run it on every keystroke.
 */
/**
 * The operators, chosen to cover what a condition is actually for rather than to be complete.
 *
 * `is_checked` is separate from `equals "true"` because a checkbox is the overwhelming case and
 * spelling it as a string comparison against a boolean is how somebody ends up writing `"false"`
 * and getting a truthy value. `is_set` / `is_empty` cover "they picked something" without needing to
 * know what, which is what a relation, a media field or a taxonomy wants.
 */
export declare const VISIBILITY_OPERATORS: readonly ["is_checked", "is_not_checked", "equals", "not_equals", "is_set", "is_empty"];
export type VisibilityOperator = (typeof VISIBILITY_OPERATORS)[number];
/** Operators that read `value`; the rest ignore it, and the builder hides the input for them. */
export declare const OPERATORS_TAKING_VALUE: readonly VisibilityOperator[];
export declare const visibilityCondition: z.ZodObject<{
    field: z.ZodString;
    operator: z.ZodEnum<{
        is_checked: "is_checked";
        is_not_checked: "is_not_checked";
        equals: "equals";
        not_equals: "not_equals";
        is_set: "is_set";
        is_empty: "is_empty";
    }>;
    value: z.ZodOptional<z.ZodString>;
}, z.core.$strict>;
export type VisibilityCondition = z.infer<typeof visibilityCondition>;
/** Read a stored `visible_when`, tolerating anything unparseable as "unconditional". */
export declare function parseVisibility(raw: string | null | undefined): VisibilityCondition | null;
/**
 * Evaluate one condition against the sibling values at the same level.
 *
 * `known` is the set of sibling `api_id`s **from the schema**, and it is what makes a dangling
 * condition fail *open*. Without it, a condition naming a field somebody has since deleted or
 * renamed reads its value as `undefined`, `is_checked` answers false, and the dependent field is
 * hidden permanently with nothing on any screen able to say why — a content-type edit quietly
 * making an input unreachable. Absent data on a field that *does* exist is a different thing and is
 * evaluated normally: a checkbox nobody has ticked is unticked, not unknown.
 */
export declare function evaluateVisibility(condition: VisibilityCondition, siblings: Record<string, unknown>, known?: ReadonlySet<string>): boolean;
/**
 * Whether one field is shown, given the fields it sits beside and their current values.
 *
 * "Beside" is always the same level and deliberately nothing wider: a top-level field sees the
 * item's data, a block's field sees that block's `data`, a repeater sub-field sees that row's
 * `data`. That scope costs nothing to enforce because every walk already has exactly it in hand —
 * `validateBlocks` recurses with the block's own fields and data, `validateRepeater` with the row's
 * — and a condition reaching across levels would have to name a path, which is a different feature
 * with a different builder.
 */
export declare function isFieldVisible(field: FieldRow, siblings: FieldRow[], data: Record<string, unknown>): boolean;
/** Does this field have a condition at all? Read by typegen, which must emit it optional. */
export declare function fieldIsConditional(field: FieldRow): boolean;