/**
 * secrets-migration-view.ts, the only view of the secret stores that reaches
 * across surfaces.
 *
 * Resolution walks ONE surface root, and that is correct: the agent has no
 * business resolving a credential out of the TUI's silo at read time, and a
 * daemon that did would be reading a value nobody asked it to. Revoke walks the
 * same set, for the same reason.
 *
 * Migration is the single exception, and the owner's machine is why it has to
 * exist. Their Telegram token sat in `~/.goodvibes/agent/secrets.enc` while the
 * daemon booted rooted at `daemon` and enumerated only its own store. The
 * credential was one directory away, perfectly readable, and invisible to the
 * only code that could have lifted it, so nothing ever lifted it.
 *
 * Kept in its own module so the widening is a thing you have to import on
 * purpose. Anything reaching for `SecretsManager` gets the narrow view by
 * default; the cross-surface one has a name that says what it is.
 */
import type { SecretRecord } from './secrets.js';
import { type SecretStoreLayout, type SecretStorePath } from './secrets-store-paths.js';
/** This manager's own stores, plus every other surface's, deduplicated by file. */
export declare function migratableStores(layout: SecretStoreLayout, ownStores: readonly SecretStorePath[]): SecretStorePath[];
/**
 * Every credential in those stores, tagged with the FILE it came from.
 *
 * The path matters as much as the tier: several surfaces share the `user`
 * scope, so a record identified only by scope cannot say which copy it is, and
 * the migration's read-back verification would be comparing against an
 * arbitrary one of them.
 */
export declare function listMigratableSecrets(stores: readonly SecretStorePath[], read: (path: string, secure: boolean) => Record<string, string> | null): SecretRecord[];
//# sourceMappingURL=secrets-migration-view.d.ts.map