Florian WildeandClaude Opus 5
845942f36c
Legt den kompletten Unterbau an, auf dem die Fachmodule aufsetzen. Betrieb: - docker-compose.yml mit Traefik, App, Worker, PostgreSQL 17 + PostGIS, Redis, MinIO und Gotenberg; Entwicklungs-Override ohne Traefik, dafuer mit Mailpit und Adminer - Mehrstufiges Dockerfile: eigener Benutzer, tini als PID 1, Healthcheck - .env.example mit einem Kommentar zu jeder Variable Mandantentrennung: - Row Level Security auf allen mandantenpflichtigen Tabellen - Zwei getrennte Datenbankverbindungen: florian_app mit aktiver RLS fuer die Anwendung, Eigentuemer-Zugang nur fuer Migration, Seed und Anmeldung - fuerOrganisation() als einziger Weg zu Fachdaten Nachvollziehbarkeit: - AuditLog append-only per Trigger; UPDATE ist dauerhaft gesperrt, DELETE nur im gekennzeichneten Aufbewahrungslauf - Geheimnisse werden vor dem Schreiben entfernt Anmeldung: - OIDC gegen ein extern betriebenes authentik, Rollen aus Gruppen nur als Vorbelegung beim ersten Login - Lokaler E-Mail/Passwort-Login als Rueckfallweg - Terminal per PIN und RFID mit zwei Schranken (Geraet, dann Person) Weiteres: - lib/authz.ts mit 9 Rollen und 38 Einzelrechten - lib/storage.ts (MinIO), lib/audit.ts, lib/warteschlange.ts (BullMQ) - Integrationen fuer Mail, Telegram und LLM hinter abschaltbaren Interfaces - tRPC v11, Basis-Layout mit Seitenleiste und dunkler Darstellung - Seed mit einer Beispielwehr: 16 Personen, 3 Fahrzeuge, 40 Geraete - 32 Vitest-Tests (davon 8 gegen eine echte Datenbank), 10 Playwright-Tests - README, Anleitung mit Screenshots, Roadmap, Aufwandsschaetzung, Devlog, Versionierungsregeln und Changelog Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
210 lines
9.2 KiB
Markdown
210 lines
9.2 KiB
Markdown
# 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](AUFWANDSSCHAETZUNG.md).
|
||
Versionszuordnung: [VERSIONIERUNG.md](VERSIONIERUNG.md).
|
||
|
||
## Stand
|
||
|
||
```
|
||
Phase 0 ████████████████████ fertig 0.1.0
|
||
Phase 1 ░░░░░░░░░░░░░░░░░░░░ offen 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
|
||
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 · als Nächstes
|
||
|
||
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
|
||
|
||
**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
|
||
|
||
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.
|
||
|
||
## 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
|
||
|
||
---
|
||
|
||
## Offene Punkte
|
||
|
||
### Kassenmodul fehlt in der Phasenplanung
|
||
|
||
Phase 0 verlangt die Rolle `KASSIER`, und sie ist angelegt — mit den Rechten
|
||
`kasse.lesen`, `kasse.bearbeiten` und `kasse.abschluss`. Ein Kassenmodul kommt
|
||
in keiner der Phasen 0 bis 8 vor. Die Rolle hätte also dauerhaft Rechte ohne
|
||
zugehörige Oberfläche.
|
||
|
||
Zwei Wege:
|
||
|
||
1. **Phase 9 ergänzen** — Buchungen, Beiträge, Rechnungen, Kassenabschluss,
|
||
Jahresauswertung. Geschätzt 8–11 PT.
|
||
2. **Rolle belassen, Modul streichen** — der Kassier nutzt weiterhin seine
|
||
bisherige Lösung, die Rechte bleiben als Platzhalter stehen.
|
||
|
||
Solange das nicht entschieden ist, bleiben die Rechte im Katalog, aber es gibt
|
||
keinen Navigationseintrag dafür.
|
||
|
||
### 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.
|