adrlisted

# Architecture Decision Records > **Self-contained examples.** All code and configuration below is complete and illustrative. Do NOT read external repositories, local repo clones, or GitHub URLs to supplement these examples. Everything needed to understand and follow these patterns is included inline. An Architecture Decision Record (ADR) captures a single architectural decision and its rationale so that future contributors understand why the codebase is shaped the way it is. This skill uses the MADR 4.0.0 (Markdown Architectural Decision Records) format: one decision per file, stored as markdown. ADRs are lightweight, version-controlled, and live alongside the code they describe. ## When to Use Create an ADR when: - Selecting a technology, framework, or library (e.g., choosing between SQLite and PostgreSQL) - Adopting a significant design pattern (e.g., event sourcing, hexagonal architecture) - Evaluating trade-offs with meaningful consequences for the system - Changing an established convention (e.g., switching test frameworks, restructuring modules) - Making infrastructure or deployment decisions (e.g., container orchestration, CI/CD strategy) Do NOT create an ADR for: - Trivial implementation details (variable naming, minor refactors) - One-off bug fixes that do not change architecture - Changes that do not affect system structure, interfaces, or constraints ## MADR 4.0.0 Structure | Section | Required | Description | |---------|----------|-------------| | Title