diff --git a/kalender-plan.md b/kalender-plan.md
index 5c94b98..25b3dbc 100644
--- a/kalender-plan.md
+++ b/kalender-plan.md
@@ -167,6 +167,33 @@ Stattdessen so gebaut, dass er später herauszulösen ist:
 Damit ist er der natürliche erste Kandidat, wenn es das Plugin-System einmal
 gibt – ohne dass wir es vorher erfinden.
 
+### Die Grenzen, an denen sich das entscheidet
+
+Kein System, sechs Regeln:
+
+1. **Niemand importiert `internal/calendar`.** Kein `files`, kein `sharing`,
+   kein `admin`. Der Kalender ist Blatt im Baum, nie Ast.
+2. **Der Kalender importiert nur `auth`, `acl` und `pkg/…`** – dieselben
+   Hilfsmittel wie jeder andere Bereich, aber keine fremde Fachlogik.
+3. **Alles unter einem Präfix**: `/api/v1/calendar/…` für die Oberfläche,
+   `/caldav/…` für die Geräte. Keine Route irgendwo dazwischen.
+4. **Eigene Tabellen, erkennbar benannt** (`cal_calendars`, `cal_objects`,
+   `cal_shares`, `cal_view`). Keine Spalte in einer bestehenden Tabelle.
+5. **Abschaltbar**: aus heißt keine Routen, kein Menüpunkt, keine Migration,
+   die etwas anderes anfasst.
+6. **Keine Änderung an bestehenden Paketen**, außer der einen Zeile in
+   `main.go` und dem Eintrag in der Ansichtsliste des Frontends.
+
+Regel 1 lässt sich festhalten statt hoffen: ein kleiner Test, der die Importe
+durchgeht und fehlschlägt, sobald ein anderes Paket den Kalender zieht. Damit
+merkt man die Grenzüberschreitung beim Bauen und nicht in zwei Jahren beim
+Herauslösen.
+
+**Migrationen** bleiben in der fortlaufenden Nummerierung des Kerns
+(`000021_calendar…`). Eine zweite Versionstabelle wäre sauberer für ein echtes
+Plugin, aber für eine persönliche Cloud ist sie Aufwand ohne Gegenwert – und
+die Dateinamen sagen ohnehin, wozu sie gehören.
+
 ## Teamkalender über Gruppen
 
 Aether kennt bereits Gruppen samt Gruppenordnern, und `acl.Access` trägt einen