diff --git a/.planning/todos/pending/2026-08-11-verschluesselungsschluessel-vorgabewert.md b/.planning/todos/pending/2026-08-11-verschluesselungsschluessel-vorgabewert.md
new file mode 100644
index 0000000..5b99793
--- /dev/null
+++ b/.planning/todos/pending/2026-08-11-verschluesselungsschluessel-vorgabewert.md
@@ -0,0 +1,63 @@
+---
+created: 2026-08-11
+title: Verschluesselungsschluessel — fest eingebauter Vorgabewert in der Basis-Compose, Dokumentation in der Beispiel-Umgebung fehlt vermutlich
+area: infra
+severity: minor
+trigger: vor der ersten Installation bei einem externen Kunden; intern folgenlos, solange die Variable gesetzt ist
+files:
+  - docker-compose.yml:46
+  - docker-compose.prod.yml:44
+  - .env.example
+  - .env.prod.example
+---
+
+## Problem
+
+Seit 4f687ea sind alle Zugangsdaten in der Datenbank verschluesselt — Kalender,
+SMTP, DKV-Postfach, Ausschreibungs-Postfach und nun auch das LDAP-Bind-Passwort.
+Der Schluessel dafuer kommt aus der Umgebungsvariable `CALENDAR_ENCRYPTION_KEY`
+und liegt bewusst NICHT in der Datenbank.
+
+Zwei Luecken drumherum:
+
+**1. Vorgabewert in der Basis-Compose.** `docker-compose.yml:46` lautet
+
+```
+CALENDAR_ENCRYPTION_KEY: ${CALENDAR_ENCRYPTION_KEY:-5dbbaba2...}
+```
+
+Ist die Variable nicht gesetzt, startet die Anwendung also trotzdem — mit einem
+Schluessel, der im Repository steht und damit jedem bekannt ist, der den Code
+hat. Die Verschluesselung sieht dann vorhanden aus, traegt aber nicht. Ein
+stiller Fehlstart ist hier schlechter als ein lauter: `docker-compose.prod.yml:44`
+macht es bereits richtig und verlangt die Variable ohne Vorgabe.
+
+**2. Dokumentation.** Ob `.env.example` / `.env.prod.example` den Schluessel
+erklaeren, konnte ich am 2026-08-11 nicht pruefen (Dateizugriff in der Sitzung
+blockiert) — beim Umsetzen also zuerst nachsehen. Falls er dort fehlt oder ohne
+Erklaerung steht, weiss bei einer Neuinstallation niemand, dass ein eigener
+Wert erzeugt werden muss und was passiert, wenn er spaeter verloren geht.
+
+Aufgefallen am 2026-08-11, als der User fragte, wo der Schluessel liegt und ob
+man ihn exportieren kann.
+
+## Solution
+
+1. Den Vorgabewert aus `docker-compose.yml:46` entfernen, sodass ein Start ohne
+   gesetzten Schluessel scheitert statt still einen bekannten zu verwenden.
+   Vorher pruefen, was das fuer die lokale Entwicklung heisst — moeglicherweise
+   braucht `docker-compose.dev.yml` dann einen eigenen, klar als Wegwerf-Wert
+   gekennzeichneten Eintrag, damit ein frisch geklontes Repo weiterhin
+   hochfaehrt.
+2. In beiden Beispiel-Umgebungsdateien den Schluessel dokumentieren: wie er
+   erzeugt wird (`openssl rand -hex 32`), dass er zu jedem Datenbank-Backup
+   gehoert und getrennt davon aufbewahrt werden sollte, und dass ein verlorener
+   Schluessel bedeutet, dass alle gespeicherten Zugangsdaten neu eingetragen
+   werden muessen.
+
+Optional im selben Zug, weil es beim Lesen sonst jedes Mal irritiert: der Name
+`CALENDAR_ENCRYPTION_KEY` stammt daher, dass das Kalender-Modul die
+Verschluesselung zuerst brauchte. Er gilt laengst fuer alle Zugangsdaten der
+Plattform. Eine Umbenennung muesste den alten Namen als Rueckfallebene lesen,
+sonst faellt jede bestehende Installation beim naechsten Start auf die Nase —
+siehe auch die Notiz dazu im LdapModule.