/**
 * This Source Code is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/.
 *
 * Copyright (c) Infonomic Company Limited
 */
import type { DocumentFieldIssue } from '../../validation/document-fields.js';
import type { DocumentLifecycleContext } from './context.js';
export interface RestoreVersionResult {
    revision: number;
    documentId: string;
    documentVersionId: string;
    sourceVersionId: string;
    /**
     * Ways the restored content fails today's field validation. Restore is
     * exempt from that gate, so these never block it — they are reported so the
     * editor can say what must be fixed before the next ordinary save, which is
     * validated in full.
     */
    validationIssues?: DocumentFieldIssue[];
}
/**
 * Restore a historical document version as the new current version.
 *
 * Reads the source version with `locale: 'all'` so the entire multi-locale
 * field tree (with `_id` / `_type` meta inlined onto blocks and array items
 * by `reconstructFromUnifiedRows`) is captured. That tree is then re-emitted
 * through `createDocumentVersion` with `locale: 'all'`, which produces a
 * fresh version row with a new UUIDv7 id and the latest `created_at`. The
 * `current_documents` view (`ROW_NUMBER() OVER PARTITION BY document_id
 * ORDER BY created_at DESC`) automatically promotes the new row to current.
 *
 * Status is hard-defaulted to the collection's configured default status.
 * For the standard editorial workflow that is `draft`, so restoring an old
 * `published` version does not re-publish it and the user runs the restored
 * draft through the normal workflow. It is NOT a guarantee: a workflow whose
 * `defaultStatus` is `published` — `SINGLE_STATUS_WORKFLOW`, or any workflow
 * configured that way — restores directly to published.
 *
 * Restore is exempt from the field-validation gate that every other versioned
 * write passes through (see `assertWritableContent`). Historical content was
 * persisted under earlier schema and validation rules, and cannot be corrected
 * before it is restored; enforcing today's rules would make it permanently
 * unrecoverable. Combined with the status default above, that means a
 * published-default workflow can republish restored content which fails
 * current validation, and `beforeUpdate` hooks on a restore run inside the
 * same exemption. Both are accepted recovery semantics. The issues are
 * computed and returned as `validationIssues` for the editor to report.
 *
 * `path` is sticky from the previous current version (not from the source),
 * matching the semantics of `updateDocument`. A path change made between
 * the source and now should not be undone by the restore.
 *
 * Auth reuses the `update` ability — restore is conceptually an edit
 * against an existing document.
 *
 * Hooks: fires `beforeUpdate` / `afterUpdate` with a `restore: { sourceVersionId }`
 * field on the context. Userland hooks that need to react differently
 * (e.g. tag the audit entry, skip search re-index) can branch on its
 * presence.
 *
 * Flow:
 *   1. Auth: `update` ability.
 *   2. Read source version with `locale: 'all'`.
 *   3. Validate source belongs to `documentId` (defence against forged
 *      cross-document version ids).
 *   4. Read current version metadata; reject if the source IS already the
 *      current version (nothing to restore).
 *   5. Read current document with reconstruction for hook `originalData`.
 *   6. `hooks.beforeUpdate({ data, originalData, collectionPath, restore })`
 *   7. `db.commands.documents.createDocumentVersion(...)` with
 *      `action: 'restore'`, `locale: 'all'`, sticky path, default status.
 *   8. `hooks.afterUpdate({ ..., restore })`
 */
export declare function restoreDocumentVersion(ctx: DocumentLifecycleContext, params: {
    documentId: string;
    expectedRevision: number;
    sourceVersionId: string;
}): Promise<RestoreVersionResult>;