Files

T

Florian WildeandClaude Opus 5 845942f36c Phase 0: Fundament der Feuerwehr-Verwaltungsplattform

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>

2026-09-03 00:13:53 +02:00

3.2 KiB

Raw Blame History

Projekt: FLORIAN — Feuerwehr-Verwaltungsplattform

Kontext

Selbstgehostete Verwaltungssoftware für Freiwillige Feuerwehren in Deutschland (Bayern). Zielgruppe: Kommandant, Gerätewart, Atemschutzgerätewart, Schriftführer, Kassier, Mannschaft. Betrieb: Docker Compose auf Proxmox VE, kein Cloud-Zwang, DSGVO-konform, Daten bleiben im Gerätehaus bzw. auf eigener Hardware.

Nicht verhandelbarer Stack

Next.js 15 App Router, TypeScript strict, React Server Components wo sinnvoll
Prisma + PostgreSQL 17 mit PostGIS
tRPC für interne Aufrufe, REST unter /api/v1 für externe Integrationen
Tailwind CSS + shadcn/ui
Redis + BullMQ für Hintergrundjobs
MinIO (S3-API) für alle Dateien — niemals lokale Pfade
Zod für jede Ein- und Ausgabevalidierung
Vitest (Unit) + Playwright (E2E)
Alles auf Deutsch: UI-Texte, Feldnamen in der UI, Kommentare. Code-Bezeichner auf Englisch, Domänenbegriffe deutsch belassen (z. B. Atemschutztrupp, Pruefintervall, Geraetewart).

Architekturregeln

Jede Tabelle hat organisationId (Mandant). Postgres RLS ist aktiv. Kein Query ohne Mandantenfilter.
Jede schreibende Operation erzeugt einen Eintrag in AuditLog (Actor, Zeitpunkt, Entität, Vorher/Nachher als JSONB). Append-only.
Prüf-, Wartungs- und Buchungsdaten werden nie hart gelöscht (Soft-Delete
- Versionierung).
Alle Fristen und Zeitberechnungen serverseitig, Zeitzone Europe/Berlin.
Berechtigungen zentral in lib/authz.ts. Keine Rollenprüfung in Komponenten.
Dateizugriff ausschließlich über lib/storage.ts.
Externe Dienste (LLM, Mail, Telegram) hinter Interfaces in lib/integrations/, damit sie im Test mockbar und optional abschaltbar sind.

Domänenwissen, das zu beachten ist

DGUV-Prüffristen: Geräte haben Prüfintervalle aus Vorschrift oder Herstellervorgabe. Status: einsatzbereit | pruefung_faellig | gesperrt | ausgesondert.
Lebensdauerkategorien: Helme, Seile, Pressluftatmer, Schutzkleidung haben eine maximale Nutzungsdauer ab Herstellungs- oder Indienststellungsdatum.
FwDV 7 (Atemschutz): Überwachung dokumentiert Truppzusammensetzung, Einsatzbeginn, Druckwerte in Intervallen, Rückzugsdruck, Ende.
FwDV 3: Einsatzstärke wird als Staffel/Gruppe/Zug erfasst.
Einsatzzeitstempel: Alarmierung, Ausrücken, Eintreffen, Einsatzende, Einrücken, Einsatzbereitschaft.

Sicherheits- und Rechtsleitplanken

Atemschutzüberwachung und Alarmmonitor sind sicherheitsrelevant. Jede entsprechende Ansicht zeigt einen Hinweis, dass die analoge Überwachung führend bleibt, solange das System nicht freigegeben ist.
Personenbezogene Daten: Löschkonzept, Export je Person, Aufbewahrungsfristen konfigurierbar.
Keine Telemetrie, keine externen CDNs, keine Google Fonts. Alles lokal.

Arbeitsweise

Arbeite phasenweise. Fasse nie mehrere Phasen in einem Schritt zusammen.
Beginne jede Phase mit dem Prisma-Schema, dann Migration, dann Server-Logik, dann UI, dann Tests.
Nach jeder Phase: docker compose up muss durchlaufen, npm run test muss grün sein, README-Abschnitt zur Phase ergänzen.
Wenn eine Anforderung fachlich unklar ist: nachfragen statt raten. Feuerwehr-Fachlichkeit ist regional unterschiedlich.

3.2 KiB Raw Blame History