/**
 * @module @nhtio/adk/eslint/rules/require_validator_any_required
 *
 * Flags every `validator.any()` schema chain that does not declare intent with `.required()`
 * or `.optional()`.
 *
 * Why: in `@nhtio/validation`, `.any()` ADMITS `null`/`undefined` unless you make it `.required()`.
 * That default is silent and easy to miss — a schema you believe rejects missing values quietly
 * accepts them, and any `.custom()` refinement is skipped for an absent value (a `.custom()` guard
 * is the usual way this surfaces, e.g. `implementsX(undefined) === true`). The fix is to make the
 * disposition an EXPLICIT declaration with no ambiguity — every `.any()` must say which it is:
 *   - `.required()`  → reject null/undefined
 *   - `.optional()`  → deliberately allow null/undefined
 *   - `.default(x)`  → allow absence, substituting a fallback value
 *   - `.forbidden()` → the value must be absent
 * This applies whether the `.any()` is top-level or nested inside `items(...)` / `alternatives(...)`:
 * the enclosing schema being `.required()` does NOT govern an inner `.any()`'s null/undefined handling.
 *
 * The sharpest illustration is `.valid(null)`: an author writing `validator.any().valid(null)`
 * means "must be exactly null" — but because `.any()` admits `undefined`, that schema actually
 * accepts BOTH `null` and `undefined` (and `undefined !== null`). The fix is
 * `validator.any().required().valid(null)`.
 *
 * Opt-out (e.g. a bare `.any()` used purely as a type argument like `items(validator.any())`):
 *   // eslint-disable-next-line adk/require-validator-any-required -- <reason>
 */
/** ESLint rule: flags a validator `any()` schema lacking an explicit required/optional/forbidden disposition. */
declare const requireValidatorAnyRequiredRule: import("@typescript-eslint/utils/ts-eslint").RuleModule<"declareIntent", [
], unknown, import("@typescript-eslint/utils/ts-eslint").RuleListener> & {
    name: string;
};
export default requireValidatorAnyRequiredRule;