import { Issue } from "@ebec/core";
import { ValidatorContext, ValidatorDescriptor, ValidupError } from "validup";
import { $ZodRawIssue } from "zod/v4/core";
import { ZodError, ZodType, output } from "zod";
//#region src/error.d.ts
type ZodIssue = $ZodRawIssue;
/**
 * Translate a `ZodError` into validup `Issue`s. Each zod issue gets:
 *
 * - `code` — mapped onto the validup `IssueCode` vocabulary where
 *   possible (see {@link mapZodIssue} for the table); falls back to
 *   `IssueCode.VALUE_INVALID` for zod codes that don't have a vocabulary
 *   equivalent.
 * - `message` — zod's own message, verbatim. Consumer-side i18n
 *   catalogs override this via the `code` lookup; `message` is the
 *   English fallback when no translation is registered.
 * - `data` — structured payload for code-aware templates
 *   (`{{min}}` / `{{max}}` / `{{pattern}}`); absent when the code
 *   carries no parameters.
 * - `expected` / `received` — vendor-specific zod fields, passed
 *   through when present.
 *
 * Pass the original parsed input as the second argument to enable the
 * `invalid_type` → `REQUIRED` promotion: zod 4's formatted issues don't
 * carry `received`, so we recover the missing-key signal by looking up
 * the issue's path against the input and checking whether the leaf is
 * `undefined`. {@link createValidator} threads `ctx.value` through
 * automatically; ad-hoc callers can opt in by passing it explicitly.
 */
declare function buildIssuesForZodError(error: ZodError, input?: unknown): Issue[];
/**
 * Build Zod Issues for validup issue.
 *
 * @param issue
 */
declare function buildZodIssuesForIssue(issue: Issue): ZodIssue[];
declare function buildZodIssuesForError(error: ValidupError): ZodIssue[];
//#endregion
//#region src/module.d.ts
type ZodCreateFn<C, Z extends ZodType> = (ctx: ValidatorContext<C>) => Z;
/**
 * Options accepted by {@link createValidator}.
 */
type ZodCreateValidatorOptions = {
  /**
   * Mark the resulting validator as having side effects (network
   * calls, sibling-field reads, observable state) so the framework
   * never caches its outcome. Default `false` — most zod schemas
   * (`z.string().email()`, length / regex / enum checks) are
   * deterministic and safe to cache by `(ctx.value, ctx.context,
   * ctx.group)`. Set to `true` for schemas that use async refines,
   * `superRefine` calls reading external state, or transforms with
   * side effects.
   */
  sideEffect?: boolean;
};
/**
 * Wrap a zod schema as a validup `ValidatorDescriptor`. The returned
 * descriptor infers its `Out` type from the schema, so the builder API
 * (`defineSchema`) and any caller using the second `Validator<C, Out>`
 * generic see the parsed shape (`z.output<Z>`) rather than `unknown`.
 *
 * Pass a factory `(ctx) => schema` to build per-context schemas.
 *
 * Returned as a {@link ValidatorDescriptor} (not a bare function) so it
 * can carry the `sideEffect` flag the validup runtime consults for its
 * result cache. Mounts unchanged via the same `container.mount(...)`
 * signatures — bare-function and descriptor inputs are interchangeable
 * at the mount site.
 */
declare function createValidator<C = unknown, Z extends ZodType = ZodType>(input: Z | ZodCreateFn<C, Z>, options?: ZodCreateValidatorOptions): ValidatorDescriptor<C, output<Z>>;
//#endregion
export { ZodCreateValidatorOptions, ZodIssue, buildIssuesForZodError, buildZodIssuesForError, buildZodIssuesForIssue, createValidator };
//# sourceMappingURL=index.d.mts.map