using IceImportDAL.DTO.IceMapFtpSource;
using IceImportDAL.DTO.RemoteFileSources;

namespace IceImportBLL.IceImportSecretResolver;

// Resolves MICEMAPFTPSOURCE's HostVaultRef/UsernameVaultRef/CredentialVaultRef (mount-relative
// Vault KV-v2 paths) into an actual RemoteFileSourceConfigDTO carrying live plaintext
// Host/Username/Credential.
//
// This is the "Vault-secret-by-key" abstraction the plan asked for. GB5 does not have one shared
// generic version of this at GB5Shared level — the only existing precedent found in the repo is
// GB5Solution/PAY/PAYBLL/Vault/{IVaultService,VaultService}.cs, a narrowly PAY-scoped
// "GetSecretAsync(vaultKeyPath, ct)" reader over VaultSharp's KV v2 engine (Singleton IVaultClient
// + IMemoryCache 5-min sliding TTL cache). IceImportBLL cannot reference PAYBLL (sibling module,
// not a shared library), so IceImportSecretResolver below re-implements the exact same
// VaultSharp client-construction pattern (TokenAuthMethodInfo + VaultClientSettings from
// "Vault:Token"/"Vault:Address" config, mount point "secret") rather than inventing a new one.
//
// TODO(vault-owner): the mount-relative path convention encoded in HostVaultRef/UsernameVaultRef/
// CredentialVaultRef (e.g. whether it's "iceimport/{IceMapId}/host" or something client/tenant
// scoped) has not been confirmed against a real Vault instance in this session — PAYBLL's own
// convention ("pay/razorpay/api_key", single flat KV entry per secret) is followed here as the
// closest working precedent, but whoever owns Vault provisioning should confirm/adjust the path
// shape admins are expected to type into MICEMAPFTPSOURCE.*VaultRef before this goes live.
public interface IIceImportSecretResolver
{
    Task<RemoteFileSourceConfigDTO> ResolveAsync(
        MicemapFtpSourceDTO config, CancellationToken ct);
}