diff --git a/kalender-plan.md b/kalender-plan.md
index 3a1137d..5c94b98 100644
--- a/kalender-plan.md
+++ b/kalender-plan.md
@@ -148,6 +148,73 @@ Baïkal stehen beide darauf, das ist also das Verhalten, an das die Clients
 gewöhnt sind. Radicale ist zum Nachlesen gut – kurzer Code –, aber es ist nicht
 die Fassung, gegen die getestet wurde.
 
+## Kein Plugin – aber ausklinkbar gebaut
+
+Der Projektplan legt es selbst fest (Abschnitt 8): *„ERST sauberer Core.
+Extension-Points erst definieren, wenn der Core stabil ist. Kernfeatures
+bleiben erstklassig, nicht als Plugin."* Ein Plugin-System zu bauen, um darauf
+den Kalender zu setzen, drehte diese Reihenfolge um – und ein Kalender wäre
+sein erster und einziger Nutzer, also entstünde die Schnittstelle nach genau
+einem Fall.
+
+Stattdessen so gebaut, dass er später herauszulösen ist:
+
+- eigenes Paket `internal/calendar`, eigene Migrationen, eigene Routen
+- angeschlossen in **einer** Zeile in `main.go`
+- greift nach außen nur auf `auth` und `acl` zu, nicht in andere Pakete hinein
+- abschaltbar: kein Kalender aktiv → keine Routen, kein Menüpunkt
+
+Damit ist er der natürliche erste Kandidat, wenn es das Plugin-System einmal
+gibt – ohne dass wir es vorher erfinden.
+
+## Teamkalender über Gruppen
+
+Aether kennt bereits Gruppen samt Gruppenordnern, und `acl.Access` trägt einen
+**Prinzipal** statt eines Eigentümers – ein Konto *oder* eine Gruppe
+(`IsGroup`). Genau das nehmen wir:
+
+| Zweck | Weg |
+|---|---|
+| **Teamkalender** | Kalender gehört einer Gruppe. Wer in der Gruppe ist, hat ihn – ohne einzelne Freigaben. Angelegt in den Admin-Optionen, wie Gruppenordner. |
+| **Persönlich teilen** | Freigabe an ein einzelnes Konto, mit Recht `read` oder `write`. In der Oberfläche ein Schalter „darf auch schreiben". |
+
+Beides läuft über dieselbe Prüfung wie bei Dateien: `resolveCalendar` nach dem
+Vorbild von `files.resolveFile`. Kein zweites Rechtekonzept.
+
+## Oberfläche
+
+**Mehrere Kalender gleichzeitig** – das ist der Normalfall, nicht die Ausnahme.
+Die Ansicht legt sie übereinander; jeder Termin trägt die Farbe seines
+Kalenders.
+
+**Sichtbarkeit mit einem Klick**, wie in Google Kalender und der Samsung-App:
+runder, in der Kalenderfarbe gefüllter Haken in der Liste. Klick = an, Klick =
+aus. **Serverseitig je Nutzer gespeichert**, damit es am Rechner und am Handy
+gleich aussieht – dafür eine Tabelle:
+
+    kalender_ansicht   nutzer_id, kalender_id, sichtbar, reihenfolge, farbe_eigen
+
+Das `farbe_eigen` ist geschenkt, wenn die Zeile ohnehin existiert: Ein geteilter
+Kalender darf bei dir grün und beim anderen blau sein – so macht es Google auch.
+
+**Wichtig:** Diese Einstellung gilt für *unsere* Oberfläche. Was das Telefon
+anzeigt, entscheiden DAVx5 und Samsung Kalender selbst; darauf haben wir keinen
+Zugriff.
+
+## Farben
+
+Zwei verschiedene Dinge, die man leicht verwechselt:
+
+- **Farbe des Kalenders** – das, was du in der Samsung-App siehst. Im Protokoll
+  `calendar-color` aus Apples Namensraum. Steht in keinem RFC, ist aber
+  de-facto-Standard: Nextcloud, Thunderbird und DAVx5 können es. **Geht.**
+- **Farbe eines einzelnen Termins** – `COLOR` aus RFC 7986. In unserer eigenen
+  Oberfläche jederzeit möglich; wie weit DAVx5 und Samsung Kalender das
+  weiterreichen, ist offen und muss am Gerät geprüft werden.
+
+**Emojis im Kalendernamen** sind kein Protokollthema – der Name ist Text.
+„🏠 Haushalt" kommt überall an.
+
 ## Die Notausfahrt
 
 Ein Kalender, der lautlos einen Termin verschluckt, ist schlimmer als einer,