docs(kalender): sechs Grenzen statt eines Plugin-Systems

Marcs Linie: kein Plugin-System bauen, aber dafür sorgen, dass der
Kalender wirklich ein Extra bleibt. Das ist als Liste festgehalten, weil
gute Absicht in sechs Monaten niemanden bindet: niemand importiert das
Paket, es importiert nur auth/acl/pkg, alles unter einem Routenpräfix,
eigene Tabellen mit cal_-Präfix, abschaltbar, keine Änderung an
bestehenden Paketen außer einer Zeile in main.go.

Die erste Regel wird ein Test, der die Importe durchgeht – dann fällt ein
Grenzübertritt beim Bauen auf und nicht Jahre später.

Migrationen bleiben in der Kernnummerierung. Eine zweite Versionstabelle
wäre für ein echtes Plugin richtig, für eine persönliche Cloud ist sie
Aufwand ohne Gegenwert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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