Dieses Verzeichnis enthält **ADRs** — kurze Markdown-Dokumente die einzelne Architektur-Entscheidungen festhalten. Das Pattern kommt von Michael Nygard und ist gemeinsamer Standard in vielen Open-Source-Projekten.
## Warum ADRs?
- **Warum, nicht Wie:** Der Code ändert sich. Die Intention soll bleiben. Eine ADR erklärt warum etwas so gebaut wurde — in einem halben Jahr weiß niemand mehr sonst.
- **Referenz für AI-Sessions:** Wenn die AI morgen eine Änderung vorschlägt, die eine bestehende Entscheidung umkehrt, soll sie das bewusst tun und neue ADR schreiben, nicht versehentlich.
- **Audit-Trail:** Jede ADR hat Status, Datum und Entscheider. Das ist Compliance-ready.
## Format
Jede ADR folgt grob diesem Schema:
```markdown
# ADR-NNNN: <Titel>
Status: Proposed | Accepted | Superseded by ADR-NNNN | Deprecated
Datum: YYYY-MM-DD
Entscheider: <Name>
Phase: <OpenProjectPhaseoderSprint>
## Kontext
Was war das Problem? Welche Optionen standen zur Wahl?
## Entscheidung
Was wurde gewählt?
## Begründung
Warum genau diese Option? Welche Prinzipien waren leitend?
## Konsequenzen
- **Positiv:** Was gewinnen wir?
- **Negativ/Trade-off:** Was geben wir auf?
## Alternativen
Was wurde verworfen und warum?
```
## Nummerierung
Fortlaufend `NNNN` beginnend bei `0001`. **Niemals** alte ADRs ändern — superseden via neue ADR mit Verweis. Die Historie ist die Wahrheit.
## Aktuelle ADRs (alle aus M7.1 — Forgejo Deployment)