Merge #37 : Update brach ohne Meldung ab

Abgeschnittene Leitungen unter pipefail beendeten update.sh stumm und haetten die Selbstpruefung der Sicherung falsch negativ gemacht. Behoben, mit ERR-Falle und Test gegen das Muster.
Update brach ohne Meldung ab
2026-08-23 22:36:53 +00:00 · 2026-08-24 00:36:08 +02:00 · 2026-08-23 22:28:47 +00:00 · 2026-08-23 23:37:02 +02:00 · 2026-08-23 23:34:38 +02:00 · 2026-08-23 21:29:15 +00:00
64 changed files with 9463 additions and 7581 deletions
@@ -0,0 +1,32 @@
 # Zeilenenden
 #
 # Im Repository steht ueberall LF, unabhaengig davon, auf welchem System
 # gearbeitet wird. Der Grund ist nicht Geschmack, sondern eine Falle:
 #
 # Solange Dateien gemischt vorliegen, schreibt jedes zeilenweise
 # arbeitende Werkzeug - sed, ein Formatierer, ein Skript - die Datei mit
 # LF zurueck. Der Diff zeigt dann nicht die drei geaenderten Zeilen,
 # sondern die ganze Datei. Genau das ist passiert: 578 Diff-Zeilen statt
 # 8, kurz vor einem Push bemerkt.
 #
 # Nebenwirkung derselben Mischung: "git diff --check" meldet bei
 # CRLF-Dateien jede hinzugefuegte Zeile als "trailing whitespace", weil
 # es das CR so wertet. Damit ist die Pruefung fuer diese Dateien wertlos.
 * text=auto eol=lf
 # Shell-Skripte laufen auf dem Server. Ein CRLF im Shebang macht sie
 # unbrauchbar ("bad interpreter"), und der Fehler ist von aussen nicht
 # anzusehen. Deshalb hier ausdruecklich, nicht nur ueber die Regel oben.
 *.sh text eol=lf
 # Binaerdateien nie anfassen.
 *.png binary
 *.jpg binary
 *.jpeg binary
 *.gif binary
 *.ico binary
 *.pdf binary
 *.woff binary
 *.woff2 binary
 *.ttf binary
 *.zip binary
@@ -26,6 +26,141 @@ Wiederherstellung*.
 _Noch nichts._
 ## [1.10.2] – 2026-08-24
 ### Behoben
 - **Das Update brach ohne Meldung ab.** Beim Sprung von 1.5.0 auf 1.10.1
  endete `scripts/update.sh` mitten in der Ausgabe — kein Fehler, keine
  Zeile, einfach zurück zur Eingabeaufforderung. Ursache war eine
  abgeschnittene Leitung:
  ```
  git log --oneline "HEAD..$ZIEL" | head -15 | sed ...
  ```
  `head` schließt die Leitung nach 15 Zeilen, `git log` schreibt weiter
  und bekommt SIGPIPE. Weil das Skript mit `set -o pipefail` und
  `set -e` läuft, gilt die ganze Kette als gescheitert und das Skript
  beendet sich — stumm.
  Das ist zeitabhängig und deshalb monatelang nicht aufgefallen: Solange
  `git log` fertig war, bevor `head` zumachte, ging alles gut. Genau bei
  1.10.0 lagen zum ersten Mal **mehr als 15 Commits** dazwischen.
 - **Dieselbe Falle in der Selbstprüfung der Sicherung.** `sicherung.sh`
  prüfte mit `openssl … | head -c 5 | grep -q "PGDMP"`, ob sich die
  frische Sicherung wieder entschlüsseln lässt. Bei kleiner Datenbank
  ging das gut, weil alles im Puffer stand. Mit wachsender Datenbank
  hätte es gekippt — und dann hätte das Skript eine **völlig intakte
  Sicherung als kaputt gemeldet** und das Update verweigert.
 ### Geändert
 - **Ein stummer Abbruch ist nicht mehr möglich.** `update.sh` meldet
  jetzt bei jedem unerwarteten Ende die Zeilennummer und den Exitcode,
  und erklärt bei 141 ausdrücklich, dass es sich um SIGPIPE handelt und
  um einen Fehler im Skript, nicht um einen Bedienfehler.
 - Stehen mehr als 15 Commits an, steht jetzt „… und N weitere" darunter,
  statt sie wortlos wegzulassen.
 ### Geprüft
 - Ein Test verbietet das Muster künftig in allen Betriebsskripten:
  Wer wieder `| head` in eine Leitung schreibt, bekommt die Zeilennummer
  genannt. Gegenprobe gemacht — der Test schlägt an.
 - Der Ablauf von 1.5.0 auf 1.10.1 einmal nachgestellt: läuft durch.
 ## [1.10.1] – 2026-08-23
 ### Geändert
 - **Der Beispielfall hat jetzt ein Jahr Kontobewegungen**
  ([#22](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/issues/22)).
  Bisher brachte er Konten und Kontostände mit, aber keine einzige
  Buchung — Kassenbuch, Belegpflicht, Dauerzahlungen und die Erkennung
  wiederkehrender Zahlungen liefen darin also leer. Wer die Anwendung zum
  ersten Mal ansah, musste erst eine CSV importieren.
  Neu sind 107 Buchungen über zwölf Monate: Rente, Betriebsrente und
  Pflegekasse als Einnahmen, Heimentgelt, Barbetrag, Sterbegeldbeitrag,
  Telefon und Kontoführung als monatliche Ausgaben, dazu Rundfunkbeitrag
  und Grundsteuer vierteljährlich sowie eine Handvoll Einzelposten.
  Das betrifft nur neue Installationen mit `SEED_DEMO=true` — an einem
  bestehenden Bestand ändert sich nichts.
 ### Behoben
 - **„gGmbH" wurde nicht als Rechtsform erkannt.** Beim Zusammenfassen
  wiederkehrender Zahlungen galten „Seniorenzentrum St. Katharina" und
  „Seniorenzentrum St. Katharina gGmbH" als zwei verschiedene Empfänger —
  und damit zerfiel die Gruppe genau dort, wo sie am meisten zählt: Heime,
  Sozialdienste und Träger sind fast durchweg gGmbH.
 ### Was der Beispielfall jetzt zeigt
 - Das Heimentgelt steht in **drei Schreibweisen** auf dem Auszug und wird
  trotzdem als eine monatliche Zahlung von 2.489 € geführt.
 - Genau **eine** Buchung hat weder Quittung noch Begründung — damit die
  Belegpflicht etwas zu zeigen hat, aber die Liste nicht rot leuchtet.
 - Die Sterbegeld-Lastschriften sind bewusst **nicht** zugeordnet: So lässt
  sich der Handgriff „zwölf Zahlungen als belegt zuordnen" ausprobieren.
  Der Beitrag steigt im Mai von 18,40 € auf 19,80 €, damit auch die
  Abweichungsprüfung sichtbar wird.
 - Der Kontostand zum 31.07.2026 wird aus dem Anfangsstand und den
  Buchungen **gerechnet**, nicht behauptet. Ein Beispielfall, der sich
  selbst widerspricht, wäre schlimmer als einer ohne Buchungen.
 ### Geprüft
 - Ein Einheitstest für die gGmbH-Erkennung.
 - Vier End-to-End-Tests am Beispielfall: Umfang und Zeitraum der
  Buchungen, die Übereinstimmung von Kontostand und Buchungssumme, die
  erkannten Zahlungsgruppen und das Kassenbuch.
 ## [1.10.0] – 2026-08-23
 ### Hinzugefügt
 - **Deine Anschrift steht jetzt in jedem Schreiben**
  ([#21](https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/issues/21)).
  Bisher ging jeder Brief ohne Rücksendeadresse hinaus — im
  Absenderblock stand nur dein Name, und in der Datumszeile fehlte der
  Ort. Bei einer Versicherung oder Behörde wirkt das unseriös und macht
  es der Gegenstelle unnötig schwer zu antworten.
  Unter **Mein Konto → Meine Anschrift** einmal Straße, PLZ und Ort
  hinterlegen. Ab da stehen sie im Absenderblock jedes erzeugten
  Schreibens, und die Datumszeile lautet „Bayreuth, den 23.08.2026".
  Betroffen ist alles: Rückkaufswert-Anfrage, Serienabfrage, Kündigung,
  Sachstandsanfrage und die eigenen Vorlagen.
 - **Zwei neue Platzhalter** für eigene Vorlagen: `{{betreuer_anschrift}}`
  und `{{betreuer_ort}}`.
 ### Eine Zusage
 **Was fehlt, bleibt weg.** Jede der drei Angaben ist einzeln freiwillig.
 Hinterlegst du nur den Ort, bekommst du die Datumszeile mit Ort und einen
 Absenderblock, der weiterhin nur aus deinem Namen besteht — keine leeren
 Zeilen, kein Komma ohne Ort. Eine halb ausgefüllte Adresse sieht nach
 Fehler aus, ein bloßer Name nach Absicht.
 ### Datenbank
 Eine Migration: drei Felder am Benutzer. Die Anschrift hängt an dir und
 nicht an der betreuten Person — sie gilt für alle Akten.
 ### Geprüft
 - Sieben Einheitstests für den Absenderblock, darunter jede
  Teilbefüllung und die Gegenprobe, dass nie die Heimadresse der
  betreuten Person im Absender landet.
 - Vier End-to-End-Tests: der Brief ohne hinterlegte Anschrift, das
  Speichern unter *Mein Konto*, der Brief danach und die Gegenprobe am
  Rückkaufswert-Schreiben.
 ## [1.9.0] – 2026-08-23
 ### Hinzugefügt
@@ -1036,7 +1171,10 @@ Was davon wann angegangen wird, steht in [`docs/ROADMAP.md`](docs/ROADMAP.md).
 ---
-[Unveröffentlicht]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.9.0...HEAD
+[Unveröffentlicht]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.10.2...HEAD
 [1.10.2]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.10.1...v1.10.2
 [1.10.1]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.10.0...v1.10.1
 [1.10.0]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.9.0...v1.10.0
 [1.9.0]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.8.0...v1.9.0
 [1.8.0]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.7.0...v1.8.0
 [1.7.0]: https://git.wilde-server.de/florian.wilde/betreuungs-cockpit/compare/v1.6.0...v1.7.0
@@ -97,11 +97,12 @@ DATABASE_URL="postgresql://cockpit:entwicklung@localhost:5433/betreuungs_cockpit
 **3. Datenbank einrichten:**
 ```bash
-npx prisma migrate dev --name fundament
+npm run setup             # Migrationen, Volltextsuche, Audit-Schutz, Beispieldaten
 npm run db:sql            # Volltextsuche und Audit-Schutz
 npm run db:seed
 ```
 Das ist die Kurzform für `db:deploy`, `db:sql` und `db:seed` — die drei
 Schritte laufen ohne Rückfrage durch.
 **4. Starten:**
 ```bash
@@ -513,6 +514,35 @@ npm run protokoll        # Bauprotokoll aus der Git-Historie
 npm run version -- patch # Version anheben, Changelog vorbereiten
 ```
 ### Die Datenbankbefehle
 Welcher Befehl wofür — und welcher am Terminal Rückfragen stellt. Nur
 `db:migrate` ist interaktiv; alle anderen laufen in Skripten, in der CI
 und im Container durch.
 | Befehl | Wofür | Rückfragen? |
 |---|---|---|
 | `npm run setup` | Ersteinrichtung: Migrationen, SQL-Skripte, Beispieldaten | nein |
 | `npm run db:migration -- <name>` | Schemaänderung während der Entwicklung — erzeugt die Migration und nimmt die `DROP INDEX`-Zeilen zur Volltextsuche heraus | nein |
 | `npm run db:deploy` | Vorhandene Migrationen anwenden (Server, CI, Container) | nein |
 | `npm run db:migrate` | `prisma migrate dev` — fragt nach dem Namen und bietet an, die Datenbank zurückzusetzen | **ja** |
 | `npm run db:sql` | Volltextsuche und Audit-Schutz; läuft nicht mit den Migrationen mit | nein |
 | `npm run db:pruefen` | Nachsehen, ob die Trigramm-Indizes noch stehen | nein |
 | `npm run db:seed` | Beispieldaten einspielen | nein |
 Der übliche Weg für eine Schemaänderung:
 ```bash
 # Schema in prisma/schema.prisma ändern, dann
 npm run db:migration -- ansprechpartner   # erzeugen und lesen
 npm run db:deploy                          # anwenden
 npm run db:pruefen                         # Indizes nachsehen
 ```
 `db:migrate` braucht man dafür nicht mehr. Es bleibt für die Fälle, in
 denen man wirklich den interaktiven Prisma-Ablauf will — etwa um eine
 verkorkste Entwicklungsdatenbank zurückzusetzen.
 Konventionen — verbindlich für alle Beiträge:
 [`docs/KONVENTIONEN.md`](docs/KONVENTIONEN.md).
 Schnittstellen zwischen den Modulen:
@@ -545,7 +575,8 @@ Produktion.
  über den Abschnitt `environment:`.
 - Beim ersten Start eines Containers laufen die Migrationen automatisch
  mit. Die beiden SQL-Skripte (Volltextsuche, Audit-Schutz) sind
-  **einmalig von Hand** anzustoßen, siehe oben.
+  **einmalig von Hand** anzustoßen, siehe oben. Beim Aktualisieren
  erledigt das `scripts/update.sh` mit — beide Skripte sind idempotent.
 ### Technische Grundlage
@@ -131,14 +131,14 @@ cd /opt/betreuungs-cockpit
 # Auf die letzte veröffentlichte Fassung wechseln,
 # nicht auf den laufenden Entwicklungsstand
-git checkout v1.9.0
+git checkout v1.10.2
 ```
 ### Kontrolle
 ```bash
 ls docker-compose.yml Dockerfile .env.example   # alle drei da
-git describe --tags                              # v1.9.0
+git describe --tags                              # v1.10.2
 ```
 ---
@@ -299,7 +299,7 @@ betreuungs-cockpit-sicherung-1  Up
 ```bash
 # Antwortet die Anwendung? (Port anpassen, falls du APP_PORT gesetzt hast)
 curl -s http://127.0.0.1:3000/api/gesundheit
-# {"status":"bereit","version":"1.9.0","commit":"..."}
+# {"status":"bereit","version":"1.10.2","commit":"..."}
 ```
 Kommt hier nichts, sieh in die Logs:
@@ -649,7 +649,7 @@ Erst **vom Proxy-Server aus** — kommt er überhaupt an?
 ```bash
 curl -s http://10.0.0.5:3000/api/gesundheit
-# {"status":"bereit","version":"1.9.0",...}
+# {"status":"bereit","version":"1.10.2",...}
 ```
 Kommt hier nichts, liegt es an 7a: falsche `APP_BIND`, Firewall, oder der
@@ -700,7 +700,7 @@ Zum Schluss: **Fristen → Pflichtfristen ableiten**.
 - Du kommst mit E-Mail, Passwort und dem Code aus der App herein.
 - Unter **Fristen** stehen Einträge mit Paragraphenbezug.
 - Unter **Protokoll** siehst du deine eigene Anmeldung.
- Unten links in der Seitenleiste steht `Version 1.9.0 · <commit>`.
+- Unten links in der Seitenleiste steht `Version 1.10.2 · <commit>`.
 ---
@@ -875,7 +875,7 @@ alles so vor wie zuvor.
 | Aufruf | Wirkung |
 |---|---|
 | `./scripts/update.sh` | auf die neueste veröffentlichte Fassung |
-| `./scripts/update.sh v1.9.0` | auf eine bestimmte Fassung |
+| `./scripts/update.sh v1.10.2` | auf eine bestimmte Fassung |
 | `./scripts/update.sh --pruefen` | nur nachsehen, nichts ändern |
 | `./scripts/update.sh --ja` | ohne Rückfrage (für cron) |
 | `./scripts/update.sh --verwerfen` | eigene Änderungen wegwerfen statt beiseitelegen |
@@ -913,7 +913,7 @@ git fetch --tags
 git log --oneline HEAD..origin/main
 # 3. Umschalten
-git checkout v1.9.0
+git checkout v1.10.2
 # 4. Neu bauen und starten
 GIT_COMMIT=$(git rev-parse --short HEAD) BUILD_ZEIT=$(date -Iseconds) docker compose up -d --build
@@ -9,7 +9,7 @@ Zeit spart. Er steht weit unten, wenn er nur schön wäre.
 Diese Datei ist eine Absichtserklärung, kein Vertrag. Was sich im Betrieb
 als wichtiger herausstellt, rutscht nach oben.
-Stand: 23.08.2026 · Aktuelle Fassung: **1.9.0** ([CHANGELOG](../CHANGELOG.md))
+Stand: 23.08.2026 · Aktuelle Fassung: **1.10.2** ([CHANGELOG](../CHANGELOG.md))
 ---
@@ -0,0 +1,97 @@
 import { expect, test } from '@playwright/test'
 import { PrismaClient } from '@prisma/client'
 import { anmelden } from './hilfen'
 /**
 * Die eigene Anschrift im Schreiben — gegen die echte Anwendung.
 *
 * Der Weg, um den es geht: einmal unter „Mein Konto" hinterlegen, und
 * ab da steht sie im Absenderblock und der Ort in der Datumszeile —
 * ohne dass man beim Schreiben daran denken muss.
 */
 async function mitDb<T>(arbeit: (db: PrismaClient) => Promise<T>): Promise<T> {
  const db = new PrismaClient()
  try {
    return await arbeit(db)
  } finally {
    await db.$disconnect()
  }
 }
 /** Zurück auf „nichts hinterlegt", damit der Fall auch prüfbar bleibt. */
 async function anschriftLeeren(): Promise<void> {
  await mitDb(async (db) => {
    await db.user.updateMany({ data: { strasse: null, plz: null, ort: null } })
  })
 }
 test.describe('Absenderanschrift', () => {
  test.beforeAll(async () => {
    await anschriftLeeren()
  })
  test.afterAll(async () => {
    await anschriftLeeren()
  })
  test('ohne hinterlegte Anschrift steht nur der Name im Brief', async ({ page }) => {
    await anmelden(page)
    await page.goto('/schreiben/neu?art=FREI')
    const text = await page.locator('textarea#text').inputValue()
    const zeilen = text.split('\n')
    // Erste Zeile ist der Absender, danach kommt gleich die Leerzeile.
    expect(zeilen[0]).toBe('Florian Wilde')
    expect(zeilen[1]).toBe('')
    // Kein Ort in der Datumszeile, also auch kein Komma davor.
    expect(text).not.toContain(', den ')
  })
  test('speichert die Anschrift unter Mein Konto', async ({ page }) => {
    await anmelden(page)
    await page.goto('/konto')
    await page.locator('input#strasse').fill('Cottenbacher Str. 23')
    await page.locator('input#plz').fill('95445')
    await page.locator('input#ort').fill('Bayreuth')
    await page.getByRole('button', { name: 'Anschrift speichern' }).click()
    await expect(page.getByText('Deine Anschrift ist gespeichert.')).toBeVisible()
    await page.reload()
    await expect(page.locator('input#strasse')).toHaveValue('Cottenbacher Str. 23')
  })
  test('trägt sie in Absenderblock und Datumszeile des Schreibens', async ({ page }) => {
    await anmelden(page)
    await page.goto('/schreiben/neu?art=FREI')
    const text = await page.locator('textarea#text').inputValue()
    const zeilen = text.split('\n')
    expect(zeilen[0]).toBe('Florian Wilde')
    expect(zeilen[1]).toBe('Cottenbacher Str. 23')
    expect(zeilen[2]).toBe('95445 Bayreuth')
    expect(text).toContain('Bayreuth, den ')
  })
  test('steht auch im Rückkaufswert-Schreiben zum Vertrag', async ({ page }) => {
    const vertragId = await mitDb(async (db) => {
      const vertrag = await db.vertrag.findFirst({
        where: { art: 'LEBENSVERSICHERUNG', geloeschtAm: null },
        select: { id: true },
      })
      return vertrag?.id ?? ''
    })
    test.skip(vertragId === '', 'Kein Lebensversicherungsvertrag im Bestand.')
    await anmelden(page)
    await page.goto(`/schreiben/neu?art=RUECKKAUFSWERT&vertragId=${vertragId}`)
    const text = await page.locator('textarea#text').inputValue()
    expect(text).toContain('Cottenbacher Str. 23')
    expect(text).toContain('Bayreuth, den ')
  })
 })
@@ -0,0 +1,138 @@
 import { expect, test } from '@playwright/test'
 import { PrismaClient } from '@prisma/client'
 import { anmelden } from './hilfen'
 /**
 * Der Demo-Fall mit Kontobewegungen — gegen die echte Anwendung.
 *
 * Was hier geprüft wird, ist kein Verhalten der Anwendung, sondern die
 * Brauchbarkeit der Beispieldaten: Wer die Anwendung zum ersten Mal
 * ansieht, soll auf den Finanzseiten etwas vorfinden und nicht erst
 * eine CSV importieren müssen.
 *
 * Die Prüfungen sind bewusst grob gehalten — sie sollen anschlagen, wenn
 * der Demo-Fall leer läuft, und nicht bei jeder geänderten Zahl.
 */
 async function mitDb<T>(arbeit: (db: PrismaClient) => Promise<T>): Promise<T> {
  const db = new PrismaClient()
  try {
    return await arbeit(db)
  } finally {
    await db.$disconnect()
  }
 }
 test.describe('Demo-Fall', () => {
  test('bringt ein Jahr Kontobewegungen mit', async () => {
    const zahlen = await mitDb(async (db) => {
      const betreute = await db.betreute.findFirst({
        where: { vorname: 'Erika', nachname: 'Musterfrau' },
        select: { id: true },
      })
      if (!betreute) return null
      const buchungen = await db.buchung.findMany({
        where: { betreuteId: betreute.id, geloeschtAm: null },
        select: { datum: true },
        orderBy: { datum: 'asc' },
      })
      const ohneNachweis = await db.buchung.count({
        where: { betreuteId: betreute.id, belegId: null, belegFehltBegruendung: null },
      })
      return { buchungen, ohneNachweis }
    })
    test.skip(zahlen === null, 'Kein Demo-Fall in dieser Datenbank.')
    if (!zahlen) return
    expect(zahlen.buchungen.length).toBeGreaterThan(50)
    // Über mindestens zwölf Monate verteilt, nicht alle an einem Tag.
    const erste = zahlen.buchungen[0]!.datum
    const letzte = zahlen.buchungen[zahlen.buchungen.length - 1]!.datum
    const monate =
      (letzte.getUTCFullYear() - erste.getUTCFullYear()) * 12 +
      (letzte.getUTCMonth() - erste.getUTCMonth())
    expect(monate).toBeGreaterThanOrEqual(11)
    // Genau ein Fall ohne Beleg und ohne Begründung — sonst hätte die
    // Belegpflicht nichts zu zeigen, oder zu viel.
    expect(zahlen.ohneNachweis).toBe(1)
  })
  test('der Kontostand stimmt mit der Summe der Buchungen überein', async () => {
    const ergebnis = await mitDb(async (db) => {
      const konto = await db.konto.findFirst({
        where: { art: 'GIRO', betreute: { vorname: 'Erika', nachname: 'Musterfrau' } },
        select: { id: true },
      })
      if (!konto) return null
      const staende = await db.saldostand.findMany({
        where: { kontoId: konto.id },
        orderBy: { stichtag: 'asc' },
      })
      if (staende.length < 2) return null
      const [anfang, ende] = [staende[0]!, staende[staende.length - 1]!]
      const bewegungen = await db.buchung.findMany({
        where: {
          kontoId: konto.id,
          geloeschtAm: null,
          datum: { gt: anfang.stichtag, lte: ende.stichtag },
        },
        select: { betragCent: true, richtung: true },
      })
      const summe = bewegungen.reduce(
        (wert, b) => (b.richtung === 'EINNAHME' ? wert + b.betragCent : wert - b.betragCent),
        0n,
      )
      return { erwartet: anfang.betragCent + summe, tatsaechlich: ende.betragCent }
    })
    test.skip(ergebnis === null, 'Kein Demo-Fall mit zwei Kontoständen.')
    if (!ergebnis) return
    // Ein Demo-Fall, der sich selbst widerspricht, ist schlimmer als
    // einer ohne Buchungen: Man rechnet nach und verliert das Vertrauen.
    expect(ergebnis.tatsaechlich).toBe(ergebnis.erwartet)
  })
  test('die Erkennung wiederkehrender Zahlungen findet mehrere Gruppen', async ({ page }) => {
    await anmelden(page)
    await page.goto('/finanzen/wiederkehrend')
    const inhalt = await page.locator('body').innerText()
    // Monatliches und Vierteljährliches, beides erkannt.
    expect(inhalt).toContain('Seniorenzentrum')
    expect(inhalt).toContain('TeleCare')
    expect(inhalt).toContain('Beitragsservice')
    expect(inhalt).toContain('monatlich')
    expect(inhalt).toContain('vierteljährlich')
    // Der eigentliche Vorführeffekt: Das Heim steht in drei Schreibweisen
    // auf dem Auszug und wird trotzdem als eine Zahlung geführt.
    expect(inhalt).toContain('3 Schreibweisen zusammengefasst')
    // Die Sterbekasse steht im zweiten Abschnitt: Zu ihr gibt es einen
    // Vertrag, die Zahlungen sind ihm aber noch nicht zugeordnet. Damit
    // lässt sich der Handgriff aus der Dauerzahlungs-Zuordnung am
    // Demo-Fall ausprobieren, statt ihn nur zu beschreiben.
    expect(inhalt).toContain('Schon einem Vertrag zugeordnet')
    expect(inhalt).toContain('Nordheim Sterbekasse')
    expect(inhalt).toContain('als belegt zuordnen')
  })
  test('das Kassenbuch zeigt die Buchungen und die fehlende Quittung', async ({ page }) => {
    await anmelden(page)
    await page.goto('/finanzen/buchungen')
    const inhalt = await page.locator('body').innerText()
    expect(inhalt).toContain('Heimentgelt')
    // Die eine Buchung ohne Quittung und ohne Begründung.
    expect(inhalt).toContain('Modehaus Lindner')
  })
 })
@@ -0,0 +1,116 @@
 import { expect, test } from '@playwright/test'
 import { PrismaClient } from '@prisma/client'
 import { anmelden } from './hilfen'
 /**
 * Verweise über Aktengrenzen hinweg — gegen die echte Anwendung.
 *
 * Die Auswahllisten im Browser zeigen nur die eigene Akte. Darauf darf
 * sich der Server nicht verlassen: Wer das Formular verändert, schickt
 * jede beliebige Id.
 *
 * Genau das wird hier nachgestellt — nicht als nachgebauter Aufruf,
 * sondern indem dem echten Auswahlfeld ein Eintrag mit einer fremden Id
 * untergeschoben und das Formular ganz normal abgeschickt wird. Nur so
 * beweist der Test etwas: Er liefe rot, wenn die Prüfung fehlte.
 *
 * Solange nur eine betreute Person angelegt ist, wäre der Fehler
 * folgenlos. Er bliebe es nicht — ein fremder Name stünde im Briefkopf.
 */
 const KENNUNG = 'Prüfhausen Fremdakte'
 async function mitDb<T>(arbeit: (db: PrismaClient) => Promise<T>): Promise<T> {
  const db = new PrismaClient()
  try {
    return await arbeit(db)
  } finally {
    await db.$disconnect()
  }
 }
 async function aufraeumen(): Promise<void> {
  await mitDb(async (db) => {
    await db.betreute.deleteMany({ where: { nachname: { contains: 'Fremdakte' } } })
  })
 }
 test.describe('Verweise auf eine fremde Akte', () => {
  test.beforeAll(async () => {
    await aufraeumen()
  })
  test.afterAll(async () => {
    await aufraeumen()
  })
  test('weist einen Kontakt aus einer anderen Akte ab', async ({ page }) => {
    // Zweite Akte mit einem Kontakt darin — der angemeldete Benutzer hat
    // auf sie keinen Zugriff.
    const fremderKontakt = await mitDb(async (db) => {
      const fremde = await db.betreute.create({
        data: {
          vorname: 'Otto',
          nachname: `${KENNUNG} Fremdakte`,
          geburtsdatum: new Date(Date.UTC(1940, 0, 1)),
        },
      })
      const kontakt = await db.kontakt.create({
        data: {
          betreuteId: fremde.id,
          name: `${KENNUNG} Fremder Sachbearbeiter`,
          rolle: 'SACHBEARBEITER_BEZIRK',
        },
      })
      return kontakt.id
    })
    await anmelden(page)
    // Irgendeinen Vorgang der eigenen Akte öffnen.
    const vorgangId = await mitDb(async (db) => {
      const vorgang = await db.vorgang.findFirst({
        where: { geloeschtAm: null, betreute: { vorname: 'Erika' } },
        select: { id: true },
      })
      return vorgang?.id ?? ''
    })
    test.skip(vorgangId === '', 'Kein Vorgang in der eigenen Akte.')
    await page.goto(`/vorgaenge/${vorgangId}`)
    const auswahl = page.locator('select[name="ansprechpartnerId"]')
    await auswahl.waitFor()
    // Dem echten Auswahlfeld die fremde Id unterschieben und ganz normal
    // abschicken — so, wie es ein verändertes Formular täte.
    await auswahl.evaluate((feld, id) => {
      const eintrag = document.createElement('option')
      eintrag.value = id
      eintrag.textContent = 'untergeschoben'
      ;(feld as HTMLSelectElement).append(eintrag)
      ;(feld as HTMLSelectElement).value = id
    }, fremderKontakt)
    await page.getByRole('button', { name: 'Speichern' }).click()
    // Der Server lehnt ab, mit einer Meldung, die den Grund nennt.
    // Grosszuegige Frist: Im Entwicklungsmodus wird die Server Action beim
    // ersten Aufruf uebersetzt, und das dauert laenger als die Vorgabe.
    await expect(page.getByText(/gehört nicht zu dieser betreuten Person/).first()).toBeVisible({
      timeout: 45_000,
    })
    // Und vor allem: Die Verknüpfung ist nicht entstanden.
    const verknuepft = await mitDb((db) =>
      db.vorgang.count({ where: { ansprechpartnerId: fremderKontakt } }),
    )
    expect(verknuepft).toBe(0)
  })
  test('die Auswahlliste zeigt den fremden Kontakt gar nicht erst', async ({ page }) => {
    await anmelden(page)
    await page.goto('/vorgaenge')
    const inhalt = await page.locator('body').innerText()
    expect(inhalt).not.toContain('Fremder Sachbearbeiter')
  })
 })
@@ -117,3 +117,46 @@ export function beispielPdf(text = 'Bescheid'): Buffer {
  return Buffer.from(pdf, 'latin1')
 }
 /**
 * Doppelt gerenderte Listen — was beim Suchen schiefgeht.
 *
 * Die Dokumentenliste (und moeglicherweise kuenftig weitere) rendert
 * denselben Inhalt ZWEIMAL: als Karten fuers Handy, als Tabelle ab
 * Tablet. Eine der beiden Fassungen ist per Breakpoint versteckt, steht
 * aber im DOM.
 *
 * Die Folge im Test:
 *
 *   await expect(page.getByText('Bescheid').first()).toBeVisible()
 *   // -> "element is not visible", obwohl die Seite richtig aussieht
 *
 * `.first()` nimmt, was zuerst im Baum steht - und das ist die Karte,
 * also am Schreibtisch die unsichtbare Fassung. Es liegt NICHT an der
 * Anwendung.
 *
 * Nachgemessen an /dokumente mit acht Dokumenten: Ein Titel liefert 16
 * Treffer, davon 8 sichtbar - und `.first()` ist unsichtbar.
 *
 * Drei Wege, die tragen:
 *
 *   1. Ueber den Seitentext pruefen, wenn es nur um "steht das da?" geht:
 *
 *        const inhalt = await page.locator('body').innerText()
 *        expect(inhalt).toContain('Bescheid')
 *
 *      innerText liefert nur sichtbaren Text - die versteckte Fassung
 *      faellt von selbst weg. (Fuer Inhalt in einem zugeklappten
 *      <details> braucht es dagegen textContent.)
 *
 *   2. Auf die sichtbare Fassung einschraenken, wenn geklickt wird:
 *
 *        page.getByRole('link', { name: 'Bescheid' }).locator('visible=true')
 *
 *   3. Die Zusammenfassungszeile pruefen ("12 Dokumente"), wenn es um
 *      Anzahlen geht - die steht nur einmal.
 *
 * Was nicht traegt: eine feste Anzahl erwarten. `getByText(...)` findet
 * jeden Eintrag zweimal, und wer das mit toHaveCount(1) prueft, schreibt
 * einen Test, der bei jeder Layoutaenderung umfaellt.
 */
@@ -1,6 +1,6 @@
 {
  "name": "betreuungs-cockpit",
-  "version": "1.9.0",
+  "version": "1.10.2",
  "private": true,
  "description": "Arbeits- und Dokumentationswerkzeug fuer die ehrenamtliche rechtliche Betreuung",
  "engines": {
@@ -17,6 +17,8 @@
    "db:generate": "prisma generate",
    "db:migrate": "prisma migrate dev",
    "db:deploy": "prisma migrate deploy",
    "db:migration": "node scripts/migration-erzeugen.mjs",
    "db:pruefen": "node -e \"import('./scripts/migration-erzeugen.mjs').then(m => m.indizesPruefen())\"",
    "db:volltext": "prisma db execute --schema prisma/schema.prisma --file prisma/sql/volltextsuche.sql",
    "db:seed": "prisma db seed",
    "db:studio": "prisma studio",
@@ -2,10 +2,11 @@
 --
 -- ACHTUNG beim Erzeugen weiterer Migrationen: "prisma migrate diff" wollte
 -- hier zusaetzlich die Trigramm-Indizes "dokument_absender_trgm" und
-- "vorgang_titel_trgm" loeschen. Die stammen aus prisma/sql/suche.sql und
+-- "vorgang_titel_trgm" loeschen. Die stammen aus prisma/sql/volltextsuche.sql und
 -- sind Prisma unbekannt - ein DROP haette die unscharfe Suche stillgelegt,
 -- ohne dass irgendetwas fehlgeschlagen waere. Solche Zeilen gehoeren aus
 -- jeder erzeugten Migration entfernt.
 -- Kuenftig nimmt "npm run db:migration" diese Zeilen selbst heraus.
 -- CreateEnum
 CREATE TYPE "PasskeyAnfrageArt" AS ENUM ('REGISTRIERUNG', 'ANMELDUNG');
@@ -2,10 +2,11 @@
 --
 -- ACHTUNG, zum zweiten Mal in diesem Projekt: "prisma migrate diff" wollte
 -- hier wieder die Trigramm-Indizes "dokument_absender_trgm" und
-- "vorgang_titel_trgm" loeschen. Die stammen aus prisma/sql/suche.sql und
+-- "vorgang_titel_trgm" loeschen. Die stammen aus prisma/sql/volltextsuche.sql und
 -- sind Prisma unbekannt; ein DROP haette die unscharfe Suche stillgelegt,
 -- ohne dass irgendetwas fehlgeschlagen waere. Die Zeilen sind entfernt.
 -- Wer die naechste Migration erzeugt: nachsehen und wieder herausnehmen.
 -- Kuenftig nimmt "npm run db:migration" diese Zeilen selbst heraus.
 -- CreateTable
 CREATE TABLE "zahlungsgruppe_geklaert" (
@@ -2,10 +2,11 @@
 --
 -- ACHTUNG, zum dritten Mal: "prisma migrate diff" wollte wieder die
 -- Trigramm-Indizes "dokument_absender_trgm" und "vorgang_titel_trgm"
-- loeschen. Sie stammen aus prisma/sql/suche.sql und sind Prisma
+-- loeschen. Sie stammen aus prisma/sql/volltextsuche.sql und sind Prisma
 -- unbekannt; ein DROP legt die unscharfe Suche stumm, ohne dass etwas
 -- fehlschlaegt. Zeilen entfernt. Wer die naechste Migration erzeugt:
 -- nachsehen.
 -- Kuenftig nimmt "npm run db:migration" diese Zeilen selbst heraus.
 -- AlterTable
 ALTER TABLE "buchung" ADD COLUMN     "vertragAutomatisch" BOOLEAN NOT NULL DEFAULT false,
@@ -1,8 +1,9 @@
 -- Eigene Schreibvorlagen.
 --
 -- ACHTUNG, zum vierten Mal: "prisma migrate diff" wollte wieder die
-- Trigramm-Indizes aus prisma/sql/suche.sql loeschen. Zeilen entfernt.
+-- Trigramm-Indizes aus prisma/sql/volltextsuche.sql loeschen. Zeilen entfernt.
 -- Wer die naechste Migration erzeugt: nachsehen.
 -- Kuenftig nimmt "npm run db:migration" diese Zeilen selbst heraus.
 -- CreateTable
 CREATE TABLE "schreibvorlage" (
@@ -1,8 +1,9 @@
 -- Ansprechpartner am Vorgang, Anrede am Kontakt.
 --
 -- ACHTUNG, zum fuenften Mal: "prisma migrate diff" wollte wieder die
-- Trigramm-Indizes aus prisma/sql/suche.sql loeschen. Zeilen entfernt.
+-- Trigramm-Indizes aus prisma/sql/volltextsuche.sql loeschen. Zeilen entfernt.
 -- Wer die naechste Migration erzeugt: nachsehen.
 -- Kuenftig nimmt "npm run db:migration" diese Zeilen selbst heraus.
 -- CreateEnum
 CREATE TYPE "KontaktAnrede" AS ENUM ('OHNE', 'FRAU', 'HERR');
@@ -0,0 +1,14 @@
 -- betreuer_anschrift
 --
 -- Erzeugt mit "npm run db:migration". Entfernt wurden die
 -- DROP-INDEX-Anweisungen zu diesen Indizes:
 --   dokument_absender_trgm
 --   vorgang_titel_trgm
 --
 -- Sie stammen aus prisma/sql/volltextsuche.sql und sind Prisma unbekannt;
 -- ohne sie waere die Volltextsuche still langsam geworden.
 -- AlterTable
 ALTER TABLE "benutzer" ADD COLUMN     "ort" TEXT,
 ADD COLUMN     "plz" TEXT,
 ADD COLUMN     "strasse" TEXT;
@@ -81,6 +81,13 @@ model User {
  // (Passwortwechsel, Rollenaenderung, Verdacht auf Kompromittierung).
  sitzungsGeneration Int @default(0)
  /// Die eigene Anschrift - Absenderblock und Ort in der Datumszeile
  /// jedes erzeugten Schreibens. Sie gehoert zum Betreuer und nicht zur
  /// betreuten Person: Sie gilt fuer alle Akten.
  strasse String?
  plz     String?
  ort     String?
  // Oberflaechen-Einstellungen
  theme String @default("system") // "system" | "hell" | "dunkel"
@@ -22,7 +22,7 @@
 *
 * Der Seed ist idempotent: mehrfaches Ausfuehren aendert nichts.
 */
-import { PrismaClient } from '@prisma/client'
+import { PrismaClient, type BuchungKategorie, type Prisma } from '@prisma/client'
 import { hash } from '@node-rs/argon2'
 import { createCipheriv, randomBytes } from 'node:crypto'
@@ -263,9 +263,11 @@ async function demofall(userId: string) {
      art: 'GIRO',
      ibanVerschluesselt: verschluesseln('DE02773501100123456789', 'ibanVerschluesselt'),
      saldostaende: {
        // Nur der Anfangsstand. Der spaetere wird weiter unten aus den
        // Buchungen gerechnet - ein Demofall, der sich selbst
        // widerspricht, waere schlimmer als einer ohne Buchungen.
        create: [
          { stichtag: datum('2026-02-14'), betragCent: cent(4218.36), quelle: 'Kontoauszug 02/2026' },
          { stichtag: datum('2026-07-31'), betragCent: cent(2967.11), quelle: 'Kontoauszug 07/2026' },
        ],
      },
    },
@@ -523,6 +525,309 @@ async function demofall(userId: string) {
    })
  }
  // --- Kontobewegungen ----------------------------------------------------
  // Zwoelf Monate auf dem Girokonto. Erzeugt aus einem Muster und nicht
  // einzeln abgetippt: So bleibt der Fall aenderbar, und die Betraege
  // widersprechen sich nicht.
  //
  // Die Gegenstellen sind absichtlich uneinheitlich geschrieben. Genau
  // damit muss die Zusammenfassung wiederkehrender Zahlungen umgehen - auf
  // einem Kontoauszug steht dieselbe Stelle auch mal in Grossbuchstaben.
  type Buchungsvorlage = {
    tag: number
    betrag: number
    richtung: 'EINNAHME' | 'AUSGABE'
    kategorie: BuchungKategorie
    gegenstellen: string[]
    zweck: string
  }
  const MONATLICH: Buchungsvorlage[] = [
    {
      tag: 1,
      betrag: 1284.17,
      richtung: 'EINNAHME',
      kategorie: 'RENTE',
      gegenstellen: [
        'Deutsche Rentenversicherung Bund',
        'DRV BUND',
        'Deutsche Rentenversich. Bund',
      ],
      zweck: 'Altersrente',
    },
    {
      tag: 1,
      betrag: 96.4,
      richtung: 'EINNAHME',
      kategorie: 'RENTE',
      gegenstellen: ['Zusatzversorgungskasse Bayern', 'ZVK Bayern'],
      zweck: 'Betriebsrente',
    },
    {
      tag: 3,
      betrag: 1262,
      richtung: 'EINNAHME',
      kategorie: 'PFLEGEKASSE',
      gegenstellen: ['Pflegekasse bei der AOK Bayern', 'AOK Bayern - Pflegekasse'],
      zweck: 'Leistung vollstationaere Pflege, Pflegegrad 3',
    },
    {
      tag: 5,
      betrag: 2489,
      richtung: 'AUSGABE',
      kategorie: 'HEIMKOSTEN',
      gegenstellen: [
        'Seniorenzentrum St. Katharina',
        'SENIORENZENTRUM ST KATHARINA',
        'Seniorenzentrum St. Katharina gGmbH',
      ],
      zweck: 'Heimentgelt',
    },
    {
      tag: 5,
      betrag: 135,
      richtung: 'AUSGABE',
      kategorie: 'BARBETRAG',
      // Eigene Gegenstelle, nicht das Heim: Sonst faellt der Barbetrag
      // mit dem Heimentgelt in eine Gruppe, und aus zwei sauberen
      // monatlichen Zahlungen wird eine "schwankende".
      gegenstellen: ['Barauszahlung Verwahrgeldkonto'],
      zweck: 'Barbetrag zur persoenlichen Verfuegung',
    },
    {
      tag: 15,
      betrag: 18.4,
      richtung: 'AUSGABE',
      kategorie: 'VERSICHERUNG',
      gegenstellen: ['Nordheim Sterbekasse VVaG', 'NORDHEIM STERBEKASSE', 'Nordheim Sterbekasse'],
      zweck: 'Beitrag Sterbegeldversicherung SG-220417',
    },
    {
      tag: 20,
      betrag: 24.9,
      richtung: 'AUSGABE',
      kategorie: 'TELEFON_INTERNET',
      gegenstellen: ['TeleCare Kommunikation GmbH', 'TELECARE KOMMUNIKATION'],
      zweck: 'Telefon und Fernsehen im Zimmer',
    },
    {
      tag: 28,
      betrag: 4.9,
      richtung: 'AUSGABE',
      kategorie: 'BANKGEBUEHREN',
      gegenstellen: ['Sparkasse Bayreuth'],
      zweck: 'Kontofuehrung',
    },
  ]
  /** Zwoelf Monate bis einschliesslich Juli 2026. */
  const MONATE = [
    '2025-08',
    '2025-09',
    '2025-10',
    '2025-11',
    '2025-12',
    '2026-01',
    '2026-02',
    '2026-03',
    '2026-04',
    '2026-05',
    '2026-06',
    '2026-07',
  ]
  const buchungen: Prisma.BuchungCreateManyInput[] = []
  MONATE.forEach((monat, lauf) => {
    MONATLICH.forEach((vorlage, stelle) => {
      // Die Sterbegeld-Lastschrift steigt im Mai 2026. Daran wird die
      // Pruefung beim Zuordnen einer Dauerzahlung sichtbar: Der Betrag
      // weicht vom hinterlegten Beitrag ab.
      const betrag =
        vorlage.kategorie === 'VERSICHERUNG' && monat >= '2026-05' ? 19.8 : vorlage.betrag
      buchungen.push({
        betreuteId: betreute.id,
        kontoId: giro.id,
        datum: datum(`${monat}-${String(vorlage.tag).padStart(2, '0')}`),
        betragCent: cent(betrag),
        richtung: vorlage.richtung,
        kategorie: vorlage.kategorie,
        gegenstelle: vorlage.gegenstellen[lauf % vorlage.gegenstellen.length],
        verwendungszweckVerschluesselt: verschluesseln(
          vorlage.zweck,
          'verwendungszweckVerschluesselt',
        ),
        // Wiederkehrende Zahlungen brauchen keinen Einzelbeleg - der
        // Bescheid bzw. der Vertrag dahinter ist der Nachweis.
        belegFehltBegruendung:
          vorlage.richtung === 'EINNAHME'
            ? 'Laufender Bezug, Nachweis ist der Bescheid.'
            : 'Wiederkehrende Zahlung aus laufendem Vertrag.',
        // Die Stelle in der Vorlagenliste gehoert in die Referenz: Zwei
        // Renten am Monatsersten haetten sonst dieselbe, und der
        // Unique-Index gegen Doppelbuchungen schlaegt zu Recht zu.
        importReferenz: `demo-${monat}-${stelle}-${vorlage.kategorie}`,
      })
    })
  })
  // Vierteljaehrliches und Einmaliges - damit nicht alles im Monatsraster
  // liegt und die Belegpflicht etwas zu zeigen hat.
  const EINZELN: {
    datum: string
    betrag: number
    richtung: 'EINNAHME' | 'AUSGABE'
    kategorie: BuchungKategorie
    gegenstelle: string
    zweck: string
    begruendung?: string
  }[] = [
    {
      datum: '2025-08-15',
      betrag: 55.08,
      richtung: 'AUSGABE',
      kategorie: 'RUNDFUNKBEITRAG',
      gegenstelle: 'ARD ZDF Deutschlandradio Beitragsservice',
      zweck: 'Rundfunkbeitrag 3. Quartal 2025',
      begruendung: 'Wiederkehrende Zahlung, Beitragsbescheid liegt vor.',
    },
    {
      datum: '2025-11-15',
      betrag: 55.08,
      richtung: 'AUSGABE',
      kategorie: 'RUNDFUNKBEITRAG',
      gegenstelle: 'ARD ZDF Deutschlandradio Beitragsservice',
      zweck: 'Rundfunkbeitrag 4. Quartal 2025',
      begruendung: 'Wiederkehrende Zahlung, Beitragsbescheid liegt vor.',
    },
    {
      datum: '2026-02-15',
      betrag: 55.08,
      richtung: 'AUSGABE',
      kategorie: 'RUNDFUNKBEITRAG',
      gegenstelle: 'ARD ZDF Deutschlandradio Beitragsservice',
      zweck: 'Rundfunkbeitrag 1. Quartal 2026',
      begruendung: 'Wiederkehrende Zahlung, Beitragsbescheid liegt vor.',
    },
    {
      datum: '2026-05-15',
      betrag: 55.08,
      richtung: 'AUSGABE',
      kategorie: 'RUNDFUNKBEITRAG',
      gegenstelle: 'ARD ZDF Deutschlandradio Beitragsservice',
      zweck: 'Rundfunkbeitrag 2. Quartal 2026',
      begruendung: 'Wiederkehrende Zahlung, Beitragsbescheid liegt vor.',
    },
    {
      datum: '2026-02-16',
      betrag: 187.5,
      richtung: 'AUSGABE',
      kategorie: 'GRUNDSTEUER',
      gegenstelle: 'Gemeinde Bindlach',
      zweck: 'Grundsteuer B, 1. Rate 2026',
      begruendung: 'Bescheid der Gemeinde liegt in der Akte.',
    },
    {
      datum: '2026-05-16',
      betrag: 187.5,
      richtung: 'AUSGABE',
      kategorie: 'GRUNDSTEUER',
      gegenstelle: 'Gemeinde Bindlach',
      zweck: 'Grundsteuer B, 2. Rate 2026',
      begruendung: 'Bescheid der Gemeinde liegt in der Akte.',
    },
    {
      datum: '2026-01-19',
      betrag: 240,
      richtung: 'AUSGABE',
      kategorie: 'IMMOBILIE_BETRIEBSKOSTEN',
      gegenstelle: 'Stadtwerke Bayreuth',
      zweck: 'Abschlag Strom und Wasser, Haus Bindlach',
      begruendung: 'Jahresabrechnung steht noch aus.',
    },
    {
      datum: '2026-03-11',
      betrag: 10,
      richtung: 'AUSGABE',
      kategorie: 'ZUZAHLUNG',
      gegenstelle: 'Apotheke am Markt',
      zweck: 'Zuzahlung Rezept',
      begruendung: 'Quittung liegt in der Akte.',
    },
    // Der Fall fuer die Belegpflicht: keine Quittung und keine Begruendung.
    // Genau so sieht eine Buchung aus, die noch Arbeit macht.
    {
      datum: '2026-04-08',
      betrag: 89.95,
      richtung: 'AUSGABE',
      kategorie: 'BEKLEIDUNG',
      gegenstelle: 'Modehaus Lindner',
      zweck: 'Winterjacke und zwei Nachthemden',
    },
    {
      datum: '2026-06-17',
      betrag: 23,
      richtung: 'AUSGABE',
      kategorie: 'SONSTIGE_AUSGABE',
      gegenstelle: 'Friseur im Haus',
      zweck: 'Friseur',
      begruendung: 'Bar aus dem Barbetrag bezahlt, keine Quittung ausgestellt.',
    },
    {
      datum: '2026-07-02',
      betrag: 62.4,
      richtung: 'EINNAHME',
      kategorie: 'ZINSEN',
      gegenstelle: 'Sparkasse Bayreuth',
      zweck: 'Zinsgutschrift',
      begruendung: 'Der Kontoauszug ist der Nachweis.',
    },
  ]
  for (const eintrag of EINZELN) {
    buchungen.push({
      betreuteId: betreute.id,
      kontoId: giro.id,
      datum: datum(eintrag.datum),
      betragCent: cent(eintrag.betrag),
      richtung: eintrag.richtung,
      kategorie: eintrag.kategorie,
      gegenstelle: eintrag.gegenstelle,
      verwendungszweckVerschluesselt: verschluesseln(
        eintrag.zweck,
        'verwendungszweckVerschluesselt',
      ),
      belegFehltBegruendung: eintrag.begruendung ?? null,
      importReferenz: `demo-${eintrag.datum}-${eintrag.kategorie}`,
    })
  }
  await db.buchung.createMany({ data: buchungen })
  // Der Kontostand zum 31.07.2026 wird gerechnet, nicht behauptet: Anfangs-
  // stand plus alles, was seither ueber das Konto gelaufen ist. Sonst
  // widerspraeche der Demofall sich selbst, sobald jemand nachrechnet.
  const bewegungCent = buchungen
    .filter((eintrag) => {
      const tag = eintrag.datum as Date
      return tag > datum('2026-02-14') && tag <= datum('2026-07-31')
    })
    .reduce((summe, eintrag) => {
      const betrag = eintrag.betragCent as bigint
      return eintrag.richtung === 'EINNAHME' ? summe + betrag : summe - betrag
    }, 0n)
  await db.saldostand.create({
    data: {
      kontoId: giro.id,
      stichtag: datum('2026-07-31'),
      betragCent: cent(4218.36) + bewegungCent,
      quelle: 'Kontoauszug 07/2026',
    },
  })
  console.log('Demofall "Erika Musterfrau" angelegt.')
 }
@@ -0,0 +1,32 @@
 /**
 * Typen fuer das Werkzeugskript.
 *
 * Das Skript selbst bleibt .mjs - es laeuft ohne Bauschritt, auch auf
 * einem Rechner, auf dem nur Node steht. Die Typen daneben sorgen dafuer,
 * dass die Tests trotzdem geprueft werden und nicht stillschweigend
 * gegen "any" laufen.
 */
 export type GeschuetzterIndex = {
  name: string
  quelle: string
 }
 export declare const GESCHUETZTE_INDIZES: GeschuetzterIndex[]
 export declare function dropZeilenEntfernen(
  sql: string,
  geschuetzt?: GeschuetzterIndex[],
 ): { sql: string; entfernt: string[] }
 export declare function hatAnweisungen(sql: string): boolean
 export declare function kopfBauen(
  name: string,
  entfernt: string[],
  geschuetzt?: GeschuetzterIndex[],
 ): string
 export declare function ordnernameBauen(name: string, jetzt?: Date): string
 export declare function indizesPruefen(): void
@@ -0,0 +1,296 @@
 #!/usr/bin/env node
 /**
 * Eine Migration erzeugen, ohne die Volltextsuche kaputtzumachen.
 *
 *   npm run db:migration -- ansprechpartner
 *   npm run db:migration -- ansprechpartner --anwenden
 *
 * Das Problem, das dieses Skript loest: "prisma migrate diff" kennt nur
 * das, was im Prisma-Schema steht. Die Trigramm-Indizes der Suche stehen
 * aber in prisma/sql/volltextsuche.sql und sind Prisma unbekannt - also
 * haelt es sie fuer ueberfluessig und schreibt in JEDE erzeugte Migration:
 *
 *   DROP INDEX "dokument_absender_trgm";
 *   DROP INDEX "vorgang_titel_trgm";
 *
 * Fuenfmal ist das passiert, fuenfmal mussten die Zeilen von Hand raus.
 * Auf dem Server waere es nicht aufgefallen, weil update.sh die Indizes
 * hinterher ohnehin neu anlegt - in der Entwicklung dagegen waere die
 * Suche still langsam geworden, ohne dass etwas fehlschlaegt.
 *
 * Was das Skript macht:
 *   1. Migration mit "migrate diff" erzeugen.
 *   2. DROP-Zeilen zu geschuetzten Indizes entfernen und im Kopf
 *      vermerken, welche das waren.
 *   3. Auf Wunsch (--anwenden) "migrate deploy" laufen lassen und danach
 *      pruefen, dass die geschuetzten Indizes wirklich noch stehen.
 *
 * Nicht automatisch angewendet wird die Migration ohne --anwenden: Erst
 * liest man, was da erzeugt wurde.
 */
 import { execFileSync } from 'node:child_process'
 import { mkdirSync, rmSync, writeFileSync } from 'node:fs'
 import { tmpdir } from 'node:os'
 import { dirname, join } from 'node:path'
 import { fileURLToPath } from 'node:url'
 const WURZEL = join(dirname(fileURLToPath(import.meta.url)), '..')
 /**
 * Indizes, die es nur in prisma/sql/ gibt und die Prisma deshalb nicht
 * kennt. Wer dort einen hinzufuegt, traegt ihn hier ein - sonst faellt er
 * der naechsten Migration zum Opfer.
 */
 export const GESCHUETZTE_INDIZES = [
  { name: 'dokument_absender_trgm', quelle: 'prisma/sql/volltextsuche.sql' },
  { name: 'vorgang_titel_trgm', quelle: 'prisma/sql/volltextsuche.sql' },
 ]
 /**
 * Entfernt DROP-INDEX-Anweisungen zu geschuetzten Indizes.
 *
 * Bewusst eng gefasst: Nur eine Anweisung, die genau einen geschuetzten
 * Index nennt, faellt weg. Ein DROP INDEX auf einen Prisma-eigenen Index
 * bleibt stehen - der soll ja weg. Der Kommentar "-- DropIndex", den
 * Prisma darueber setzt, wird mitgenommen, damit keine verwaisten
 * Ueberschriften zurueckbleiben.
 *
 * @param {string} sql
 * @param {{name: string}[]} geschuetzt
 * @returns {{sql: string, entfernt: string[]}}
 */
 export function dropZeilenEntfernen(sql, geschuetzt = GESCHUETZTE_INDIZES) {
  const namen = geschuetzt.map((eintrag) => eintrag.name)
  const zeilen = sql.split('\n')
  const behalten = []
  const entfernt = []
  for (let i = 0; i < zeilen.length; i++) {
    const zeile = zeilen[i]
    const treffer = namen.find(
      (name) => /^\s*DROP\s+INDEX\b/i.test(zeile) && zeile.includes(name),
    )
    if (!treffer) {
      behalten.push(zeile)
      continue
    }
    entfernt.push(treffer)
    // Die "-- DropIndex"-Ueberschrift darueber mitnehmen, samt der
    // Leerzeile davor - sonst bleiben Luecken im Text stehen.
    while (behalten.length > 0 && /^\s*--\s*DropIndex\s*$/i.test(behalten[behalten.length - 1])) {
      behalten.pop()
      while (behalten.length > 0 && behalten[behalten.length - 1].trim() === '') behalten.pop()
    }
    // Leerzeilen, die der entfernten Anweisung folgen, ebenfalls.
    while (i + 1 < zeilen.length && zeilen[i + 1].trim() === '') i++
  }
  return { sql: behalten.join('\n').replace(/\n{3,}/g, '\n\n').trimStart(), entfernt }
 }
 /**
 * Steht in dem SQL ueberhaupt noch eine Anweisung?
 *
 * Wichtig fuer den Normalfall: Wenn Schema und Datenbank uebereinstimmen,
 * besteht der ganze Diff aus den beiden bekannten DROP-INDEX-Zeilen. Nach
 * dem Entfernen bleibt nichts uebrig - und eine leere Migration anzulegen
 * waere schlimmer als gar keine, weil sie als angewendet in der Historie
 * steht und niemand mehr weiss, wofuer sie gut war.
 *
 * @param {string} sql
 * @returns {boolean}
 */
 export function hatAnweisungen(sql) {
  return sql
    .split('\n')
    .some((zeile) => zeile.trim() !== '' && !zeile.trim().startsWith('--'))
 }
 /** Der Kopfkommentar der erzeugten Datei. */
 export function kopfBauen(name, entfernt, geschuetzt = GESCHUETZTE_INDIZES) {
  const zeilen = [`-- ${name}`, '--']
  if (entfernt.length === 0) {
    zeilen.push('-- Erzeugt mit "npm run db:migration". Nichts zu entfernen.')
  } else {
    const quellen = [
      ...new Set(
        entfernt.map(
          (eintrag) => geschuetzt.find((g) => g.name === eintrag)?.quelle ?? 'prisma/sql/',
        ),
      ),
    ]
    zeilen.push(
      '-- Erzeugt mit "npm run db:migration". Entfernt wurden die',
      '-- DROP-INDEX-Anweisungen zu diesen Indizes:',
      ...entfernt.map((eintrag) => `--   ${eintrag}`),
      '--',
      `-- Sie stammen aus ${quellen.join(', ')} und sind Prisma unbekannt;`,
      '-- ohne sie waere die Volltextsuche still langsam geworden.',
    )
  }
  zeilen.push('')
  return zeilen.join('\n')
 }
 /** Zeitstempel im Prisma-Format, aus der lokalen Uhr. */
 export function ordnernameBauen(name, jetzt = new Date()) {
  const zwei = (zahl) => String(zahl).padStart(2, '0')
  const stempel = [
    jetzt.getFullYear(),
    zwei(jetzt.getMonth() + 1),
    zwei(jetzt.getDate()),
    zwei(jetzt.getHours()),
    zwei(jetzt.getMinutes()),
    zwei(jetzt.getSeconds()),
  ].join('')
  return `${stempel}_${name}`
 }
 // --- Ab hier: Ausfuehrung ----------------------------------------------------
 /**
 * Prisma direkt ueber sein Eintrittsskript aufrufen, nicht ueber npx.
 *
 * Mit "shell: true" wuerde Node warnen (Argumente werden dann nur
 * aneinandergehaengt statt maskiert), und ohne Shell findet Windows das
 * npx-Skript nicht. Der Weg ueber node loest beides und ist derselbe,
 * den scripts/update.sh schon nimmt.
 */
 function prisma(argumente, optionen = {}) {
  const eintritt = join(WURZEL, 'node_modules', 'prisma', 'build', 'index.js')
  return execFileSync(process.execPath, [eintritt, ...argumente], {
    cwd: WURZEL,
    encoding: 'utf8',
    ...optionen,
  })
 }
 function abbruch(meldung) {
  console.error(`\n  Abbruch: ${meldung}\n`)
  process.exit(1)
 }
 function hauptlauf() {
  const argumente = process.argv.slice(2)
  const anwenden = argumente.includes('--anwenden')
  const name = argumente.find((eintrag) => !eintrag.startsWith('--'))
  if (!name) {
    abbruch(
      'Bitte einen Namen angeben:  npm run db:migration -- <name> [--anwenden]\n' +
        '           Beispiel:              npm run db:migration -- ansprechpartner',
    )
  }
  if (!/^[a-z0-9_]+$/.test(name)) {
    abbruch(`"${name}" taugt nicht als Ordnername. Erlaubt: a-z, 0-9 und _`)
  }
  console.log(`\n  Migration "${name}" erzeugen\n`)
  let roh
  try {
    roh = prisma([
      'migrate',
      'diff',
      '--from-schema-datasource',
      'prisma/schema.prisma',
      '--to-schema-datamodel',
      'prisma/schema.prisma',
      '--script',
    ])
  } catch (fehler) {
    abbruch(`"prisma migrate diff" ist fehlgeschlagen:\n${fehler.message}`)
  }
  if (roh.trim() === '' || /^--\s*This is an empty migration/im.test(roh)) {
    abbruch('Schema und Datenbank stimmen bereits ueberein - es gibt nichts zu migrieren.')
  }
  const { sql, entfernt } = dropZeilenEntfernen(roh)
  if (!hatAnweisungen(sql)) {
    const grund =
      entfernt.length > 0
        ? `Uebrig blieben nur die bekannten DROP-INDEX-Zeilen (${entfernt.join(', ')}).`
        : 'Der Vergleich hat keine Anweisungen ergeben.'
    abbruch(
      `Es gibt nichts zu migrieren. ${grund}\n` +
        '           Es wurde keine Migration angelegt.',
    )
  }
  const ordner = join(WURZEL, 'prisma', 'migrations', ordnernameBauen(name))
  mkdirSync(ordner, { recursive: true })
  const datei = join(ordner, 'migration.sql')
  writeFileSync(datei, `${kopfBauen(name, entfernt)}\n${sql.trimEnd()}\n`, 'utf8')
  console.log(`  Geschrieben: ${datei.replace(WURZEL, '.')}`)
  if (entfernt.length > 0) {
    console.log('\n  Entfernte DROP-INDEX-Anweisungen:')
    for (const eintrag of entfernt) console.log(`    - ${eintrag}`)
  } else {
    console.log('  Keine DROP-INDEX-Anweisung zu schuetzenden Indizes gefunden.')
  }
  if (!anwenden) {
    console.log('\n  Jetzt: die Datei lesen, dann anwenden mit')
    console.log('    npm run db:deploy && npm run db:pruefen\n')
    return
  }
  console.log('\n  Anwenden ...')
  try {
    prisma(['migrate', 'deploy'], { stdio: 'inherit' })
  } catch {
    abbruch('"prisma migrate deploy" ist fehlgeschlagen. Die Datei bleibt liegen.')
  }
  indizesPruefen()
 }
 /**
 * Stehen die geschuetzten Indizes noch?
 *
 * Der Sinn des ganzen Skripts haengt an dieser Pruefung: Sie ist der
 * Unterschied zwischen "sollte gutgegangen sein" und "nachgesehen".
 */
 export function indizesPruefen() {
  const bedingung = GESCHUETZTE_INDIZES.map((eintrag) => `'${eintrag.name}'`).join(', ')
  const sql = `DO $$
 BEGIN
  IF (SELECT count(*) FROM pg_indexes WHERE indexname IN (${bedingung})) <> ${GESCHUETZTE_INDIZES.length} THEN
    RAISE EXCEPTION 'Es fehlen geschuetzte Indizes';
  END IF;
 END $$;`
  // In den Temp-Ordner, nicht ins Repository: Die Datei ist Werkzeug,
  // kein Bestandteil des Projekts.
  const datei = join(tmpdir(), `indizes-pruefung-${process.pid}.sql`)
  writeFileSync(datei, sql, 'utf8')
  try {
    prisma(['db', 'execute', '--schema', 'prisma/schema.prisma', '--file', datei], {
      stdio: 'pipe',
    })
    console.log('\n  Geschuetzte Indizes stehen:')
    for (const eintrag of GESCHUETZTE_INDIZES) console.log(`    - ${eintrag.name}`)
    console.log('')
  } catch {
    abbruch(
      'Nach der Migration fehlen geschuetzte Indizes.\n' +
        '           Wiederherstellen mit:  npm run db:sql',
    )
  } finally {
    rmSync(datei, { force: true })
  }
 }
 if (process.argv[1] && process.argv[1].endsWith('migration-erzeugen.mjs')) {
  hauptlauf()
 }
@@ -75,9 +75,19 @@ done
 # --- Selbstpruefung ----------------------------------------------------------
 # Ein Backup, das sich nicht entschluesseln laesst, ist kein Backup.
 # Deshalb wird sofort geprueft, ob die Datei wieder lesbar ist.
-if openssl enc -d -aes-256-cbc -pbkdf2 -iter 200000 \
+# Kein "| head -c 5 | grep -q": Beide schliessen die Leitung, sobald sie
-     -pass env:SICHERUNG_PASSWORT -in "$DATEI" 2>/dev/null \
+# genug haben. openssl schreibt dann in ein geschlossenes Rohr, bekommt
-   | head -c 5 | grep -q "PGDMP"; then
+# SIGPIPE - und mit "set -o pipefail" gilt die ganze Kette als
 # gescheitert. Bei einer kleinen Datenbank faellt das nicht auf, weil
 # alles schon im Puffer steht; mit wachsender Datenbank kippt es, und
 # dann meldet die Selbstpruefung eine INTAKTE Sicherung als kaputt.
 #
 # "dd" liest eine feste Menge und beendet sich regulaer.
 KOPF="$(openssl enc -d -aes-256-cbc -pbkdf2 -iter 200000 \
          -pass env:SICHERUNG_PASSWORT -in "$DATEI" 2>/dev/null \
        | dd bs=1 count=5 2>/dev/null || true)"
 if [ "$KOPF" = "PGDMP" ]; then
  echo "$(date -Iseconds) Selbstpruefung bestanden."
 else
  echo "$(date -Iseconds) FEHLER: Die Sicherung laesst sich nicht entschluesseln!" >&2
@@ -52,6 +52,32 @@ gut()      { printf '    %s%s%s\n' "$GRUEN" "$1" "$AUS"; }
 warnung()  { printf '    %s%s%s\n' "$GELB" "$1" "$AUS"; }
 abbruch()  { printf '\n%sAbbruch: %s%s\n\n' "$ROT" "$1" "$AUS" >&2; exit 1; }
 # --- Unerwarteter Abbruch ----------------------------------------------------
 #
 # "set -e" beendet das Skript bei jedem Befehl, der nicht 0 zurueckgibt -
 # stumm. Auf dem Bildschirm bricht die Ausgabe dann einfach ab, und man
 # sucht an der falschen Stelle.
 #
 # Genau das ist beim Sprung von v1.5.0 auf v1.10.1 passiert: Eine Leitung
 # der Form "git log ... | head -15" hat den Erzeuger mit SIGPIPE beendet,
 # "pipefail" hat das an die Kette weitergereicht, und das Skript war weg.
 #
 # Diese Falle sagt jetzt wenigstens, WO es passiert ist. Exitcode 141
 # heisst SIGPIPE - dann wurde irgendwo wieder eine Leitung zu frueh
 # geschlossen.
 unerwartet() {
  code=$1
  zeile=$2
  printf '%sAbbruch in Zeile %s (Exitcode %s).%s\n' "$ROT" "$zeile" "$code" "$AUS" >&2
  if [ "$code" = "141" ]; then
    printf '%sExitcode 141 ist SIGPIPE: eine Leitung wurde zu frueh geschlossen,%s\n' "$ROT" "$AUS" >&2
    printf '%setwa durch "| head". Das ist ein Fehler im Skript, nicht bei dir.%s\n' "$ROT" "$AUS" >&2
  fi
  printf '%sKam der Abbruch vor Schritt 5, wurde nichts veraendert.%s\n' "$ROT" "$AUS" >&2
 }
 trap 'unerwartet $? $LINENO' ERR
 # --- Aufrufparameter ---------------------------------------------------------
 ZIEL=""
@@ -113,7 +139,11 @@ if ! git fetch --tags --quiet origin; then
 fi
 JETZT="$(git describe --tags --exact-match 2>/dev/null || git rev-parse --short HEAD)"
-NEUESTE="$(git tag --list 'v*' --sort=-v:refname | head -1)"
+# Kein "| head -1": Siehe den Hinweis zu SIGPIPE weiter unten. Die erste
 # Zeile holt die Shell selbst.
 ALLE_TAGS="$(git tag --list 'v*' --sort=-v:refname)"
 NEUESTE="${ALLE_TAGS%%$'
 '*}"
 [ -n "$NEUESTE" ] || abbruch "Es gibt keine veroeffentlichte Fassung (kein Tag)."
@@ -123,7 +153,8 @@ fi
 git rev-parse --verify --quiet "$ZIEL^{commit}" >/dev/null \
  || abbruch "Die Fassung '$ZIEL' gibt es nicht. Vorhanden:
-$(git tag --list 'v*' --sort=-v:refname | head -5 | sed 's/^/           /')"
+$(printf '%s
 ' "$ALLE_TAGS" | sed -n '1,5p' | sed 's/^/           /')"
 printf '    Jetzt:   %s\n' "$JETZT"
 printf '    Ziel:    %s%s%s\n' "$FETT" "$ZIEL" "$AUS"
@@ -152,14 +183,23 @@ if [ -n "$CHANGELOG" ]; then
      if (nummer == jetzt) exit
      drucken = (nummer != "Unveröffentlicht")
    }
-    drucken { print "    " $0 }
+    drucken && zeilen < 60 { print "    " $0; zeilen++ }
-  ' | head -60
+  '
 else
  warnung "Kein CHANGELOG.md in $ZIEL gefunden."
 fi
 printf '\n'
-git log --oneline --no-decorate "HEAD..$ZIEL" | head -15 | sed 's/^/    /'
+# "-15" statt "| head -15": Bei mehr Commits als der Grenze schliesst head
 # die Leitung, git bekommt SIGPIPE, und mit "set -o pipefail" gilt die ganze
 # Kette als gescheitert - "set -e" beendet das Skript dann OHNE Meldung.
 # Genau das ist beim Sprung von v1.5.0 auf v1.10.1 passiert.
 ANZAHL="$(git rev-list --count "HEAD..$ZIEL")"
 git log --oneline --no-decorate -15 "HEAD..$ZIEL" | sed 's/^/    /'
 if [ "$ANZAHL" -gt 15 ]; then
  printf '    ... und %s weitere
 ' "$((ANZAHL - 15))"
 fi
 if [ "$NUR_PRUEFEN" = "1" ]; then
  printf '\n'
@@ -0,0 +1,89 @@
 'use client'
 import { useActionState } from 'react'
 import { useFormStatus } from 'react-dom'
 import { AlertCircle, CheckCircle2, Loader2 } from 'lucide-react'
 import { anschriftSpeichern, type AnschriftZustand } from '@/server/actions/konto'
 import { Alert, AlertDescription } from '@/components/ui/alert'
 import { Button } from '@/components/ui/button'
 import { Input } from '@/components/ui/input'
 import { Feld } from '@/components/feld'
 function Absenden() {
  const { pending } = useFormStatus()
  return (
    <Button type="submit" disabled={pending}>
      {pending && <Loader2 className="animate-spin" aria-hidden="true" />}
      {pending ? 'Wird gespeichert …' : 'Anschrift speichern'}
    </Button>
  )
 }
 export function AnschriftFormular({
  strasse,
  plz,
  ort,
 }: {
  strasse: string | null
  plz: string | null
  ort: string | null
 }) {
  const [zustand, aktion] = useActionState<AnschriftZustand, FormData>(anschriftSpeichern, {})
  return (
    <form action={aktion} className="space-y-4" noValidate>
      {zustand.fehler && (
        <Alert variant="fehler">
          <AlertCircle aria-hidden="true" />
          <AlertDescription>{zustand.fehler}</AlertDescription>
        </Alert>
      )}
      {zustand.erfolg && (
        <Alert variant="erfolg">
          <CheckCircle2 aria-hidden="true" />
          <AlertDescription>{zustand.erfolg}</AlertDescription>
        </Alert>
      )}
      <Feld id="strasse" beschriftung="Straße und Hausnummer" fehler={zustand.felder?.strasse}>
        <Input
          id="strasse"
          name="strasse"
          defaultValue={strasse ?? ''}
          maxLength={150}
          autoComplete="street-address"
        />
      </Feld>
      <div className="grid gap-4 sm:grid-cols-[8rem_1fr]">
        <Feld id="plz" beschriftung="PLZ" fehler={zustand.felder?.plz}>
          <Input
            id="plz"
            name="plz"
            defaultValue={plz ?? ''}
            maxLength={10}
            autoComplete="postal-code"
            inputMode="numeric"
          />
        </Feld>
        <Feld
          id="ort"
          beschriftung="Ort"
          erklaerung="Steht außerdem in der Datumszeile: „Bayreuth, den 23.08.2026“."
          fehler={zustand.felder?.ort}
        >
          <Input
            id="ort"
            name="ort"
            defaultValue={ort ?? ''}
            maxLength={100}
            autoComplete="address-level2"
          />
        </Feld>
      </div>
      <Absenden />
    </form>
  )
 }
@@ -1,6 +1,6 @@
 import type { Metadata } from 'next'
 import Link from 'next/link'
-import { Fingerprint, KeyRound, ShieldCheck } from 'lucide-react'
+import { Fingerprint, KeyRound, MapPin, ShieldCheck } from 'lucide-react'
 import { Badge } from '@/components/ui/badge'
 import { Button } from '@/components/ui/button'
 import { Card, CardContent, CardDescription, CardHeader, CardTitle } from '@/components/ui/card'
@@ -11,6 +11,7 @@ import { PasskeyVerwaltung } from '@/components/konto/passkey-verwaltung'
 import { ROLLEN_BESCHRIFTUNG, ROLLEN_ERKLAERUNG } from '@/lib/auth/rollen'
 import { formatDatumZeit } from '@/lib/utils'
 import { PasswortFormular } from './passwort-formular'
 import { AnschriftFormular } from './anschrift-formular'
 export const metadata: Metadata = { title: 'Mein Konto' }
 export const dynamic = 'force-dynamic'
@@ -22,7 +23,10 @@ export default async function KontoSeite() {
  return (
    <div className="max-w-2xl space-y-6">
-      <SeitenKopf titel="Mein Konto" beschreibung="Zugangsdaten, zweiter Faktor und Passkeys." />
+      <SeitenKopf
        titel="Mein Konto"
        beschreibung="Zugangsdaten, eigene Anschrift, zweiter Faktor und Passkeys."
      />
      <Card>
        <CardHeader className="pb-3">
@@ -55,6 +59,27 @@ export default async function KontoSeite() {
        </CardContent>
      </Card>
      <Card>
        <CardHeader className="pb-3">
          <CardTitle className="flex items-center gap-2 text-base">
            <MapPin className="size-5" aria-hidden="true" />
            Meine Anschrift
          </CardTitle>
          <CardDescription>
            Steht im Absenderblock jedes Schreibens, das hier entsteht, und liefert den Ort für
            die Datumszeile. Ohne sie geht ein förmlicher Brief ohne Rücksendeadresse hinaus.
            Jede Angabe ist einzeln freiwillig — was fehlt, bleibt im Brief einfach weg.
          </CardDescription>
        </CardHeader>
        <CardContent>
          <AnschriftFormular
            strasse={benutzer.strasse}
            plz={benutzer.plz}
            ort={benutzer.ort}
          />
        </CardContent>
      </Card>
      <Card>
        <CardHeader className="pb-3">
          <CardTitle className="flex items-center gap-2 text-base">
@@ -50,7 +50,7 @@ export default async function SchreibenSeite({
  try {
    entwurf = await entwurfBauen({
      betreuteId: aktive.id,
-      benutzerName: benutzer.name,
+      benutzer,
      art,
      vertragId: text('vertragId') || null,
      vorgangId: text('vorgangId') || null,
@@ -17,6 +17,21 @@ import {
 *
 * Am Handy eine Karte je Dokument, ab Tablet eine Tabelle - die Tabelle
 * scrollt dabei im eigenen Rahmen, nie die ganze Seite.
 *
 * ACHTUNG, jeder Inhalt steht ZWEIMAL im DOM: einmal als Karte, einmal
 * als Tabellenzeile. Eine der beiden Fassungen ist per Breakpoint
 * versteckt, steht aber trotzdem im Baum.
 *
 * Fuer Tests heisst das: getByText(...).first() trifft womoeglich die
 * unsichtbare Kopie, und die Pruefung scheitert mit "element is not
 * visible" an einer Stelle, die augenscheinlich in Ordnung ist. Der Weg,
 * der traegt, steht in e2e/hilfen.ts unter "Doppelt gerenderte Listen".
 *
 * Warum nicht eine Fassung fuer beide? Eine Tabelle, die sich zu Karten
 * umbricht, verlangt display:block auf Zeilen und Zellen. Damit ist es
 * keine Tabelle mehr - Vorlesesoftware verliert den Zusammenhang von
 * Spaltenkopf und Wert, und genau der macht eine Dokumentenliste mit
 * acht Spalten erst benutzbar. Die Verdopplung ist der Preis dafuer.
 */
 export function DokumentListe({ eintraege }: { eintraege: Listeneintrag[] }) {
  return (
@@ -0,0 +1,121 @@
 import 'server-only'
 import { db, nichtGeloescht } from '@/lib/db'
 /**
 * Gehoert ein verknuepfter Datensatz zu dieser Akte?
 *
 * Wenn ein Formular einen Fremdschluessel mitschickt - Konto, Vertrag,
 * Immobilie, Dokument, Vorgang, Kontakt -, dann kommt der aus einer
 * Auswahlliste im Browser. Der Server darf sich darauf nicht verlassen:
 * Eine veraenderte Anfrage kann jede beliebige Id enthalten.
 *
 * Ohne die Pruefung entstuende eine Verknuepfung ueber Aktengrenzen
 * hinweg. Was daran gefaehrlich ist, sieht man erst an den Folgen: Der
 * Rueckkaufswert der einen Akte haengt am Vertrag der anderen, ein
 * fremder Name steht im Briefkopf, ein fremder Beschluss in der
 * Genehmigungskette.
 *
 * Solange nur eine betreute Person angelegt ist, ist all das folgenlos.
 * Die Pruefung gehoert trotzdem hin - sie kostet eine Abfrage, und die
 * zweite betreute Person kommt frueher, als man denkt.
 *
 * Bewusst KEINE Ausnahme geworfen: Formularaktionen geben Fehler zurueck,
 * damit die Eingaben des Benutzers nicht verlorengehen.
 */
 /** Die Tabellen, auf die ein Formular verweisen darf. */
 export type Verweisziel =
  | 'konto'
  | 'vertrag'
  | 'immobilie'
  | 'dokument'
  | 'vorgang'
  | 'kontakt'
  | 'vermoegensposten'
  | 'buchung'
 type Sucher = (id: string, betreuteId: string) => Promise<{ id: string } | null>
 /**
 * Je Ziel eine Abfrage, ausgeschrieben statt dynamisch zusammengesetzt.
 *
 * Das ist ein paar Zeilen laenger als ein Zugriff ueber den Tabellennamen -
 * dafuer ist die Liste der erlaubten Ziele eine bewusste Aufzaehlung und
 * keine Nebenwirkung, und der Typpruefer sieht jede Abfrage.
 */
 const SUCHER: Record<Verweisziel, Sucher> = {
  konto: (id, betreuteId) =>
    db.konto.findFirst({ where: { id, betreuteId, ...nichtGeloescht }, select: { id: true } }),
  vertrag: (id, betreuteId) =>
    db.vertrag.findFirst({ where: { id, betreuteId, ...nichtGeloescht }, select: { id: true } }),
  immobilie: (id, betreuteId) =>
    db.immobilie.findFirst({ where: { id, betreuteId, ...nichtGeloescht }, select: { id: true } }),
  dokument: (id, betreuteId) =>
    db.dokument.findFirst({ where: { id, betreuteId, ...nichtGeloescht }, select: { id: true } }),
  vorgang: (id, betreuteId) =>
    db.vorgang.findFirst({ where: { id, betreuteId, ...nichtGeloescht }, select: { id: true } }),
  kontakt: (id, betreuteId) =>
    db.kontakt.findFirst({ where: { id, betreuteId, ...nichtGeloescht }, select: { id: true } }),
  vermoegensposten: (id, betreuteId) =>
    db.vermoegensposten.findFirst({
      where: { id, betreuteId, ...nichtGeloescht },
      select: { id: true },
    }),
  buchung: (id, betreuteId) =>
    db.buchung.findFirst({ where: { id, betreuteId, ...nichtGeloescht }, select: { id: true } }),
 }
 const BESCHRIFTUNG: Record<Verweisziel, string> = {
  konto: 'Dieses Konto',
  vertrag: 'Dieser Vertrag',
  immobilie: 'Diese Immobilie',
  dokument: 'Dieses Dokument',
  vorgang: 'Dieser Vorgang',
  kontakt: 'Dieser Kontakt',
  vermoegensposten: 'Dieser Vermögensposten',
  buchung: 'Diese Buchung',
 }
 /**
 * Prueft einen einzelnen Verweis.
 *
 * Ein leerer Verweis ist in Ordnung - "keine Verknuepfung" ist ein
 * gueltiger Zustand und keine Verletzung.
 *
 * @returns null, wenn alles stimmt; sonst die fertige Fehlermeldung.
 */
 export async function verweisPruefen(
  ziel: Verweisziel,
  id: string | null | undefined,
  betreuteId: string,
 ): Promise<string | null> {
  if (!id) return null
  const treffer = await SUCHER[ziel](id, betreuteId)
  return treffer ? null : `${BESCHRIFTUNG[ziel]} gehört nicht zu dieser betreuten Person.`
 }
 /**
 * Prueft mehrere Verweise auf einmal und meldet den ersten Verstoss.
 *
 * Die Abfragen laufen nebeneinander: Bei vier Verweisen ist das eine
 * Wartezeit statt vier.
 *
 * @example
 *   const fehler = await verweisePruefen(betreuteId, {
 *     konto: werte.kontoId,
 *     vertrag: werte.vertragId,
 *   })
 *   if (fehler) return { fehler }
 */
 export async function verweisePruefen(
  betreuteId: string,
  verweise: Partial<Record<Verweisziel, string | null | undefined>>,
 ): Promise<string | null> {
  const eintraege = Object.entries(verweise) as [Verweisziel, string | null | undefined][]
  const ergebnisse = await Promise.all(
    eintraege.map(([ziel, id]) => verweisPruefen(ziel, id, betreuteId)),
  )
  return ergebnisse.find((meldung) => meldung !== null) ?? null
 }
@@ -122,6 +122,10 @@ export type Zahlungsgruppe = {
 const RECHTSFORMEN = [
  'gmbh & co kg',
  'gmbh und co kg',
  // Die haeufigste Rechtsform in diesem Fachgebiet ueberhaupt: Heime,
  // Sozialdienste und Traeger sind fast durchweg gGmbH. Fehlte sie,
  // zerfiele die Zusammenfassung genau dort, wo sie gebraucht wird.
  'ggmbh',
  'gmbh',
  'mbh',
  'ohg',
@@ -1,7 +1,7 @@
 import 'server-only'
 import { db, nichtGeloescht } from '@/lib/db'
 import { oeffnen } from '@/lib/crypto/feld'
-import { briefkopfBauen } from '@/lib/vertraege/briefkopf'
+import { briefkopfBauen, type Absender } from '@/lib/vertraege/briefkopf'
 import {
  absenderBlock,
  anschriftBlock,
@@ -107,7 +107,8 @@ export function betreffAusText(text: string): string {
 export type EntwurfEingabe = {
  betreuteId: string
-  benutzerName: string
+  /** Wer schreibt - mit Anschrift, wenn hinterlegt. */
  benutzer: Absender
  art: SchreibenArt
  vertragId?: string | null
  vorgangId?: string | null
@@ -127,7 +128,7 @@ export async function entwurfBauen(eingabe: EntwurfEingabe): Promise<SchreibenEn
  const kopf = briefkopfBauen({
    betreute: oeffnen('Betreute', betreute),
-    benutzer: { name: eingabe.benutzerName },
+    benutzer: eingabe.benutzer,
  })
  const gemeinsam = {
@@ -229,7 +230,7 @@ export async function entwurfBauen(eingabe: EntwurfEingabe): Promise<SchreibenEn
        geburtsdatum: betreute.geburtsdatum,
      },
      betreuer: {
-        name: eingabe.benutzerName,
+        name: eingabe.benutzer.name,
        aktenzeichenGericht: betreute.aktenzeichenGericht,
        betreuungsgericht: betreute.betreuungsgericht,
      },
@@ -278,6 +279,11 @@ export async function entwurfBauen(eingabe: EntwurfEingabe): Promise<SchreibenEn
        : null,
      betreute_anschrift: kopf.betreuteAnschrift,
      betreuer_name: kopf.betreuerName,
      betreuer_anschrift:
        [kopf.betreuerStrasse, [kopf.betreuerPlz, kopf.betreuerOrt].filter(Boolean).join(' ')]
          .filter((zeile) => zeile && zeile.trim() !== '')
          .join('\n') || null,
      betreuer_ort: kopf.betreuerOrt,
      betreuungsgericht: kopf.betreuungsgericht,
      aktenzeichen_gericht: kopf.aktenzeichenGericht,
      bestellung_datum: kopf.bestellungAm ? formatDatum(kopf.bestellungAm) : null,
@@ -21,6 +21,8 @@ export type PlatzhalterName =
  | 'betreute_geburtsdatum'
  | 'betreute_anschrift'
  | 'betreuer_name'
  | 'betreuer_anschrift'
  | 'betreuer_ort'
  | 'betreuungsgericht'
  | 'aktenzeichen_gericht'
  | 'bestellung_datum'
@@ -49,6 +51,12 @@ export const PLATZHALTER: readonly PlatzhalterBeschreibung[] = [
  { name: 'betreute_geburtsdatum', beschriftung: 'Geburtsdatum', quelle: 'Stammdaten' },
  { name: 'betreute_anschrift', beschriftung: 'Anschrift (Heim)', quelle: 'Stammdaten' },
  { name: 'betreuer_name', beschriftung: 'Dein Name', quelle: 'Dein Zugang' },
  {
    name: 'betreuer_anschrift',
    beschriftung: 'Deine Anschrift',
    quelle: 'Mein Konto',
  },
  { name: 'betreuer_ort', beschriftung: 'Dein Ort', quelle: 'Mein Konto' },
  { name: 'betreuungsgericht', beschriftung: 'Betreuungsgericht', quelle: 'Stammdaten' },
  { name: 'aktenzeichen_gericht', beschriftung: 'Aktenzeichen des Gerichts', quelle: 'Stammdaten' },
  { name: 'bestellung_datum', beschriftung: 'Datum der Bestellung', quelle: 'Stammdaten' },
@@ -17,7 +17,7 @@
 */
 /** Muss zur "version" in der package.json passen. */
-export const VERSION = '1.9.0'
+export const VERSION = '1.10.2'
 /**
 * Kurzer Git-Stand, beim Bauen hineingereicht:
@@ -3,11 +3,20 @@ import type { Briefkopf } from '@/lib/vertraege/anschreiben'
 /**
 * Baut den Briefkopf aus Stammdaten und angemeldetem Benutzer.
 *
- * Die Anschrift des Betreuers steht im Datenmodell nicht - der Benutzer
+ * Die Anschrift des Betreuers haengt am Benutzer, nicht an der betreuten
- * hat nur Name und E-Mail. Sie bleibt deshalb leer; im erzeugten Text
+ * Person: Sie gehoert zu mir und gilt fuer alle Akten. Ist sie nicht
- * fehlen dann schlicht die beiden Zeilen, und wer den Entwurf kopiert,
+ * hinterlegt, bleiben die Zeilen weg - ein Absenderblock mit leeren
- * ergaenzt sie im Briefkopf seines Textverarbeitungsprogramms ohnehin.
+ * Zeilen sieht schlimmer aus als einer, der nur aus dem Namen besteht.
 */
 /** Wer schreibt - Name und, wenn hinterlegt, die eigene Anschrift. */
 export type Absender = {
  name: string
  strasse?: string | null
  plz?: string | null
  ort?: string | null
 }
 export type BriefkopfQuelle = {
  betreute: {
    vorname: string
@@ -22,7 +31,7 @@ export type BriefkopfQuelle = {
    aktenzeichenGericht: string | null
    bestellungAm: Date | null
  }
-  benutzer: { name: string }
+  benutzer: Absender
 }
 export function briefkopfBauen(quelle: BriefkopfQuelle): Briefkopf {
@@ -37,11 +46,11 @@ export function briefkopfBauen(quelle: BriefkopfQuelle): Briefkopf {
  return {
    betreuerName: quelle.benutzer.name,
-    betreuerStrasse: null,
+    betreuerStrasse: quelle.benutzer.strasse ?? null,
-    betreuerPlz: null,
+    betreuerPlz: quelle.benutzer.plz ?? null,
-    // Der Ort in der Datumszeile ist der Ort des Betreuers, nicht der des
+    // Der Ort in der Datumszeile ist der Ort des Betreuers, nicht der
-    // Heims - er steht nirgends im Datenmodell und bleibt deshalb leer.
+    // des Heims.
-    betreuerOrt: null,
+    betreuerOrt: quelle.benutzer.ort ?? null,
    betreuteName: `${b.anrede ? `${b.anrede} ` : ''}${b.vorname} ${b.nachname}`.trim(),
    betreuteGeburtsdatum: b.geburtsdatum,
    betreuteAnschrift: anschrift || null,
@@ -4,7 +4,7 @@ import { db, nichtGeloescht } from '@/lib/db'
 import { oeffnen } from '@/lib/crypto/feld'
 import { protokollieren } from '@/lib/audit'
 import { ablegenMitTyp } from '@/lib/speicher'
-import { briefkopfBauen } from '@/lib/vertraege/briefkopf'
+import { briefkopfBauen, type Absender } from '@/lib/vertraege/briefkopf'
 import {
  RUECKKAUFSWERT_WIEDERVORLAGE_TAGE,
  rueckkaufswertAnschreiben,
@@ -53,7 +53,7 @@ export async function serienlaufDurchfuehren(eingabe: {
  betreuteId: string
  vertragIds: string[]
  stichtag: Date
-  benutzer: { id: string; name: string; email: string }
+  benutzer: { id: string; name: string; email: string } & Absender
 }): Promise<SerienErgebnis> {
  const heute = heuteAlsTag()
  const { betreuteId, benutzer } = eingabe
@@ -65,7 +65,7 @@ export async function serienlaufDurchfuehren(eingabe: {
  const kopf = briefkopfBauen({
    betreute: oeffnen('Betreute', betreute),
-    benutzer: { name: benutzer.name },
+    benutzer,
  })
  // Nur Vertraege dieser betreuten Person - fremde IDs laufen ins Leere.
@@ -4,6 +4,7 @@ import { revalidatePath } from 'next/cache'
 import { redirect } from 'next/navigation'
 import { Prisma } from '@prisma/client'
 import { db, nichtGeloescht } from '@/lib/db'
 import { verweisePruefen } from '@/lib/auth/verweise'
 import { erfordereZugang, ZugriffVerweigert } from '@/lib/auth/sitzung'
 import { aenderungErmitteln, protokollieren } from '@/lib/audit'
 import { sealen } from '@/lib/crypto/feld'
@@ -325,29 +326,15 @@ export async function buchungSpeichern(
    }
    const werte = gepruft.data
-    if (werte.kontoId) {
+    // Alle vier Verweise auf einmal - der Vorgang war bisher der einzige,
-      const konto = await db.konto.findFirst({
+    // der ungeprueft durchging.
-        where: { id: werte.kontoId, betreuteId, ...nichtGeloescht },
+    const verweisfehler = await verweisePruefen(betreuteId, {
-        select: { id: true },
+      konto: werte.kontoId,
-      })
+      vertrag: werte.vertragId,
-      if (!konto) return { fehler: 'Dieses Konto gehört nicht zu dieser betreuten Person.' }
+      dokument: werte.belegId,
-    }
+      vorgang: werte.vorgangId,
-
+    })
-    // Wie beim Konto: Der Vertrag muss zu dieser Akte gehoeren.
+    if (verweisfehler) return { fehler: verweisfehler }
    if (werte.vertragId) {
      const vertrag = await db.vertrag.findFirst({
        where: { id: werte.vertragId, betreuteId, ...nichtGeloescht },
        select: { id: true },
      })
      if (!vertrag) return { fehler: 'Dieser Vertrag gehört nicht zu dieser betreuten Person.' }
    }
    if (werte.belegId) {
      const beleg = await db.dokument.findFirst({
        where: { id: werte.belegId, betreuteId, ...nichtGeloescht },
        select: { id: true },
      })
      if (!beleg) return { fehler: 'Dieses Dokument gehört nicht zu dieser betreuten Person.' }
    }
    const felder = {
      kontoId: werte.kontoId,
@@ -635,34 +622,14 @@ export async function vermoegenspostenSpeichern(
    }
    const werte = gepruft.data
-    if (werte.kontoId) {
+    // An der Verknuepfung zum Vertrag haengt dessen Rueckkaufswert - sie
-      const konto = await db.konto.findFirst({
+    // darf nicht in eine fremde Akte zeigen.
-        where: { id: werte.kontoId, betreuteId, ...nichtGeloescht },
+    const verweisfehler = await verweisePruefen(betreuteId, {
-        select: { id: true },
+      konto: werte.kontoId,
-      })
+      vertrag: werte.vertragId,
-      if (!konto) return { fehler: 'Dieses Konto gehört nicht zu dieser betreuten Person.' }
+      immobilie: werte.immobilieId,
-    }
+    })
-
+    if (verweisfehler) return { fehler: verweisfehler }
    // Dieselbe Pruefung fuer die beiden anderen Verweise. Sie fehlte:
    // An der Verknuepfung zum Vertrag haengt dessen Rueckkaufswert, und
    // die darf nicht in eine fremde Akte zeigen.
    if (werte.vertragId) {
      const vertrag = await db.vertrag.findFirst({
        where: { id: werte.vertragId, betreuteId, ...nichtGeloescht },
        select: { id: true },
      })
      if (!vertrag) return { fehler: 'Dieser Vertrag gehört nicht zu dieser betreuten Person.' }
    }
    if (werte.immobilieId) {
      const immobilie = await db.immobilie.findFirst({
        where: { id: werte.immobilieId, betreuteId, ...nichtGeloescht },
        select: { id: true },
      })
      if (!immobilie) {
        return { fehler: 'Diese Immobilie gehört nicht zu dieser betreuten Person.' }
      }
    }
    const felder = {
      bezeichnung: werte.bezeichnung,
@@ -1,5 +1,6 @@
 'use server'
 import { revalidatePath } from 'next/cache'
 import { z } from 'zod'
 import { db } from '@/lib/db'
 import { erfordereBenutzer } from '@/lib/auth/sitzung'
@@ -102,3 +103,82 @@ export async function passwortAendern(
  await aufMindestdauerWarten(begonnen)
  return { erfolg: true }
 }
 /**
 * Die eigene Anschrift.
 *
 * Sie steht im Absenderblock jedes erzeugten Schreibens und liefert den
 * Ort fuer die Datumszeile. Angaben sind einzeln freiwillig: Wer nur den
 * Ort hinterlegt, bekommt "Bayreuth, den 23.08.2026" und keinen
 * Absenderblock mit leeren Zeilen.
 */
 const AnschriftSchema = z.object({
  strasse: z.string().trim().max(150, 'Bitte höchstens 150 Zeichen.'),
  plz: z.string().trim().max(10, 'Bitte höchstens 10 Zeichen.'),
  ort: z.string().trim().max(100, 'Bitte höchstens 100 Zeichen.'),
 })
 export type AnschriftZustand = {
  fehler?: string
  felder?: Partial<Record<'strasse' | 'plz' | 'ort', string>>
  erfolg?: string
 }
 export async function anschriftSpeichern(
  _vorher: AnschriftZustand,
  formular: FormData,
 ): Promise<AnschriftZustand> {
  const benutzer = await erfordereBenutzer()
  const gelesen = AnschriftSchema.safeParse({
    strasse: formular.get('strasse') ?? '',
    plz: formular.get('plz') ?? '',
    ort: formular.get('ort') ?? '',
  })
  if (!gelesen.success) {
    const felder = gelesen.error.flatten().fieldErrors
    return {
      fehler: 'Bitte prüfe die Eingaben.',
      felder: {
        strasse: felder.strasse?.[0],
        plz: felder.plz?.[0],
        ort: felder.ort?.[0],
      },
    }
  }
  // Leer heisst "nicht hinterlegt", nicht "leere Zeichenkette" - sonst
  // stuende im Brief eine Zeile aus Leerzeichen.
  const leerZuNull = (wert: string) => (wert === '' ? null : wert)
  await db.user.update({
    where: { id: benutzer.id },
    data: {
      strasse: leerZuNull(gelesen.data.strasse),
      plz: leerZuNull(gelesen.data.plz),
      ort: leerZuNull(gelesen.data.ort),
    },
  })
  await protokollieren({
    aktion: 'GEAENDERT',
    entitaet: 'User',
    entitaetId: benutzer.id,
    bezeichnung: benutzer.name,
    userId: benutzer.id,
    userEmail: benutzer.email,
    userName: benutzer.name,
    aenderung: {
      anschrift: {
        alt: [benutzer.strasse, benutzer.plz, benutzer.ort].filter(Boolean).join(', ') || null,
        neu:
          [gelesen.data.strasse, gelesen.data.plz, gelesen.data.ort].filter(Boolean).join(', ') ||
          null,
      },
    },
  })
  revalidatePath('/konto')
  return { erfolg: 'Deine Anschrift ist gespeichert.' }
 }
@@ -6,6 +6,7 @@ import type { Prisma } from '@prisma/client'
 import { db, nichtGeloescht } from '@/lib/db'
 import { erfordereZugang } from '@/lib/auth/sitzung'
 import { aenderungErmitteln, protokollieren, type Aenderung } from '@/lib/audit'
 import { verweisePruefen } from '@/lib/auth/verweise'
 import { oeffnen, sealen } from '@/lib/crypto/feld'
 import {
  AufgabeAbhakenSchema,
@@ -69,34 +70,6 @@ async function kontaktnameZu(kontaktId: string | null): Promise<string | null> {
  return [kontakt.name, kontakt.organisation].filter(Boolean).join(', ')
 }
 /**
 * Gehoert der Ansprechpartner zu dieser Akte?
 *
 * Ohne die Pruefung koennte ein veraendertes Formular einen Kontakt aus
 * einer fremden Akte an den Vorgang haengen - und sein Name stuende
 * anschliessend im Briefkopf.
 */
 async function ansprechpartnerPruefen(
  betreuteId: string,
  ansprechpartnerId: string | null,
 ): Promise<{ ok: true } | { ok: false; zustand: Formularzustand }> {
  if (!ansprechpartnerId) return { ok: true }
  const kontakt = await db.kontakt.findFirst({
    where: { id: ansprechpartnerId, betreuteId, geloeschtAm: null },
    select: { id: true },
  })
  if (kontakt) return { ok: true }
  return {
    ok: false,
    zustand: {
      fehler: 'Diesen Kontakt gibt es nicht (mehr).',
      felder: { ansprechpartnerId: 'Bitte einen Kontakt aus dem Verzeichnis wählen.' },
    },
  }
 }
 export async function vorgangAnlegen(
  _vorher: Formularzustand,
  formular: FormData,
@@ -119,8 +92,13 @@ export async function vorgangAnlegen(
  const eingabe = gelesen.data
-  const geprueft = await ansprechpartnerPruefen(betreuteId, eingabe.ansprechpartnerId)
+  // Sein Name stuende sonst im Briefkopf - siehe lib/auth/verweise.ts.
-  if (!geprueft.ok) return geprueft.zustand
+  const verweisfehler = await verweisePruefen(betreuteId, {
    kontakt: eingabe.ansprechpartnerId,
  })
  if (verweisfehler) {
    return { fehler: verweisfehler, felder: { ansprechpartnerId: verweisfehler } }
  }
  const jetzt = new Date()
@@ -250,8 +228,12 @@ export async function vorgangAendern(
  const eingabe = gelesen.data
-  const geprueft = await ansprechpartnerPruefen(vorgang.betreuteId, eingabe.ansprechpartnerId)
+  const verweisfehler = await verweisePruefen(vorgang.betreuteId, {
-  if (!geprueft.ok) return geprueft.zustand
+    kontakt: eingabe.ansprechpartnerId,
  })
  if (verweisfehler) {
    return { fehler: verweisfehler, felder: { ansprechpartnerId: verweisfehler } }
  }
  const vorherOffen = oeffnen('Vorgang', vorgang)
@@ -0,0 +1,84 @@
 import { describe, expect, it } from 'vitest'
 import { briefkopfBauen } from '@/lib/vertraege/briefkopf'
 import { absenderBlock, datumsZeile } from '@/lib/vertraege/anschreiben'
 /**
 * Der Absenderblock.
 *
 * Ein foermliches Schreiben ohne Ruecksendeadresse wirkt unserioes und
 * macht es der Gegenstelle schwer zu antworten. Umgekehrt gilt: Lieber
 * nur der Name als ein Block mit leeren Zeilen - eine halb ausgefuellte
 * Adresse sieht nach Fehler aus, ein blosser Name nach Absicht.
 */
 const BETREUTE = {
  vorname: 'Erika',
  nachname: 'Musterfrau',
  anrede: 'Frau',
  geburtsdatum: new Date(Date.UTC(1943, 3, 17)),
  heimName: 'Seniorenheim Sonnenhof',
  heimStrasse: 'Heimweg 3',
  heimPlz: '95445',
  heimOrt: 'Bayreuth',
  betreuungsgericht: 'Amtsgericht Bayreuth',
  aktenzeichenGericht: 'XVII 412/25',
  bestellungAm: new Date(Date.UTC(2026, 1, 14)),
 }
 const VOLLSTAENDIG = {
  name: 'Florian Wilde',
  strasse: 'Cottenbacher Str. 23',
  plz: '95445',
  ort: 'Bayreuth',
 }
 describe('Absenderblock', () => {
  it('nennt Name, Straße und Ort', () => {
    const kopf = briefkopfBauen({ betreute: BETREUTE, benutzer: VOLLSTAENDIG })
    expect(absenderBlock(kopf)).toBe('Florian Wilde\nCottenbacher Str. 23\n95445 Bayreuth')
  })
  it('bleibt beim Namen, wenn keine Anschrift hinterlegt ist', () => {
    // Kein Block mit leeren Zeilen - das sieht nach Fehler aus.
    const kopf = briefkopfBauen({ betreute: BETREUTE, benutzer: { name: 'Florian Wilde' } })
    expect(absenderBlock(kopf)).toBe('Florian Wilde')
  })
  it('lässt die Straße weg, wenn nur der Ort bekannt ist', () => {
    const kopf = briefkopfBauen({
      betreute: BETREUTE,
      benutzer: { name: 'Florian Wilde', plz: '95445', ort: 'Bayreuth' },
    })
    expect(absenderBlock(kopf)).toBe('Florian Wilde\n95445 Bayreuth')
  })
  it('verträgt einen Ort ohne PLZ', () => {
    const kopf = briefkopfBauen({
      betreute: BETREUTE,
      benutzer: { name: 'Florian Wilde', ort: 'Bayreuth' },
    })
    expect(absenderBlock(kopf)).toBe('Florian Wilde\nBayreuth')
  })
  it('nimmt die Anschrift vom Betreuer, nicht vom Heim', () => {
    // Die Heimadresse ist die der betreuten Person und gehört in den
    // Anschriftenblock, nie in den Absender.
    const kopf = briefkopfBauen({ betreute: BETREUTE, benutzer: VOLLSTAENDIG })
    expect(absenderBlock(kopf)).not.toContain('Heimweg')
    expect(kopf.betreuteAnschrift).toContain('Heimweg 3')
  })
 })
 describe('Datumszeile', () => {
  const heute = new Date(Date.UTC(2026, 7, 23))
  it('stellt den Ort des Betreuers voran', () => {
    const kopf = briefkopfBauen({ betreute: BETREUTE, benutzer: VOLLSTAENDIG })
    expect(datumsZeile(kopf.betreuerOrt, heute)).toBe('Bayreuth, den 23.08.2026')
  })
  it('lässt ohne Ort das Komma weg', () => {
    const kopf = briefkopfBauen({ betreute: BETREUTE, benutzer: { name: 'Florian Wilde' } })
    expect(datumsZeile(kopf.betreuerOrt, heute)).toBe('23.08.2026')
  })
 })
@@ -0,0 +1,128 @@
 import { describe, expect, it } from 'vitest'
 import {
  dropZeilenEntfernen,
  hatAnweisungen,
  kopfBauen,
  ordnernameBauen,
 } from '../scripts/migration-erzeugen.mjs'
 /**
 * Der Migrations-Wrapper.
 *
 * Die eine Sache, die hier schiefgehen darf und nicht schiefgehen soll:
 * zu viel entfernen. Ein DROP INDEX, das Prisma zu Recht schreibt, muss
 * stehen bleiben - sonst repariert das Skript die Suche und zerlegt
 * dafuer das Schema.
 */
 const GESCHUETZT = [
  { name: 'dokument_absender_trgm', quelle: 'prisma/sql/volltextsuche.sql' },
  { name: 'vorgang_titel_trgm', quelle: 'prisma/sql/volltextsuche.sql' },
 ]
 describe('DROP-Zeilen entfernen', () => {
  it('nimmt die geschützte Anweisung samt Überschrift heraus', () => {
    const roh = [
      '-- DropIndex',
      'DROP INDEX "dokument_absender_trgm";',
      '',
      '-- AlterTable',
      'ALTER TABLE "kontakt" ADD COLUMN "anrede" TEXT;',
    ].join('\n')
    const { sql, entfernt } = dropZeilenEntfernen(roh, GESCHUETZT)
    expect(entfernt).toEqual(['dokument_absender_trgm'])
    expect(sql).not.toContain('DROP INDEX')
    expect(sql).not.toContain('DropIndex')
    expect(sql).toContain('ALTER TABLE "kontakt"')
  })
  it('lässt ein DROP INDEX auf einen Prisma-eigenen Index stehen', () => {
    // Der Kern der Sache: Das Skript darf nicht alles wegräumen, was nach
    // DROP INDEX aussieht - manche sollen wirklich weg.
    const roh = ['-- DropIndex', 'DROP INDEX "vertrag_betreuteId_status_idx";'].join('\n')
    const { sql, entfernt } = dropZeilenEntfernen(roh, GESCHUETZT)
    expect(entfernt).toEqual([])
    expect(sql).toContain('DROP INDEX "vertrag_betreuteId_status_idx";')
    expect(sql).toContain('-- DropIndex')
  })
  it('entfernt mehrere geschützte Anweisungen und meldet beide', () => {
    const roh = [
      '-- DropIndex',
      'DROP INDEX "dokument_absender_trgm";',
      '',
      '-- DropIndex',
      'DROP INDEX "vorgang_titel_trgm";',
      '',
      '-- CreateTable',
      'CREATE TABLE "schreibvorlage" ();',
    ].join('\n')
    const { sql, entfernt } = dropZeilenEntfernen(roh, GESCHUETZT)
    expect(entfernt).toEqual(['dokument_absender_trgm', 'vorgang_titel_trgm'])
    expect(sql.startsWith('-- CreateTable')).toBe(true)
  })
  it('verträgt IF EXISTS und abweichende Schreibweise', () => {
    const roh = 'drop index if exists "vorgang_titel_trgm";'
    expect(dropZeilenEntfernen(roh, GESCHUETZT).entfernt).toEqual(['vorgang_titel_trgm'])
  })
  it('lässt eine Migration ohne Treffer unverändert', () => {
    const roh = ['-- AlterTable', 'ALTER TABLE "vorgang" ADD COLUMN "x" TEXT;'].join('\n')
    const { sql, entfernt } = dropZeilenEntfernen(roh, GESCHUETZT)
    expect(entfernt).toEqual([])
    expect(sql).toBe(roh)
  })
  it('greift nicht bei einem bloßen Vorkommen des Namens im Text', () => {
    // Ein Kommentar, der den Index nennt, ist keine Anweisung.
    const roh = '-- dokument_absender_trgm bleibt bestehen'
    const { sql, entfernt } = dropZeilenEntfernen(roh, GESCHUETZT)
    expect(entfernt).toEqual([])
    expect(sql).toBe(roh)
  })
 })
 describe('Leere Migration erkennen', () => {
  it('sieht eine echte Anweisung', () => {
    expect(hatAnweisungen('-- AlterTable\nALTER TABLE "x" ADD COLUMN "y" TEXT;')).toBe(true)
  })
  it('hält reinen Kommentartext für leer', () => {
    // Der Normalfall: Schema und Datenbank stimmen überein, der ganze
    // Diff bestand aus den zwei bekannten DROP-Zeilen. Dann darf keine
    // Migration entstehen — eine leere in der Historie ist schlimmer als
    // keine.
    expect(hatAnweisungen('-- nur ein Kommentar\n\n-- noch einer')).toBe(false)
  })
  it('hält Leerraum für leer', () => {
    expect(hatAnweisungen('   \n\n  ')).toBe(false)
  })
 })
 describe('Kopfkommentar', () => {
  it('benennt die entfernten Indizes und ihre Quelle', () => {
    const kopf = kopfBauen('ansprechpartner', ['vorgang_titel_trgm'], GESCHUETZT)
    expect(kopf).toContain('vorgang_titel_trgm')
    expect(kopf).toContain('prisma/sql/volltextsuche.sql')
  })
  it('sagt auch, wenn nichts zu entfernen war', () => {
    expect(kopfBauen('leer', [], GESCHUETZT)).toContain('Nichts zu entfernen')
  })
 })
 describe('Ordnername', () => {
  it('baut den Zeitstempel im Prisma-Format', () => {
    expect(ordnernameBauen('anrede', new Date(2026, 7, 23, 9, 5, 3))).toBe(
      '20260823090503_anrede',
    )
  })
 })
@@ -85,3 +85,50 @@ describe.skipIf(!mitGit)('Betriebsskripte', () => {
    }
  })
 })
 /**
 * Abschneidende Leitungen in Skripten mit "pipefail".
 *
 * Anlass ist ein Abbruch im Betrieb: Beim Sprung von v1.5.0 auf v1.10.1
 * endete update.sh mitten in der Ausgabe, ohne jede Meldung. Ursache war
 *
 *     git log --oneline "HEAD..$ZIEL" | head -15 | sed ...
 *
 * "head" schliesst die Leitung nach 15 Zeilen, "git log" schreibt weiter
 * und bekommt SIGPIPE (Exitcode 141). Mit "set -o pipefail" gilt die
 * ganze Kette als gescheitert, "set -e" beendet das Skript - stumm.
 *
 * Es ist zeitabhaengig: Solange der Erzeuger fertig wird, bevor "head"
 * zumacht, faellt nichts auf. Deshalb lief es monatelang gut und riss
 * genau dann, als zum ersten Mal mehr als 15 Commits dazwischenlagen.
 *
 * Dieselbe Falle steckte in der Selbstpruefung der Sicherung, wo sie
 * eine intakte Sicherung als kaputt gemeldet haette, sobald die
 * Datenbank gross genug ist.
 *
 * Der Test verbietet das Muster deshalb ganz. Wer eine Ausgabe kuerzen
 * will, nimmt "git log -15", "sed -n '1,15p'" oder einen Zaehler in awk -
 * alles drei liest bis zum Ende und schliesst nichts zu frueh.
 */
 describe('Skripte mit pipefail', () => {
  const skripte = ['scripts/update.sh', 'scripts/sicherung.sh', 'scripts/wiederherstellung.sh']
  it.each(skripte)('%s schneidet keine Leitung mit head ab', (pfad) => {
    const inhalt = readFileSync(pfad, 'utf8')
    if (!/set -[a-z]*o pipefail|set -o pipefail/.test(inhalt)) return
    const treffer = inhalt
      .split('\n')
      .map((zeile, nummer) => ({ zeile, nummer: nummer + 1 }))
      // Kommentarzeilen erklaeren das Muster gerade - sie sind erlaubt.
      .filter(({ zeile }) => !zeile.trim().startsWith('#'))
      .filter(({ zeile }) => !zeile.includes('printf'))
      .filter(({ zeile }) => /\|\s*head\b/.test(zeile))
    expect(
      treffer.map((t) => `Zeile ${t.nummer}: ${t.zeile.trim()}`),
      'Abschneidende Leitung: der Erzeuger bekommt SIGPIPE, pipefail reicht ' +
        'es weiter, set -e beendet das Skript stumm.',
    ).toEqual([])
  })
 })
@@ -75,6 +75,17 @@ describe('Schreibweisen vergleichbar machen', () => {
    expect(normalisieren('Debeka AG')).toBe(normalisieren('Debeka'))
  })
  it('kennt die gGmbH', () => {
    // Heime, Sozialdienste und Träger sind fast durchweg gGmbH — ohne
    // sie zerfiele die Zusammenfassung genau dort, wo sie zählt.
    expect(normalisieren('Seniorenzentrum St. Katharina gGmbH')).toBe(
      normalisieren('Seniorenzentrum St. Katharina'),
    )
    expect(normalisieren('SENIORENZENTRUM ST KATHARINA GGMBH')).toBe(
      normalisieren('Seniorenzentrum St. Katharina'),
    )
  })
  it('entfernt auch mehrteilige Rechtsformen', () => {
    expect(normalisieren('Stadtwerke Bamberg GmbH & Co KG')).toBe(
      normalisieren('Stadtwerke Bamberg'),
Author	SHA1	Message	Date
florian.wilde	ece995bb6a	Merge #37 : Update brach ohne Meldung ab Abgeschnittene Leitungen unter pipefail beendeten update.sh stumm und haetten die Selbstpruefung der Sicherung falsch negativ gemacht. Behoben, mit ERR-Falle und Test gegen das Muster.	2026-08-23 22:36:53 +00:00
Florian Wilde	107406e3c0	Update brach ohne Meldung ab Beim Sprung von 1.5.0 auf 1.10.1 endete scripts/update.sh mitten in der Ausgabe. Kein Fehler, keine Zeile, einfach zurueck zur Eingabeaufforderung. Ursache war eine abgeschnittene Leitung: git log --oneline "HEAD..$ZIEL" \| head -15 \| sed ... head schliesst die Leitung nach 15 Zeilen, git log schreibt weiter und bekommt SIGPIPE (141). Mit "set -o pipefail" gilt die ganze Kette als gescheitert, "set -e" beendet das Skript - stumm. Zeitabhaengig, deshalb monatelang unauffaellig: Solange git log fertig wurde, bevor head zumachte, ging es gut. Die Schwelle liegt exakt bei 15 Commits, und v1.5.0..v1.10.0 waren die ersten 16. Behoben, indem der Erzeuger selbst begrenzt (git log -15) statt die Leitung zu kappen. Dieselbe Behandlung fuer die beiden Tag-Listen. Dieselbe Falle steckte in der Selbstpruefung von sicherung.sh: openssl enc -d ... \| head -c 5 \| grep -q "PGDMP" Beide Leser schliessen frueh. Bei kleiner Datenbank steht alles im Puffer und es faellt nicht auf; mit wachsender Datenbank kippt es - und dann meldet das Skript eine INTAKTE Sicherung als kaputt und verweigert das Update. Jetzt liest dd eine feste Menge und endet regulaer. Damit so etwas nicht wieder stumm passiert: - Eine ERR-Falle nennt Zeilennummer und Exitcode und erklaert bei 141, dass es SIGPIPE ist und ein Fehler im Skript, nicht beim Benutzer. - Ein Test verbietet "\| head" in Skripten mit pipefail und nennt die Zeile. Gegenprobe gemacht: Er schlaegt an. - Bei mehr als 15 Commits steht "... und N weitere" darunter, statt sie wortlos wegzulassen. Nachgestellt: der Ablauf von 1.5.0 auf 1.10.1 laeuft durch.	2026-08-24 00:36:08 +02:00
florian.wilde	9ea78a4d29	Merge #36 : Zeilenenden im Repository auf LF Behebt Issue #26: .gitattributes legt LF fest, 29 Dateien normalisiert. Nachgewiesen nur Zeilenenden, kein Zeichen Inhalt geaendert. Closes #26	2026-08-23 22:28:47 +00:00
Florian Wilde	1ed19eb76e	Zeilenenden der 24 verbliebenen Dateien normalisieren Ausschliesslich Zeilenenden. Nachgewiesen mit "git diff --cached --ignore-cr-at-eol": Der Diff ist leer, es hat sich kein Zeichen Inhalt geaendert. Deshalb ein eigener Commit: 7448 geaenderte Zeilen in einem Commit mit echten Aenderungen zu verstecken, macht die Historie an dieser Stelle unlesbar. So laesst er sich beim Durchsehen ueberspringen. Refs #26	2026-08-23 23:37:02 +02:00
Florian Wilde	6a0db51e3b	Zeilenenden im Repository auf LF festlegen Ohne .gitattributes liegen Dateien gemischt vor: 29 von 500 mit CRLF, der Rest mit LF. Jedes zeilenweise arbeitende Werkzeug schreibt eine CRLF-Datei dann mit LF zurueck, und der Diff zeigt statt drei geaenderten Zeilen die ganze Datei - bei Issue #7 waren es 578 statt 8, kurz vor dem Push bemerkt. Dieser Commit legt nur die Regel fest. Die Normalisierung der 29 Dateien kommt getrennt, damit die Historie lesbar bleibt. Refs #26	2026-08-23 23:34:38 +02:00
florian.wilde	851724774a	Merge #35 : Doppelt gerenderte Listen dokumentieren Behebt Issue #28: Kommentar an der Dokumentenliste, Muster und drei tragfaehige Wege in e2e/hilfen.ts, Begruendung warum die Verdopplung bleibt. Closes #28	2026-08-23 21:29:15 +00:00
Florian Wilde	3772e360e1	Doppelt gerenderte Listen dokumentieren Die Dokumentenliste rendert jeden Eintrag zweimal: als Karte fuers Handy, als Tabellenzeile ab Tablet. Eine Fassung ist per Breakpoint versteckt, steht aber im DOM. Beim Testen trifft getByText(...).first() deshalb die unsichtbare Kopie, und die Pruefung scheitert mit "element is not visible" an einer Stelle, die augenscheinlich in Ordnung ist. Das hat mehrfach Zeit gekostet, weil man den Grund nicht sieht. Nachgemessen an /dokumente mit acht Dokumenten: ein Titel liefert 16 Treffer, davon 8 sichtbar - und first() ist unsichtbar. - Kommentar an der Komponente, mit dem Verweis auf die Hilfsdatei. - In e2e/hilfen.ts das Muster beschrieben und drei Wege genannt, die tragen: innerText fuer "steht das da", visible=true zum Klicken, die Zusammenfassungszeile fuer Anzahlen. Alle drei nachgeprueft, bevor sie aufgeschrieben wurden - eine Anleitung mit kaputtem Rezept waere schlimmer als keine. Zur Frage aus dem Issue, ob sich die Verdopplung vermeiden laesst: nein, nicht ohne Verlust. Eine Tabelle, die zu Karten umbricht, verlangt display:block auf Zeilen und Zellen - damit ist es keine Tabelle mehr, Vorlesesoftware verliert den Zusammenhang von Spaltenkopf und Wert, und genau der macht eine Liste mit acht Spalten erst benutzbar. Die Begruendung steht jetzt am Code, statt die Frage offen zu lassen. Betroffen ist uebrigens nur diese eine Stelle, nicht mehrere: kalender-monat.tsx und das Stammdatenformular nutzen Breakpoints, ohne Inhalt doppelt zu rendern. Refs #28	2026-08-23 23:28:22 +02:00
florian.wilde	d75eb185d5	Merge #34 : Verweise auf fremde Akten an einer Stelle pruefen Behebt Issue #23: Durchgang durch alle Server Actions, eine Luecke geschlossen (buchung.vorgangId), die Pruefung in lib/auth/verweise.ts zusammengefasst. Closes #23	2026-08-23 21:21:40 +00:00
Florian Wilde	91a9aca0d8	Verweise auf fremde Akten an einer Stelle pruefen Wenn ein Formular einen Fremdschluessel mitschickt, kommt der aus einer Auswahlliste im Browser. Der Server darf sich darauf nicht verlassen - eine veraenderte Anfrage kann jede beliebige Id enthalten. Alle 22 Dateien unter src/server/actions/ durchgesehen. Das Ergebnis ist besser als befuerchtet: Bis auf eine Stelle war jeder Verweis geprueft. buchung.vorgangId ging ungeprueft durch. Konto, Beleg und Vertrag wurden geprueft, der Vorgang nicht. Die Pruefung liegt jetzt in lib/auth/verweise.ts statt verstreut in den Aktionen. Die acht erlaubten Ziele sind eine ausgeschriebene Aufzaehlung und kein dynamischer Tabellenzugriff: So sieht der Typpruefer jede Abfrage, und welche Tabellen erreichbar sind, ist eine Entscheidung und keine Nebenwirkung. Mehrere Verweise laufen nebeneinander - bei vier Verweisen eine Wartezeit statt vier. Umgestellt: die vier Einzelpruefungen der Buchung, die drei des Vermoegenspostens, die eigene Hilfsfunktion fuer den Ansprechpartner. Nicht angefasst wurden die Stellen, die ihre eigene, passendere Form haben - etwa das Kontaktprotokoll, das beide Verweise parallel laedt und feldgenaue Meldungen zurueckgibt. Zum Test: Der erste Entwurf rief die Server Action per fetch nach. Der waere auch ohne jede Pruefung gruen gewesen, weil Next einen Aufruf ohne gueltige Action-Id ohnehin ablehnt - er haette nichts bewiesen. Der jetzige schiebt dem echten Auswahlfeld einen Eintrag mit fremder Id unter und schickt das Formular normal ab. Gegenprobe mit ausgebauter Pruefung: faellt um, wie er soll. Refs #23	2026-08-23 23:20:26 +02:00
florian.wilde	91592cbe88	Merge #33 : Ein Jahr Kontobewegungen im Beispielfall Behebt Issue #22: 107 Buchungen ueber zwoelf Monate im Demofall, mit gerechnetem Kontostand. Dazu behoben: gGmbH fehlte in der Rechtsformliste beim Zusammenfassen wiederkehrender Zahlungen. Closes #22	2026-08-23 19:36:49 +00:00
Florian Wilde	18709a8e49	Ein Jahr Kontobewegungen im Beispielfall Der Demofall brachte Konten und Kontostaende mit, aber keine einzige Buchung. Kassenbuch, Belegpflicht, Dauerzahlungen und die Erkennung wiederkehrender Zahlungen liefen darin also leer - wer die Anwendung zum ersten Mal ansah, musste erst eine CSV importieren. Neu sind 107 Buchungen ueber zwoelf Monate, erzeugt aus einem Muster statt einzeln abgetippt: Rente, Betriebsrente und Pflegekasse als Einnahmen, Heimentgelt, Barbetrag, Sterbegeldbeitrag, Telefon und Kontofuehrung monatlich, dazu Rundfunkbeitrag und Grundsteuer vierteljaehrlich sowie eine Handvoll Einzelposten. Was der Fall damit zeigt: - Das Heimentgelt steht in drei Schreibweisen auf dem Auszug und wird trotzdem als eine monatliche Zahlung gefuehrt. - Genau eine Buchung hat weder Quittung noch Begruendung. Eine, nicht zwanzig: Die Liste soll etwas zu zeigen haben und nicht rot leuchten. - Die Sterbegeld-Lastschriften bleiben unzugeordnet, damit sich der Handgriff "zwoelf Zahlungen als belegt zuordnen" ausprobieren laesst. Der Beitrag steigt im Mai von 18,40 auf 19,80 - damit auch die Abweichungspruefung sichtbar wird. - Der Kontostand zum 31.07. wird aus Anfangsstand und Buchungen gerechnet, nicht behauptet. Ein Beispielfall, der sich selbst widerspricht, waere schlimmer als einer ohne Buchungen. Zwei Funde beim Bauen: Der Unique-Index auf (kontoId, importReferenz) hat einen echten Fehler in den Daten gefangen: Zwei Renten am Monatsersten ergaben dieselbe Referenz. Genau dafuer ist er da. "gGmbH" fehlte in der Rechtsformliste. Dadurch galten "Seniorenzentrum St. Katharina" und "... gGmbH" als zwei Empfaenger - und die Gruppe zerfiel ausgerechnet in dem Fachgebiet, in dem fast jeder Traeger eine gGmbH ist. Ergaenzt, mit Test. Geprueft: ein Einheitstest fuer die Rechtsform, vier End-to-End-Tests am Beispielfall - Umfang und Zeitraum, Kontostand gegen Buchungssumme, die erkannten Gruppen und das Kassenbuch. Refs #22	2026-08-23 21:35:46 +02:00
florian.wilde	b6b579a04d	Merge #32 : Absenderanschrift in jedem Schreiben Behebt Issue #21: Strasse, PLZ und Ort unter "Mein Konto", von dort in den Absenderblock jedes Schreibens und als Ort in die Datumszeile. Was fehlt, bleibt weg. Closes #21	2026-08-23 18:30:23 +00:00
Florian Wilde	848aaf1b9f	Absenderanschrift in jedem Schreiben Jeder erzeugte Brief ging bisher ohne Ruecksendeadresse hinaus: Im Absenderblock stand nur der Name, in der Datumszeile fehlte der Ort. Bei einer Versicherung oder Behoerde wirkt das unserioes und macht es der Gegenstelle unnoetig schwer zu antworten. Neu unter "Mein Konto" ein Feld fuer Strasse, PLZ und Ort. Ab da stehen sie im Absenderblock jedes Schreibens, und die Datumszeile lautet "Bayreuth, den 23.08.2026". Die Anschrift haengt am Benutzer, nicht an der betreuten Person: Sie gehoert zu mir und gilt fuer alle Akten. Nicht die Logik fehlte, sondern die Datenquelle - absenderBlock() und datumsZeile() konnten die Felder schon, briefkopfBauen() hat sie mit einem Kommentar auf null gesetzt, weil es sie im Datenmodell nicht gab. Aufbau: - Drei Felder am Benutzer, Migration ueber den Wrapper aus #24. Das war sein erster echter Einsatz: erzeugte Datei ohne Handarbeit brauchbar, DROP-INDEX-Zeilen bereits heraus. - Ein Absender-Typ statt eines blossen Namens, durchgereicht bis in den Serienlauf - der hat bisher {name} gebaut und haette die Anschrift sonst still verloren. - Zwei Platzhalter fuer eigene Vorlagen: betreuer_anschrift, betreuer_ort. Was fehlt, bleibt weg: Jede der drei Angaben ist einzeln freiwillig. Nur ein Ort ergibt eine Datumszeile mit Ort und einen Absenderblock, der weiterhin nur aus dem Namen besteht. Eine halb ausgefuellte Adresse sieht nach Fehler aus, ein blosser Name nach Absicht. Geprueft: sieben Einheitstests fuer den Absenderblock inklusive jeder Teilbefuellung und der Gegenprobe, dass nie die Heimadresse der betreuten Person im Absender landet; vier End-to-End-Tests vom leeren Zustand ueber das Speichern bis zum fertigen Brief. Refs #21	2026-08-23 20:29:17 +02:00
florian.wilde	5022a97a6f	Merge #31 : Datenbankbefehle benennen, welcher Rueckfragen stellt Behebt Issue #27: Uebersicht der sieben Datenbankbefehle in der README, db:migrate als einziger interaktiver benannt, Ersteinrichtung auf npm run setup vereinheitlicht. Closes #27	2026-08-23 17:36:06 +00:00
Florian Wilde	110b11bef8	Datenbankbefehle benennen, welcher Rueckfragen stellt "npm run db:migrate" ist "prisma migrate dev" und damit interaktiv: Es fragt nach einem Namen und bietet an, die Datenbank zurueckzusetzen. In einem Skript, in der CI oder aus einem Agenten heraus bleibt es haengen. Aus dem Namen ging das nicht hervor, also lief man einmal hinein. - Neuer Abschnitt in der README mit allen sieben Datenbankbefehlen, wofuer sie da sind und welcher Rueckfragen stellt. Es ist genau einer. - Der uebliche Weg fuer eine Schemaaenderung steht als Dreizeiler daneben - ueber den Wrapper aus #24, nicht ueber migrate dev. - Die Ersteinrichtung in der README rief "npx prisma migrate dev --name fundament" auf, obwohl es dafuer "npm run setup" gibt. Das war der Ausgangspunkt der Verwirrung; jetzt steht dort der eine Befehl. - Der Hinweis unter "Betriebswissen", die SQL-Skripte seien von Hand anzustossen, galt nur fuer die Ersteinrichtung. Beim Aktualisieren erledigt update.sh das mit - jetzt steht das dabei. "db:migrate" bleibt bestehen. Der interaktive Ablauf hat seinen Platz, etwa um eine verkorkste Entwicklungsdatenbank zurueckzusetzen; er ist nur nicht mehr der Standardweg. Refs #27	2026-08-23 19:35:20 +02:00
florian.wilde	4aed9824d1	Merge #30 : Migrationskommentare zeigen auf die richtige Datei Behebt Issue #25: prisma/sql/suche.sql gibt es nicht, richtig ist volltextsuche.sql. Dazu ein Verweis auf npm run db:migration aus #24. Closes #25	2026-08-23 17:31:35 +00:00
Florian Wilde	e19300b33d	Migrationskommentare zeigen auf die richtige Datei Fuenf Migrationen verwiesen fuer die Herkunft der Trigramm-Indizes auf prisma/sql/suche.sql. Diese Datei gibt es nicht; sie heisst volltextsuche.sql. Der Hinweis steht genau dort, wo ihn jemand liest, der die naechste Migration erzeugt - ein falscher Pfad schickt ihn ins Leere. Dazu ein Verweis auf das Werkzeug aus #24: "npm run db:migration" nimmt die Zeilen inzwischen selbst heraus, die Kommentare rieten aber weiterhin nur zum Nachsehen. Geprueft, bevor die Dateien angefasst wurden: Prisma speichert zwar eine Pruefsumme je Migration, "migrate deploy" verifiziert sie fuer bereits angewendete Migrationen aber nicht. Nachgestellt mit genau der Lage, die auch auf dem Server entsteht - Pruefsumme in der Datenbank weicht ab, "migrate status" und "migrate deploy" bleiben zufrieden. Refs #25	2026-08-23 19:30:46 +02:00
florian.wilde	41e33ad85f	Merge #29 : Migrations-Wrapper gegen das Loeschen der Trigramm-Indizes Behebt Issue #24: npm run db:migration erzeugt Migrationen ohne die bekannten DROP-INDEX-Zeilen und prueft nach dem Anwenden, dass die Indizes stehen. Closes #24	2026-08-23 17:25:52 +00:00
Florian Wilde	3153e6179d	Migrationen erzeugen, ohne die Suche kaputtzumachen "prisma migrate diff" kennt die Trigramm-Indizes aus prisma/sql/volltextsuche.sql nicht und schreibt deshalb in jede Migration ein DROP INDEX dafuer. Fuenfmal mussten die Zeilen von Hand raus. Auf dem Server waere es folgenlos geblieben - update.sh legt die Indizes hinterher neu an -, in der Entwicklung dagegen waere die Suche still langsam geworden. npm run db:migration -- <name> [--anwenden] npm run db:pruefen Aufbau: - Die Liste der geschuetzten Indizes steht an einer Stelle. Wer in prisma/sql/ einen hinzufuegt, traegt ihn dort ein. - dropZeilenEntfernen() ist bewusst eng: Nur eine DROP-Anweisung, die einen geschuetzten Index nennt, faellt weg. Ein DROP INDEX auf einen Prisma-eigenen Index bleibt stehen - der soll ja weg. Ein Kommentar, der den Namen bloss erwaehnt, ebenfalls. - Der Kopf der erzeugten Datei sagt, was entfernt wurde und warum. - Nach --anwenden wird gegen die Datenbank geprueft, ob die Indizes wirklich noch stehen. Das ist der Unterschied zwischen "sollte gutgegangen sein" und "nachgesehen". Beim Probelauf gefunden und behoben: Stimmen Schema und Datenbank ueberein, besteht der ganze Diff aus den beiden bekannten DROP-Zeilen. Das Skript legte dafuer eine leere Migration an - und eine leere Migration in der Historie ist schlimmer als keine, weil sie als angewendet gilt und niemand mehr weiss, wofuer sie gut war. Jetzt bricht es vorher ab, ohne einen Ordner zu hinterlassen. Die Typen liegen als .d.mts daneben: Das Skript bleibt .mjs und laeuft ohne Bauschritt, die Tests laufen trotzdem nicht gegen "any". Geprueft: zwoelf Einheitstests, dazu von Hand der Lauf mit echter Schemaaenderung und der Lauf ohne. Refs #24	2026-08-23 19:25:09 +02:00