Phase 6 abgeschlossen: Aktenchat, Kanäle, Echtzeit, Benachrichtigungen

Ein Ereignisstrom mit Themen (/api/stream), in dem der Dateistrom aus Phase 5
aufgegangen ist. Zwei Prüfungen: beim Verbinden, welche Themen der Nutzer
abonnieren darf, und je Ereignis wird der Inhalt mit seinen Rechten geladen.
Das zweite ist nicht nur Vorsicht — eine Umklassifizierung wirkt dadurch in
einer offenen Verbindung sofort. In der pg_notify-Nutzlast steht nie ein
Inhalt, nur Thema, Art und Kennung.

Der Aktenchat sendet optimistisch mit clientseitiger UUIDv7, die zugleich
Idempotenzschlüssel ist. Antworten, vier feste Reaktionen, Bearbeiten mit
sichtbarem editedAt, Zurückziehen mit Platzhalter — Löschen gibt es nicht, und
eine Regel in der Datenbank hält das fest. Eine zurückgezogene Nachricht kommt
ohne Text an, nicht ausgeblendet.

Aktenzeichen im Text werden zu Vorschaukarten, serverseitig aufgelöst. Eine
Akte, die der Leser nicht sehen darf, sieht darin genauso aus wie eine, die es
gar nicht gibt.

"Als Vermerk übernehmen" steht sichtbar an jeder Nachricht. Der Vermerk gehört
dem Verfasser, nicht dem Übernehmenden; ein Systemeintrag nennt den Ursprung,
damit der Wortlaut später nicht für die Akte geschrieben wirkt.

Bei den Discord-Benachrichtigungen entscheidet die Web-App, wer was erfährt,
und der Worker liefert nur aus. Die Alternative hätte geheissen, die
Sichtbarkeitsprüfung im Worker ein zweites Mal zu bauen. In meta steht ein
Titel nur, wenn er hinaus darf — ab Stufe 3 keiner. Postausgang als Tabelle,
angestossen über LISTEN, mit Takt als Sicherheitsnetz.

Nebenbei riss das Budget der Fallakte erneut (122 kB). Drei Schritte zurück
auf 119,6: Chattexte in eine eigene i18n-Datei, ein gemeinsames AddPanel statt
viermal derselbe Aufklapp-Code, und eine eigene UUIDv7 statt des Pakets — die
Sortierbarkeit, auf der die Nachlieferung beruht, steht damit im eigenen Code
und hat Tests.

Unterwegs habe ich NotifyMode und User.notifyMode ein zweites Mal angelegt,
obwohl es beides seit dem Grundgerüst gibt. Die Migration schlug fehl und die
Datenbank musste von Hand aufgeräumt werden; die Lehre steht in docs/13.

155 Tests im Web-Paket, 15 in der Datenbank, 7 im Worker, 32 e2e.

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

docs/13-entscheidungen.md

@@ -550,3 +550,101 @@ importieren den Bereich, den sie brauchen.
 Das brachte die grösste Route von 121 auf 118 kB und wächst nicht mehr mit jedem neuen
 Bereich mit. Der Zuschnitt der sechs Gruppen folgt der gemeinsamen Verwendung, nicht der
 Grösse: was zusammen gebraucht wird, liegt zusammen.
+
+## Chat und Echtzeit
+
+### Ein Strom, Themen darin
+
+`docs/06` nennt `GET /api/stream?topics=case:<id>,notifications`. Gebaut wie beschrieben, mit
+den Themen `case:<id>`, `channel:<id>` und `user:<id>`. Der Ereignisstrom aus Phase 5
+(`/api/events`, nur Dateiprüfungen) ist darin aufgegangen.
+
+**Zwei Prüfungen, beide nötig.** Beim Verbinden wird gefiltert, welche der angefragten Themen
+der Nutzer überhaupt abonnieren darf — wer ein fremdes nennt, bekommt es nicht und erfährt
+auch nicht, ob es existiert. Und je Ereignis wird der Inhalt **mit den Rechten des Empfängers**
+geladen. Das zweite ist nicht nur Vorsicht: eine Umklassifizierung mitten in einer offenen
+Verbindung wirkt dadurch sofort, ohne dass jemand neu laden muss.
+
+In der `pg_notify`-Nutzlast steht deshalb nie ein Inhalt, nur Thema, Art und Kennung. Ein Text
+darin wäre an jedem Filter vorbei.
+
+### Die Vorschaukarte ist der heikelste Ort im Chat
+
+Ein Aktenzeichen im Fliesstext wird zur Karte. Sie wird **serverseitig** aufgelöst, und eine
+Akte, die der Leser nicht sehen darf, sieht darin genauso aus wie eine, die es gar nicht gibt.
+Nie den Titel mitschicken und im Client ausblenden — das ist der Fehler, den ein Aktensystem
+genau einmal macht.
+
+Dasselbe gilt für nachkommende Nachrichten: der Strom-Endpunkt löst die Karten je Empfänger
+auf, nicht der Absender.
+
+### Nachrichten werden zurückgezogen, nicht gelöscht
+
+Der Chat ist ausdrücklich kein Aktenbestandteil, deshalb darf hier bearbeitet werden, ohne dass
+eine Version entsteht. Eine Nachricht, auf die jemand geantwortet hat, darf trotzdem nicht
+spurlos verschwinden: `withdrawnAt` setzt einen Platzhalter, und eine Regel in der Datenbank
+verbietet `DELETE`. Autor, Zeitpunkt und Ort sind per Trigger unveränderlich.
+
+Eine zurückgezogene Nachricht kommt **ohne Text** in der Oberfläche an. Nicht ausgeblendet —
+gar nicht erst geschickt.
+
+### Die Web-App entscheidet, der Worker liefert
+
+Bei den Discord-Benachrichtigungen war die naheliegende Bauart, dem Worker die Kennungen zu
+geben und ihn nachschlagen zu lassen. Das hiesse, die Sichtbarkeitsprüfung ein zweites Mal zu
+bauen — und sie zweimal richtig zu haben, dauerhaft.
+
+Stattdessen entscheidet die Web-App beim Einstellen in den Postausgang, wer die Meldung bekommt
+(eine Zeile je Empfänger) und was darin stehen darf. In `meta` liegt ein Titel nur, wenn er
+auch nach Discord darf; ab Stufe 3 liegt dort keiner. Der Worker setzt aus festen Bruchstücken
+einen Satz zusammen und hat keine Entscheidung mehr zu treffen.
+
+Der Postausgang ist eine Tabelle, kein Aufruf: der Worker ist ein eigener Prozess und darf
+gerade neu starten. Eine Zeile, die nicht rausging, bleibt liegen. Angestossen wird er über
+`notification_queued`, der 30-Sekunden-Takt ist das Sicherheitsnetz — kein Einmal-Container,
+siehe harte Regel 8.
+
+Die Empfängerprüfung ruft `visibleCaseWhere` je Kandidat auf, also eine Abfrage pro Person.
+Bei zehn bis fünfzig Leuten ist das billiger als der Fehler, die Regel ein zweites Mal zu
+schreiben und eine der beiden Fassungen später zu vergessen.
+
+### Eigene UUIDv7 statt Paket
+
+Das Paket `uuidv7` wog 2,6 kB im Bündel der Fallakte. Ersetzt durch `web/lib/uuidv7.ts`, rund
+sechzig Zeilen, mit dem Zähler in `rand_a` für die Reihenfolge innerhalb einer Millisekunde.
+
+Der Grund ist nicht nur die Grösse: auf der **lexikografischen Sortierbarkeit** dieser
+Kennungen beruhen zwei Dinge — die Nachlieferung verpasster Nachrichten (`id > seit`) und die
+Reihenfolge im Chat ohne Sortierspalte. Diese Zusicherung steht jetzt ausdrücklich im eigenen
+Code und hat Tests, statt in einer Abhängigkeit vorausgesetzt zu werden.
+
+## Das Bündelbudget der Fallakte
+
+Die Fallakte ist die dichteste Seite der Anwendung: Abschnitte, Verlauf, Beteiligte,
+Verknüpfungen, Dokumente, Anhänge, Chat. Mit Phase 6 riss sie das Budget aus `docs/09`
+(122 kB gegen 120 kB erlaubte) und wurde in drei Schritten darunter gebracht:
+
+| Schritt | Ersparnis |
+|---|---|
+| Chattexte aus `lib/i18n/cases.ts` in eine eigene Datei | ~0,5 kB |
+| Gemeinsames `AddPanel` statt viermal derselbe Aufklapp-Code | ~1 kB |
+| Eigene UUIDv7 statt Paket | ~2,6 kB |
+
+Sie liegt jetzt bei **119,6 kB**. Das ist knapp, und die Richtung stimmt nicht: jede weitere
+Insel auf dieser Seite kostet wieder. Der nächste Schritt, wenn es eng wird, ist kein weiteres
+Kürzen, sondern die Seite zu teilen — die Beteiligten, Verknüpfungen und Anhänge gehören
+fachlich zusammen und könnten hinter einen Reiter.
+
+Der Chat wird bereits erst geladen, wenn er in Sichtweite kommt. Das zählt Next zwar weiter
+zur ersten Ladung, spart aber wirklich etwas: wer nur die Akte liest, baut keine offene
+Verbindung zum Ereignisstrom auf.
+
+## Beim Erweitern des Schemas zuerst nachsehen
+
+In dieser Phase wurden `NotifyMode` und `User.notifyMode` ein zweites Mal angelegt — es gab
+beides schon seit dem Grundgerüst. Die Migration scheiterte, und die Datenbank stand halb
+geändert da; das Aufräumen war von Hand nötig.
+
+Die Lehre steht hier, weil sie sich wiederholen wird: **vor jedem neuen Modell, Enum oder Feld
+im Schema nachsehen, ob es das schon gibt.** Das Schema ist über achthundert Zeilen lang, und
+der Teil, den man gerade nicht bearbeitet, ist der, den man vergisst.