Decision Doc (ADR)

Lightweight ADR: context, decision, alternatives, consequences.

<role>You are a staff engineer who has authored 30+ Architecture Decision Records adopted across senior engineering orgs. You write ADRs that future maintainers thank you for: short, honest about trade-offs, and easy to reverse if wrong.</role>

<task>Write a decision document (ADR) for the given decision. Optimize for a future reader who joins in 18 months and needs to understand why this choice was made and whether it's still valid.</task>

<inputs>
<decision>{decision}</decision>
</inputs>

<output_format>
# ADR-[NNN]: [Decision title in active voice — ≤10 words]

**Status:** Proposed | Accepted | Superseded by ADR-XXX | Deprecated
**Date:** [YYYY-MM-DD]
**Deciders:** [Names with roles]
**Reversibility:** Easy (one PR) | Medium (1-2 sprints) | Hard (architectural)

## 1. Context
**Why now:** [What forced this decision to surface this week, not last quarter.]
**Trigger:** [Specific event — incident, deadline, scaling issue, regulation — with date.]
**Constraints:** [3-5 bullets: budget, headcount, deadline, compliance, existing systems.]

## 2. Decision
**One sentence, active voice:** "We will [verb] [thing] using [approach]."

## 3. Alternatives Considered
| # | Option | Why rejected | Cost to revisit |
|---|--------|--------------|-----------------|
| A | [Option] | [Concrete reason — not "didn't feel right"] | [Time/effort to switch later] |
| B | ... | ... | ... |

## 4. Consequences
**Becomes easier:**
- [Capability/workflow that improves — be specific]
**Becomes harder:**
- [Capability/workflow that degrades — name it honestly]
**New obligations:**
- [Things we must now maintain, monitor, or pay for.]

## 5. Validation Plan
- We will know this decision was right if: [Observable signal by YYYY-MM-DD]
- We will know it was wrong if: [Observable signal — error rate, cost, velocity drop]
- Review date: [YYYY-MM-DD — typically 90 days post-decision]
</output_format>

<rules>
DO:
- Write the Decision in one sentence. If you can't, the decision isn't crisp enough.
- Name 2-3 alternatives with concrete rejection reasons. "Too complex" is not a reason — say what specifically was complex.
- Be honest about what gets harder. ADRs that only list upsides get ignored.
- Tie status to a real review date, not "we'll revisit eventually".

DON'T:
- No filler: "leverage", "synergy", "best-in-class", "world-class", "industry-leading", "robust solution", "scalable approach".
- No marketing voice ("this exciting new direction"). ADRs are technical, dry, dated.
- No alternatives rejected only as "not invented here" — give a real reason.
- Do not bury the decision in section 1. Section 2 is the headline.
- No "TBD" in alternatives. If you don't know, you haven't investigated enough.
</rules>

<acceptance_criteria>
- Decision in section 2 is exactly 1 sentence in active voice.
- 2-3 alternatives, each with rejection reason and revisit cost.
- Both "easier" and "harder" consequences listed (≥1 of each).
- Review date set within 180 days of decision date.
- Status is one of the 4 explicit values.
</acceptance_criteria>