import { Editor } from '../../core/Editor.js';
export interface RepairBlockIdentitiesReport {
    /** Total number of block nodes whose identity attrs were rewritten. */
    repairedBlockCount: number;
    /** The original identity values that collided (one entry per duplicate group). */
    duplicateBlockIds: string[];
    /** The original→replacement mapping applied (deterministic, useful for tests/logs). */
    renames: Array<{
        originalValue: string;
        replacementValue: string;
        attrs: string[];
    }>;
}
/**
 * Identifies duplicate block identities in the editor's current state and, if
 * any are found, dispatches a single transaction that renames the duplicate
 * halves using the same deterministic allocator as the import-time normalizer.
 *
 * Returns a report describing what was repaired. Returns `null` if no repair
 * was necessary.
 *
 * The transaction is marked with `addToHistory: false` because the rename is
 * remediation, not user intent — undoing it would just put the editor back
 * into the broken state.
 *
 * Uses per-attribute `tr.setNodeAttribute` calls (not `setNodeMarkup`) because
 * those emit PM AttrSteps with no `from`/`to` range. Transaction filters that
 * gate ranged steps (`structured-content-lock-plugin.filterTransaction` skips
 * "steps without from/to" by design; `permission-ranges` follows the same
 * convention) cannot silently reject metadata-only rewrites, so a duplicate
 * paraId sitting inside a locked SDT is still repaired. See
 * `sdt-properties-write.ts` for the same documented pattern.
 *
 * After dispatch we verify the planned attrs actually landed on the doc. If a
 * filter rejected the transaction anyway, we surface that as an explicit
 * `REPAIR_BLOCKED` error rather than returning a misleading success report —
 * see
 */
export declare function repairDuplicateBlockIdentities(editor: Editor): RepairBlockIdentitiesReport | null;
//# sourceMappingURL=repair-block-identities.d.ts.map