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>
62 lines
3.2 KiB
Markdown
62 lines
3.2 KiB
Markdown
# 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
|
|
1. Jede Tabelle hat `organisationId` (Mandant). Postgres RLS ist aktiv.
|
|
Kein Query ohne Mandantenfilter.
|
|
2. Jede schreibende Operation erzeugt einen Eintrag in `AuditLog`
|
|
(Actor, Zeitpunkt, Entität, Vorher/Nachher als JSONB). Append-only.
|
|
3. Prüf-, Wartungs- und Buchungsdaten werden nie hart gelöscht (Soft-Delete
|
|
+ Versionierung).
|
|
4. Alle Fristen und Zeitberechnungen serverseitig, Zeitzone Europe/Berlin.
|
|
5. Berechtigungen zentral in `lib/authz.ts`. Keine Rollenprüfung in Komponenten.
|
|
6. Dateizugriff ausschließlich über `lib/storage.ts`.
|
|
7. 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. |