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>
29 lines
1.7 KiB
Markdown
29 lines
1.7 KiB
Markdown
Phase 2: Wartungs- und Prüfmanagement. Das ist das wichtigste Modul.
|
|
|
|
Modelle: Wartungsvorlage (Name, Geraetetyp, Intervall in Monaten,
|
|
Vorwarnzeit, Pruefvorschrift-Referenz), Checklistenpunkt (Text, Typ:
|
|
ja_nein | messwert | text | foto, Pflichtfeld, Sollwert), Wartungstermin
|
|
(Geraet, Vorlage, faellig_am, Status), Pruefung (Termin, Prüfer,
|
|
durchgefuehrt_am, Dauer in Minuten, Ergebnis: bestanden |
|
|
bestanden_mit_maengeln | nicht_bestanden, extern durchgeführt von,
|
|
Kosten), Pruefergebnis (Checklistenpunkt, Wert, Foto), Signatur,
|
|
Mangel (Geraet, Melder, Beschreibung, Foto, Prioritaet, Status,
|
|
behoben_am, behoben_von), Rueckruf (Hersteller, betroffene Typen/Chargen).
|
|
|
|
Funktionen:
|
|
- Fristen-Dashboard: überfällig / diese Woche / diesen Monat / nächste 90 Tage,
|
|
gruppierbar nach Fahrzeug, Standort, Gerätetyp, Prüfer
|
|
- BullMQ-Job (nächtlich): Termine generieren, Erinnerungen bei T-30/T-7/T-0,
|
|
Gerätestatus automatisch auf "pruefung_faellig" setzen
|
|
- Prüfungs-Wizard: Checkliste Schritt für Schritt, Fotoupload je Punkt,
|
|
Zeiterfassung, Unterschrift auf Canvas (Touch und Maus)
|
|
- PDF-Prüfprotokoll via Gotenberg: Kopf mit Wehr/Gerät/Prüfer-ID,
|
|
Checkliste mit Ergebnissen, eingebettete Fotos, eingebettete Signatur,
|
|
Fußzeile mit Prüfvorschrift und Prüfdatum. Ablage in MinIO, unveränderbar.
|
|
- Lebensdauerüberwachung: Warnung X Monate vor Ablauf, Vorschlag zur Aussonderung
|
|
- Rückrufe: betroffene Geräte automatisch markieren und optional sperren
|
|
- Externe Wartung: Fachfirma erfassen, Fremdprotokoll als PDF anhängen
|
|
- Mängel-Workflow: melden → zugewiesen → in Arbeit → behoben, mit Benachrichtigung
|
|
|
|
Wichtig: Ein abgeschlossenes Prüfprotokoll ist unveränderbar. Korrekturen
|
|
erzeugen ein neues Protokoll mit Verweis auf das ursprüngliche. |