import { m as JsonObject, w as SchemaMeta } from "./types-BBQaEPfE.mjs";
import { i as DiagnosticsOptions } from "./diagnostics-mftUZI7c.mjs";

//#region src/core/adapter.d.ts
/**
 * Classification produced by {@link detectSchemaKind} when inspecting a
 * runtime schema input.
 *
 * @group Adapter
 */
type SchemaKind = "zod4" | "zod3" | "jsonSchema" | "openapi" | "unsupported-schema-lib";
/**
 * Classify a runtime schema input by structural markers — Zod 4, Zod 3,
 * OpenAPI document, plain JSON Schema, or an unsupported third-party
 * schema library.
 *
 * - `zod4` — has a `_zod` marker (further validation that `_zod.def` is a
 *   non-null object happens inside `normaliseZod4`).
 * - `zod3` — has `_def` and no `_zod`. The `typeName` field is no longer
 *   required: any `_def` without `_zod` is treated as a probable Zod 3
 *   schema. Third-party libraries that expose `_def` without `_zod` are
 *   nearly always Zod 3 forks; surfacing the migration message is the
 *   correct response.
 * - `openapi` — has `openapi` or `swagger` at the root.
 * - `unsupported-schema-lib` — has `parse` and `safeParse` callables but
 *   no `_zod` and no `_def` marker. This catches Standard Schema
 *   implementations (valibot, arktype, etc.) that would otherwise flow
 *   through as "malformed JSON Schema".
 * - `jsonSchema` — fallback for anything that does not match the above.
 *
 * @group Adapter
 */
declare function detectSchemaKind(input: unknown): SchemaKind;
/**
 * Wraps z.toJSONSchema() for a runtime-validated Zod schema.
 *
 * The _zod guard in normaliseZod4 has confirmed this is a valid Zod schema,
 * but TypeScript cannot represent "has _zod.def" as the $ZodType parameter
 * that z.toJSONSchema expects. This is the library boundary equivalent of
 * `object → Record<string, unknown>` — the type mismatch is genuinely unavoidable.
 *
 * # Options
 *
 * `z.toJSONSchema` is invoked with an explicit options object rather than
 * Zod's defaults so the conversion contract is pinned and stable:
 *
 * - `target: "draft-2020-12"` — matches the walker's draft target.
 * - `unrepresentable: "throw"` — keeps the unrepresentable-type rules in
 *   the classifier table firing instead of silently emitting `{}`.
 * - `cycles: "ref"` — converts cyclic graphs into $ref pairs rather than
 *   throwing. Cycles in user schemas surface through the walker's $ref
 *   resolution rather than the adapter.
 * - `io` — selects which side of every transform / pipe / codec is
 *   converted. Defaults to `"output"` (the OUTPUT side); pass `"input"`
 *   to render the INPUT side instead. The input side is invisible to
 *   the converted schema when `io: "output"` is in force, even though
 *   `safeParse` on the same Zod schema consumes the input shape. For
 *   transforms this divergence is fatal and the call throws via
 *   `Transforms cannot be represented`; for `z.codec(...)` the call
 *   succeeds but only the selected side is rendered. Consumers receive
 *   a `zod-codec-output-only` diagnostic in the codec case so the
 *   asymmetry is visible — see `screenPreConversion`.
 *
 * # Error classification
 *
 * Any exception thrown by z.toJSONSchema is classified into a
 * SchemaNormalisationError so the caller does not have to re-parse error
 * message strings. The classification covers:
 *
 * - Nested Zod 3 schemas inside a Zod 4 tree → zod3-unsupported.
 *   Detected structurally (presence of `_def.typeName` markers anywhere
 *   in the schema tree) so the check works across V8, JavaScriptCore,
 *   and SpiderMonkey, none of which agree on the wording of
 *   "Cannot read properties of undefined".
 * - Transforms → zod-transform-unsupported. This also catches `z.codec(…)`
 *   because Zod implements codecs as a pipe + transform internally, so
 * they trip the same processor when round-tripping is forced. (Plain
 *   `z.toJSONSchema(codec)` itself does NOT throw because Zod picks one
 *   side of the codec; the static rejection in `typeInference.ts` is the
 *   compile-time guard.)
 * - Dynamic catch values whose handler throws → zod-type-unrepresentable
 *   with zodType "dynamic-catch".
 * - Unrepresentable types — bigint, date, map, set, symbol, function, custom,
 *   undefined, void, NaN, and the literal-only forms `z.literal(undefined)`
 *   ("undefined-literal") and `z.literal(<bigint>)` ("bigint-literal") →
 *   zod-type-unrepresentable.
 * - The catch-all "Non-representable type encountered: <type>" fallback Zod
 *   emits for any new schema kind without a registered processor →
 *   zod-type-unrepresentable with zodType set to the offending def.type.
 * - Cycle detected (`cycles: "throw"`) → zod-cycle-detected.
 * - Duplicate schema id → zod-duplicate-id.
 * - "Unprocessed schema. This is a bug in Zod." → zod-conversion-bug.
 * - "Error converting schema to JSON." → zod-conversion-failed (explicit
 *   classification rather than the generic fallback so the contract test
 *   protects the prefix from drift).
 * - Anything else → zod-conversion-failed.
 *
 * The original error is preserved on each classified error via the `cause`
 * field so consumers can still inspect the Zod stack trace.
 */
/**
 * Direction of the Zod transform / pipe / codec that
 * {@link normaliseSchema} should surface to the renderer.
 *
 * - `"output"` (default) — the server-facing side of every transform,
 *   matching `z.toJSONSchema`'s default and the historic adapter
 *   behaviour.
 * - `"input"` — the client-facing side; flips a `z.codec(...)` chain
 *   so consumers can render its input shape.
 *
 * @group Adapter
 */
type SchemaIoSide = "input" | "output";
/**
 * True when `value` is a Zod schema implemented as a codec
 * (`z.codec(...)`). Detection looks for the `$ZodCodec` marker on the
 * schema's `_zod.traits` Set — the same structural check used by Zod
 * itself in `to-json-schema.ts`'s `isTransforming` helper.
 *
 * Promoted from a duplicated local helper in `react/SchemaComponent.tsx`
 * so the validation boundary inside `runValidation` can branch on
 * codec-vs-not-codec without re-implementing the trait check. The
 * shared helper anchors a single source of truth for codec detection:
 * any future change to Zod's trait naming flows through here, not
 * through two parallel copies.
 *
 * Returns `false` for non-objects, plain JSON Schema inputs, OpenAPI
 * documents, or Zod schemas of any other kind. This is structural
 * rather than nominal — a Zod 4 codec produced by any path that ends
 * up tagging `_zod.traits` with `$ZodCodec` is recognised, including
 * schemas wrapped by user-defined helpers.
 */
declare function isCodecSchema(value: unknown): boolean;
/**
 * Exposed for unit testing — lets the contract test enumerate every rule's
 * `prefix` value and assert mutual non-prefixing.
 */
declare const __CLASSIFIER_RULES_FOR_TEST: readonly {
  readonly prefix: string;
}[];
/**
 * Result of {@link normaliseSchema}. Carries the canonical Draft 2020-12
 * JSON Schema the walker consumes, the optional original Zod schema
 * (used for validation), and the resolved root document so cross-document
 * `$ref`s can be dereferenced downstream.
 *
 * @group Adapter
 */
interface NormalisedSchema {
  /** JSON Schema object — the authoritative schema for rendering. */
  jsonSchema: JsonObject;
  /** Original Zod schema, if input was Zod. Used for validation. */
  zodSchema?: unknown;
  /** Root-level metadata. */
  rootMeta: SchemaMeta | undefined;
  /** The root document for $ref resolution. */
  rootDocument: JsonObject;
}
/**
 * Options accepted by {@link normaliseSchema}.
 *
 * @group Adapter
 */
interface NormaliseOptions {
  /** Diagnostics channel for surfacing silent fallbacks. */
  diagnostics?: DiagnosticsOptions;
  /**
   * Side of every transform / pipe / codec to render. Defaults to
   * `"output"`, matching `z.toJSONSchema`'s default and the
   * historic behaviour of the adapter. Passing `"input"` flips the
   * conversion so consumers rendering the input shape of a
   * `z.codec(...)` chain receive that side instead of the output
   * side. Only the Zod 4 branch consults this option — JSON Schema
   * and OpenAPI inputs are already a single canonical shape.
   */
  io?: SchemaIoSide;
}
/**
 * Normalise any supported schema input — Zod 4 schema, plain JSON
 * Schema (any draft), Swagger 2.0, OpenAPI 3.0 or 3.1 document — into
 * a canonical Draft 2020-12 {@link NormalisedSchema} the walker can
 * consume.
 *
 * Dispatches on {@link detectSchemaKind}, applies the appropriate
 * version normaliser, and returns the JSON Schema alongside the
 * original Zod schema (for validation) and the resolved root document
 * (for cross-document `$ref` resolution). Throws
 * `SchemaNormalisationError` for unsupported inputs (Zod 3, valibot,
 * arktype, codec or other unrepresentable Zod types).
 *
 * @group Adapter
 */
declare function normaliseSchema(input: unknown, ref?: string, options?: NormaliseOptions): NormalisedSchema;
/**
 * Surface root-level metadata from the JSON Schema into the `rootMeta`
 * shape consumed by the walker. Pulls `readOnly`, `writeOnly`,
 * `description`, `title`, `deprecated`, `examples`, and `default`
 * directly from the schema root.
 *
 * `examples` is forwarded only when present as an array (per JSON Schema
 * Draft 2020-12 — Draft 04's `example` singular is normalised upstream).
 * `default` is forwarded for any value the schema declares (any JSON
 * value, including `null` and `false`); the presence check uses `in`
 * so a literal `false` or `null` default is preserved.
 *
 * `examples` and `default` ride on the `[key: string]: unknown` index
 * signature of {@link SchemaMeta}. They are not declared as named fields
 * on `SchemaMeta` because that type lives in `types.ts` and is shared
 * with the walker; the index signature is the agreed extension point.
 */
declare function extractRootMetaFromJson(jsonSchema: JsonObject): SchemaMeta | undefined;
//#endregion
export { __CLASSIFIER_RULES_FOR_TEST as a, isCodecSchema as c, SchemaKind as i, normaliseSchema as l, NormalisedSchema as n, detectSchemaKind as o, SchemaIoSide as r, extractRootMetaFromJson as s, NormaliseOptions as t };