architecture-decision-recordlisted

# Architecture decision records An ADR captures *why* a choice was made, in enough detail that someone can later tell whether the reasoning still holds. Code shows what was decided; only an ADR shows what was rejected and under what assumptions. ## When to write one Write an ADR when the decision is **expensive to reverse** or **non-obvious in hindsight**: - A boundary changes: service split/merge, new bounded context, sync → async. - A technology enters or leaves: datastore, queue, framework, major dependency. - A cross-cutting convention is set: auth model, error contract, tenancy model. - A recommended option was rejected — record the rejection, that's the valuable part. Do **not** write one for reversible, local choices (a helper's name, a library swap behind an interface). ADR sprawl makes the important ones unfindable. ## Format One file per decision, immutable once accepted: `docs/adr/0007-postgres-for-ledger.md`. Numbered, never renumbered, never edited in substance — superseded instead. ```markdown # 7. Postgres for the ledger store Date: 2026-03-14 Status: Accepted Deciders: @tech-lead, @payments-team ## Context Facts and forces, not opinions. What problem, what constraints, what is already true. Include the numbers that drove the decision — throughput, data volume, team size, deadline. If a constraint is an assumption rather than a measurement, say so explicitly. ## Decision One paragraph, active voice: "We will store ledger entries in Postgres, using