Florian WildeandClaude Opus 5
4b3021bb50
Die Rolle KASSIER war seit Phase 0 angelegt, ein Kassenmodul fehlte in der Planung. Phase-9.md beschreibt es jetzt: Konten, Buchungen mit Beleg, Beitragslauf mit Mahnstufen, Rechnungen, Kassenabschluss und Auswertungen. Geschaetzt 8-11 PT, Version 0.10.0. Zwei Festlegungen aus der Spezifikation, weil sie den Rest bestimmen: eine festgeschriebene Buchung ist unveraenderbar und wird nur ueber eine Gegenbuchung korrigiert; der Kassenabschluss friert seinen Zeitraum ein. Ausserdem als entschieden festgehalten: - Berechtigung bleibt ohne organisationId. Die Tabelle ist der systemweite Katalog dessen, was die Software kann; mandantenbezogen wird es erst ueber RolleBerechtigung. - Die Loeschausnahme im Audit-Log bleibt. UPDATE ist dauerhaft gesperrt, DELETE nur im gekennzeichneten Aufbewahrungslauf des Workers. Roadmap, Aufwandsschaetzung, Versionierung, README und die Seitenleiste sind entsprechend ergaenzt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
224 lines
10 KiB
Markdown
224 lines
10 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
|
||
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 · 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.
|
||
|
||
## 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.
|