import { CollectionConfig, ResolvedRelation } from "@rebasepro/types";
import { PostgresCollectionRegistry } from "./PostgresCollectionRegistry";
/**
 * Check every relation against the schema it actually runs on, at boot.
 *
 * The tagged union made the *shape* of a relation impossible to get wrong: a
 * `manyToMany` cannot carry a `foreignKeyOnTarget`, a to-many cannot carry a
 * `localKey`. What it cannot know is whether any of the names are real —
 * whether `posts_tags` is a table, whether `author_id` is a column, whether a
 * `joinPath` connects the tables it claims to. Those are facts about the
 * database, and the type system never sees them.
 *
 * Until now nothing checked them until a query ran, and the failures were the
 * quiet kind. A missing junction table logged a warning and returned no rows,
 * so `posts/1/tags` answered `[]` — indistinguishable from a post with no tags.
 * The relation looked configured, the admin drew the tab, the tab was empty,
 * and nothing anywhere said why.
 *
 * The junction default is the sharp edge this exists for. `through.table`
 * defaults to the two table names sorted and joined, so renaming a table
 * silently re-points the relation at a name that was never created. It is the
 * one default whose output changes when you edit something that looks
 * unrelated.
 */
export interface RelationDefect {
    /** Slug of the collection declaring the relation. */
    collection: string;
    relationName: string;
    kind: ResolvedRelation["kind"];
    /** What is wrong, in terms of the schema. */
    problem: string;
    /** The edit that fixes it. */
    fix: string;
}
/**
 * Relations whose names do not resolve against the registered schema.
 *
 * Fails open wherever it cannot see enough to be sure — an unregistered source
 * table, a target belonging to another backend — because a false alarm here
 * costs more than a missed one: it would block boot on a working app.
 */
export declare function findRelationDefects(collections: CollectionConfig[], registry: PostgresCollectionRegistry): RelationDefect[];
/**
 * Fail boot on any relation that cannot resolve, listing all of them at once.
 *
 * Deliberately fatal rather than a warning. Every one of these produces an
 * empty result at query time and nothing else — an empty tab, an empty
 * `include`, a subcollection that looks like it has no rows. A server that
 * refuses to start is recoverable in a minute; a relation that quietly answers
 * "nothing" is the kind of bug found in production, weeks later, by a user
 * asking where their data went.
 */
export declare function assertRelationsResolve(collections: CollectionConfig[], registry: PostgresCollectionRegistry): void;