import type { VaultEngine } from './extensionRegistry';
/**
 * Holds the unlocked engines for vaults across the running session. Lives in
 * memory only on purpose - a page reload requires re-unlocking, which matches
 * what most users expect from a protected vault. A plugin (e.g.
 * `web-app-rclone-crypt`) builds an engine in its unlock UI and stashes it
 * here; `resolveVault()` inside the same plugin then reads it back. A vault
 * counts as unlocked exactly when an engine is stored for it.
 *
 * The store is mechanism-agnostic: it only knows about `VaultEngine`, the
 * common encrypt/decrypt interface. How an extension obtains one - a passphrase,
 * a derived key, a hardware token, an OAuth flow - is entirely the extension's
 * business and never reaches this store.
 *
 * Keys are `(spaceId, vaultRootPath)` rather than `(spaceId, vaultId)` by
 * design: the vault root path is the handle every callsite already has (the
 * route guard only has the path on cold reload), so path-based keying keeps
 * resolvers free of an extra path→id lookup. An engine does not depend on the
 * path it's filed under, so a vault root can be renamed without rebuilding it -
 * only this store has to be re-keyed, which `moveEngine` does from the rename
 * handler.
 */
export declare const useVaultStore: import("pinia").SetupStoreDefinition<"vault", {
    getEngine: (spaceId: string, vaultRoot: string) => VaultEngine | undefined;
    setEngine: (spaceId: string, vaultRoot: string, engine: VaultEngine) => void;
    clearEngine: (spaceId: string, vaultRoot: string) => void;
    moveEngine: (spaceId: string, fromVaultRoot: string, toVaultRoot: string) => void;
    clearEnginesUnder: (spaceId: string, pathPrefix: string) => void;
    isUnlocked: (spaceId: string, vaultRoot: string) => boolean;
}>;
export type VaultStore = ReturnType<typeof useVaultStore>;