write-adrlisted

# Write ADR Capture one architecturally significant decision — the forces behind it, what was chosen, and what it costs — so the reasoning survives past the conversation that produced it. ## When to use Whenever a decision has lasting consequence: it constrains a boundary, an interface, a technology choice, or a trade-off that would be expensive to reverse. Not for routine implementation choices a developer can freely change later. ## Method Frame the decision against the relevant C4 view first — is this a System Context decision (an external dependency or actor), a Container decision (a new service, store, or protocol between them), or a Component decision (internal structure of one container)? Naming the level keeps the ADR scoped to one decision instead of drifting into a general design doc. Then record it using Nygard's four-part structure (default) or MADR's fuller field set when the trade-off between options needs to be visible: 1. **Title.** A short noun phrase naming the decision, numbered — `NNNN-title.md`. 2. **Status.** `proposed`, `accepted`, `deprecated`, or `superseded by NNNN`. 3. **Context.** The forces and constraints in play, stated as fact, not argument for the decision. (MADR: also list **Decision drivers** explicitly if more than one competing force is at play.) 4. **Decision.** What was decided, in full sentences, active voice: "We will …". (MADR: list the **Considered options**, and for each, brief pros/cons, before naming the outcome — thi