Schliesst die letzte offene Luecke aus Phase 1. Bis dahin liessen sich Geraete
nur ueber den Import erfassen — fuer einen Bestand richtig, fuer ein einzelnes
nachbeschafftes Geraet umstaendlich.
Neu:
- /geraete/neu und /geraete/<id>/bearbeiten, beide ueber dieselbe Komponente
- Die Lagerung ist ein Umschalter statt zweier Auswahlfelder. Standort und
Fahrzeug schliessen sich aus; so kann der Fehler gar nicht erst entstehen,
den die Datenbank sonst abweisen wuerde. Beim Wechsel des Fahrzeugs wird die
Raumangabe zurueckgesetzt.
- Prueftermin und Lebensdauerende werden beim Tippen vorgerechnet, mit
denselben Funktionen wie auf dem Server. Beim Speichern rechnet der Server
erneut und behaelt das letzte Wort.
- Gibt es nur einen Standort, ist er beim Anlegen vorbelegt.
- Knopf "Neues Geraet" in der Liste, "Bearbeiten" auf der Detailseite
Behoben:
- Das Formular stuerzte 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, und das Spreaden ergibt lauter
undefined. Die Werte liegen jetzt in geraet-formular-werte.ts ohne
"use client".
- Das Sternchen an Pflichtfeldern wurde von Sprachausgaben mitgelesen
("Bezeichnung Stern"). Es traegt jetzt aria-hidden; dass ein Feld ausgefuellt
werden muss, sagt bereits das required-Attribut.
- Fehlermeldungen in Formularen sind eindeutig ansteuerbar. Next.js haengt
einen eigenen Routen-Ansager mit der Rolle "alert" in jede Seite.
Tests:
- 7 neue Playwright-Tests zum Formular, darunter die Lagerungsregel und die
Fristenvorschau
- Zwei davon laufen nicht unter Touch-Emulation: Chromium nimmt dort keine
zeichenweise Eingabe in Datumsfelder an. Begruendet uebersprungen, die
Rechnung selbst deckt qr-und-fristen.test.ts ab.
- Insgesamt 104 Unit-Tests und 56 E2E-Tests gruen
Anleitung, Changelog, Devlog, Aufwandsschaetzung und Roadmap fortgeschrieben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
10 KiB
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 ░░░░░░░░░░░░░░░░░░░░ offen 0.3.0
Phase 3 ░░░░░░░░░░░░░░░░░░░░ offen 0.4.0
Phase 4 ░░░░░░░░░░░░░░░░░░░░ offen 0.5.0
Phase 5 ░░░░░░░░░░░░░░░░░░░░ offen 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 · als Nächstes
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
- Nächtlicher Job erzeugt Termine, setzt Status, erinnert bei T-30, T-7 und T-0
- Prüfungs-Wizard mit Foto je Checklistenpunkt, Zeiterfassung und Unterschrift
- PDF-Prüfprotokoll über Gotenberg, unveränderlich in MinIO
- Lebensdauerüberwachung mit Aussonderungsvorschlag
- Rückrufe markieren betroffene Geräte automatisch
- Mängel-Workflow: melden → zugewiesen → in Arbeit → behoben
Danach kann die Wehr: einen DGUV-Nachweis führen, der einer Prüfung durch die Unfallkasse standhält.
Phase 3 — Einsätze und Übungen
- 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
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, Auto-Logout nach 90 Sekunden
- Wizards: Wartung, Fahrtenbuch, Mangel melden, Inventur, Wäsche, Anwesenheit
- Hallen-Monitor: Vollbild mit Terminen, überfälligen Prüfungen, Fahrzeugstatus, Wetterwarnung
- Offline-Betrieb mit IndexedDB-Outbox und Synchronisation bei Reconnect
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
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 Timer, per Socket.IO verteilt
- 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
- 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.