import { type ToolContext } from '../tools/types.js';
import { type FunctionalComponentRole, type FunctionalLayoutConstraints, type FunctionalLayoutPlan } from '../layout/planner.js';
import type { PlacementConstraintRegion } from '../layout/placement.js';
import type { PrimitiveRotation } from './primitive-bounds.js';
import type { SchematicSheetGeometry } from '../schematic-engine/geometry.js';
export interface LiveFunctionalLayoutComponentInput {
    primitiveId: string;
    blockId: string;
    role: FunctionalComponentRole;
    parentId?: string;
    preferredRotation?: PrimitiveRotation;
    allowedRotations?: readonly PrimitiveRotation[];
    minimumProximity?: number;
}
export interface GatherLiveFunctionalLayoutPlanOptions {
    a3FallbackAllowed?: boolean;
    constraints?: Partial<FunctionalLayoutConstraints>;
    /** Extra caller-supplied hard keepouts, in addition to the inferred title-block region. */
    hardKeepouts?: readonly PlacementConstraintRegion[];
}
/**
 * Builds the engine's richer SchematicSheetGeometry (bounds/drawableBounds/
 * titleBlockBounds) from the same sheet-info-derived width/height/margin logic
 * already proven correct by easyeda_schematic_layout_qa, rather than
 * re-deriving page geometry a second, possibly-inconsistent way.
 *
 * EasyEDA's live schematic coordinates put the page's top-left reference point
 * at (0, 0) with content extending in +X (right) and -Y (downward) -- observed
 * across every live design read this session (all real component Y values are
 * <= 0). `yAxis: 'up'` here documents that increasing Y visually goes up, i.e.
 * the page rectangle spans y in [-height, 0].
 */
export declare function buildEngineSheetGeometry(rawSheetInfo: unknown): SchematicSheetGeometry;
/**
 * Reads sheet geometry, real placed-component bounds (via the #271
 * primitive-bounds engine), and a caller-supplied functional inventory from
 * the live bridge, then runs the deterministic layout planner
 * (`planFunctionalLayout`) against them.
 *
 * Components not present in `components` are treated as pre-existing,
 * unrelated occupied regions -- the planner must never place a new block on
 * top of them (acceptance criterion: existing primitives are never
 * overwritten).
 */
export declare function gatherLiveFunctionalLayoutPlan(ctx: ToolContext, projectId: string, components: readonly LiveFunctionalLayoutComponentInput[], options?: GatherLiveFunctionalLayoutPlanOptions): Promise<FunctionalLayoutPlan>;