import type { Query } from '../../kernel/query/builder.js';
import type { MaterializedViewStrategy } from './types.js';
/**
 * Walks a `Query<T>` plan and returns the set of source collection
 * names that any source-write should trigger a refresh on.
 *
 * Handles:
 *   - root collection (the one the query was built from)
 *   - FK join targets (`.join(field, { as })`)
 *
 * Also handles:
 *   - cross-join targets (`.crossJoin(target, { as })`) — v3
 *
 * Deferred:
 *   - `.wherePredicate(name)` — v2 predicate primitive
 *   - Overlay-name expansion to {base, overlay}
 *
 * The set is materialized at MV registration time. The MV registry
 * uses it to (a) dispatch `onSourceWrite` only to MVs that actually
 * care, and (b) contribute edges to the shared cycle-detection graph.
 */
export declare function analyzeDependencies(query: Query<any>): Set<string>;
/**
 * Convenience: produce a stable string summary of the query plan
 * suitable for `queryHash` derivation. Captures everything the
 * dependency analyzer reads + the where/orderBy/limit/offset
 * structure that affects materialized rows.
 *
 * `joinContext` is intentionally NOT included — the join-resolution
 * function references would defeat hash determinism. The set of join
 * TARGETS (collection names) IS included via the plan.joins legs.
 */
export declare function summarizeQueryPlan(query: Query<any>): string;
/**
 * Canonical string description of a UNION MV's plan, used as input to
 * `computeQueryHash`.
 *
 * Asymmetry note:
 *   - Arm collection names are NOT sorted. Declaration order is
 *     semantically meaningful for the dedup-only UNION path —
 *     `materializeUnionResult` iterates `spec.unionSources` in
 *     declaration order and keeps the first-seen row per composite key
 *     (tie-break precedence). If we sorted arms here, a consumer who
 *     reordered `unionSources` to change precedence would compute the
 *     same `queryHash`, refresh would be a no-op, and stale MV rows
 *     would persist. Hashing in declaration order makes any reorder
 *     trigger a refresh.
 *   - `groupBy` fields ARE sorted. Multi-key groupBy buckets are
 *     commutative (`canonicalGroupKey` produces the same composite key
 *     regardless of field order in the input spec).
 *   - `aggregate` keys ARE sorted. Reducer-spec keys are independent
 *     of each other — order of declaration doesn't change output.
 *
 * Per-arm `map` functions are NOT fingerprinted; consumers must bump
 * the MV's `name` (or rely on application-level cache busting) when
 * `map` semantics change non-equivalently.
 */
export declare function summarizeUnionPlan<T extends Record<string, unknown>>(spec: MaterializedViewStrategy<T>): string;