/**
 * Pure query-building helpers for the aggregate `GET /posts` admin endpoint.
 *
 * Kept dependency-free (no Prisma, no DB) so the filter/sort logic that drives
 * cross-collection pagination is unit-testable in isolation. The route handler
 * in `api/handlers.ts` composes these into the actual Prisma queries.
 */
export type PostsSortBy = 'title' | 'type' | 'author' | 'status' | 'date' | 'seo';
export type SortDir = 'asc' | 'desc';
export interface PostsQueryInput {
    /** post-type slugs the caller is allowed to read */
    allowedCollections: string[];
    /** restrict to a single post type, or 'all' */
    postType?: string;
    status?: string;
    author?: string;
    search?: string;
    sortBy?: PostsSortBy;
    sortDirection?: SortDir;
}
/**
 * Which collections a query should actually scan: a single requested type when
 * it's allowed, otherwise every allowed post collection. An unknown/forbidden
 * requested type collapses to an empty set so the query returns nothing rather
 * than leaking other collections.
 */
export declare function resolveQueryCollections(input: PostsQueryInput): string[];
/**
 * Build the Prisma `where` filter for the posts query. Returns a plain object
 * (typed loosely as the Prisma document filter) so it can be asserted in tests
 * without importing Prisma types.
 */
export declare function buildPostsWhere(input: PostsQueryInput): Record<string, unknown>;
/**
 * Map the UI sort field to a Prisma `orderBy`. `date`/`type`/`status`/`title`
 * map to scalar columns and `author` orders by the related user's name. `seo`
 * has no DB-sortable column (the score lives in the JSON `data` blob), so it
 * falls back to most-recently-updated — callers should treat seo as a
 * best-effort sort.
 */
export declare function buildPostsOrderBy(sortBy?: PostsSortBy, dir?: SortDir): Record<string, unknown>;
/** Extract a numeric SEO score from a document's JSON data, if present. */
export declare function extractSeoScore(data: unknown): number | null;
//# sourceMappingURL=query.d.ts.map