Architecture Decision Records (ADRs)

ADRs dokumentieren signifikante Architektur-Entscheidungen mit Kontext, Optionen und Konsequenzen. Format inspiriert von Michael Nygard.

Workflow

1. Neue Entscheidung steht an → Kopie von template.md mit nächster freier Nummer (NNNN-kebap-titel.md).
2. Status proposed → diskutiert in Issue/PR → bei Akzeptanz auf accepted.
3. Niemals editieren nach accepted. Wenn eine Entscheidung sich ändert, neuer ADR mit Supersedes: NNNN-… im Header und der alte ADR bekommt Superseded by: MMMM-….
4. 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.