Files

T

Florian WildeandClaude Opus 5 4e2daaafd4 Atemschutzueberwachung nach FwDV 7 ergaenzen

Phase 5: das sicherheitsrelevanteste Modul des Projekts. Ueber jeder Ansicht
steht dauerhaft, dass die analoge Atemschutzueberwachung fuehrend bleibt —
abschaltbar nur zusammen mit der Fundstelle einer Freigabe des Kommandanten.

Es gibt keinen Timer. In der Datenbank stehen Zeitstempel; wie lange ein
Trupp unter Atemschutz ist, rechnet jede Ansicht bei jedem Bild neu aus.
Damit ist die Anforderung "uebersteht Neuladen und Verbindungsabbruch" keine
Funktion, die gelingen muss, sondern eine Eigenschaft, die sich nicht
verlieren laesst. Server und Browser rechnen mit denselben Funktionen.

Der Rueckzugsdruck folgt dem doppelten Anmarschverbrauch: was der Weg hinein
gekostet hat, kostet der Weg zurueck noch einmal. Bis der Trupp das
Einsatzziel meldet, greift die Zwei-Drittel-Regel — sie liegt hoeher und ist
damit die vorsichtigere Annahme.

Das Protokoll ist doppelt gesichert: entzogene Rechte und ein Trigger auf
druckmessung und atemschutz_ereignis. Ein Fehler wird durch einen neuen
Eintrag richtiggestellt, nicht durch Aendern.

Verteilt wird ueber Server-Sent Events statt Socket.IO — es geht nur in eine
Richtung, und so bleibt das Deployment bei "next start".

Behoben: ein abgerissener Ereignisstrom meldete sich nicht. Die Anzeige haette
weiter "Verbunden" behauptet, waehrend der Draht tot war. Jetzt gilt Stille
von acht Sekunden als Abriss. Dazu zwei Altlasten: der Navigationseintrag
"Protokoll" fuehrte ins Leere, und die Startseite stand noch auf Phase 1.

68 neue Tests (51 Unit, 17 gegen eine echte Datenbank, 8 E2E je Browser).

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

2026-09-03 23:19:05 +02:00

11 KiB

Raw Blame History

Roadmap

Was FLORIAN wann kann. Die Phasen kommen aus Phase-0.md bis Phase-8.md und werden einzeln abgearbeitet — nie zwei in einem Schritt.

Aufwände je Phase: AUFWANDSSCHAETZUNG.md. Versionszuordnung: VERSIONIERUNG.md.

Stand

Phase 0  ████████████████████  fertig      0.1.0
Phase 1  ████████████████████  fertig      0.2.0
Phase 2  ████████████████████  fertig      0.3.0
Phase 3  ████████████████████  fertig      0.4.0
Phase 4  ████████████████████  fertig      0.5.0
Phase 5  ████████████████████  fertig      0.6.0
Phase 6  ░░░░░░░░░░░░░░░░░░░░  offen       0.7.0
Phase 7  ░░░░░░░░░░░░░░░░░░░░  offen       0.8.0
Phase 8  ░░░░░░░░░░░░░░░░░░░░  offen       0.9.0
Phase 9  ░░░░░░░░░░░░░░░░░░░░  offen       0.10.0
Freigabe ░░░░░░░░░░░░░░░░░░░░  offen       1.0.0

Phase 0 — Fundament · fertig

Alles, worauf der Rest aufsetzt.

Monorepo, Docker Compose mit Traefik, PostgreSQL 17 + PostGIS, Redis, MinIO, Gotenberg
Mandantentrennung über Row Level Security, geprüft gegen eine echte Datenbank
Append-only-Audit-Log mit kontrolliertem Aufbewahrungslauf
Anmeldung: OIDC gegen authentik, lokaler Passwort-Login, Terminal per PIN und RFID
9 Rollen, 38 Einzelrechte, zentral in lib/authz.ts
Dateiablage in MinIO, Zugriff nur über lib/storage.ts
Basis-Layout mit Seitenleiste und dunkler Darstellung
Seed mit einer vollständigen Beispielwehr

Phase 1 — Stammdaten · fertig

Die Wehr trägt ein, was sie hat.

Standort, Geraeteraum, Geraetetyp, Qualifikationstyp, Qualifikation
Fahrzeug um Fahrgestellnummer, DIN-Typ und TÜV-Termin erweitern
Geraet um Lebensdauerkategorie und die Zuordnung „Standort ODER Fahrzeug + Geräteraum" erweitern
Tabellen mit Sortierung, Filter, Volltextsuche und Spaltenauswahl
QR-Code je Gerät, Etikettenbogen als PDF (DIN A4, 65 Etiketten)
QR-Scan über die Kamera öffnet direkt die Gerätedetailseite
CSV-/Excel-Import mit Spaltenzuordnung und Vorschau
Gerätehistorie aus dem Audit-Log
Qualifikationen mit Ablaufwarnung auf der Übersicht
Formular zum Anlegen und Bearbeiten eines einzelnen Geräts, mit Fristenvorschau beim Ausfüllen

Danach kann die Wehr: ihren Bestand vollständig führen und jedes Gerät per QR-Code am Regal wiederfinden.

Phase 2 — Wartung und Prüfung · fertig

Das wichtigste Modul. Ab hier ersetzt FLORIAN den Ordner.

Wartungsvorlagen mit Checklisten, Intervall und Vorwarnzeit
Fristen-Dashboard: überfällig / diese Woche / diesen Monat / nächste 90 Tage, gebündelt nach Fahrzeug, Standort, Gerätetyp oder Zuständigem
Nächtlicher Lauf erzeugt Termine, zieht den Gerätestatus nach und erinnert bei T-30, T-7, T-0 und einmal bei Überfälligkeit
Prüfwizard mit Foto je Checklistenpunkt, Zeiterfassung und Unterschrift auf dem Zeichenfeld
PDF-Prüfprotokoll über Gotenberg, unveränderlich in MinIO — die Sperre setzt ein Datenbanktrigger durch, nicht der Anwendungscode
Korrekturen erzeugen ein neues Protokoll mit Verweis auf das alte
Lebensdauerüberwachung mit Aussonderungsvorschlag
Rückrufe suchen betroffene Geräte über Bauart, Modell, Seriennummernbereich und Herstellungszeitraum
Mängel-Workflow: melden → zugewiesen → in Arbeit → behoben, mit Gerätesperre bei kritischen Mängeln
Externe Wartung: Fachfirma, Kosten und Fremdprotokoll als PDF

Danach kann die Wehr: einen DGUV-Nachweis führen, der einer Prüfung durch die Unfallkasse standhält.

Phase 3 — Einsätze und Übungen · fertig

Einsatz mit allen Zeitstempeln: alarmiert, ausgerückt, eingetroffen, Einsatzende, eingerückt, einsatzbereit
Schnellerfassung: Stichwort, Adresse, Fahrzeuge — Rest später
Geocoding über self-hosted Nominatim
Personalauswahl mit Vorschlag nach Verfügbarkeit und Qualifikation
Stärkeberechnung nach FwDV 3
Einsatzbericht als PDF, Jahresexport für die Gemeinde
Statistik: Kategorien, Eintreffzeiten, Beteiligung, Fahrzeugauslastung
Externes Portal für Fremdwehren über signierten QR-Link, ohne Anmeldung

Danach kann die Wehr: ihre Jahresstatistik auf Knopfdruck erzeugen.

Phase 4 — Kiosk-PWA · fertig

Für die Wandtablets in der Fahrzeughalle.

Eigenes Layout: große Kacheln, mindestens 64px, mit Handschuhen bedienbar
Anmeldung per RFID, PIN oder QR vom Handy, Abmeldung nach Untätigkeit (KIOSK_IDLE_TIMEOUT, Vorgabe 120 Sekunden)
Wizards: Fahrtenbuch, Mangel melden, Inventur, Wäsche, Anwesenheit. Die Prüfung bleibt beim Wizard aus Phase 2 — Checkliste, Fotos und Unterschrift lassen sich nicht sinnvoll in eine Warteschlange legen; die Kachel sagt „braucht Netz"
Hallen-Monitor: Vollbild mit Terminen, überfälligen Prüfungen, Fahrzeugstatus, Wetterwarnung
Offline-Betrieb mit IndexedDB-Outbox, Idempotenzschlüssel und Konfliktliste für alles, was sich beim Nachtragen nicht anwenden lässt

Danach kann die Wehr: einen Mangel in unter 30 Sekunden melden, ohne den Rechner im Büro einzuschalten — auch wenn das Netz gerade weg ist.

Phase 5 — Atemschutz nach FwDV 7 · fertig

Sicherheitsrelevant. Jede Ansicht zeigt dauerhaft den Hinweis, dass die analoge Überwachung führend bleibt — abschaltbar erst über eine Option, die eine dokumentierte Freigabe durch den Kommandanten voraussetzt.

Truppanlage per RFID, Eingangsdruck erfassen
Serverseitig autoritative Zeitstempel; verteilt über Server-Sent Events statt Socket.IO — es geht nur in eine Richtung, und so bleibt es bei next start ohne eigenen Node-Server
Rückzugsdruck-Berechnung mit Ampel und akustischem Alarm
Erinnerung zur Druckabfrage im konfigurierbaren Intervall
Mayday-Knopf je Trupp
Lückenloses PDF-Protokoll am Einsatz
G26.3-Fristen, Belastungsübungen, Tauglichkeitsübersicht

Danach kann die Wehr: die Überwachung digital mitführen — parallel zur analogen, bis die Wehr ausdrücklich anders entscheidet.

Phase 6 — Kartenmodule · als Nächstes

MapLibre GL mit selbst gehosteten Kacheln fürs Ausrückegebiet
Hydranten mit Typ, Nennweite, Durchfluss, letzter Prüfung; Import aus GeoJSON und Stadtwerke-CSV
Objekte und Feuerwehrpläne nach DIN 14095, vom Einsatz aus erreichbar
Lagekarte mit taktischen Zeichen nach FwDV 102, Echtzeit-Sync
Wasserförderung: Druckverlust, Verstärkerpumpen, druckbares Schema

Danach kann die Wehr: auf der Anfahrt sehen, wo der nächste Hydrant liegt und was ihn hergibt.

Phase 7 — Benachrichtigungen und Termine

Kanäle: E-Mail, Telegram, ntfy, Web-Push. WhatsApp bewusst nicht.
Vorlagen mit Platzhaltern, je Ereignis und Rolle konfigurierbar
Kalender: Dienste, Übungen, Lehrgänge, Arbeitsdienste; Serientermine, Selbstanmeldung mit Teilnehmerlimit, Anwesenheitsliste zum Ausdrucken
CalDAV-/ICS-Feed je Person
Digitaler Dienstausweis mit signiertem QR und Prüfseite

Warum kein WhatsApp

Die WhatsApp Business API kostet je Konversation und verlangt einen zugelassenen Anbieter dazwischen — laufende Kosten für eine Wehr, die keinen Etat dafür hat. Der schwerere Grund ist der Datenschutz: die Nummern aller Mitglieder gingen an Meta, was sich mit einer Anwendung, die bewusst im Gerätehaus steht, nicht verträgt. Telegram, ntfy und Web-Push decken denselben Bedarf ab, ntfy sogar vollständig selbst gehostet.

Phase 8 — Lokale KI

Alles gegen Ollama, kein externer Anbieter, komplett abschaltbar.

Diktat: Aufnahme im Browser → faster-whisper → Transkript im Berichtsfeld
Berichtsassistent: aus Stichpunkten einen Entwurf, immer als Vorschlag
Wiki mit pgvector: semantische Suche mit Quellenangabe
Belegerfassung: Foto einer Quittung → Vorschlag für Betrag, Datum, Händler

Jede KI-Ausgabe ist gekennzeichnet und muss bestätigt werden, bevor sie in ein Dokument mit Nachweischarakter gelangt.

Phase 9 — Kassenverwaltung

Am 03.09.2026 ergänzt. Die Rolle KASSIER war seit Phase 0 angelegt, ein Modul dazu fehlte in der ursprünglichen Planung. Spezifikation: Phase-9.md.

Kassenkonten (Bar, Bank, Rücklage), Buchungskategorien, Buchungen mit Beleg
Beitragslauf je Jahr nach Abteilung, Mahnstufen, Zahlungsabgleich aus CAMT.053 oder MT940
Rechnungen an Dritte mit Nummernkreis und PDF
Kassenabschluss mit gezähltem Bestand, Differenz und Kassenprüfbericht
Auswertungen nach Kategorie und Monat, offene Posten, Beitragsrückstände
Export für Steuerberater und Kassenprüfung der Gemeinde

Zwei Festlegungen, die den Rest bestimmen: eine festgeschriebene Buchung ist unveränderbar — Korrekturen laufen über eine Gegenbuchung mit Verweis. Und der Kassenabschluss friert seinen Zeitraum ein, danach nimmt die Buchungsmaske kein Datum daraus mehr an. Beträge durchgängig als DECIMAL(12,2), nie als Fließkommazahl.

Danach kann die Wehr: ihre Kasse führen und den Kassenprüfbericht auf Knopfdruck erzeugen.

1.0.0 — Freigabe

Kein neues Modul, sondern eine Entscheidung: die Wehr setzt FLORIAN im Echtbetrieb ein. Voraussetzungen:

Datenübernahme aus der bisherigen Verwaltung abgeschlossen und abgeglichen
Sicherungskonzept steht und ist einmal wiederhergestellt worden
Schulung von Kommandant, Gerätewart und Atemschutzgerätewart erfolgt
Löschkonzept nach DSGVO abgenommen
Der Hinweis zur analogen Atemschutzüberwachung wird bewusst und dokumentiert abgeschaltet — oder bewusst stehen gelassen

Getroffene Festlegungen

Am 03.09.2026 entschieden:

Punkt	Entscheidung
Kassenmodul	Wird als Phase 9 ergänzt. Spezifikation in `Phase-9.md`, Aufwand 8–11 PT.
`Berechtigung` ohne `organisationId`	Bleibt so. Die Tabelle ist der systemweite Katalog dessen, was die Software kann, für alle Wehren identisch — mandantenbezogen wird es erst über `RolleBerechtigung`. Für die Anwendungsrolle nur lesbar.
Löschausnahme im Audit-Log	Bleibt so. `UPDATE` ist dauerhaft gesperrt, `DELETE` nur mit `SET LOCAL app.audit_bereinigung = 'an'` im Aufbewahrungslauf des Workers. Ohne diese Ausnahme wäre das Löschkonzept nach DSGVO nicht umsetzbar.

Weitere Kandidaten für später

Idee	Nutzen	grob
Fahrtenbuch als eigenes Modul	derzeit nur als Kiosk-Wizard in Phase 4 vorgesehen	3–4 PT
Kleiderkammer und Wäscheverwaltung	in Phase 4 nur als Wizard, ohne Bestandsführung	4–6 PT
Jugendfeuerwehr mit eigener Abzeichenverwaltung	eigene Fachlichkeit	5–7 PT
Schnittstelle zur Integrierten Leitstelle	Alarmdaten automatisch übernehmen	6–10 PT, stark abhängig von der ILS
Mehrere Wehren je Installation	technisch bereits möglich, Oberfläche fehlt	4–6 PT

Die Mandantenfähigkeit ist der Punkt, der ohne Zusatzaufwand am weitesten trägt: das Datenmodell und RLS können bereits mehrere Wehren. Was fehlt, ist eine Oberfläche zum Umschalten und ein Konzept für gemeindeübergreifende Auswertungen. Für einen Landkreis, der mehrere Wehren betreiben will, wäre das der nächste sinnvolle Schritt.

11 KiB Raw Blame History Unescape Escape