FireAdministration/docs/DEVLOG.md

# Devlog

Entwicklungstagebuch mit Zeiterfassung. Jeder Arbeitsabschnitt bekommt einen
Eintrag: wann, wie lange, was entstanden ist, und was dabei schiefging.

Die aufgewendete Zeit wandert nach jedem Abschnitt in die Spalte
„tatsächlich" der [Aufwandsschätzung](AUFWANDSSCHAETZUNG.md).

## Zeitübersicht

| Phase | Sitzungszeit | Sitzungen | abgeschlossen |
|---|---:|---:|---|
| Phase 0 — Fundament | 1:00 h | 1 | 03.09.2026 |
| Phase 1 — Stammdaten | 1:15 h | 1 | 03.09.2026 |
| Phase 1 — Nachtrag Geräteformular | 0:50 h | 1 | 03.09.2026 |
| Phase 2 — Wartung und Prüfung | 2:25 h | 1 | 03.09.2026 |
| Phase 3 — Einsätze und Übungen | 2:10 h | 1 | 03.09.2026 |
| **Summe** | **7:40 h** | **5** | |

---

## 2026-09-03 · Phase 3 — Einsätze und Übungen

**12:25 – 14:35 · 2:10 h · Version 0.4.0**

### Was entstanden ist

Ab hier dokumentiert die Wehr, was sie tut. Acht neue Tabellen, ein öffentlich
erreichbares Portal und die Zahlen, nach denen die Gemeinde fragt.

**Schnellerfassung.** Im Alarmfall fragt FLORIAN drei Dinge: Stichwort, Ort,
welche Fahrzeuge raus sind. Alarmzeit ist der Moment des Anlegens. Alles
Weitere wird nachgetragen, wenn wieder Ruhe ist.

**Zeitstempel und Kennzahlen.** Sechs Stempel, je ein Knopf. Daraus rechnet
sich Ausrückzeit, Anfahrtszeit, Hilfsfrist und Einsatzdauer.

**Stärke nach FwDV 3.** Aus den Funktionen der Mannschaft, in der üblichen
Schreibweise, mit Zuordnung zur taktischen Einheit.

**Einsatzbericht.** Als PDF über Gotenberg, mit der Freigabe festgeschrieben.
Dazu der Jahresexport quer gedruckt für die Gemeinde.

**Statistik.** Kategorien nach Landesstatistik, Verteilung der Hilfsfristen mit
dem 80-Prozent-Wert, Beteiligung je Person, Auslastung je Fahrzeug.

**Portal für Fremdwehren.** Ein signierter Link ohne Anmeldung: Stand sehen,
Lagemeldung mit Foto absetzen. Zeitlich begrenzt, mengenbegrenzt, widerrufbar.

**Übungen.** Thema, Lernziele, Anwesenheit zum Abhaken — die Grundlage für die
Teilnahmequote in der Jahreshauptversammlung.

### Entscheidungen

**Die Hilfsfrist wird als 80-Prozent-Wert ausgewiesen, nicht als Durchschnitt.**
Der Durchschnitt sagt bei Eintreffzeiten nichts: ein einzelner Einsatz auf der
Autobahn zieht ihn nach oben, während neunzig Prozent der Fälle im Ort liegen.
In Bayern gilt als Ziel, in 80 Prozent der Fälle binnen zehn Minuten da zu
sein — also ist genau das die Zahl.

**Hinweise statt Sperren bei Zeiten und Stärke.** Eine verdrehte Reihenfolge
oder eine fehlende Führungskraft wird angezeigt, aber nicht verhindert.
Einsätze werden Tage später aus dem Gedächtnis nachgetragen; ein Einsatz mit
unsicheren Zeiten ist immer noch besser als einer, den niemand erfasst, weil
das Formular ihn nicht angenommen hat.

**Der freigegebene Bericht ist unveränderbar — Lagemeldungen nicht.** Der
Bericht geht an die Gemeinde, die Meldungen sind das Protokoll des Verlaufs.
Eine Meldung aus dem Portal kann eintreffen, wenn der Bericht längst
geschrieben ist; sie nachträglich abzuweisen wäre falsch.

**Das Portal zeigt bewusst wenig.** Stichwort, Ort, Zeitstempel und Meldungen —
also das, was an der Einsatzstelle ohnehin jeder sieht. Keine Namen von
Einsatzkräften, kein Bericht, keine Navigation. Der Link ist ein Fenster auf
einen Einsatz, keine Tür in die Anwendung.

**Koordinaten liegen doppelt.** Als Dezimalgrad, die Prisma lesen kann, und als
PostGIS-Punkt für die Karte ab Phase 6. Ein Trigger hält beides zusammen —
sonst wäre jede Schreiboperation Roh-SQL geworden, und ein über einen anderen
Weg angelegter Einsatz fehlte später auf der Karte.

**Geocoding nur gegen einen eigenen Nominatim.** Einsatzadressen sagen, wo es
gebrannt hat. Solche Anfragen gehören nicht an einen fremden Dienst — und die
Nutzungsbedingungen des öffentlichen Nominatim erlauben es ohnehin nicht.

### Wo es gehakt hat

| Problem | Ursache | Lösung |
|---|---|---|
| Prisma wollte wieder die Suchindizes löschen | wie in Phase 2: gin_trgm und gist kennt das Schema nicht | DROP INDEX-Zeilen aus der erzeugten Migration entfernt, mit Kommentar |
| Der Prisma-Client ließ sich nicht neu erzeugen | die Engine-DLL war vom laufenden Entwicklungsserver gesperrt | Server und Worker beenden, dann erzeugen — unter Windows unvermeidlich |
| Die Anwesenheitsliste blieb leer | sie forderte 300 Mitglieder an, erlaubt sind 200 je Seite | auf 200 gesetzt; aufgefallen in der Server-Ausgabe während der E2E-Tests |
| Zwei E2E-Tests schlugen im Gesamtlauf fehl, einzeln aber nicht | die erste Übersetzung einer Route dauert unter Last länger als das Erwartungslimit | Limit von 15 auf 25 Sekunden — Wartezeit des Entwicklungsservers, kein Fehler der Anwendung |

### Abweichung von der Vorgabe

**Keine.** Alle acht Tabellen tragen `organisationId` und stehen unter Row
Level Security, jede schreibende Operation protokolliert, gelöscht wird weich.

Eine Ergänzung: die Portalprozeduren sind die **ersten öffentlich erreichbaren
Endpunkte** in FLORIAN. Sie prüfen den Token selbst, laufen für die Suche des
Zugangs bewusst ohne Mandantenfilter (begründet im Code) und arbeiten danach im
Mandantenkontext der gefundenen Wehr.

### Offen und bewusst so gelassen

Die Zuordnung der Funktionen zur Stärke ist **regional unterschiedlich**. Hier
zählt der Maschinist zur Mannschaft und nur der Truppführer als Unterführer;
eine Gruppe ergibt damit 1/3/5/9. Andere Wehren rechnen anders. Die Zuordnung
steht an einer Stelle in `lib/einsatz/staerke.ts` und ist leicht zu ändern —
bestätigt ist sie noch nicht.

### Nachweise

- `npm run typecheck` — ohne Ausgabe
- `npm run test` — 207 Tests grün, davon 32 gegen eine echte Datenbank
- `npm run test:e2e` — 95 Tests grün, 2 übersprungen
- `npm run build` — 38 Routen
- `docker compose up -d` — Postgres, Redis, MinIO, Gotenberg gesund

---

## 2026-09-03 · Phase 2 — Wartungs- und Prüfmanagement

**09:55 – 12:20 · 2:25 h · Version 0.3.0**

### Was entstanden ist

Das Modul, wegen dem eine Wehr so ein Programm überhaupt einführt. Ab hier
ersetzt FLORIAN den Ordner mit den Prüfnachweisen.

**Datenmodell.** Elf neue Tabellen: Wartungsvorlage und Checklistenpunkt als
Regel, Wartungstermin als deren Anwendung auf ein einzelnes Gerät, Prüfung mit
Einzelergebnissen und Unterschriften als Nachweis, dazu Mangel, Rückruf mit
betroffener Bauart und je Gerät ein Bearbeitungsstand, und schließlich
Erinnerung als Nachweis und Sperre gegen Doppelversand in einem.

**Fristen-Dashboard.** Vier Töpfe nach Dringlichkeit, jede Zahl gleichzeitig
ein Filter, darunter die Verteilung nach Fahrzeug, Standort, Gerätetyp oder
Zuständigem. Daneben die Lebensdauerüberwachung mit Aussonderungsvorschlag.

**Prüfwizard.** Ein Punkt je Bildschirm, Foto aus der Kamera, Zeiterfassung im
Hintergrund, Unterschrift auf einem Zeichenfeld. Jede Antwort geht sofort zum
Server; ein abgebrochener Durchgang wird beim nächsten Öffnen fortgesetzt.

**Protokoll.** Der Worker rendert über Gotenberg ein PDF mit Kopf, Checkliste,
eingebetteten Fotos und Unterschriften und legt es in MinIO ab. Laufende
Nummer je Wehr und Jahr.

**Nächtlicher Lauf.** Termine planen, Gerätestatus nachziehen, erinnern bei
T-30, T-7, T-0 und einmal bei Überfälligkeit — als Sammelnachricht je
Empfänger.

### Entscheidungen

**Die Unveränderbarkeit sitzt in der Datenbank, nicht im Code.** Ein Trigger
weist jede Änderung an einer abgeschlossenen Prüfung ab, auch für den
Eigentümer-Zugang. Zulässig bleiben drei Dinge, die das Protokoll ergänzen
statt es zu verfälschen: der Wechsel auf „ersetzt", das Nachtragen des PDF,
solange keines hinterlegt ist, und `geaendertAm`. Dasselbe gilt für die
Bestandteile — sonst ließe sich ein festgeschriebenes Protokoll über den Umweg
der Einzelergebnisse verändern.

Der Grund ist derselbe wie beim Audit-Log in Phase 0: ein vergessener
Zustandscheck in einem Router reicht sonst, um den Nachweis wertlos zu machen.

**„Überfällig" wird gerechnet, nicht gespeichert.** Ein gespeicherter Zustand
läuft der Uhr hinterher — ein Termin, der heute Nacht fällig geworden ist,
stünde bis zum nächsten Lauf als „offen" da. Aus demselben Grund kennt
`WartungsterminStatus` nur offen, erledigt und entfallen.

**Pflichtpunkt heißt: davon hängt die Einsatzbereitschaft ab.** Ein
beanstandeter Pflichtpunkt bedeutet „nicht bestanden" und sperrt das Gerät, ein
beanstandeter Kann-Punkt „bestanden mit Mängeln". Damit ist das Ergebnis eine
fachliche Aussage und keine Zählübung. Übersteuern darf der Prüfer trotzdem —
er trägt die Verantwortung, nicht die Software.

**Bestanden hebt eine bestehende Sperre nicht auf.** Wer ein Gerät gesperrt
hat, hatte einen Grund, und der kann außerhalb dieser Prüfung liegen. Von
selbst löst sich nur „Prüfung fällig".

**Melden darf jedes Mitglied.** Der Mangel fällt dem auf, der das Gerät
benutzt. Eine Hürde beim Melden führt dazu, dass gar nicht gemeldet wird — und
ein nicht gemeldeter Riss im Schlauch ist gefährlicher als eine Fehlmeldung,
die jemand wieder verwirft.

**Die Rückrufsuche ist ein Vorschlag.** Seriennummern werden als Text
verglichen; das stimmt bei gleicher Stellenzahl und sonst nicht immer. Eine
automatische Sperre auf dieser Grundlage wäre gefährlicher als hilfreich.

### Wo es gehakt hat

| Problem | Ursache | Lösung |
|---|---|---|
| Prisma wollte die Suchindizes aus Phase 1 löschen | gin_trgm- und gist-Indizes kennt das Schema nicht | die `DROP INDEX`-Zeilen aus der erzeugten Migration entfernt, mit Kommentar für den nächsten, der sie neu erzeugt |
| Der Seed brach beim Beispielprotokoll ab | er legte die Prüfung fertig an, und der Trigger verbot die Ergebnisse dazu | erst Entwurf, dann abschließen — genau wie im Wizard |
| Zwei gleichzeitig abgeschlossene Prüfungen zogen dieselbe Protokollnummer | die Nummer kam aus einer Zählung ohne Sperre | Transaktionssperre je Wehr und Jahr, Nummer aus dem Höchstwert statt aus der Anzahl |
| Der Worker startete außerhalb des Containers nicht | `.env` wurde nicht geladen, und `server-only` wirft unter Node | `dotenv/config` und `--conditions=react-server` in beiden Startbefehlen |
| Der Wizard-Test klickte ins Leere | die Mauskoordinaten beziehen sich auf das Fenster, das Zeichenfeld lag darunter | vor dem Zeichnen ins Bild holen |
| Zwei E2E-Projekte teilten sich denselben Prüfentwurf | Desktop und Tablet laufen parallel unter demselben Benutzer | je Projekt ein eigenes Gerät |

### Abweichung von der Vorgabe

**Keine.** Alle elf Tabellen tragen `organisationId` und stehen unter Row Level
Security, jede schreibende Operation protokolliert, gelöscht wird weich.

Eine Ergänzung zur Regel „Prüfdaten werden nie hart gelöscht": ein
**Prüfentwurf** darf verschwinden. Er ist noch kein Nachweis, sondern ein
abgebrochener Vorgang; ihn aufzuheben würde die Liste der offenen Prüfungen
zumüllen. Ab dem Abschluss greift die Sperre.

### Was aufgefallen ist

Der Navigationseintrag „Protokoll" (`/protokoll`) zeigt seit Phase 1 auf eine
Seite, die es nicht gibt. Das Audit-Log ist über tRPC abrufbar, hat aber keine
Ansicht. Gehört in ein eigenes Issue.

### Nachweise

- `npm run typecheck` — ohne Ausgabe
- `npm run test` — 161 Tests grün, davon 18 gegen eine echte Datenbank
- `npm run test:e2e` — 71 Tests grün, 2 begründet übersprungen (Desktop und Tablet)
- `npm run build` — 30 Routen
- `docker compose up -d` — Postgres, Redis, MinIO, Gotenberg gesund; Worker
  richtet die Zeitpläne ein und erzeugt die Protokoll-PDFs in gut einer Sekunde

---

## 2026-09-03 · Phase 1 — Nachtrag: Geräteformular

**08:30 – 09:20 · 0:50 h**

### Was entstanden ist

Die letzte offene Lücke aus Phase 1: ein Formular zum Anlegen und Bearbeiten
eines einzelnen Geräts. Bis dahin konnte man Geräte nur über den Import
erfassen — für einen Bestand richtig, für den einen nachbeschafften Gerät
umständlich.

| Datei | Inhalt |
|---|---|
| `components/stammdaten/geraet-formular.tsx` | das Formular, geteilt von Anlegen und Bearbeiten |
| `components/stammdaten/geraet-formular-werte.ts` | Typ und Vorgabewerte, bewusst ohne `"use client"` |
| `components/ui/textarea.tsx` | fehlender Baustein |
| `app/(app)/geraete/neu/page.tsx` | Anlegen |
| `app/(app)/geraete/[id]/bearbeiten/page.tsx` | Bearbeiten |
| `tests/e2e/geraet-formular.spec.ts` | 7 Tests |

### Entscheidungen

**Die Lagerung ist ein Umschalter, keine zwei Auswahlfelder.** Standort und
Fahrzeug schließen sich aus. Zwei nebeneinanderstehende Felder laden dazu ein,
beide zu füllen; die Datenbank weist das ab, aber eine Fehlermeldung nach dem
Absenden ist schlechter als ein Formular, in dem der Fehler gar nicht möglich
ist. Beim Wechsel des Fahrzeugs wird der Geräteraum geleert — er gehört zum
Fahrzeug.

**Die Fristen werden schon beim Tippen vorgerechnet.** Wer ein Prüfintervall
einträgt, sieht sofort, wann die nächste Prüfung fällig wird. Gerechnet wird
mit denselben Funktionen wie auf dem Server; beim Speichern rechnet der Server
erneut und behält das letzte Wort. Die Vorschau ist Anzeige, keine Quelle.

**Bei nur einem Standort wird er vorbelegt.** Das ist bei den meisten Wehren
der Fall, und ein Pflichtfeld weniger ist ein Klick weniger.

### Wo es gehakt hat

| Problem | Ursache | Lösung |
|---|---|---|
| Formular stürzte beim ersten Rechnen ab | `LEERES_GERAET` lag im `"use client"`-Modul; eine Server-Komponente bekommt beim Import nur eine Client-Referenz, das Spreaden ergibt `undefined` | Werte in ein eigenes Modul ohne `"use client"` |
| E2E fand die Felder nicht | `getByLabel` vergleicht den Text des `<label>`, nicht den zugänglichen Namen — am Pflichtfeld steht dort ein Sternchen | Tests suchen über die Rolle; das Sternchen bekam zusätzlich `aria-hidden`, weil es sonst vorgelesen wird |
| `fill()` blieb bei Datumsfeldern wirkungslos | Chromium nimmt bei `input[type=date]` keinen gesetzten Wert über `fill()` an | Datum wird getippt, wie es ein Mensch auch täte |
| Zwei Tests scheiterten unter Touch-Emulation | dort öffnet Chromium den Auswähler des Betriebssystems statt Zeichen anzunehmen | begründet übersprungen; die Rechnung selbst deckt der Unit-Test ab |
| Anmeldung im Screenshot-Skript lief ins Zeitlimit | bei kaltem `.next` übersetzt `next dev` die Route erst beim ersten Aufruf | Zeitlimit von 20 auf 90 Sekunden |

### Nachweise

- `npm run typecheck` — ohne Ausgabe
- `npm run test` — 104 Tests grün
- `npm run test:e2e` — 56 grün, 2 begründet übersprungen
- `npm run build` — 19 Routen
- Testgeräte aus dem E2E-Lauf wurden aus der Entwicklungsdatenbank entfernt

---

## 2026-09-03 · Phase 1 — Stammdaten

**07:10 – 08:25 · 1:15 h · Version 0.2.0**

### Was entstanden ist

41 neue Quelldateien, der Umfang wächst von rund 6.100 auf 15.600 Zeilen.

| Bereich | Inhalt |
|---|---|
| Datenmodell | 5 neue Tabellen (Standort, Geraeteraum, Geraetetyp, Qualifikationstyp, Qualifikation), Fahrzeug und Geraet deutlich erweitert, 2 Migrationen |
| Fachlogik | `fristen.ts` (Prüftermine, Lebensdauer, Statusableitung), `qr.ts` und `qr-parser.ts`, `etiketten.ts`, `pdf.ts`, `import.ts` und `import-felder.ts` |
| Server | 8 tRPC-Router mit Liste, Detail, Anlegen, Ändern, Massenbearbeitung und Verlauf |
| Oberfläche | Geräteliste mit Suche und Spaltenauswahl, Gerätedetail mit QR, Fahrzeugliste und -detail mit Beladung, Mitgliederliste, Mitgliedsdetail, Qualifikationen, Import-Assistent, QR-Scanner |
| Daten | Seed erweitert: 3 Standorte, 20 Geräteräume, 14 Gerätetypen, 49 Geräte, 14 Qualifikationstypen, 107 Qualifikationen |
| Tests | 104 Vitest-Tests (vorher 32), 44 Playwright-Tests (vorher 10) |

### Entscheidungen

**Der Gerätetyp ist Vorgabe, das Gerät darf abweichen.** Vierzig Pressluftatmer
haben dasselbe Prüfintervall — das gehört einmal an den Typ und nicht
vierzigmal an das Gerät. Wo der Hersteller für eine Charge etwas anderes
vorschreibt, gewinnt der Wert am Gerät. Umgesetzt in `effektiverWert()`, das
bewusst zwischen `null` und `0` unterscheidet: ein Intervall von 0 ist eine
Angabe, kein fehlender Wert.

**Ein Gerät liegt entweder an einem Standort oder auf einem Fahrzeug.** Beides
gleichzeitig wäre eine Falschangabe, keines von beidem auch. Das steht als
Prüfbedingung in der Datenbank, nicht nur im Formular — und ein Trigger prüft
zusätzlich, dass ein angegebener Geräteraum wirklich zu dem angegebenen
Fahrzeug gehört. Das ließe sich als CHECK nicht ausdrücken.

**Der QR-Code enthält die Inventarnummer, nicht die UUID.** Eine UUID wäre
36 Zeichen lang; der Code bekäme ein feines Muster, und auf einem 38 × 21 mm
großen Etikett im staubigen Geräteraum wird das unzuverlässig. Die
Inventarnummer steht ohnehin lesbar daneben, und wer den Code mit einem
beliebigen Scanner liest, sieht sofort, um welches Gerät es geht.

**Der Import liest die Datei zweimal.** Die Vorschau zeigt, was passieren
würde; beim Übernehmen wird die Datei erneut hochgeladen und serverseitig neu
eingelesen. Es wandert kein einziger Wert aus dem Browser in die Datenbank.
Der Preis ist eine zweite Übertragung — bei den Größen, um die es geht, kein
Thema.

**Der Etikettenbogen kann an beliebiger Position beginnen.** Wer drei Etiketten
braucht, soll nicht einen ganzen Bogen opfern.

### Wo es gehakt hat

| Problem | Ursache | Lösung |
|---|---|---|
| Fristen um einen Tag verschoben | `startOfDay` aus date-fns rechnet in der Zeitzone des Servers; ein DATE aus der Datenbank kommt als UTC-Mitternacht und landete dadurch auf dem Vortag | eigene Kalenderarithmetik auf UTC-Bestandteilen, „heute“ über Europe/Berlin bestimmt |
| `ctx.sitzung` blieb nullbar | `t.middleware()` erzeugt eine Middleware auf dem Wurzelkontext; die Verengung aus der vorigen Middleware ging verloren | Middleware direkt als Funktion an `.use()` übergeben |
| Import-Tests brachen beim Laden ab | `import "server-only"` wirft beim blossen Import, und Vitest ist weder Server noch Browser | im Testlauf durch ein leeres Modul ersetzt (`tests/stubs/server-only.ts`) |
| 15 E2E-Tests im Zeitlimit | `next dev` übersetzt jede Route erst beim ersten Aufruf; zu viele parallele Erstaufrufe | Worker auf 4 begrenzt, Zeitlimit angehoben |
| 5 weitere E2E-Tests rot | `CardTitle` war ein `div` und damit keine Überschrift | in der Komponente auf ein echtes `h3` umgestellt — behebt zugleich einen Zugänglichkeitsmangel |
| Erste Bilder zeigten Ladebalken | „networkidle“ greift zu früh: die Listen holen ihre Daten erst nach, wenn React im Browser gelaufen ist | Screenshot-Skript wartet, bis keine Ladeanzeige mehr im Baum ist |
| Demodaten inkonsistent | die 40 Geräte aus Phase 0 hatten keinen Gerätetyp, und der Seed ist idempotent | Geräte-Zeilen der Entwicklungsdatenbank gezielt geleert und neu eingespielt |

### Abweichung von der Vorgabe

**`prisma migrate reset` wurde nicht ausgeführt.** Der naheliegende Weg, die
Demodaten sauber neu aufzubauen, verlangt eine ausdrückliche Freigabe — Prisma
verweigert den Befehl gegenüber einem KI-Agenten ohne Zustimmung. Statt zu
fragen wurde der schmalere Weg gewählt: nur die Tabelle `geraet` der
Entwicklungsdatenbank geleert und neu eingespielt.

**Kein eigenes Formular zum Anlegen von Geräten.** Die Router können anlegen,
ändern, umlagern und aussondern; die Oberfläche dazu deckt Liste, Detail,
Massenbearbeitung und Import ab. Ein einzelnes Anlegeformular fehlt noch — in
der Praxis kommen Bestände als Tabelle herein, und einzelne Neuzugänge lassen
sich bis dahin über den Import erfassen. Nachzuholen in Phase 2, wo ohnehin
Formulare für Prüfungen entstehen.

### Nachweise

- `npm run typecheck` — ohne Ausgabe
- `npm run test` — 104 Tests grün, davon 8 gegen eine echte Datenbank
- `npm run test:e2e` — 44 Tests grün (Desktop und Tablet)
- `npm run build` — 17 Routen, 103 kB gemeinsames JavaScript
- `npm run screenshots` — 18 Bilder, hell und dunkel
- Keine Konsolenfehler und keine Hydratationswarnungen im Browser

---

## 2026-09-02 / 03 · Phase 0 — Fundament

**23:13 – 00:13 · 1:00 h · Version 0.1.0**

### Was entstanden ist

46 Quelldateien, rund 6.100 Zeilen. Im Einzelnen:

| Bereich | Inhalt |
|---|---|
| Betrieb | `docker-compose.yml` (7 Dienste), Entwicklungs-Override, mehrstufiges Dockerfile, Postgres-Initialisierung, `.env.example` mit Kommentar zu jeder Variable |
| Datenmodell | Prisma-Schema mit 11 Tabellen, 3 Migrationen |
| Kern | `env`, `db`, `authz`, `storage`, `audit`, `auth`, `passwort`, `warteschlange`, 3 Integrationsschnittstellen |
| Server | tRPC v11 mit drei Prozedurarten, Kontext, Wurzel-Router |
| Oberfläche | Layout, Seitenleiste, Anmeldeseite, Übersicht, 5 shadcn-Bausteine, Farbwelt in OKLCH |
| Daten | Seed: 1 Wehr, 9 Rollen, 38 Rechte, 16 Personen, 3 Fahrzeuge, 40 Geräte |
| Tests | 32 Vitest-Tests, 10 Playwright-Tests |
| Doku | README, Anleitung, Roadmap, Aufwandsschätzung, Versionierung, Changelog |

### Entscheidungen

**Zwei Datenbankverbindungen statt einer.** Der erste Entwurf hatte einen
einzigen Prisma-Client. Der ist beim ersten Anmeldeversuch aufgelaufen: die
Anwendung verbindet sich als `florian_app`, für den Row Level Security greift
— und die Anmeldung muss eine E-Mail-Adresse über alle Wehren hinweg suchen,
bevor überhaupt feststeht, zu welcher Wehr sie gehört. Ohne gesetzten
Mandantenkontext liefert RLS null Zeilen, also fand der Login nie jemanden.

Die Lösung ist eine saubere Trennung: `prismaApp` für alle Fachdaten (RLS
aktiv), `prismaSystem` für die wenigen Vorgänge, die vor der
Mandantenauflösung stattfinden. Der Name ist bewusst unbequem, damit auffällt,
wenn ihn jemand im falschen Zusammenhang benutzt.

**Kein FORCE ROW LEVEL SECURITY.** Der Tabelleneigentümer umgeht RLS. Das ist
gewollt: Migrationen und Seed müssen über alle Mandanten hinweg arbeiten
können. Mit `FORCE` wäre der Seed nicht mehr lauffähig gewesen.

**Audit-Log: append-only mit genau einer Ausnahme.** Der erste Trigger hat
`UPDATE` und `DELETE` ausnahmslos gesperrt. Das ist beim Aufräumen der
Testdaten aufgefallen — eine Organisation ließ sich nicht mehr löschen, weil
die Kaskade auf den Audit-Log traf.

Das ist kein Testproblem, sondern ein echtes: nach
`AUDIT_AUFBEWAHRUNG_TAGE` muss der Worker alte Einträge exportieren und dann
entfernen, sonst wächst die Tabelle unbegrenzt und das Löschkonzept nach DSGVO
lässt sich nicht umsetzen. Die zweite Migration führt deshalb einen
ausdrücklichen Schalter ein: `SET LOCAL app.audit_bereinigung = 'an'` erlaubt
`DELETE` für die laufende Transaktion. `UPDATE` bleibt unter allen Umständen
gesperrt — ein Eintrag darf verschwinden, nachdem er gesichert wurde, aber
niemals verfälscht werden.

**Rollen aus authentik nur als Vorbelegung.** Auf Nachfrage entschieden: der
Gruppen-Claim setzt die Rolle beim ersten Login, danach ist die in FLORIAN
gepflegte Rolle führend. Umgesetzt über das Feld `ausOidcGruppe` an
`PersonRolle` und eine Prüfung, die nur bei leerer Rollenliste greift.

**Terminal mit zwei Schranken.** Erst weist sich das Gerät mit
`KIOSK_DEVICE_SECRET` aus, dann die Person mit PIN oder Karte. Eine erratene
sechsstellige PIN nützt ohne das Gerätegeheimnis nichts.

### Wo es gehakt hat

| Problem | Ursache | Lösung |
|---|---|---|
| Postgres startete nicht | `de_DE.UTF-8` gibt es im Debian-Basisimage nicht | ICU-Locale: `--locale-provider=icu --icu-locale=de-DE --locale=C.UTF-8` |
| Init-Skript brach mit Syntaxfehler ab | psql ersetzt seine Variablen nicht innerhalb dollar-quotierter Blöcke | `DO $$`-Block durch `SELECT format(...) \gexec` ersetzt |
| Anmeldung schlug immer fehl | siehe oben: RLS blockierte die E-Mail-Suche | zweite Datenbankverbindung |
| `npm install` ließ Installationsskripte aus | npm 11.17 verlangt eine ausdrückliche Freigabe | `npm approve-scripts` für Prisma, esbuild und drei weitere |
| Aufräumen der Testdaten scheiterte | Audit-Trigger blockierte die Kaskade | Aufbewahrungsschalter (siehe oben) |
| Zwei E2E-Tests rot | Next.js hängt einen eigenen Routen-Ansager mit `role="alert"` in die Seite; `CardTitle` ist ein `div`, keine Überschrift | Fehlermeldung über `data-testid` angesprochen, Anmeldetitel zu einer echten `h1` gemacht |

### Abweichung von der Vorgabe

**`Berechtigung` trägt kein `organisationId`.** Die Architekturregel verlangt
es für jede Tabelle. Diese Tabelle ist aber kein Mandantendatum, sondern der
systemweite Katalog dessen, was die Software überhaupt kann — für alle Wehren
identisch. Mandantenbezogen wird es erst über `RolleBerechtigung`, und die
trägt `organisationId`. Die Tabelle ist für alle lesbar und für die
Anwendungsrolle nicht beschreibbar. Die Ausnahme steht im Schema und in der
Migration kommentiert.

**Phasenzuordnung in der Seitenleiste korrigiert.** Beim Schreiben der Roadmap
ist aufgefallen, dass ich die Module den falschen Phasen zugeordnet hatte
(Atemschutz als Phase 3, Einsätze als Phase 4). Nach `Phase-3.md` bis
`Phase-8.md` gilt: 3 Einsätze, 4 Kiosk, 5 Atemschutz, 6 Karten, 7
Benachrichtigungen, 8 KI. Seitenleiste, Kommentare in `authz.ts` und die
Übersicht sind entsprechend berichtigt.

**Kassenmodul kommt in keiner Phase vor.** Die Rolle `KASSIER` ist gefordert
und angelegt, ein Modul dazu gibt es in `Phase-0.md` bis `Phase-8.md` nicht.
Die Rechte stehen im Katalog, es gibt aber keinen Navigationseintrag. Offene
Entscheidung, siehe [ROADMAP.md](ROADMAP.md).

### Nachweise

- `npm run typecheck` — ohne Ausgabe
- `npm run test` — 32 Tests grün, davon 8 gegen eine echte Datenbank
- `npm run test:e2e` — 10 Tests grün (Desktop und Tablet)
- `npm run build` — 6 Routen, 103 kB gemeinsames JavaScript
- `docker compose up -d` — Postgres, Redis, MinIO, Gotenberg gesund

---

## Vorlage für neue Einträge

```markdown
## JJJJ-MM-TT · Phase N — Titel

**HH:MM – HH:MM · X:XX h · Version 0.N.0**

### Was entstanden ist
### Entscheidungen
### Wo es gehakt hat
### Abweichung von der Vorgabe
### Nachweise
```