/**
 * Computing a `<pool>` — once, before any row exists.
 *
 * Separate from `pool.ts` only to keep the imports acyclic: `build.ts` needs
 * the pool TYPE and the member pick, while computing a pool needs `build.ts`
 * itself. The split costs one file and buys a dependency graph that stays a
 * graph.
 *
 * Every pool draws from a DERIVED seed, `<seed>#pool:<Name>`. This is the one
 * decision here worth arguing for. The alternative — taking the pool's values
 * off the main stream — would mean that adding a pool to a config silently
 * shifts every column declared after it: the ids stay, but the ages, the names
 * and the dates all move, and a snapshot recorded last week stops matching for
 * a reason nobody can see in the diff. With a derived seed a pool is invisible
 * to everything it does not feed.
 */
import { type SequenceBuildOptions } from './build.js';
import type { PoolSpec, PoolTables } from './pool.js';
/** The seed a pool's own values are drawn from. Part of the cross-language contract. */
export declare function poolSeed(seed: string, poolName: string): string;
/**
 * Compute every pool declared in the config.
 *
 * A pool is built by the ordinary sequence machinery with `count` set to the
 * member count instead of the row count — which is the whole reason a `<uniq>`,
 * a `<mix>`, an `if=` or a `parent=` inside a pool behaves exactly as it does
 * outside one, with no code here to make it so.
 */
export declare function buildPoolTables(pools: readonly PoolSpec[], seed: string, locale: string, now: number, options?: SequenceBuildOptions): PoolTables;
//# sourceMappingURL=pool-build.d.ts.map