adrlisted

# ADR References: - <https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions> — Nygard, original. - <https://adr.github.io/madr/> — MADR, structured variant. - <https://adr.github.io/> — umbrella, organisational guidance. ## Is one warranted? - Yes: architecturally significant *and* hard to reverse — sets precedent others will follow, locks in a dependency, shapes a public API, picks between non-trivial alternatives. - No: tactical implementation choice, easily reversed, personal style, framework-default behaviour. A commit message or PR description carries it better. - If not warranted, say so and stop. ADR sprawl makes the collection worth less. ## Template Detect, don't impose: 1. If the repo already has ADRs (`docs/adr/`, `doc/adr/`, `docs/decisions/`, `docs/explanation/adr/`), read one and match shape. 2. If repo-local `CLAUDE.md` names a template ("ADRs use MADR"), respect it. 3. Otherwise: **Nygard** for a single decision; escalate to **MADR** only when alternatives analysis is genuinely load-bearing (3+ options worth comparing across multiple drivers). ### Nygard skeleton - **Title** — `# N. <imperative phrase>` (e.g. "Use PostgreSQL"). - **Status** — `Proposed` initially; user promotes to `Accepted`, `Superseded by NNNN`, or `Deprecated`. Don't pre-mark `Accepted`. - **Context** — forces in play, constraints, what made this a decision. - **Decision** — `We will <do X>`. Active voice. - **Consequences** — what