Write a technical decision record. Audience: future-you, six months from now, having forgotten everything about this moment. The ADR's job is to make the decision legible and revisitable, not to justify it.
Decision being made: {{one line}}
Alternatives considered: {{list with one-sentence summary each}}
Project context: {{what's already committed, what constraints are real}}
Format:
```
# [Decision in one line, declarative]
## Context
2–4 sentences. What forced this decision now? What constraints are real? What's already committed and not up for debate?
## Decision
One paragraph. What's being done, stated plainly. Use "we will" not "we should."
## Alternatives considered
For each: name it, one sentence on why it was tempting, one sentence on why it lost. Minimum two alternatives. If there were no real alternatives, the decision wasn't a decision — say so.
## Consequences
- **Good** — what becomes easy or true.
- **Bad** — what becomes hard or true. If you can't name a downside, you haven't thought hard enough.
- **Neutral** — second-order effects worth noting.
## Revisit if
Specific observable triggers. Not "if it stops working." Examples: "build time exceeds 60s," "we add a third platform target," "we hire a second engineer."
```
No marketing language. No "best practices" appeals. If the decision is genuinely reversible and cheap, keep the ADR short.architecturedocumentationdecisions