docs(kalender): Festlegungen, Felder, Clients und das Teilen nachgetragen

Teilen war in der ersten Fassung zu pauschal abgeräumt. Es meint drei
Dinge: dasselbe Konto auf mehreren Geräten (ab Phase 1), ein Kalender für
einen anderen Nutzer (Tabelle plus Bedingung in ListCalendars, keine
Protokollarbeit) und ein öffentlicher Abo-Link (Aether hat Freigabelinks
schon). Nur Einladungen per E-Mail bleiben draußen.

Dazu Marcs Festlegungen: mehrere Kalender und VTODO von Anfang an,
Anhänge kein Ziel, Erinnerungen weckt die App auf dem Telefon.

Und die Einschränkung, die sonst später überrascht: Androids
Kalenderspeicher kennt keine Aufgaben. Ohne Tasks.org o. ä. bietet DAVx5
sie nicht an, und Samsung Kalender zeigt sie nie.

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

kalender-plan.md

@@ -4,6 +4,20 @@ Stand 02.09.2026. Ausgangspunkt: Radicale ist für einen einfachen selbst
 gehosteten Kalender überraschend umständlich (Konfigurationsdateien, dünne
 Doku, keine OIDC-Anbindung).
 
+## Festgelegt (02.09.2026)
+
+- **Mehrere Kalender** von Anfang an. Nicht weil es heute drei sein müssen,
+  sondern weil es jetzt eine Spalte ist und später ein Umbau.
+- **Aufgaben (VTODO)** werden von Anfang an gespeichert und über CalDAV
+  angeboten; die Ansicht in Aether kommt später. Muss vorher feststehen, weil
+  jeder Kalender dem Client meldet, was er kann – nachträglich richten die
+  Clients ihre Konten neu ein.
+- **Ändern statt neu erzeugen**, sobald unsere eigene Oberfläche schreibt.
+- Anhänge sind kein Ziel. Falls doch, dann als Verweis in Aethers Dateien –
+  nie als eingebettete Datei in der `.ics`.
+- Erinnerungen weckt die App auf dem Telefon. Browser-Benachrichtigungen in
+  der Weboberfläche: nett für später, kein Drang.
+
 ## Entscheidung: ein Modul in Aether, kein eigener Dienst
 
 Der Grund ist genau das, was bei Radicale gefehlt hat.
@@ -72,15 +86,67 @@ Die abgeleiteten Spalten sind nur zum Vorsortieren da.
 | **1** | CalDAV lesend und schreibend, ein Kalender, Anmeldung über App-Passwörter, Auffindpfade (`/.well-known/caldav`, `current-user-principal`, `calendar-home-set`). Ziel: DAVx5 gleicht ab. | 1–2 Abende |
 | **2** | Mehrere Kalender, Farbe, Umbenennen, Löschen. Export als `.ics`, Import einer bestehenden Datei. | 1 Abend |
 | **3** | Weboberfläche in Aether: Monat, Woche, Liste; Termin anlegen, ändern, löschen. Der Teil, der Spaß macht – und dessen Fehler man **sieht**. | 2–3 Abende |
-| **4** | `sync-collection` statt Vollabgleich, Aufgaben (VTODO), Kalender in der HoneyOS-Leiste. | offen |
+| **4** | `sync-collection` statt Vollabgleich, Aufgabenansicht, Teilen mit anderen Nutzern, öffentlicher Abo-Link, Kalender in der HoneyOS-Leiste. | offen |
 | **5** | Kontakte (CardDAV). Dieselbe Maschinerie, dieselbe Bibliothek – und **einfacher**, weil es dort keine Wiederholungen gibt. | später entscheiden |
 
-## Was es ausdrücklich nicht wird
+## Teilen – drei Bedeutungen, zwei davon gehen
 
-Keine Einladungen an andere Leute (iMIP/Scheduling), keine Frei/Belegt-Abfragen
-über Häuser hinweg, kein Teilen zwischen Nutzern. Das ist der Teil, an dem
-Groupware-Server groß und kompliziert werden. Ein Kalender für dich, auf allen
-deinen Geräten – das ist das Ziel.
+„Geteilter Kalender" meint je nach Person etwas anderes:
+
+1. **Derselbe Kalender auf mehreren Geräten.** Das ist der Sinn der Sache und
+   ab Phase 1 da.
+2. **Ein Kalender, den ein anderer Nutzer sieht** – lesend oder schreibend, wie
+   das Teilen in Nextcloud. Geht, und es ist keine Protokollarbeit: Wir kennen
+   unsere Nutzer und unsere Kalender, also ist es eine Tabelle
+   (`kalender × nutzer × recht`) und eine Bedingung in `ListCalendars`. Der
+   Client sieht danach schlicht einen Kalender mehr in seiner Liste. **Phase 4.**
+3. **Ein Kalender an der Adresse eines Links**, den jemand ohne Konto
+   abonnieren kann – nur lesend, wie ein Freigabelink für Dateien. Klein, und
+   Aether hat die Freigabelinks schon. **Phase 4.**
+
+Was **nicht** kommt: Einladungen per E-Mail (iMIP/iTIP) und Frei/Belegt-Abfragen
+über Serviergrenzen hinweg. Das ist der Teil, an dem Groupware groß und
+kompliziert wird – und der einzige, der wirklich wehtut.
+
+## Felder – was ein Termin mitbringt
+
+Alles aus RFC 5545, und wir müssen dafür nichts „unterstützen": Wir speichern
+die Datei unverändert, also überleben auch Felder, die wir nicht kennen.
+
+    RRULE/EXDATE Wiederholung · DESCRIPTION Notiz · LOCATION Ort
+    VALARM Erinnerung · CATEGORIES · CLASS privat/öffentlich
+    ATTENDEE Teilnehmer (gespeichert, aber niemand wird eingeladen)
+    DTSTART ohne Uhrzeit = ganztägig
+
+**Die Regel, die Daten rettet:** Sobald unsere Oberfläche einen Termin ändert,
+wird die vorhandene Datei eingelesen, die angefassten Felder ersetzt und der
+Rest unberührt zurückgeschrieben. Nie neu erzeugen. Sonst verschiebt man am
+Rechner einen Termin um eine Stunde und die Erinnerung, die das Telefon
+angelegt hatte, ist weg – und das fällt erst Wochen später auf.
+
+## Clients, gegen die geprüft wird
+
+| Client | Prüft |
+|---|---|
+| **DAVx5 → Samsung Kalender** | der Hauptweg. DAVx5 schreibt in Androids Kalenderspeicher, Samsung Kalender liest daraus. In der App unter „Kalender verwalten" einmal sichtbar schalten, und DAVx5 von der Akkuoptimierung ausnehmen. |
+| **Tasks.org** | Aufgaben. Androids Kalenderspeicher kennt keine – ohne so eine App bietet DAVx5 die Aufgabenlisten gar nicht erst an, und **Samsung Kalender zeigt sie nie**. |
+| **Thunderbird** | der gutmütige Prüfstein am Rechner, Termine und Aufgaben nebeneinander. |
+| **Vivaldi** | Marcs Browser bringt einen CalDAV-Kalender mit. Wie eigenwillig er ist, wissen wir noch nicht. |
+| **HoneyOS** | braucht **kein** CalDAV: Kachel und Leiste fragen Aethers eigene JSON-Schnittstelle. CalDAV ist für fremde Programme. |
+
+## Standards und Vorbild
+
+    RFC 5545  das .ics-Format
+    RFC 4791  CalDAV (PUT, REPORT, calendar-query)
+    RFC 6764  /.well-known/caldav – damit reicht dem Client der Hostname
+    RFC 5397  current-user-principal: „wer bin ich, wo liegen meine Kalender"
+    RFC 6578  sync-collection: nur Änderungen holen
+    RFC 6352  CardDAV, falls Kontakte dazukommen
+
+Wo der Standard Spielraum lässt, halten wir es wie **SabreDAV**: Nextcloud und
+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.
 
 ## Die Notausfahrt