Architecture Decision Records (ADRs)
ADRs dokumentieren signifikante Architektur-Entscheidungen mit Kontext, Optionen
und Konsequenzen. Format inspiriert von Michael Nygard.
Workflow
- Neue Entscheidung steht an → Kopie von
template.md mit nächster freier
Nummer (NNNN-kebap-titel.md).
- Status
proposed → diskutiert in Issue/PR → bei Akzeptanz auf accepted.
- Niemals editieren nach
accepted. Wenn eine Entscheidung sich ändert,
neuer ADR mit Supersedes: NNNN-… im Header und der alte ADR bekommt
Superseded by: MMMM-….
- Status
deprecated für Entscheidungen, die ohne Nachfolger auslaufen.
Index
| ID |
Titel |
Status |
Datum |
| 0001 |
LLM-Citations server-seitig binden statt prompt-seitig |
accepted |
2026-04-10 |
| 0002 |
Adapter-Pattern mit ParlamentAdapter-Basisklasse + Registry |
accepted |
2026-04-10 |
| 0003 |
Sub-D Property-Verification: Zitate als Substring der zitierten PDF-Seite |
accepted |
2026-04-10 |
| 0004 |
Docker Compose Deploy mit DB-/Reports-Volume und SN-XML-Sonderpfad |
accepted |
2026-04-10 |
Wann ADR, wann nicht
| ADR-würdig |
nicht ADR-würdig |
| Wahl zwischen mehreren plausiblen Architekturen mit Trade-offs |
Bug-Fix |
| Strukturelle Konsequenzen für mehrere Module |
Refactoring innerhalb eines Moduls |
| Reverse-Engineering-Findings die andere Adapter beeinflussen |
Stiländerungen, Linting-Konventionen |
| Neue externe Abhängigkeiten oder APIs |
Dependency-Bumps ohne API-Änderung |
| Workflow-Konventionen die mehrere Sessions überdauern müssen |
Tagesgeschäft, Issue-Tracking |
Faustregel: Wenn ein neuer Kollege (oder eine neue Session) die Entscheidung
sonst rückgängig machen würde, gehört sie in einen ADR.
