/**
 * Filter sidebar detection and configuration resolution.
 *
 * Design reference: docs/design/list-search-filters.md §3.5, §5.5, §6, §8.
 *
 * Auto-detection is intentionally narrow — Boolean and enum only — because
 * their value domain is known STATICALLY from the schema (zero extra query
 * to render the sidebar). DateTime, numeric ranges, and FK all require
 * explicit `listFilter` config (DateTime presets are an editorial choice,
 * ranges need two inputs not a fixed set, FK needs a query to load options
 * — see §3.5, §6.2). This is a deliberate perf guard: an auto-detect
 * heuristic that fires `groupBy`/`findMany` on every list render is a trap
 * that can't be removed later without a breaking change.
 */
import type { PrismaModel } from '../introspection/parser.js';
import type { RelationGraph } from '../introspection/relations.js';
export declare const DATETIME_PRESETS: readonly ["today", "7d", "month", "year"];
export type DateTimePreset = (typeof DATETIME_PRESETS)[number];
export type ListFilterConfigEntry = string | {
    field: string;
    label?: string;
    /** DateTime only: which shortcuts to offer as sidebar links (default: all four, §5.5). */
    presets?: DateTimePreset[];
    /** Numeric field only: render two `gte`/`lte` inputs in a GET form instead of a fixed link set. */
    range?: boolean;
};
export interface ResolvedFilterField {
    field: string;
    label: string;
    kind: 'boolean' | 'enum' | 'datetime' | 'range' | 'fk';
    /** Only present for kind 'enum'. */
    enumValues?: string[];
    /** Only present for kind 'datetime'. */
    presets?: DateTimePreset[];
}
/** A filter entry that was configured as an FK scalar (e.g. `authorId` on Post), with its target relation resolved. */
export interface FkFilterSpec {
    /** Scalar FK field name, e.g. `authorId`. */
    field: string;
    label: string;
    /** Owning relation field name on this model, e.g. `author`. */
    relationField: string;
    /** Target model name, e.g. `User`. */
    targetModel: string;
}
/**
 * Validate a `listFilter` config entry against the schema at boot time.
 * Invalid config throws immediately — a developer typo (unknown field,
 * sensitive field, relation, Json/Bytes) should fail loud at startup, not
 * silently produce a sidebar entry that does nothing. This is a DIFFERENT
 * failure mode than a forged URL (§5.4 of the design doc): bad config is a
 * developer error, a bad URL is untrusted input that must degrade quietly.
 */
export declare function validateListFilterConfig(modelName: string, entries: ListFilterConfigEntry[], model: PrismaModel, relationGraph?: RelationGraph, hidden?: Set<string>): void;
/**
 * Trouve l'arête to-one-owning qui porte ce scalaire FK sur ce modèle, si
 * elle existe. Lookup direct sur `edges` avec la clé `"Model.field"` — on ne
 * passe PAS par `scalarToRelation` (indexée par nom de champ seul, donc
 * ambiguë si deux modèles ont une FK du même nom, ex: `Post.authorId` et
 * `Comment.authorId`).
 */
export declare function findFkEdge(relationGraph: RelationGraph, modelName: string, scalarFieldName: string): import("../introspection/relations.js").RelationEdge | undefined;
/**
 * Resolve the filter sidebar entries for a model: explicit `listFilter`
 * config wins (already validated at boot by `validateListFilterConfig`),
 * otherwise the auto-detect heuristic (Boolean + enum fields) — unless
 * `autoDetect` is explicitly disabled, in which case a model with no
 * explicit `listFilter` gets no sidebar at all rather than a heuristic
 * one it didn't ask for.
 */
export declare function resolveListFilters(model: PrismaModel, enums: Map<string, string[]>, configured: ListFilterConfigEntry[] | undefined, toLabel: (name: string) => string, relationGraph?: RelationGraph, hidden?: Set<string>, autoDetect?: boolean): ResolvedFilterField[];