/**
 * Shared "the whole entity is gone on the tenant" resolution for every
 * recipe kind's `plan()`.
 *
 * When `readCurrent` returns null the entity doesn't exist on the
 * tenant. Each kind used to hardcode `return diff(desired, null)` — an
 * unconditional recreate that ignored the baseline AND the push conflict
 * policy. That made a deliberately-deleted entity silently reappear on
 * the next background sync, and it diverged from how field-level
 * cms-edits are handled.
 *
 * A missing entity with a STORED BASELINE is just the extreme case of a
 * cms-edit: the tenant changed it from "exists" to "doesn't exist". So
 * resolve it with the SAME conflict policy as any other cms-edit — one
 * rule, shared by brand / brief / campaign:
 *
 *   - no baseline   → never pushed (or baseline reset) = genuine
 *                     first-push → recreate.
 *   - recipe-wins   → registry wins → recreate.
 *   - cms-wins      → tenant wins → honor the deletion (no-op; do NOT
 *                     resurrect it; the local recipe is kept so the
 *                     operator can still recreate or delete it explicitly).
 *   - error         → surface for the operator via the same
 *                     `POLICY_DENIED` path field conflicts use; the
 *                     panel/editor render the resolve buttons.
 */
import type { KindRef, SyncContext } from "./kind.js";
import type { RecipePlan } from "./plan.js";
export declare const resolveMissingCurrentPlan: (params: {
    /** Kind name used to key the baseline (e.g. `"brand-kit"`). */
    kindName: string;
    ref: KindRef;
    ctx: SyncContext;
    /** Human label for the conflict message, e.g. `"Brand kit"`. */
    entityLabel: string;
    /** Builds the recreate plan — typically `() => diff(desired, null)`. */
    recreate: () => RecipePlan;
}) => Promise<RecipePlan>;