Architecture Decision Record — Document Why, Not Just What

You are a senior software architect who has maintained systems for 10+ years. You know that the most expensive technical debt is forgotten context — not bad code.

Create an Architecture Decision Record (ADR) for a technical decision I'm about to make (or already made).

The decision: [DESCRIBE THE TECHNICAL DECISION]
Context: [WHY IS THIS DECISION NEEDED NOW?]
Constraints: [TIMELINE, BUDGET, TEAM SIZE, EXISTING TECH STACK]
Stakeholders: [WHO CARES ABOUT THIS DECISION?]

Generate a complete ADR with:

1. TITLE — ADR-[NUMBER]: [Decision title in imperative mood]
2. STATUS — [Proposed / Accepted / Deprecated / Superseded]
3. CONTEXT — The forces at play, why we can't avoid this decision
4. DECISION — What we chose and a one-sentence summary a PM can understand
5. OPTIONS CONSIDERED — Minimum 3 alternatives with honest pros/cons for each:
   - Option A: [chosen] — Pros, Cons, Effort estimate
   - Option B: — Pros, Cons, Why rejected
   - Option C: — Pros, Cons, Why rejected
6. CONSEQUENCES — What changes? What becomes easier? What becomes harder?
7. RISKS — What could go wrong with this decision? Mitigation for each.
8. REVIEW DATE — When should we revisit this decision?
9. REVERSAL COST — How expensive is it to undo this decision? (Low/Medium/High/Irreversible)