architecture-decision-recordslisted

# Architecture decision records A decision made in a meeting evaporates the moment the room clears, and six months later someone reverses it without knowing what it cost the last time. An ADR is the durable answer to "why is it built this way": one file, written once, that a future maintainer can trust more than anyone's memory. ## Method 1. **One decision per record, numbered and immutable.** Name files `docs/adr/0007-use-postgres-for-billing.md`. The number never changes and the file is append-only after acceptance. A record that mixes two decisions cannot be superseded cleanly when only one of them ages out. 2. **Write the context as forces, not narrative.** State the constraints, requirements, and pressures in play: throughput targets, team skills, existing contracts, deadlines. The reader must feel the pressure that made the decision reasonable at the time, even if it looks wrong later. 3. **State the decision in the active voice.** "We will store billing events in Postgres and stream them to the warehouse nightly." Not "Postgres seems like a good option." A decision hedged into a suggestion is not a decision. 4. **Record consequences honestly, both signs.** List what gets easier and what gets harder: the new operational burden, the capability you gave up, the follow-on work this forces. An ADR with only upsides is marketing. 5. **Track status through a fixed lifecycle.** Proposed, accepted, deprecated, superseded. When a later ADR ove