feat: Dashboard Heute, Kontakte und Kontaktprotokoll

Das Dashboard beantwortet die Frage, was heute ansteht - nicht, welche
Daten es gibt. Jede Kachel endet in einer Handlung: Fristen-Ampel,
wartet auf andere (mit Tagen seit dem letzten Kontakt), offene
Nachforderungen des Bezirks mit Fortschrittsbalken, ungepruefter
Posteingang, unverbuchte Belege, Kennzahlen.

Zwoelf Abfragen in einem Promise.all, kein N+1. Cent-Betraege werden
beim Verlassen der Serverseite gewandelt.

Kacheln zu Modulen, die ein Mitleser nicht freigegeben bekommen hat,
entfallen ganz - sie zeigen nicht "0", denn das waere eine Aussage ueber
Daten, die er nicht sehen darf.

Kontaktprotokoll als Schnellerfassung: Datum vorbelegt, Art als grosse
Knopfreihe, Dauer als Schnellwahl, ein Freitextfeld. Alles andere
eingeklappt. Ziel sind unter 20 Sekunden am Handy.

Das Haekchen "persoenlicher Kontakt zur betreuten Person" ist bewusst
NICHT vorbelegt - es wandert in den Jahresbericht nach § 1863 BGB, und
ein versehentlich gesetztes Haekchen waere dort eine falsche Angabe
gegenueber dem Gericht.

Aus demselben Grund gilt der Textbaustein "regelmaessiger persoenlicher
Kontakt" erst ab persoenlichem Kontakt in mindestens 75 Prozent der
Monate. Sonst schreibt die Auswertung ausdruecklich, dass kein
persoenlicher Kontakt dokumentiert ist. Ein geschoenter Bericht hilft
niemandem.

Protokolldaten werden als 12:00 UTC gespeichert und durchgaengig in UTC
gerechnet, sonst kippt die Zeitzone einzelne Besuchstage.

51 Tests.

Etappe: 2
Phase: Alltag

docs/schema-wuensche/dashboard.md

@@ -0,0 +1,120 @@
+# Schema-Wünsche aus Dashboard und Kontakten
+
+Diese Datei sammelt, was beim Bauen von `/heute` und den Kontakten
+aufgefallen ist. `prisma/schema.prisma` wurde **nicht** geändert – alles
+hier ist ein Vorschlag für eine spätere Migration, mit der Begründung
+daneben.
+
+---
+
+## 1. `Heimkostenmonat`: Kostenseite und Deckungsseite überschneiden sich
+
+**Was ich gebaut habe.** Die Kennzahl „Deckungslücke“ rechnet exakt nach
+der Gruppierung im Schema:
+
+```
+Gesamtkosten = pflegeEigenanteil + unterkunftVerpflegung
+             + investitionskosten + ausbildungsumlage + zusatzleistungen
+
+Deckung      = pflegekasse + leistungszuschlag + rente
+             + sonstigeEinkuenfte + sozialhilfe + eigenmittel
+
+Deckungslücke = Gesamtkosten − Deckung
+```
+
+**Das Problem.** `pflegeEigenanteilCent` heißt „Eigenanteil“. Der
+einrichtungseinheitliche Eigenanteil ist definitionsgemäß **schon um die
+Leistung der Pflegekasse nach § 43 SGB XI gekürzt**. Steht in derselben
+Zeile zusätzlich `pflegekasseCent` als Deckung, wird dieser Betrag doppelt
+gezählt, und das Dashboard weist eine Überdeckung aus, die es nicht gibt.
+Dasselbe gilt für `leistungszuschlagCent` (§ 43c SGB XI), der den
+Eigenanteil ebenfalls mindert.
+
+**Wunsch.** Entweder
+
+- den Kommentar am Feld schärfen: „`pflegeEigenanteilCent` ist der
+  **Brutto**-Pflegesatz; `pflegekasseCent` und `leistungszuschlagCent`
+  werden davon abgezogen" – dann stimmt die Rechnung oben; oder
+- ein Feld `heimrechnungGesamtCent` ergänzen, das schlicht die Summe der
+  Heimrechnung trägt, und die Aufteilung nur noch informativ führen.
+
+Solange das offen ist, sollte das Heim-Modul entweder den Bruttosatz oder
+`pflegekasseCent = 0` erfassen – konsequent das eine oder das andere.
+Wer die Kachel zum ersten Mal sieht und einen absurden Wert findet, weiß
+mit dieser Notiz, woran es liegt.
+
+---
+
+## 2. `Kontaktprotokoll.datum` könnte `@db.Date` sein
+
+**Was ich gebaut habe.** Das Feld ist `DateTime`. Die Schnellerfassung
+kennt nur einen Tag, keine Uhrzeit; gespeichert wird deshalb bewusst
+**12:00 UTC**. Um die Mittagszeit herum verschiebt keine Zeitzone den
+Eintrag auf den Vor- oder Folgetag, und die Auswertung („an wie vielen
+Tagen bestand persönlicher Kontakt?") zählt zuverlässig.
+
+**Wunsch.** `datum DateTime @db.Date` – dann verschwindet die
+12:00-Konvention, und der Typ sagt, was gemeint ist. Fachlich zählt beim
+Jahresbericht nach § 1863 BGB der Tag, nicht die Uhrzeit.
+
+Falls die Uhrzeit später doch gebraucht wird (Zeiterfassung für die
+Vergütung), wäre ein zusätzliches `beginnUhrzeit String?` sauberer als das
+Datumsfeld doppelt zu belegen.
+
+---
+
+## 3. `Kontakt`: kein Feld für „nicht mehr zuständig"
+
+Sachbearbeiter wechseln. Heute bleibt nur der Papierkorb – dann ist aber
+auch die Gesprächshistorie aus dem Verzeichnis verschwunden, obwohl sie
+für den Jahresbericht und für Rückfragen weiter gebraucht wird.
+
+**Wunsch.** `aktivBis DateTime? @db.Date` oder `aktiv Boolean @default(true)`.
+Das Verzeichnis würde inaktive Kontakte einklappen statt löschen, und die
+Historie bliebe sichtbar. Ein `nachfolgerId String?` auf denselben Typ
+wäre die Kür: „Frau Krämer, jetzt Herr Sandner".
+
+---
+
+## 4. `Nachforderung`: kein `betreuteId`
+
+`Nachforderung` hängt nur über `antrag` an der betreuten Person. Jede
+Abfrage muss deshalb über die Beziehung filtern:
+
+```ts
+where: { antrag: { betreuteId, geloeschtAm: null }, geloeschtAm: null }
+```
+
+Das funktioniert, ist aber die einzige Stelle im Dashboard, an der die
+Zugriffsprüfung nicht direkt auf einer Spalte sitzt. Bei einer späteren
+Row-Level-Security in Postgres wäre eine denormalisierte `betreuteId`
+(wie bei `DokumentVerknuepfung`) die einfachere Grundlage.
+
+---
+
+## 5. `Vermoegensposten`: kein Kennzeichen „zählt nicht in die Summe"
+
+Die Kachel „Vermögen" summiert je Posten den jüngsten `Wertstand` und
+zieht `VERBINDLICHKEIT` ab. Posten ohne jeden Wertstand werden gesondert
+gezählt und ausgewiesen („2 Posten haben noch keinen Wert und fehlen in
+dieser Summe") – stillschweigend als 0 zu führen wäre in einer
+Rechnungslegung nach § 1865 BGB falsch.
+
+Offen bleibt der Fall „bewusst nicht bewertbar" (Hausrat, persönliche
+Gegenstände). Heute sieht er aus wie „vergessen".
+
+**Wunsch.** `ohneWertBegruendung String?` – analog zu
+`belegFehltBegruendung` bei `Buchung`. Dann kann die Kachel zwischen
+„fehlt noch" und „bewusst ohne Wert" unterscheiden.
+
+---
+
+## 6. Kein Modell für die Sachstandsanfrage
+
+Die Kachel „Wartet auf andere" verlinkt auf
+`/vorgaenge/<id>?aktion=sachstandsanfrage`. Ob daraus ein Schreiben wird,
+entscheidet das Vorgangsmodul. Wird eine Anfrage verschickt, sollte
+`Vorgang.letzterKontaktAm` fortgeschrieben werden – sonst bleibt der
+Vorgang für immer rot, obwohl gerade nachgefasst wurde. Das ist kein
+Schema-Wunsch, sondern eine Verabredung zwischen den Modulen; sie steht
+hier, damit sie nicht verloren geht.