architecture-decision-recordslisted

# Architecture Decision Records ## Coverage Create and audit ADRs for significant technical choices. Covers decision context, forces, considered options, chosen decision, rejected alternatives, consequences, status, supersession, links to implementation, and follow-up verification. Use for decisions with future readers, cross-team consequences, operational cost, or hard-to-reverse effects. ## Philosophy An ADR is not a design essay. It is a durable answer to "Why did we choose this, given what we knew then?" It should preserve the tradeoff, not retroactively make the decision look inevitable. Good ADRs are short, dated, statused, and honest about consequences. If a future agent cannot tell whether the decision still holds, the record failed. ## Method 1. Name the decision in one sentence. 2. Capture context and forces, including constraints and non-goals. 3. List serious options considered, including "do nothing" when real. 4. State the decision and why it won. 5. Record consequences: benefits, costs, risks, migration obligations, and reversibility. 6. Set status: proposed, accepted, deprecated, or superseded. 7. Link implementation surfaces and verification checks. ## Verification - [ ] The ADR records one decision, not a cluster of unrelated choices - [ ] Rejected options are concrete and plausible - [ ] Consequences include costs and risks, not only benefits - [ ] Status and date are present - [ ] Supersession links are explicit when the decision changed - [ ] Imp