Architecture
gobankcli uses one spine:
read-only provider -> normalized model -> SQLite archive -> export/query -> CLIProviders are bank-agnostic. GoCardless Bank Account Data and Enable Banking AIS are concrete providers, but commands should depend on provider interfaces except for small provider-specific flow completion such as Enable Banking callback exchange.
The provider package owns generic institutions, connections, accounts, transactions, and sync runs. Concrete providers normalize their API payloads into those models before store/export code sees them.
SQLite is the local archive because it is durable, inspectable, scriptable, and works well for private single-user data. Raw provider JSON will be preserved beside normalized rows so normalization can improve without losing source data.
Schema migrations are local and monotonic. The archive stores institutions, consent connections, accounts, transactions, and sync runs. Accounts keep a stable provider account ID plus an optional current provider resource ID for APIs with session-scoped fetch IDs. Transactions have a stable dedupe key based on provider/account transaction ID, then reference, then a hash of normalized transaction fields.
The product evolves by adding capabilities. Do not split the design into hard version phases.