Phase 2: Wartungs- und Pruefmanagement

Wartungsvorlagen mit Checklisten, Prueftermine aus einem naechtlichen Lauf,
Prueffristen-Dashboard, Pruefwizard mit Foto und Unterschrift, unveraenderliche
Protokolle als PDF, Maengel-Workflow, Rueckrufe und Lebensdauerueberwachung.

Elf neue Tabellen, alle mit organisationId und Row Level Security. Die
Unveraenderbarkeit abgeschlossener Protokolle setzt ein Datenbanktrigger
durch, nicht der Anwendungscode: eine Korrektur erzeugt eine neue Pruefung
mit Verweis auf die alte, beide bleiben lesbar.

79 neue Tests (47 Unit, 10 gegen eine echte Datenbank, 22 E2E).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -8,10 +8,110 @@ Die Regeln dazu stehen in [docs/VERSIONIERUNG.md](docs/VERSIONIERUNG.md).
 
 ## [Unveröffentlicht]
 
-Nächster Schritt ist Phase 2 (Wartungs- und Prüfmanagement).
+Nächster Schritt ist Phase 3 (Einsätze und Übungen).
+
+---
+
+## [0.3.0] — 2026-09-03
+
+Phase 2: Wartungs- und Prüfmanagement. Das Modul, wegen dem eine Wehr so ein
+Programm einführt — Fristen im Blick behalten und im Streitfall nachweisen
+können, dass geprüft wurde.
 
 ### Hinzugefügt
 
+**Datenmodell**
+
+- `Wartungsvorlage` — was an einem Gerätetyp in welchem Takt geprüft wird, mit
+  Intervall, Vorwarnzeit, Prüfvorschrift und Erfahrungswert für die Dauer.
+- `Checklistenpunkt` in vier Ausprägungen: Ja/Nein, Messwert (mit zulässigem
+  Bereich und Einheit), Text und Foto. Pflichtpunkte sind die, an denen die
+  Einsatzbereitschaft hängt.
+- `Wartungstermin` — ein fälliger Termin an einem konkreten Gerät. Eindeutig
+  über Gerät, Vorlage und Fälligkeitstag, damit ein zweiter nächtlicher Lauf
+  nichts doppelt anlegt.
+- `Pruefung`, `Pruefergebnis` und `Signatur` — die durchgeführte Prüfung mit
+  Antworten je Punkt und Unterschrift.
+- `Mangel` mit dem Weg melden → zugewiesen → in Arbeit → behoben.
+- `Rueckruf`, `RueckrufGeraetetyp` und `RueckrufBetroffenheit` — eine
+  Herstellerwarnung, die betroffene Bauart und der Stand je Gerät.
+- `Erinnerung` als Nachweis und gleichzeitig als Sperre gegen Doppelversand.
+
+**Unveränderbarkeit der Protokolle**
+
+- Ein Trigger in der Datenbank weist jede Änderung an einer abgeschlossenen
+  Prüfung ab. Zulässig bleiben genau drei Dinge: der Wechsel auf „ersetzt", das
+  Nachtragen des PDF, solange keines hinterlegt ist, und `geaendertAm`.
+- Dieselbe Sperre gilt für die Bestandteile: an einem abgeschlossenen Protokoll
+  lassen sich weder Einzelergebnisse ändern noch Unterschriften nachtragen.
+- Korrekturen erzeugen eine **neue** Prüfung mit Verweis auf die alte. Beide
+  bleiben lesbar.
+- Gelöscht wird ein Protokoll nur im gekennzeichneten Aufbewahrungslauf —
+  derselbe Schalter wie beim Audit-Log.
+
+**Fristen-Dashboard** (`/pruefungen`)
+
+- Vier Töpfe nach Dringlichkeit: überfällig, diese Woche, diesen Monat, nächste
+  90 Tage. Jede Zahl ist gleichzeitig ein Filter.
+- Bündelung nach Fahrzeug, Standort, Gerätetyp oder Zuständigem — wer einen
+  Prüftag ansetzt, arbeitet ein Fahrzeug ab, keine alphabetische Liste.
+- Sammelzuweisung mehrerer Termine an eine Person.
+- Daneben die Lebensdauerüberwachung (`/pruefungen/lebensdauer`) mit Vorschlag
+  zur Aussonderung.
+
+**Prüfwizard** (`/pruefungen/neu`)
+
+- Ein Prüfpunkt je Bildschirm, große Schaltflächen, Foto direkt aus der Kamera.
+- Zeiterfassung läuft mit und landet im Protokoll.
+- Unterschrift auf einem Zeichenfeld, das Finger, Stift und Maus versteht; das
+  PNG landet in MinIO.
+- Jede Antwort geht sofort zum Server — bricht das WLAN weg, ist höchstens die
+  letzte verloren, und der Entwurf wird beim nächsten Öffnen fortgesetzt.
+- Mängel werden aus den beanstandeten Punkten vorgeschlagen.
+- Externe Wartung: Fachfirma, Kosten und das Fremdprotokoll als PDF.
+
+**Prüfprotokoll als PDF**
+
+- Erzeugt der Hintergrundprozess über Gotenberg und legt es in MinIO ab: Kopf
+  mit Wehr, Gerät und Prüfer-Kennung, Checkliste mit Soll, Ist und Befund,
+  eingebettete Fotos und Unterschriften, Fußzeile mit Prüfvorschrift, Prüfdatum
+  und Seitenzahl.
+- Laufende Protokollnummer `JJJJ-NNNN` je Wehr und Jahr.
+
+**Nächtlicher Lauf**
+
+- `fristen.pruefen` (3:15 Uhr) plant Termine aus den Vorlagen und zieht Frist
+  und Status an jedem Gerät nach.
+- `erinnerung.senden` (3:45 Uhr) verschickt Vorwarnungen bei T-30, T-7, T-0 und
+  einmal bei Überfälligkeit — als Sammelnachricht je Empfänger.
+- Beide Läufe sind wiederholbar und tragen sich beim Start des Workers je Wehr
+  selbst ein.
+
+**Mängel und Rückrufe**
+
+- Melden darf jedes Mitglied; ein kritischer Mangel sperrt das Gerät sofort.
+- Beim Beheben wird die Sperre aufgehoben — aber nur, wenn kein anderer offener
+  Mangel dasselbe Gerät sperrt.
+- Rückrufe suchen betroffene Geräte über Bauart, Modell, Seriennummernbereich
+  und Herstellungszeitraum. Das Ergebnis ist ein Vorschlag, keine automatische
+  Sperre.
+
+**Sonstiges**
+
+- Datei-Upload unter `/api/dateien` für Fotos, Unterschriften und
+  Fremdprotokolle — als Multipart, nicht Base64 durch eine JSON-Antwort.
+- Der Seed legt 5 Wartungsvorlagen mit echten Prüfvorgaben an (DGUV 112-190,
+  DIN 14811, DGUV Vorschrift 3, DIN 14920), dazu die fälligen Termine, ein
+  abgeschlossenes Protokoll samt Mangel und einen Beispielrückruf.
+- 79 neue Tests: 47 Unit-Tests zu Fristen, Bewertung und Planung, 10 gegen eine
+  echte Datenbank zur Unveränderbarkeit und Mandantentrennung, 22 Playwright-
+  Durchläufe über Dashboard, Vorlagen, Wizard, Mängel und Rückrufe.
+
+**Nachzügler aus Phase 1**
+
+Mit dieser Version wird auch das Geräteformular ausgeliefert, das nach der
+0.2.0 entstanden ist:
+
 - **Formular zum Anlegen und Bearbeiten eines Geräts** (`/geraete/neu` und
   `/geraete/<id>/bearbeiten`). Damit ist die letzte offene Lücke aus Phase 1
   geschlossen: Ein Neuzugang lässt sich einzeln erfassen, ohne den Umweg über
@@ -25,7 +125,7 @@ Nächster Schritt ist Phase 2 (Wartungs- und Prüfmanagement).
 - 7 weitere Playwright-Tests zum Formular (nun 58 statt 44, zwei davon unter
   Touch-Emulation begründet übersprungen).
 
-### Behoben
+Dabei behoben:
 
 - **Das Formular stürzte beim ersten Rechnen ab.** Die Vorgabewerte lagen in
   einem `"use client"`-Modul und wurden von einer Server-Komponente importiert;
@@ -38,6 +138,29 @@ Nächster Schritt ist Phase 2 (Wartungs- und Prüfmanagement).
 - Fehlermeldungen in Formularen sind eindeutig ansteuerbar (`data-testid`) —
   Next.js hängt einen eigenen Routen-Ansager mit derselben Rolle in jede Seite.
 
+### Geändert
+
+- Die Datumsarithmetik aus Phase 1 (`utcTag`, `monateAddieren`, `heutigerTag`,
+  `tagesabstand`) ist jetzt exportiert. Zwei Umsetzungen derselben Rechnung
+  wären früher oder später um einen Tag auseinandergelaufen.
+- Die Seitenleiste zeigt Prüfungen, Mängel und Rückrufe als verfügbar.
+- Die Gerätedetailseite zeigt Prüfhistorie, offene Mängel und anstehende
+  Termine — und startet die Prüfung.
+
+### Behoben
+
+- **Zwei gleichzeitig abgeschlossene Prüfungen zogen dieselbe Protokollnummer.**
+  Die eindeutige Bedingung in der Datenbank fing das ab, aber der zweite Prüfer
+  bekam einen Datenbankfehler statt eines Protokolls. Die Nummer wird jetzt
+  unter einer Transaktionssperre je Wehr und Jahr vergeben — gefunden von den
+  E2E-Tests, weil Desktop- und Tablet-Durchlauf parallel prüften.
+- **Der Worker ließ sich außerhalb des Containers nicht starten.** Ihm fehlte
+  das Laden der `.env`, und `server-only` warf beim Import unter Node. Beide
+  Startbefehle laufen jetzt mit `--conditions=react-server`, womit der leere
+  Export dieses Pakets greift.
+
+---
+
 ## [0.2.0] — 2026-09-03
 
 Phase 1: Stammdaten. Ab hier führt die Wehr ihren Bestand in FLORIAN — mit