FireAdministration/CHANGELOG.md

Changelog

Alle nennenswerten Änderungen an FLORIAN. Format nach Keep a Changelog, Versionierung nach Semantic Versioning.

Die Regeln dazu stehen in docs/VERSIONIERUNG.md.

[Unveröffentlicht]

Nächster Schritt ist Phase 9 (Kassenverwaltung).

---

[0.9.0] — 2026-09-04

Phase 8: Lokale KI. Ein Wiki mit semantischer Suche, Diktat, Berichtsassistent und Belegerfassung — alles gegen selbst betriebene Modelle.

Nichts, was ein Modell erzeugt, gelangt ungeprüft in einen Nachweis. Jede KI-Ausgabe ist zuerst ein eigener Datensatz und nicht ein Feld im Zieldokument. Sie ist gekennzeichnet, sie steht daneben statt mittendrin, und sie braucht zwei gleich große Knöpfe, bevor etwas mit ihr geschieht.

Es läuft alles im Haus. Ollama und faster-whisper als Container daneben, kein Anbieter, kein Schlüssel. Es gibt keinen Rückfall auf einen Cloud-Dienst: fehlen die Container, fehlt die Funktion.

Hinzugefügt

Datenmodell

• KiVorgang — jede Befragung eines Modells mit Eingabe, Ausgabe, Modell, Dauer und der Entscheidung darüber. Auch Fehlschläge: ein Modell, das dreimal am Tag in eine Zeitüberschreitung läuft, ist eine Information.
• Wikiseite, Wikiabschnitt (mit vector(768)) und Wikiversion.
• Diktat mit Aufnahme in MinIO, Belegentwurf mit allen Feldern optional — ein Modell, das den Betrag nicht findet, soll nichts erfinden.

Postgres mit pgvector

• Eigenes Image (docker/postgres/Dockerfile), weil FLORIAN PostGIS und pgvector braucht und es kein offizielles Image mit beidem gibt.
• HNSW-Index statt IVFFlat: IVFFlat muss auf gefülltem Bestand trainiert werden, HNSW ist ab der ersten Zeile brauchbar. Ein Wiki wächst Seite für Seite — es gibt nie den Moment, an dem man den Index einmal aufbaut.

Wiki

• Markdown, selbst gerendert ohne HTML: der Text kommt von Anwendern, und jeder Weg über dangerouslySetInnerHTML wäre ein Weg für ein <script> in einer Dienstvorschrift.
• Zwei Suchen: Wortsuche (immer, mit Textstelle) und Frage ans Modell (semantisch, mit Fundstellen). Steht die Antwort nicht in den Unterlagen, sagt FLORIAN das — ohne passende Auszüge wird gar nicht erst gefragt.
• Zerlegt wird an den Überschriften, mit der Überschriftenkette im Einbettungstext: ein Abschnitt über „Rückzugsdruck" ohne das Wort „Atemschutz" darüber findet sich sonst nicht.
• Jede Änderung schreibt die vorherige Fassung weg.

Diktat, Bericht, Beleg

• Aufnahme im Browser, Erkennung über faster-whisper im Hintergrund. Die Aufnahme bleibt, solange nicht entschieden ist — sie ist das einzige Original.
• Berichtsentwurf aus Stichpunkten. Zeitstempel und Einsatznummer bekommt das Modell nicht: sie stehen schon als Felder im Bericht.
• Belegerfassung mit Vision-Modell. Nicht erkannte Felder bleiben leer und gelb hinterlegt statt geraten zu werden.

Zwei Protokolle

• /ki-protokoll — was die Maschine getan hat, mit Kennzahlen und aufklappbarer Eingabe/Ausgabe.
• /protokoll — das Audit-Log. Wird seit Phase 0 geschrieben; die Ansicht dazu kam jetzt, weil beides nebeneinander gehört: was hat ein Mensch getan, was die Maschine.

Geändert

• lib/integrations/llm.ts kann jetzt drei Dinge statt einem: Text, Einbettungen und Bilder — mit je eigenem Modell, weil ein Rechner ohne Grafikkarte das Einbettungsmodell noch schafft und das Vision-Modell nicht.
• Der Datei-Upload nimmt Tonaufnahmen an (webm, ogg, mp4, wav).
• Neue Rechte: wiki.lesen als Grundrecht (eine Wehr, in der nur die Führung nachschlagen darf, hat kein Wiki, sondern einen Aktenschrank), wiki.bearbeiten, ki.nutzen, ki.protokoll, beleg.erfassen.
• Der Aufbewahrungslauf zieht nebenbei Wiki-Seiten nach, deren Suchstand veraltet ist.

Behoben

• Beim Zerlegen einer Wiki-Seite wurde ein kurzer Abschnitt an den vorherigen gehängt, auch wenn er unter einer anderen Überschrift stand. Unter einer Antwort hätte dann eine Fundstelle gestanden, in der der zitierte Satz gar nicht vorkommt. Gefunden hat es der Test, nicht das Ausprobieren.

Sicherheit

• Row Level Security für die sechs neuen Tabellen — auch für die Vektorsuche: ein perfekt passender Abschnitt einer fremden Wehr taucht nicht auf.
• Eingabe, Ausgabe, Modell und Art eines KI-Vorgangs sind nach dem Anlegen unveränderlich (Trigger). Über einen Vorschlag wird genau einmal entschieden. REVOKE DELETE ON "ki_vorgang".
• REVOKE UPDATE, DELETE ON "wikiversion": eine Dienstvorschrift, deren Vorgeschichte sich bereinigen lässt, ist als Nachweis wertlos.
• Prüfbedingungen: keine Entscheidung ohne Zeitpunkt, kein Fehlschlag ohne Grund, kein negativer Betrag auf einer Quittung.

Tests

• 73 neue Unit-Tests: Zerlegen einer Seite (Überschriftenketten, Codeblöcke, Teilung an Absatzgrenzen), Auswerten einer Modellantwort auf ein Belegfoto (deutsche Zahlen, Tausenderpunkt, unmögliche Daten), die Anweisungen an das Modell und die Datenbankregeln samt Vektorsuche über Mandanten hinweg.
• 14 neue E2E-Tests, die ohne laufendes Modell prüfen, dass alles andere vollständig benutzbar bleibt und ehrlich sagt, was fehlt.

---

[0.8.0] — 2026-09-04

Phase 7: Benachrichtigungen und Termine. Ab hier weiß die Mannschaft, wann der nächste Dienst ist — ohne dass jemand eine Rundmail tippt.

Niemand wird ungefragt benachrichtigt. Wer nichts einträgt, bekommt nichts. Es gibt keine Voreinstellung, die stillschweigend alle anmeldet: ein neu eingerichteter Zustellweg hat eine leere Ereignisliste, und erst wer ankreuzt, wofür er ihn will, bekommt etwas.

Hinzugefügt

Datenmodell

• Termin mit Art, Ort, Beginn und Ende, Leitung, Platzbegrenzung, Anmeldeschluss und Serienkennung. Abgesagt wird mit Grund und Zeitpunkt — gelöscht wird nicht, wer zugesagt hat, soll den Grund sehen.
• Terminanmeldung mit Zu-, Absage oder Warteliste, dem Grund einer Absage und der Anwesenheit als eigenem Feld. Zusage und Anwesenheit sind bewusst getrennt: wer zugesagt hat und nicht kam, steht genau so in der Liste.
• Zustellkanal — ein Datensatz je Person und Weg, mit der Adresse dieses Wegs und der Liste der Ereignisse, für die er benutzt wird. Leer bedeutet: für nichts.
• Benachrichtigung — steht vor dem Versand in der Tabelle, nicht danach. Damit ist nachvollziehbar, wer wann worüber informiert wurde und wer nicht, weil sein Kanal nicht erreichbar war.
• Benachrichtigungsvorlage je Ereignis und Kanal, Kalenderzugang mit SHA-256 des Tokens.

Terminkalender

• Liste mit Filter nach Art und „nur meine", Rückmeldung direkt aus der Zeile.
• Serientermine werden ausgeschrieben, nicht als Regel gespeichert: jeder Abend ist ein eigener Datensatz. Sonst wäre jeder ausgefallene Übungsabend ein Sonderfall. Vor dem Anlegen steht in der Maske, wie viele Termine daraus werden.
• Kalenderrechnung statt Millisekunden: „monatlich" heißt derselbe Tag im nächsten Monat, und der 31. Januar landet im Februar auf dem 28. — nicht im März, wie es passiert, wenn man stur Monate addiert.
• Warteliste, die von selbst nachrückt. Wer bei belegten Plätzen zusagt, landet auf ihr; sagt jemand ab, rückt der Erste nach und erfährt es.
• Absage mit Grund, wahlweise für alle folgenden Termine einer Serie. Vergangene bleiben unberührt. Benachrichtigt werden die Angemeldeten, nicht die ganze Wehr.
• Anwesenheitsliste über alle aktiven Mitglieder, nicht nur die Angemeldeten — auf einem Blatt zum Abhaken muss jeder stehen. Zum Abhaken am Tablet oder zum Ausdrucken.

Kalenderabonnement

• ICS-Feed nach RFC 5545 unter /api/kalender/<token>.ics. Die Termine der Wehr stehen damit im Handy neben allem anderen.
• Bewusst kein CalDAV: das ist ein Schreib-Lese-Protokoll mit Rechteverwaltung und Konfliktauflösung. Gebraucht wird nur Lesen.
• Die Adresse steht genau einmal auf dem Bildschirm; gespeichert wird nur ihr Hash. Jeder Zugang lässt sich einzeln widerrufen, und wer austritt, verliert ihn.
• Ausgeliefert werden nur Termine — keine Anmeldelisten, keine Personen außer der Leitung.

Vier Zustellwege, hinter Schnittstellen

• SMTP löst den Platzhalter aus Phase 0 ab: nodemailer mit Verbindungspool, damit ein Sammellauf mit vierzig Nachrichten Sekunden statt Minuten braucht.
• ntfy (neu, selbst gehostet, Compose-Profil push): Push aufs Handy ohne Konto, ohne Telefonnummer, ohne Telefonbuchabgleich. Läuft der Server im Gerätehaus, verlässt keine Nachricht das Haus.
• Web-Push (neu, VAPID): Push in den Browser ohne App. Schlüsselpaar über npm run vapid.
• Telegram aus Phase 0 wird jetzt tatsächlich benutzt.
• Was das Netz der Wehr verlässt (Telegram, Web-Push), bekommt nur die Kurzfassung — „3 Prüfungen fällig", nicht welche. In der Oberfläche steht das neben jedem externen Kanal.

Textvorlagen

• Je Ereignis und Kanal, mit eingebautem Standardtext für alles. Eine Wehr, die nichts einstellt, bekommt trotzdem brauchbare Nachrichten.
• Platzhalter zum Anklicken, Vorschau mit erfundenen Beispielwerten. Ein Platzhalter, den es für das Ereignis nicht gibt, wird beim Speichern abgewiesen — mit der Liste der erlaubten daneben.
• Ein unbekannter Platzhalter bleibt im Text sichtbar stehen, statt still zu verschwinden. Eine Lücke, die niemand bemerkt, ist schlimmer als ein seltsam aussehender Text, den jemand korrigiert.

Digitaler Dienstausweis

• QR-Code auf dem Handy, Prüfseite ohne Anmeldung unter /ausweis/<code>. Sie zeigt Name, Wehr, Funktion, Foto und die gültigen Qualifikationen.
• Signiert statt gespeichert (HMAC über Person, Wehr und Zeitstempel), fünf Minuten gültig. Die Prüfseite nennt den Zeitpunkt der Ausstellung — ein Ausweis, der „gültig" sagt, ohne zu sagen seit wann, ist wertlos.
• Der Zweck steht im signierten Teil, damit ein Ausweis nicht als Anmeldemarke aus Phase 4 durchgeht und umgekehrt.
• Ein gültig signierter Code für jemanden, der ausgetreten ist, wird abgewiesen. Das Passbild ist über denselben Code erreichbar und damit genauso lange gültig.

Was von selbst benachrichtigt

• Prüfung fällig, Mangel gemeldet, Qualifikation läuft ab (90/30/7 Tage vorher), neuer Termin, Terminerinnerung (7 und 1 Tag vorher), Einsatzbericht freigegeben.
• Anlegen und Zustellen sind getrennt. Wo ein Ereignis entsteht, wird nur eine Zeile geschrieben; der Worker schickt sie weg. Sonst hinge das Speichern eines Termins am Antwortverhalten von Telegram.
• Erinnert wird um sieben Uhr morgens, zugestellt jede Minute: eine Push-Meldung um drei Uhr weckt Leute, die am nächsten Tag arbeiten müssen — eine Absage am Dienstagabend muss dagegen ankommen, solange sie noch etwas nützt.
• Die Sammelmail an den zuständigen Gerätewart bleibt, wie sie war. Wer sie ohnehin bekommt, wird von der zusätzlichen Benachrichtigung ausgenommen und hat sie damit nicht doppelt.

Geändert

• lib/integrations/mail.ts verschickt tatsächlich, statt eine Meldung ins Log zu schreiben. Ohne MAIL_ENABLED bleibt es beim Log.
• Neue Rechte: termin.lesen und benachrichtigung.eigene als Grundrechte (jeder sieht den Kalender und richtet seine eigenen Wege ein — das ist keine Sache des Kommandanten), termin.bearbeiten, termin.anwesenheit und benachrichtigung.vorlagen bei Kommandant, Schriftführer und Ausbilder.
• DIENSTGRAD_TEXT liegt jetzt in lib/stammdaten/texte.ts statt zweimal fast gleich in zwei Seiten.
• Der Service Worker nimmt Push-Meldungen an und öffnet beim Antippen ein schon offenes FLORIAN, statt einen zwölften Tab aufzumachen.
• Der Aufbewahrungslauf räumt zugestellte Benachrichtigungen nach Frist ab. Fehlgeschlagene bleiben — sie zeigen einen kaputten Kanal an, und das verliert seinen Wert nicht durch Zeitablauf.

Behoben

• Die Vorlagenmaske überschrieb den gerade getippten Text, sobald die Liste im Hintergrund nachgeladen wurde (nach dem Speichern, beim Zurückkommen ins Fenster). Gefunden hat es der E2E-Test, nicht das Ausprobieren.

Sicherheit

• Row Level Security und Mandantenfilter für alle sechs neuen Tabellen.
• REVOKE DELETE ON "benachrichtigung" für die Anwendungsrolle: wer wann worüber informiert wurde, lässt sich nicht über die Oberfläche wegräumen. Die Aufbewahrungsfrist läuft über den Systemzugang.
• Prüfbedingungen in der Datenbank: kein Ende vor dem Beginn, kein Anmeldeschluss nach dem Termin, kein Kontingent von null Plätzen, keine negative Versuchszahl.
• Kalendertoken nur als SHA-256; ein Push-Abo, das der Dienst als tot meldet, wird stillgelegt statt gelöscht, damit die Person es in ihren Einstellungen sieht und neu erlauben kann.
• Kein WhatsApp — Begründung im README unter „Warum kein WhatsApp": Verarbeitung über Meta-Server, Kosten je Konversation, Telefonbuchabgleich.

Tests

• 56 neue Unit-Tests: Serienrechnung (Monatsenden, Schaltjahr, Kappung), ICS-Erzeugung (Maskierung, Zeilenumbruch nach 75 Oktetten, CRLF, Absage), Textbausteine (Kurzfassung für externe Kanäle, unbekannte Platzhalter), Dienstausweis (Frist, Fälschung, Verwechslung mit der Anmeldemarke) und die Datenbankregeln der neuen Tabellen.
• 17 neue E2E-Tests für Kalender, Rückmeldung, Warteliste, Absage, Anwesenheitsliste, Kalenderabonnement, Vorlagen und Prüfseite.

---

[0.7.0] — 2026-09-04

Phase 6: Kartenmodule. Ab hier weiß die Wehr auf der Anfahrt, wo der nächste Hydrant liegt und was er hergibt.

Keine Kacheln aus dem Netz. Wo eine Wehr ausrückt, wo ihre Hydranten liegen und welche Objekte sie im Blick hat, ist niemandes Geschäft. Der Kartenserver läuft selbst (tileserver-gl im Compose-Profil karte); ohne ihn zeigt die Karte einen leeren Grund und sagt das auch — Punkte, Entfernungen und Umkreissuche funktionieren trotzdem.

Hinzugefügt

Datenmodell

• Hydrant mit Typ (Unterflur, Überflur, Saugstelle, Zisterne, offenes Gewässer), Nennweite, Durchfluss, Zustand, letzter Prüfung und Hinweis für das, was man vor Ort wissen muss.
• Objekt mit Kategorie, Zufahrt, Gefahren und Schlüsseldepot als eigene Felder — im Einsatz sucht niemand in einem Absatz. Dazu Objektkontakt (mit „jederzeit erreichbar") und Objektplan (DIN 14095).
• Lagekarte und Lageelement — eine Karte je Einsatz, jedes Element mit Geometrie, Zeichen und Urheber.
• Wasserfoerderung und Foerderpunkt — die Eingaben einer Förderstrecke. Das Ergebnis wird nicht gespeichert, sondern bei jeder Anzeige neu gerechnet.
• Standorte haben jetzt Dezimalgrade neben dem PostGIS-Punkt und liegen damit auf der Karte.

Karte

• MapLibre GL aus dem eigenen Paketstand, Kacheln aus dem eigenen tileserver-gl. Kein Skript, kein Stylesheet, kein Bild von einem fremden Server.
• Hydranten und Objekte als getrennt schaltbare Ebenen, Filter nach Art und Zustand, Suche über Straße, Nummer, Objektname und Gefahrenstichwort.
• Umkreissuche über PostGIS: ST_DWithin auf der Geografie mit GiST-Index — in die Karte tippen, und es steht da, was in 500 Metern erreichbar ist, nach Entfernung sortiert.

Import

• GeoJSON und Tabellen der Stadtwerke. Spaltennamen werden erkannt („DN", „Lage", „Latitude", „Pruefdatum"), deutsche Kommazahlen und Datumsangaben ebenso, vertauschte Achsen werden erkannt und zurückgedreht.
• Zwei Schritte wie beim Geräteimport aus Phase 1: erst zeigen, was herauskäme, dann übernehmen. Übersprungene Zeilen stehen mit Zeilennummer und Grund da.
• Wiederholbar: Hydranten mit einer Nummer des Versorgers werden aktualisiert statt doppelt angelegt.

Objekte und Feuerwehrpläne

• Zufahrt, Gefahren, Schlüsseldepot und Löschwasser am Objekt stehen ganz oben — in dieser Reihenfolge werden sie auf der Anfahrt gelesen.
• Ansprechpartner mit Telefonnummern zum Antippen und der Angabe, wer nachts ans Telefon geht.
• Planblätter nach DIN 14095 mit Art und Stand. Ein Plan von 2009 ist eine Vermutung, und das steht dran.

Lagekarte

• 22 taktische Zeichen nach FwDV 102, selbst gezeichnet als SVG in lib/karte/taktische-zeichen.ts: Fahrzeuge, Einheiten, Führung, Stellen, Gefahren, Maßnahmen.
• Zeichen setzen, Linien ziehen, Flächen aufziehen, beschriften — ein Werkzeug, ein Klick.
• Abgleich zwischen Geräten über denselben Ereignisstrom wie die Atemschutzüberwachung aus Phase 5; der Zustand der Verbindung steht sichtbar da.
• Zurücknehmen statt löschen: was um 14:12 eingezeichnet wurde, gehört zur Mitschrift.

Wasserförderung

• Strecke in die Karte tippen, Durchmesser und Fördermenge einstellen — die Rechnung läuft mit: Reibungsverlust, Höhenunterschied, Zahl der Verstärkerpumpen, Schlauchlängen je Abschnitt.
• Gerechnet wird im Browser und auf dem Server mit demselben Code.
• Reicht ein Abschnitt selbst mit voller Pumpe nicht, sagt die Ausgabe das, statt eine Zahl auszuwerfen, die niemand halten kann.
• Unter jeder Rechnung steht, dass sie eine Planungshilfe ist — was zählt, ist der Druck am Verteiler.

Dateien abrufen

• /api/dateien/[id] liefert eine abgelegte Datei aus, mandantengebunden und mit Eintrag im Protokoll. Bis Phase 6 gab es nur den Upload und eigene Endpunkte je Dokumentart.

Sonstiges

• Der Seed legt 24 Löschwasserstellen an — mit Weiher, Zisterne und Saugstelle im Außenbereich, zwei defekten und zwei ungeprüften — sowie drei Objekte mit Ansprechpartnern: Schule, Pflegeheim, Aussiedlerhof.
• 59 neue Tests: 48 Unit-Tests zu Druckverlust, Förderplan und Import, 11 Playwright-Durchläufe je Browser.

Geändert

• Der Koordinaten-Trigger aus Phase 3 ist jetzt allgemein: eine Funktion für jede Tabelle mit Breiten- und Längengrad. Sie hängt an Standort, Hydrant und Objekt.
• Der Ereignisstrom-Hook aus Phase 5 nimmt jetzt eine Adresse entgegen und wird von Lagekarte und Atemschutzüberwachung gemeinsam benutzt. Zwei Ströme mit unterschiedlichem Verhalten wären ein Ort mehr, an dem sich ein Fehler verstecken kann.

---

[0.6.0] — 2026-09-03

Phase 5: Atemschutzüberwachung nach FwDV 7. Das sicherheitsrelevanteste Modul des Projekts — und deshalb das mit dem höchsten Testanteil.

Über jeder Ansicht steht: Ergänzendes System — die analoge Atemschutzüberwachung bleibt führend. Der Hinweis lässt sich nur abschalten, wenn zusätzlich die Fundstelle einer Freigabe des Kommandanten hinterlegt ist; ohne sie bleibt er stehen.

Hinzugefügt

Datenmodell

• Atemschutzeinsatz — eine Überwachung mit Überwacher, Abfrageintervall, Warndruck und Sicherheitszuschlag. Hängt an einem Einsatz oder einer Übung, kann aber auch für sich stehen: im Ernstfall wird zuerst überwacht und später zugeordnet.
• Atemschutztrupp mit Status (bereit, im Einsatz, Rückweg, draußen), den Zeitstempeln dazu, dem errechneten Rückzugsdruck und dem Notfallzeitpunkt.
• Truppmitglied — zwei oder drei Personen je Trupp, genau eine davon Truppführer, optional mit dem verwendeten Pressluftatmer.
• Druckmessung mit Art (Eingang, Einsatzziel, Zwischenmeldung, Ausgang).
• AtemschutzEreignis — jede Zeile des Protokolls mit Zeitpunkt.
• G26Untersuchung und Belastungsuebung als eigene Nachweise.

Die Zeit gehört dem Server

• Nirgends wird eine Restzeit heruntergezählt. Jede Dauer entsteht aus zwei Zeitstempeln — einem aus der Datenbank und der aktuellen Uhr. Deshalb übersteht die Anzeige ein Neuladen, einen zweiten Bildschirm und einen Verbindungsabbruch: es gibt nichts, das dabei verloren gehen könnte.
• Server und Browser rechnen mit denselben Funktionen aus lib/atemschutz/berechnung.ts. Was das Tablet anzeigt, weist das Protokoll später genauso aus.

Rückzugsdruck nach dem doppelten Anmarschverbrauch

• Der Trupp meldet beim Erreichen des Einsatzziels einmal seinen Druck. Daraus: 2 × Anmarschverbrauch + Ansprechdruck der Warneinrichtung + Zuschlag.
• Solange keine Zielmeldung vorliegt, greift die Zwei-Drittel-Regel — sie liegt höher und ist damit die vorsichtigere Annahme.
• Maßgeblich ist immer der ungünstigste Wert im Trupp: der Trupp geht gemeinsam zurück.
• Ampel in drei Stufen mit Klartext daneben, Gelb schon zehn Prozent über der Grenze. Bei Notfall zusätzlich ein erzeugter Ton — ausdrücklich eine Zugabe.

Überwachungsschirm

• Trupp anlegen mit Eingangsdruck je Person; daneben steht, ob die Person nach FwDV 7 überhaupt einsetzbar ist. Gesperrt wird nichts — im Einsatz entscheidet der Einheitsführer, und ein Programm, das ihm im entscheidenden Moment eine Person verweigert, wird umgangen.
• Druckabfrage für den ganzen Trupp in einer Zeile, Erinnerung im konfigurierbaren Intervall (Vorgabe zehn Minuten).
• Mayday je Trupp, ausdrücklich aufzuheben statt wegzuklicken.
• Rückzug anordnen, Statuswechsel, Notizen ins Protokoll.
• Die Überwachung lässt sich erst beenden, wenn alle Trupps als draußen gemeldet sind.

Ereignisstrom über Server-Sent Events

• Ein Route Handler unter /api/atemschutz/strom meldet Änderungen; der Browser holt daraufhin den Stand. Kein eigener Server nötig, EventSource verbindet nach einem Abbruch von selbst neu.
• Der Zustand der Verbindung steht sichtbar auf dem Schirm. Bleibt das Lebenszeichen des Servers aus, gilt die Verbindung nach acht Sekunden als tot — auch wenn der Browser keinen Fehler meldet.
• Fällt der Strom ganz aus, bleibt die Ansicht bedienbar: sie fragt zusätzlich im festen Takt nach.

Protokoll

• Lückenloses PDF mit Rahmen, Trupps und dem Verlauf aus Ereignissen und Druckmessungen in einer gemeinsamen Zeitachse.
• Entsteht beim Beenden im Hintergrundprozess und bei Bedarf beim Abruf — ein Nachweis, den man nicht bekommt, weil ein Dienst einen schlechten Tag hatte, wäre keiner.
• Im Kopf steht, ob die digitale Überwachung freigegeben war. Wer das Blatt später liest, soll wissen, was er in der Hand hält.

Tauglichkeit nach FwDV 7

• Drei Nachweise, die gleichzeitig gelten müssen: gültige G26.3, Belastungsübung im laufenden Jahr, Einsatzübung im laufenden Jahr. Ein Einsatz unter Atemschutz ersetzt die Einsatzübung.
• Ampel mit Klartext, was fehlt — eine rote Ampel ohne Begründung hilft am Fahrzeug niemandem.
• Fristvorschlag für die G26 nach Alter: drei Jahre, ab fünfzig eines.
• Nachweise pflegen: G26 je Person, Belastungsübung für die ganze Gruppe auf einmal.
• Kachel auf der Startseite: wie viele Träger heute einsetzbar sind und wie viele davon knapp davor stehen, es nicht mehr zu sein.

Sonstiges

• Der Seed legt acht G26-Untersuchungen an — darunter eine abgelaufene und eine bald ablaufende —, zwölf Übungsnachweise und eine vollständig durchgespielte Überwachung mit zwei Trupps.
• 68 neue Tests: 51 Unit-Tests zu Rückzugsdruck, Ampel, Restzeit, Statusfolge und Tauglichkeit, 17 gegen eine echte Datenbank und 8 Playwright-Durchläufe je Browser — darunter die beiden, um die es in dieser Phase geht: die Uhr nach einem Neuladen und bei abgerissenem Ereignisstrom.

Geändert

• Die Datenbank verweigert dem Anwendungszugang UPDATE und DELETE auf druckmessung und atemschutz_ereignis; zusätzlich sitzt auf beiden ein Trigger. Ein Fehler wird durch einen neuen Eintrag richtiggestellt, nicht durch Ändern — sonst wäre jede Aufzeichnung nachträglich glättbar.
• Neue Bedingungen: Druck zwischen 0 und 400 bar, kein Rückzug vor dem Einstieg, kein Ende vor dem Beginn, genau ein Truppführer je Trupp.
• Die Startseite stand noch auf dem Stand von Phase 1 („Als Nächstes kommt das Prüfmanagement"). Sie nennt jetzt den tatsächlichen Ausbaustand.
• Der Navigationseintrag „Protokoll" führte auf eine Seite, die es nicht gibt. Die Ansicht des Audit-Logs gehört zum Löschkonzept in Phase 8; bis dahin steht der Eintrag ausgegraut da statt ins Leere zu führen.

---

[0.5.0] — 2026-09-03

Phase 4: das Terminal im Gerätehaus. Ein Wandtablet, das mit Handschuhen bedienbar ist und weiterarbeitet, wenn das Netz weg ist.

Hinzugefügt

Datenmodell

• Fahrt — Fahrtenbuch je Fahrzeug: Fahrer, Zweck, Ziel, Kilometerstand bei Abfahrt und Rückkehr, getankte Menge. Eine Fahrt ohne Rückkehr ist die laufende Fahrt.
• Anwesenheit — wer im Gerätehaus ist, mit Anlass (Dienst, Übung, Einsatz, Arbeitsdienst) und offener Abmeldung, solange jemand da ist.
• Waescheabgabe — Schutzkleidung in der Reinigung, mit Grund und Stand von „abgegeben" bis „zurück".
• Inventurgang und Inventurposten — der Gerätewart geht mit dem Tablet durch die Halle und scannt; am Ende steht die Liste dessen, was fehlt.
• KioskVorgang — jeder vom Terminal übermittelte Vorgang, mit der im Browser erzeugten Kennung als Primärschlüssel. Das ist der Kern des Offline-Betriebs: kommt derselbe Vorgang nach einem abgebrochenen Sendeversuch ein zweites Mal an, wird er wiedererkannt statt neu angelegt.
• SyncKonflikt — was sich beim Nachtragen nicht anwenden ließ. Nichts geht verloren, es wartet auf eine Entscheidung.

Terminaloberfläche unter /kiosk

• Kachelschirm: sieben Kacheln, jede mindestens 160 Pixel hoch, jede mit Symbol und Text, sichtbar nach Rechten. Keine Navigationsleiste.
• Anmeldung auf drei Wegen: Ausweis auflegen (der RFID-Leser tippt die Kennung als Tastatureingabe, erkannt am Anschlagstempo), QR-Code vom Handy oder Mitgliedsnummer samt PIN.
• Mangel melden in drei Schritten — Gerät scannen, Foto und ein Satz dazu, Dringlichkeit antippen. Anspruch war „unter dreißig Sekunden".
• Kommen und Gehen mit zwei Tipps, Fahrtenbuch, Wäscheabgabe und Inventurgang.
• Abmeldeuhr: nach KIOSK_IDLE_TIMEOUT Sekunden Untätigkeit meldet sich das Terminal von selbst ab, mit sichtbarer Warnung vorher.
• Hallenmonitor unter /kiosk/monitor: Uhrzeit, laufender Einsatz, wer im Haus ist, Fahrzeuge, fällige Prüfungen und die nächsten Termine — Vollbild ohne Bedienung.

Offline-Betrieb

• Ein von Hand geschriebener Service Worker (public/sw.js): App-Shell und Stammdaten im Zwischenspeicher, network-first für Seiten mit Ausweichseite /kiosk/offline, stale-while-revalidate für lesende tRPC-Aufrufe. Schreibende Anfragen und alles unter /api/auth fasst er nicht an — eine zwischengespeicherte Anmeldung wäre eine Sicherheitslücke.
• Warteschlange in einer IndexedDB (Dexie): jede schreibende Aktion geht zuerst dorthin, auch online. Sonst gäbe es zwei Wege durch den Code, und der seltenere wäre der ungetestete.
• Fotos liegen als Blob in derselben Warteschlange und werden beim Übertragen zuerst hochgeladen.
• Sichtbarer Zustand als Leiste über allem: verbunden, wie viele Änderungen warten, kein Netz — in Klartext, nicht nur als Farbe.
• Erledigt heißt: angenommen oder als bereits verarbeitet erkannt oder in der Konfliktliste gelandet. In allen drei Fällen ist der Vorgang beim Server und darf aus der Warteschlange verschwinden.

Anmeldemarke

• /anmeldemarke zeigt einen QR-Code fürs Handy: signiert mit AUTH_SECRET, gültig 60 Sekunden, nicht gespeichert. Ein abfotografierter Code aus der Umkleide nützt nach einer Minute nichts mehr.

Terminalübersicht in der Verwaltung

• /terminal zeigt Konflikte zuerst — das sind die Vorgänge, die ein Mensch anfassen muss —, danach Anwesende, Wäsche und Fahrtenbuch.

Installierbar als App

• Web-App-Manifest, eigene Symbole (npm run icons), Startseite /kiosk. Kein externes CDN, keine fremde Schriftart.

Wetterwarnungen (optional, aus)

• Warnungen des DWD auf dem Hallenmonitor, hinter einer Schnittstelle in lib/integrations/. Standardmäßig aus — es ist die einzige Verbindung, die FLORIAN von sich aus nach außen aufbaut. Fällt sie aus, bleibt die Kachel leer.

Sonstiges

• Der Seed legt ein Fahrtenbuch mit vier Fahrten (eine läuft noch), vier Anwesenheiten (eine Person ist noch im Haus) und drei Wäscheabgaben an.
• 31 neue Tests: 20 Unit-Tests zu Anmeldemarke und Warteschlange (letztere unter jsdom mit fake-indexeddb), 11 gegen eine echte Datenbank (Kilometerstände, Anwesenheitszeiten, Unveränderbarkeit der Vorgänge, Mandantentrennung) und 9 Playwright-Durchläufe je Browser — darunter der Offline-Fall mit context.setOffline(true) und der doppelt gesendete Vorgang, dessen Antwort unterwegs verloren geht.

Geändert

• Die Datenbank setzt vier neue Regeln selbst durch: Kilometerstände laufen vorwärts, eine Rückkehr liegt nicht vor der Abfahrt, ein Gehen nicht vor dem Kommen, eine Wäscheabgabe umfasst mindestens ein Stück. Dazu REVOKE UPDATE, DELETE auf kiosk_vorgang — ein übermittelter Vorgang lässt sich nicht nachträglich glätten.
• Die Beschriftung der DWD-Warnstufen liegt in src/lib/integrations/wetter-texte.ts, getrennt vom server-only-Modul daneben — dieselbe Trennung wie bei qr.ts und qr-parser.ts.
• Neue Rechte fahrtenbuch.lesen und fahrtenbuch.fuehren, beide im Grundrechtebündel.

Behoben

• Die Warteschlange rief sich selbst in eine Renderschleife: jetztSenden hatte das Mutationsobjekt von React Query in seinen Abhängigkeiten, und das ist bei jedem Rendern ein neues. Damit wurde der 20-Sekunden-Zeitgeber ständig neu aufgezogen und lief nie ab — ein liegen gebliebener Vorgang wäre ohne Zutun nie ein zweites Mal losgeschickt worden. Gefunden vom Offline-E2E-Test, der genau darauf wartet.
• /kiosk/einrichten ließ sich nicht vorab erzeugen, weil useSearchParams() ohne Suspense-Grenze stand. Der Produktionsbuild brach dabei ab.
• Der Anwesenheits- und der Fahrten-Wizard zeigten erst die eine, nach dem Laden des eigenen Stands die andere Fassung — wer zügig tippte, drückte ins Leere. Bis der Stand bekannt ist, steht dort jetzt ein Platzhalter.
• Die Offline-Seite blieb stehen, wenn nur eine einzelne Anfrage abgebrochen war. Am Hallenmonitor, den niemand bedient, hieße das: bis jemand vorbeikommt. Sie versucht es jetzt alle zehn Sekunden von selbst.
• Der Hallenmonitor stapelte alle laufenden Einsätze übereinander und schob damit Anwesenheit, Fahrzeuge und Prüfungen aus dem Bild. Zwei stehen groß, der Rest als Zeile.

---

[0.4.0] — 2026-09-03

Phase 3: Einsätze und Übungen. Ab hier dokumentiert die Wehr, was sie tut — für die Gemeinde, für die Versicherung und für die eigene Mannschaft.

Hinzugefügt

Datenmodell

• Einsatz mit den sechs Zeitstempeln (alarmiert, ausgerückt, eingetroffen, Einsatzende, eingerückt, einsatzbereit), Ort samt Koordinaten, Kategorie nach der bayerischen Feuerwehrstatistik und den Zahlen für die Gemeindemeldung.
• Einsatzfahrzeug mit eigenen Zeiten je Fahrzeug — Nachalarmierung bleibt sichtbar —, Kilometerstand und Wasserabgabe.
• Einsatzkraft mit Funktion nach FwDV 3, Fahrzeug, Zeitraum und Atemschutz-Kennzeichen.
• Materialverbrauch und Lagemeldung mit Foto und Herkunft.
• PortalZugang — ein zeitlich begrenzter Link für eine Fremdwehr, gespeichert nur als Hash.
• Uebung und Uebungsteilnahme mit Thema, Lernzielen und Anwesenheit.

Schnellerfassung

• Stichwort, Ort, ausgerückte Fahrzeuge — mehr fragt die Erfassung im Alarmfall nicht. Alarmzeit ist der Moment des Anlegens, alles Weitere wird nachgetragen.
• Fortlaufende Einsatznummer JJJJ-NNNN je Wehr und Jahr, vergeben unter einer Transaktionssperre.

Zeiten und Stärke

• Ein Knopf je Zeitstempel, solange der Einsatz läuft.
• Daraus gerechnet: Ausrückzeit, Anfahrtszeit, Hilfsfrist und Einsatzdauer.
• Stärke nach FwDV 3 in der Schreibweise Führer/Unterführer/Mannschaft/Gesamt, mit Zuordnung zur taktischen Einheit (Trupp, Staffel, Gruppe, Zug).
• Hinweise statt Sperren: eine verdrehte Zeitreihenfolge oder eine fehlende Führungskraft wird angezeigt, verhindert das Speichern aber nicht — ein Einsatz, der drei Wochen später nachgetragen wird, ist immer noch besser als einer, den niemand erfasst.

Personalvorschlag

• Sortiert nach Einsatzerfahrung der letzten zwölf Monate, mit dem Qualifikationsstand daneben: eine abgelaufene G26.3 fällt auf, bevor jemand unter Atemschutz geht.

Einsatzbericht und Freigabe

• Bericht als PDF über Gotenberg: Kopf, Zeitleiste mit Kennzahlen, Fahrzeuge, Mannschaft mit Stärke, Material, Verlauf und Bericht.
• Mit der Freigabe wird der Einsatz festgeschrieben — durchgesetzt von einem Datenbanktrigger, nicht vom Anwendungscode. Ausgenommen bleiben das nachgetragene PDF und die Lagemeldungen.
• Jahresexport als quer gedrucktes PDF unter /api/einsaetze/jahresexport.

Statistik

• Einsätze nach Kategorie und Monat, Verteilung der Hilfsfristen mit dem 80-Prozent-Wert, Beteiligung je Person (Einsätze, davon unter Atemschutz, Übungen) und Auslastung je Fahrzeug.

Einsatzportal für Fremdwehren

• Signierter Link ohne Anmeldung, gültig 24 Stunden, jederzeit widerrufbar, jeder Aufruf wird mitgezählt.
• Zeigt Stichwort, Ort, Zeitstempel und Lagemeldungen — keine Namen von Einsatzkräften, keinen Bericht, keinen Weg in den Rest der Anwendung.
• Nimmt Lagemeldungen mit Foto an, begrenzt auf 30 Meldungen und 10 Fotos je Zugang und Stunde.
• Eigene Zugriffsbegrenzung über Redis (src/lib/ratelimit.ts), die bei Störung durchlässt statt zu blockieren.

Übungen

• Thema, Art, Lernziele, Ort und Leitung; Anwesenheit als Liste zum Abhaken.
• Fließt in die Beteiligungsstatistik ein.

Adressen zu Koordinaten

• Anbindung an einen selbst betriebenen Nominatim hinter einer Schnittstelle in lib/integrations/. Ohne Konfiguration bleibt die Suche leer und die Koordinaten werden von Hand eingetragen.
• Koordinaten liegen doppelt: als Dezimalgrad für die Anwendung und als PostGIS-Punkt für die Karte ab Phase 6, zusammengehalten von einem Trigger.

Sonstiges

• Der Seed legt acht Einsätze über das Jahr verteilt an — Brände, technische Hilfeleistungen, ein Fehlalarm einer Brandmeldeanlage — dazu sechs Übungen und die Beteiligung der Mannschaft.
• 57 neue Tests: 32 Unit-Tests zu Stärke, Zeiten und Nummernkreis, 14 gegen eine echte Datenbank (Koordinaten-Trigger, Freigabe, Mandantentrennung) und 11 Playwright-Durchläufe einschließlich des Portals in einem Browser ohne Sitzung.

Geändert

• Der Nummernkreis JJJJ-NNNN liegt jetzt in src/lib/nummernkreis.ts und wird von Prüfprotokollen, Einsätzen und Übungen gemeinsam verwendet.
• Die Seitenleiste zeigt Einsätze und Übungen als verfügbar.
• Das Zeitlimit der E2E-Erwartungen steigt von 15 auf 25 Sekunden: mit fünfzig Routen dauert die erste Übersetzung einer Seite im Entwicklungsserver unter Last länger als vorher, und daran scheiterten gelegentlich Tests, die einzeln grün sind.

Behoben

• Die Anwesenheitsliste einer Übung forderte 300 Mitglieder an und lief damit in die Höchstzahl von 200 je Seite — die Liste blieb leer. Gefunden über die Server-Ausgabe während der E2E-Tests.

---

[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 eine Importdatei.
  • Die Lagerung wird als Umschalter geführt statt als zwei Auswahlfelder, die man versehentlich beide füllen kann.
  • Prüftermin und Lebensdauerende werden schon beim Tippen ausgerechnet und angezeigt — mit denselben Funktionen, mit denen der Server anschließend rechnet.
  • Ist nur ein Standort angelegt, wird er vorbelegt.
• 7 weitere Playwright-Tests zum Formular (nun 58 statt 44, zwei davon unter Touch-Emulation begründet übersprungen).

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; dort kommt nur eine Client-Referenz an, kein Objekt. Das Spreaden davon ergab lauter undefined. Die Werte liegen jetzt in einem eigenen Modul ohne "use client".
• Das Sternchen an Pflichtfeldern wurde vorgelesen. Eine Sprachausgabe nannte das Feld „Bezeichnung Stern". Das Sternchen trägt jetzt aria-hidden; dass ein Feld ausgefüllt werden muss, sagt das required-Attribut.
• 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 Standorten, Fahrzeugen samt Beladeordnung, Gerätetypen als Vorgabe und Geräten, die per QR-Code am Regal auffindbar sind.

Hinzugefügt

Datenmodell

• Standort (Gerätehaus, Lager, Außenstelle, Werkstatt) mit PostGIS-Punkt für die Karte ab Phase 6.
• Geraeteraum — die Fächer am Fahrzeug (G1 bis G6, Heck, Dach, Mannschaftsraum), in Beladereihenfolge sortierbar.
• Geraetetyp als Vorgabe für Prüfintervall, Prüfvorschrift und Lebensdauer. Ein einzelnes Gerät darf davon abweichen; sonst gilt der Typ.
• Qualifikationstyp und Qualifikation mit Gültigkeitsdauer und eigener Vorwarnzeit je Typ.
• Fahrzeug erweitert um Fahrgestellnummer, DIN-Typkurzzeichen, Erstzulassung, Sitzplätze, Tankinhalt, Gesamtmasse und die UVV-Frist.
• Geraet erweitert um Gerätetyp, Lebensdauerkategorie, errechnetes Lebensdauerende, Anschaffungspreis und die Lagerung.

Regeln in der Datenbank

• Ein Gerät steht entweder an einem Standort oder ist auf einem Fahrzeug verlastet — eine Prüfbedingung setzt das durch, ein Trigger stellt zusätzlich sicher, dass ein angegebener Geräteraum auch zum angegebenen Fahrzeug gehört.
• Row Level Security auf allen neuen Tabellen.
• Trigram-Indizes für die Volltextsuche über Geräte, Fahrzeuge und Personen.

Funktionen

• Geräteliste mit Volltextsuche, Statusfilter, serverseitiger Sortierung, Blättern und Spaltenauswahl. Die Spaltenauswahl bleibt je Browser gespeichert.
• Massenbearbeitung: Status mehrerer Geräte auf einmal setzen, Geräte umlagern. Jede Änderung erzeugt einen eigenen Protokolleintrag am jeweiligen Gerät.
• QR-Code je Gerät. Der Code zeigt auf /g/<inventarnummer> und führt nach der Anmeldung direkt zur Gerätedetailseite.
• Etikettenbogen als PDF über Gotenberg: DIN A4 mit 65 Etiketten (38,1 × 21,2 mm). Der Druck kann an einer beliebigen Position beginnen, damit angebrochene Bögen weiterverwendet werden können.
• QR-Scan über die Kamera im Browser, mit Eingabefeld als Rückfallweg.
• Import aus CSV und Excel: Spalten werden nach den Überschriften automatisch zugeordnet, die Vorschau zeigt Zeile für Zeile, was übernommen würde und was daran nicht stimmt. Geschrieben wird erst nach Bestätigung.
• Gerätehistorie und Fahrzeughistorie, gerendert aus dem Audit-Log.
• Qualifikationen mit Ablaufwarnung, gerechnet mit der Vorwarnzeit des jeweiligen Typs.
• Fahrzeugdetail zeigt die Beladung nach Geräteräumen statt alphabetisch.

Daten und Tests

• Der Seed legt jetzt zusätzlich 3 Standorte, 20 Geräteräume, 14 Gerätetypen mit echten Prüfvorgaben (DGUV, DIN, vfdb), 49 Geräte und 107 Qualifikationen an. Fristen sind bewusst gestreut, damit die Ampeln etwas zeigen.
• 104 Vitest-Tests (vorher 32), davon 40 zum Import und 32 zu QR und Fristen.
• 44 Playwright-Tests (vorher 10) über Desktop und Tablet.

Geändert

• Fristenrechnung auf UTC-Kalenderarithmetik umgestellt. Vorher wurde über startOfDay aus date-fns gerechnet, das die Zeitzone des Servers verwendet. Ein Prüfdatum kommt aus der Datenbank als UTC-Mitternacht und wurde dabei auf den Vortag zurückgeschoben — Fristen wären einen Tag zu früh fällig geworden.
• CardTitle rendert eine echte Überschrift statt eines div. Wer mit einer Sprachausgabe arbeitet, springt von Überschrift zu Überschrift; Karten tauchten in dieser Navigation vorher gar nicht auf.
• Die Entwicklungsanzeige von Next.js ist abgeschaltet, damit sie nicht in den Bildern der Anleitung mitläuft.

Sicherheit

• Der Etikettendruck wird protokolliert (EXPORTIERT) — damit ist nachvollziehbar, wann welche Aufkleber erzeugt wurden.
• Der Import übernimmt keine Werte, die der Browser geschickt hat: die Datei wird beim Übernehmen erneut serverseitig eingelesen und geprüft. Sonst ließe sich die Vorschau umgehen.

[0.1.0] — 2026-09-03

Phase 0: das Fundament. Ab hier steht ein lauffähiger Stack mit Mandantentrennung, Anmeldung, Dateiablage und lückenloser Protokollierung.

Hinzugefügt

Betrieb

• docker-compose.yml mit Traefik, App, Worker, PostgreSQL 17 + PostGIS, Redis, MinIO und Gotenberg.
• docker-compose.override.yml für die Entwicklung: ohne Traefik, mit Mailpit als SMTP-Auffangkorb und Adminer für den Blick in die Datenbank. Host-Ports bewusst abseits der Standardwerte (3100, 5442, 6389, 9010/9011), damit FLORIAN neben anderen lokalen Stacks laufen kann.
• Mehrstufiges docker/Dockerfile: eigener Benutzer florian (UID 1001, kein root), tini als PID 1, Healthcheck gegen /api/health, Standalone-Build von Next.js.
• docker/entrypoint.sh wendet ausstehende Migrationen an — nur im App-Container, nicht im Worker.
• docker/postgres/10-init-app-role.sh legt beim ersten Start die Rolle florian_app (NOBYPASSRLS) samt Vorgabeprivilegien an.
• .env.example mit einem Kommentar zu jeder einzelnen Variable.

Datenmodell

• Prisma-Schema mit Organisation, Person, Rolle, Berechtigung, RolleBerechtigung, PersonRolle, AusweisToken, AuditLog, Datei.
• Fahrzeug und Geraet bereits schmal angelegt, damit der Seed eine realistische Wehr aufbauen kann. Phase 1 erweitert beide.
• Migration 20260902000100_rls_policies: Row Level Security auf allen mandantenpflichtigen Tabellen, Funktion aktuelle_organisation(), Append-only-Trigger auf audit_log.
• Migration 20260902000200_audit_bereinigung: UPDATE auf audit_log bleibt dauerhaft gesperrt, DELETE ist nur im gekennzeichneten Aufbewahrungslauf möglich.

Anwendungskern

• lib/env.ts — Zod-Validierung der gesamten Umgebung beim Start.
• lib/db.ts — getrennte Verbindungen für Anwendung (RLS aktiv) und System (RLS-frei), fuerOrganisation() als einziger Weg zu Fachdaten.
• lib/authz.ts — 9 Rollen, 38 Einzelrechte, zentrale Prüffunktionen.
• lib/storage.ts — MinIO, presignte Up- und Downloads, SHA-256-Prüfsumme.
• lib/audit.ts — Protokolleinträge mit Vorher/Nachher-Vergleich, entfernt Geheimnisse vor dem Schreiben.
• lib/auth.ts — Auth.js mit OIDC gegen authentik, lokalem Passwort-Login und Terminal-Anmeldung über PIN oder RFID.
• lib/warteschlange.ts und src/worker/ — BullMQ-Gerüst mit den Auftragsarten für Fristen, Erinnerungen, PDF und Aufbewahrung.
• lib/integrations/ — Mail, Telegram und LLM hinter abschaltbaren Schnittstellen.
• tRPC v11 mit den Prozedurarten oeffentlich, angemeldet und mitRecht(...).

Oberfläche

• Basis-Layout mit Seitenleiste, heller und dunkler Darstellung (Systemvorgabe als Standard) und durchgängig deutschen Texten.
• Anmeldeseite, die genau die eingerichteten Anmeldewege zeigt.
• Übersicht mit Kennzahlen und dem Sicherheitshinweis zur analogen Atemschutzüberwachung.
• Farbwelt in OKLCH mit festen Statusfarben für Gerätezustände.

Daten und Tests

• Seed mit einer vollständigen Beispielwehr: 15 Personen mit Rollen und Terminal-Ausweisen, 3 Fahrzeuge, 40 Geräte mit gemischten Prüffristen.
• Vitest: 32 Tests, darunter acht, die die Mandantentrennung gegen eine echte Datenbank prüfen.
• Playwright: 10 Tests über Desktop und Tablet.
• npm run screenshots erzeugt die Bilder für die Anleitung.

Dokumentation

• README mit Schnellstart in sechs Zeilen.
• Anleitung, Roadmap, Aufwandsschätzung, Devlog und Versionierungsregeln.