import { Attribute, Entity } from './types';
/**
 * 다음 표시 순서 값 = 현재 최대 `order` + 1(비어 있으면 0). 표시 순서가 `order` 필드 단일 SoT이므로
 * add-side는 반드시 이 값을 써야 order가 항상 distinct하다. 배열 `.length`를 쓰면
 * `removeAttribute`/`removeOperation`가 재인덱싱하지 않아(splice만) 남은 order와 length가 충돌할 수
 * 있다(order [0,2] + length 2 → 신규 order 2 = 중복). [[attribute-display-order-array-vs-order-field]]
 */
export declare function nextOrder(items: readonly {
    order: number;
}[]): number;
/**
 * 재정렬 결과 순서 — 대상(`movingIds`)을 현재 상대 순서를 유지한 채 `toIndex`로 옮긴 배열.
 * `toIndex`는 **대상을 모두 뺀 배열(rest) 기준 삽입 위치**다.
 *
 * 순수 함수로 뽑은 이유: 같은 산식을 세 곳이 쓴다 — `commands.reorderAttributes`/`reorderOperations`의
 * apply, 그리고 **임베드 슬롯 정렬 전파**(`embedSlots.planEmbedSlotReorder` 호출부)가 커밋 전에
 * "재정렬 후 순서"를 미리 알아야 한다. 각자 splice를 다시 쓰면 전파가 실제 재정렬과 어긋난다.
 */
export declare function reorderedSequence<T extends {
    modelId: string;
}>(items: readonly T[], movingIds: readonly string[], toIndex: number): T[];
/** 물리 FK 컬럼을 가진 FK 여부 — derivedFrom(관계 파생) + dbAttrs(물리 컬럼) 보유. */
export declare function isPhysicalFk(a: Attribute): boolean;
/**
 * 물리 FK 컬럼을 가진 FK를 순수 PK 바로 뒤로 당긴다. `순수 PK → 물리 FK → 나머지` 순으로 재배열하되,
 * FK끼리·나머지끼리의 상대 순서는 원본 order를 보존한다(순서를 새로 추정하지 않음). 순수 PK가 없으면
 * FK를 맨 앞으로. 물리 컬럼 없는 nav 참조(dbAttrs=0)는 추정이라 제외 — 실제로 그런 참조는 어느 엔티티
 * attributes에도 물질화되지 않으므로(유령 앵커 참조) 대상이 되는 일도 없다.
 *
 * ★ order 필드뿐 아니라 **배열 물리 순서 자체**를 재정렬한다. 캔버스 노드(EntityNode)는 attributes를
 * 배열 순서 그대로 렌더하고(order 정렬 미적용), 코드젠·탐색기는 order로 정렬하므로, 둘을 일치시켜야
 * 모든 표시 경로에서 순서가 같다. [[attribute-display-order-array-vs-order-field]]
 *
 * 경계 강등(mergeDiagram)으로 derivedFrom이 제거된 FK는 `isPhysicalFk`가 false라 일반 컬럼으로 제자리에
 * 남는다 — 강등 이후에 호출해야 한다.
 */
export declare function reorderForeignAttributes(entities: Entity[]): void;