//! Bitwarden cloud-pull integration for tsafe.
//!
//! # E2E Encryption — bw CLI approach
//!
//! Bitwarden REST API ciphers are always E2E encrypted client-side.  Even when
//! authenticated with a `client_credentials` machine token (`api.organization`
//! scope), the `/api/sync` response contains `encryptedString` blobs for every
//! field value.  Decryption requires the Bitwarden client-side SDK and the
//! organization symmetric key derived from the master password, neither of
//! which is available to a headless API caller.
//!
//! This crate therefore delegates to the `bw` CLI subprocess, which handles
//! local decryption after `bw unlock --passwordenv <VAR>`.  This is the same
//! pattern used by `tsafe op-pull` (1Password CLI delegation).
//!
//! ## Auth flow
//!
//! 1. `bw login --apikey --clientid $id --clientsecret $secret`
//! 2. `bw unlock --passwordenv TSAFE_BW_PASSWORD` → `BW_SESSION` token
//! 3. `BW_SESSION=<token> bw list items [--folderid <id>]`
//! 4. `bw lock` (cleanup; non-fatal)
//!
//! ## Configuration
//!
//! | Env var                   | Purpose                                      |
//! |---------------------------|----------------------------------------------|
//! | `TSAFE_BW_CLIENT_ID`      | Bitwarden API client ID                      |
//! | `TSAFE_BW_CLIENT_SECRET`  | Bitwarden API client secret                  |
//! | `TSAFE_BW_PASSWORD`       | Master password for `bw unlock`              |
//! | `TSAFE_BW_API_URL`        | API base URL (default: Bitwarden cloud)      |
//! | `TSAFE_BW_IDENTITY_URL`   | Identity base URL (default: Bitwarden cloud) |

pub mod config;
pub mod error;
pub mod sync;

pub use config::BitwConfig;
pub use error::BitwError;
pub use sync::{map_ciphers_to_kv, normalize_item_name, pull_items, BwCipher, BwField, BwLogin};
