import { ViewportContext, ViewportEntityHit, ViewportPositionHit, ViewportRect, SelectionSlice } from './types.js';
/**
 * Returns true when `(x, y)` lies inside any of the provided
 * viewport-relative rects. Uses inclusive bounds so a click on a
 * rect's edge still counts as "inside" — consumers rendering selection
 * highlights expect right-clicks on the highlight border to be treated
 * as inside the selection.
 *
 * Empty rects array (no live selection / collapsed caret) returns
 * false, which is what `insideSelection` semantically means.
 */
export declare function pointInsideRects(x: number, y: number, rects: ReadonlyArray<ViewportRect>): boolean;
/**
 * Build the {@link ViewportContext} bundle from already-resolved
 * primitives. The controller calls each primitive itself (entityAt,
 * positionAt, ui.selection.getRects, current selection slice) and
 * passes the results in here so this helper stays pure.
 */
export declare function buildViewportContext(args: {
    x: number;
    y: number;
    entities: ViewportEntityHit[];
    position: ViewportPositionHit | null;
    selection: SelectionSlice;
    selectionRects: ReadonlyArray<ViewportRect>;
}): ViewportContext;
/**
 * Type guard for the bundle vs the legacy `{ entities }` call shape
 * accepted by `ui.commands.getContextMenuItems(input)`.
 *
 * Requires `point` to be a non-null object with numeric `x` / `y`.
 * `typeof null === 'object'` is the easy trap here, plus a hand-built
 * `{ entities, point: null }` should keep the legacy path so the
 * registry doesn't read `entities` from a partial bundle whose other
 * fields are `undefined`. Both call layers (controller proxy and
 * registry) route through this guard so they cannot disagree.
 */
export declare function isViewportContextBundle(input: unknown): input is ViewportContext;
//# sourceMappingURL=viewport-context.d.ts.map