Architekturentscheidungen (ADRs)
Ein Architecture Decision Record (ADR) hält eine einzelne, folgenreiche technische Entscheidung fest: den Kontext, die getroffene Wahl und die Konsequenzen. Ziel ist, dass spätere Mitlesende (oder das eigene Ich in sechs Monaten) das Warum nachvollziehen können — nicht nur das Was.
Jeder Eintrag folgt dem Schema Status · Kontext · Entscheidung · Konsequenzen.
| # | Entscheidung | Status |
|---|---|---|
| 0001 | OpenRouter statt direkter OpenAI-API | Akzeptiert |
| 0002 | DSGVO-Provider-Routing (China-Ausschluss + ZDR) | Akzeptiert |
| 0003 | fastembed (ONNX) statt torch für Embeddings | Akzeptiert |
| 0004 | Caddy auf der Edge-VM statt lokalem nginx | Akzeptiert |
| 0005 | SQLite + FTS5 als einzige Datenbank | Akzeptiert |
| 0007 | Long-Polling statt Webhook für den Bot | Abgelöst |
| 0008 | Deploy nur bei gemergtem PR | Akzeptiert |
Neue Entscheidung? Neue Datei
NNNN-kurz-titel.mdmit demselben Schema und einer Zeile in dieser Tabelle. ADRs werden nicht gelöscht — überholte werden auf „Ersetzt durch …“ gesetzt.