docs(arbeitskacheln): FOUND-013 Error-Tracking (GlitchTip) geplant, Index-Statuszeilen auf Ist-Stand nachgezogen
CI / backend-tests (push) Successful in 2m50s
CI / frontend-build (push) Successful in 18s

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVgbozhYmuEhiEJHffRXCV
This commit is contained in:
patrickandClaude Sonnet 5 committed 2026-09-10 13:33:01 +02:00
1 parent ddd1b446a2
commit fdeae8b5e3
2 files changed
+64 -21

No files matched your search

+20 -19
View File
@@ -127,14 +127,15 @@ vergeben statt geraten.
| FOUND-004 | Foundation | Authorization-Grundgerüst | P0 | M | MEDIUM | FOUND-003 | ✅ (`permission.py` Rollen/Berechtigungen) |
| FOUND-005 | Foundation | API-Grundgerüst/Konventionen | P0 | S | LOW | FOUND-002 | ✅ (`api/v1/api.py` Router-Sammlung) |
| FOUND-006 | Foundation | Logging & Audit-Grundgerüst | P0 | S | LOW | FOUND-002 | 🔶 (Historie-Modell/Audit-Trail vorhanden, kein strukturiertes Logging-Framework gefunden) |
| FOUND-007 | Foundation | CSV/XLS-Import/Export Objektstammdaten (neu, Referenz: HiOrg-Server) | P2 | M | MEDIUM | ASSET-003 | ⬜ (kein Massen-Import/Export gefunden) |
| FOUND-008 | Foundation | Generischer Fristen-Dienst (neu, Refactoring) | P3 | M | LOW | INV-005, PERS-007, MAINT-002 | ⬜ (drei getrennte Fristen-Implementierungen, kein gemeinsamer Dienst) |
| FOUND-007 | Foundation | CSV/XLS-Import/Export Objektstammdaten (neu, Referenz: HiOrg-Server) | P2 | M | MEDIUM | ASSET-003 | ✅ (`app/services/import_export.py`, CSV für Objekt+GeraetInstanz, kein XLS) |
| FOUND-008 | Foundation | Generischer Fristen-Dienst (neu, Refactoring) | P3 | M | LOW | INV-005, PERS-007, MAINT-002 | ✅ (`app/services/fristen.py`, Normalisierungsschicht mit Dringlichkeits-Ampel) |
| FOUND-007 | Foundation | Konfigurationsmanagement | P0 | XS | LOW | FOUND-001 | ✅ (`core/app_settings.py`, BaseSettings) |
| FOUND-008 | Foundation | Docker/Compose-Setup | P0 | M | MEDIUM | FOUND-001 | ⬜ (kein Dockerfile/docker-compose im Repo gefunden) |
| FOUND-009 | Foundation | CI/CD-Grundgerüst | P0 | S | LOW | FOUND-008 | ✅ (`.gitea/workflows/ci.yml` - Backend-Tests + Frontend-Build/Tests, vorheriger Abgleich hat nur `.github/` geprüft) |
| FOUND-010 | Foundation | Backup-Strategie | P1 | S | MEDIUM | FOUND-002 | ⬜ (kein Backup-Skript/-Dokumentation gefunden) |
| FOUND-011 | Foundation | Test-Grundgerüst | P0 | M | LOW | FOUND-002 | ✅ (`backend/pytest.ini`+`backend/tests/`, seit 2026-09-08 auch `frontend/vitest.config.ts`+`src/**/*.test.ts(x)`, beide in CI) |
| FOUND-012 | Foundation | Dokumentationsgerüst | P1 | XS | LOW | FOUND-001 | ✅ (`README.md` im Projektwurzelverzeichnis) |
| FOUND-013 | Foundation | Error-Tracking (GlitchTip, neu, geplant 2026-09-10) | P2 | M | LOW | — | ⬜ Plan steht, Zielserver-Entscheidung offen |
| IDENT-001 | Identity | Objekt-ID-Schema | P0 | S | LOW | FOUND-002 | ✅ (Objekt-Code-Vergabe, `/objekte/naechster-code`) |
| IDENT-002 | Identity | Inventarnummer manuell | P0 | S | LOW | IDENT-001 | ✅ (Objektposition-Code, `objektposition.py`) |
| IDENT-003 | Identity | Inventarnummer-Nummernschemata | P1 | M | MEDIUM | IDENT-002 | ✅ (`Nummernschema` je Objekttyp, Migration 0032, `/objekte/naechster-code?objekttyp_id=` nutzt es, Admin-UI in ObjekttypSection) |
@@ -152,7 +153,7 @@ vergeben statt geraten.
| FILE-005 | Digital File | Akte-Historienbereich | P0 | M | MEDIUM | FILE-001, FOUND-006 | ✅ (`historie.py`, `admin/HistorieSection.tsx`) |
| FILE-006 | Digital File | Akte-Übersichtsseite (UI) | P0 | M | LOW | FILE-002..005 | ✅ (`AktePage.tsx`) |
| FILE-007 | Digital File | Akte-Audit-Anbindung | P1 | S | LOW | FILE-005 | ✅ (Historie durchgängig in Akte eingebunden) |
| FILE-008 | Digital File | Manipulationssicheres Audit-Journal (Hash-Kette, neu, Referenz: KP Front/InvenTree) | P2 | M | MEDIUM | FOUND-006, FILE-007 | ⬜ (kein Hash-Ketten-Schutz im Audit-Log gefunden) |
| FILE-008 | Digital File | Manipulationssicheres Audit-Journal (Hash-Kette, neu, Referenz: KP Front/InvenTree) | P2 | M | MEDIUM | FOUND-006, FILE-007 | ✅ (`historie.hash`, `app/services/historie_hash.py`, Verifikations-Endpoint) |
| FILE-009 | Digital File | Freitext-Notizen in der Akte (neu) | P2 | S | LOW | FILE-001 | ⬜ (keine Notiz-Funktion in der Akte gefunden) |
| ASSET-001 | Assets | AssetCategory | P0 | XS | LOW | FOUND-002 | ✅ (`Kategorie` in `stammdaten.py`) |
| ASSET-002 | Assets | AssetType | P0 | S | LOW | ASSET-001 | ✅ (`Objekttyp` in `stammdaten.py`) |
@@ -163,7 +164,7 @@ vergeben statt geraten.
| ASSET-007 | Assets | AssetSet | P2 | M | MEDIUM | ASSET-003 | ⬜ (kein eigenständiges Set-Konzept über Objekt/Objektposition hinaus gefunden) |
| ASSET-008 | Assets | Consumable | P1 | M | MEDIUM | ASSET-002 | 🔶 (Verbrauchsmaterial über `MaterialTyp`/Mengenlogik abgebildet, kein eigenes Consumable-Modell) |
| ASSET-009 | Assets | Nutzungszähler (Kilometer/Betriebsstunden generisch) | P1 | S | LOW | ASSET-003 | ✅ (`fahrzeugdetails.py` Kilometerstand, MAINT-002 nutzt es) |
| ASSET-010 | Assets | Custody/Ausgabe an GeraetInstanz (neu, Referenz: Shelf.nu) | P2 | M | MEDIUM | ASSET-003, PERS-001, DOC-001 | ⬜ (kein Ausgabe-/Rücknahme-Konzept je Person gefunden; Design vollständig geklärt 2026-09-09, bereit für Implementierung) |
| ASSET-010 | Assets | Custody/Ausgabe an GeraetInstanz (neu, Referenz: Shelf.nu) | P2 | M | MEDIUM | ASSET-003, PERS-001, DOC-001 | ✅ (`geraet_instanz_custody`+`signier_token`, QR-Signier-Flow, `app/services/custody.py`) |
| FLEET-001 | Fleet | Fahrzeugtypen | P1 | XS | LOW | ASSET-002 | ✅ (Objekttyp deckt Fahrzeugtypen ab) |
| FLEET-002 | Fleet | Fahrzeuge (Kennzeichen/Funkrufname) | P1 | S | LOW | ASSET-003, FLEET-001 | ✅ (`fahrzeugdetails.py`: Kennzeichen, Funkrufname, OPTA/Funkkennung) |
| FLEET-003 | Fleet | Kilometerstand (Anwendung von ASSET-009) | P1 | XS | LOW | FLEET-002, ASSET-009 | ✅ (Kilometerstand-Feld + Wartungsintervall-Kopplung) |
@@ -202,7 +203,7 @@ vergeben statt geraten.
| MAINT-004 | Maintenance | Wartungshistorie | P2 | S | LOW | MAINT-003, FOUND-006 | ✅ (Wartungsauftrag-Status/Erledigen-Verlauf, `WartungsplanSection.tsx`) |
| MAINT-005 | Maintenance | Ersatzteile/Kosten | P3 | M | MEDIUM | MAINT-003 | ✅ (`WartungsauftragTeil`, Migration 0033, `/wartungsauftraege/{id}/teile`-CRUD, UI in `WartungSection.tsx`) |
| MAINT-006 | Maintenance | Wartungsdokument-Anbindung | P2 | XS | LOW | MAINT-003, DOC-001 | ✅ (Dokument polymorph, deckt Wartungsauftrag ab) |
| MAINT-007 | Maintenance | Tankbuch/Kraftstoffverbrauch (neu, Referenz: FleetMS) | P3 | S | LOW | FLEET-002, ASSET-009 | ⬜ (kein Kraftstoff-Tracking gefunden) |
| MAINT-007 | Maintenance | Tankbuch/Kraftstoffverbrauch (neu, Referenz: FleetMS) | P3 | S | LOW | FLEET-002, ASSET-009 | ✅ (`tankbuch_eintrag`, `app/services/tankbuch.py`, Verbrauchsberechnung) |
| DEFECT-001 | Defects | Mangelmeldung + Foto | P1 | M | LOW | ASSET-003, DOC-001 | ✅ (`mangel.py`, `MangelListePage.tsx`, Dokument-Anhang möglich) |
| DEFECT-002 | Defects | Priorität & Status-Workflow | P1 | S | LOW | DEFECT-001 | ✅ (`MangelStatus`, `MangelPrioritaet` Enums) |
| DEFECT-003 | Defects | Verantwortlicher & Reparaturzuordnung | P1 | S | LOW | DEFECT-002, PERS-002 | ✅ (Zustaendigkeit/Kontrollverantwortung koppelt an Mangel-Objekt) |
@@ -215,12 +216,12 @@ vergeben statt geraten.
| PERS-005 | Personnel | Qualifikationen/Lehrgänge | P1 | S | LOW | PERS-001 | ✅ (`Qualifikationstyp`, `BenutzerQualifikation`) |
| PERS-006 | Personnel | Führerscheine/Berechtigungen mit Gültigkeit | P1 | M | MEDIUM | PERS-005, ASSET-002 | ✅ (`Qualifikationskategorie.fuehrerschein`, `ObjekttypQualifikationsanforderung`) |
| PERS-007 | Personnel | Qualifikationsablauf-Warnungen | P1 | S | LOW | PERS-006 | ✅ (`QualifikationTile.tsx`, `/dashboard/qualifikationsablaeufe`) |
| READY-001 | Readiness | Regel-Engine (Grundgerüst) | P1 | M | HIGH | ASSET-004 | 🔶 (Logik existiert in `services/dashboard.py`/`services/akte.py`, aber fest verdrahtet statt konfigurierbare Engine) |
| READY-001 | Readiness | Regel-Engine (Grundgerüst) | P1 | M | HIGH | ASSET-004 | ✅ (`readiness_regel`-Tabelle, sieben Kriterien an/abschaltbar, keine volle Gewichtungs-Engine — bewusst reduzierter Scope) |
| READY-002 | Readiness | Zustände READY/LIMITED/NOT_READY/UNKNOWN | P1 | S | MEDIUM | READY-001 | ✅ (bereit/eingeschränkt/unbekannt/nicht_einsatzbereit in `services/dashboard.py`, laut DECISION-Abschnitt am 2026-09-05 live gefixt) |
| READY-003 | Readiness | Regel-Kopplung (Prüfung/Wartung/Mangel/Beladung) | P1 | L | HIGH | READY-002, INSP-004, DEFECT-005, LOAD-006 | ✅ (`einsatzbereitschaft()` zieht Fehlbestand/Mangel/Gerätestatus zusammen) |
| READY-004 | Readiness | Readiness-Dashboard | P1 | S | LOW | READY-003 | ✅ (`EinsatzbereitschaftTile.tsx`, `/dashboard/einsatzbereitschaft`) |
| READY-005 | Readiness | Regel-Konfiguration-UI | P2 | M | MEDIUM | READY-003 | ⬜ (keine UI zur Regel-Konfiguration gefunden, Regeln sind Code) |
| READY-006 | Readiness | Statistik-/Reporting-Dashboard-Kachel (neu, Referenz: HiOrg-Server) | P2 | M | MEDIUM | READY-004 | ⬜ (nur aktueller Zustand, keine Verlaufs-/Trend-Ansicht) |
| READY-006 | Readiness | Statistik-/Reporting-Dashboard-Kachel (neu, Referenz: HiOrg-Server) | P2 | M | MEDIUM | READY-004 | ✅ (`readiness_snapshot` täglicher Snapshot je Objekt, Dashboard-Trend + Akte-Historie) |
| DOC-001 | Documents | Dokument-Grundgerüst (Upload) | P1 | M | MEDIUM | FILE-001 | ✅ (`dokument.py` Model+Endpunkt, inkl. SHA-256-Duplikaterkennung, Migration 0024/0016 referenzieren DOC-001) |
| DOC-002 | Documents | Dokumenttypen | P2 | XS | LOW | DOC-001 | ✅ (`DokumentTyp`-Enum, Migration 0026, Filter beim Listen, Auswahl beim Upload) |
| DOC-003 | Documents | Versionierung | P2 | M | MEDIUM | DOC-001 | ✅ (`vorgaenger_id`-Kette, Migration 0027, `/ersetzen`+`/versionen`-Endpunkte, alte Version bleibt erhalten) |
@@ -231,15 +232,15 @@ vergeben statt geraten.
| MOBILE-003 | Mobile | Offline-Grundgerüst | P2 | L | HIGH | MOBILE-001 | 🔶 (`offline/queue.ts`, `useOnlineStatus.ts`, `SyncStatus.tsx` vorhanden — Warteschlange für Kontrollen, kein vollständiges Offline-App-Grundgerüst über alle Module) |
| MOBILE-004 | Mobile | Mobile Mangelmeldung + Foto | P1 | S | LOW | MOBILE-002, DEFECT-001 | ✅ (Mangel-Erfassung inkl. Foto/Dokument-Anhang, in Kontroll-Flow verdrahtet) |
| MOBILE-005 | Mobile | Mobile Beladungskontrolle | P1 | S | MEDIUM | MOBILE-002, LOAD-004 | ✅ (`KontrollPage.tsx` mit Fach-Gruppierung, mobil-optimiert laut Memory-Feedback) |
| OPS-001 | Operations | Einsatzverwaltung (Platzhalter) | P3 | L | HIGH | FILE-001 | ⬜ (kein Einsatz-Modell im Code, bewusst Platzhalter) |
| OPS-002 | Operations | Einsatzmittel-Verknüpfung | P3 | M | MEDIUM | OPS-001, ASSET-003 | ⬜ (kein Nachweis) |
| OPS-003 | Operations | Einsatznachbereitung (Platzhalter) | P3 | L | HIGH | OPS-001 | ⬜ (kein Nachweis) |
| OPS-001 | Operations | Einsatzverwaltung (Bedarf konkretisiert 2026-09-10) | P3 | L | HIGH | FILE-001 | ✅ (`einsatz`-Modell, Nachdokumentation) |
| OPS-002 | Operations | Einsatzmittel-Verknüpfung | P3 | M | MEDIUM | OPS-001, ASSET-003 | ✅ (`einsatz_ressource` M:N, ohne Zeitraum-Tracking) |
| OPS-003 | Operations | Einsatznachbereitung (Bedarf konkretisiert 2026-09-10) | P3 | L | HIGH | OPS-001 | ✅ (`einsatz.debriefing_notiz`, Nachbestellung nicht umgesetzt) |
| ZUST-001 | Zuständigkeit | Objekt/Standort ↔ Verantwortlicher | P0 | S | LOW | FOUND-002, ASSET-003 | ✅ (`Zustaendigkeit`-Modell, `zustaendigkeit.py`-Endpunkt) |
| ZUST-002 | Zuständigkeit | Objekt ↔ Benutzer/Gruppe (Kontrollzuweisung) | P1 | S | LOW | ZUST-001, PERS-003 | ✅ (`Kontrollverantwortung`-Modell, `KontrollverantwortungSection.tsx`) |
| ZUST-003 | Zuständigkeit | Standort-Scoping für granulare Berechtigungen (neu, Referenz: keines der Vergleichsprojekte löst das) | P2 | M | MEDIUM | ZUST-001, `permission.py` | ⬜ (Berechtigungen aktuell nur global, kein Standort-Scoping gefunden) |
| ZUST-003 | Zuständigkeit | Standort-Scoping für granulare Berechtigungen (neu, Referenz: keines der Vergleichsprojekte löst das) | P2 | M | MEDIUM | ZUST-001, `permission.py` | ✅ (`benutzer_rolle_zuordnung.standort_id`, `pruefe_berechtigung_am_standort()`) |
| NOTIF-001 | Notifications | Benachrichtigung bei neuem Fehlbestand | P1 | S | LOW | INV-006 | ✅ (`services/benachrichtigung.py`: `benachrichtige_neuer_fehlbestand`, E-Mail-Versand) |
| NOTIF-002 | Notifications | Eskalation lange offener Fehlbestände | P1 | M | MEDIUM | INV-006, NOTIF-001 | ✅ (`eskalation.py` Endpunkt+Konfiguration, `EskalationSection.tsx`) |
| NOTIF-003 | Notifications | Proaktive Wartungsfälligkeits-Benachrichtigung (neu, Referenz: Shelf.nu) | P2 | S | LOW | MAINT-002, NOTIF-001 | ⬜ (Fälligkeit wird berechnet, aber nicht proaktiv zugestellt) |
| NOTIF-003 | Notifications | Proaktive Wartungsfälligkeits-Benachrichtigung (neu, Referenz: Shelf.nu) | P2 | S | LOW | MAINT-002, NOTIF-001 | ✅ (`wartung_benachrichtigung`-Tracking, täglicher Timer) |
| SAT-001 | Satelliten-Server | Hauptserver mit Satelliten-Servern | P3 | L | HIGH | FOUND-002, ASSET-003, MOBILE-003 | 🔶 (`Systemknoten`-Modell mit `KnotenTyp.haupt/satellit` existiert, Docstring vermerkt aber "V1 nutzt ausschließlich den Hauptserver" — keine Sync-Logik implementiert) |
## Abhängigkeitsgraph (Epic-Ebene)
@@ -299,25 +300,25 @@ eigenes Modul (MAINT-\*, MABEA hat nur Prüfung, keine Wartung)**.
| `01_foundation.md` | FOUND-001 … FOUND-008 (001-006 vollständig/teilweise, FOUND-007/008 offen/ungeplant, Referenz HiOrg-Server, 2026-09-09) |
| `02_identity.md` | IDENT-001, 002, 004, 005 … 010 |
| `03_digital_file.md` | FILE-001 … FILE-009 (001-007 vollständig, FILE-008/009 offen/ungeplant, 2026-09-09/10) |
| `04_assets.md` | ASSET-001 … ASSET-010 (ASSET-009 nachträglich ergänzt, ASSET-010 offen/ungeplant, Referenz Shelf.nu, 2026-09-09) |
| `04_assets.md` | ASSET-001 … ASSET-010 (ASSET-009 nachträglich ergänzt, ASSET-010 ✅ umgesetzt 2026-09-10) |
| `05_fleet.md` | FLEET-001 … FLEET-006 (vollständig, FLEET-006 Referenz Resgrid AVL ergänzt 2026-09-09) |
| `06_inventory.md` | INV-001 … INV-007 (vollständig) |
| `07_warehouse.md` | WH-001 … WH-007 (vollständig) |
| `08_loadout.md` | LOAD-001 … LOAD-006 (vollständig) |
| `09_inspections.md` | INSP-001 … INSP-006 (vollständig) |
| `10_maintenance.md` | MAINT-001 … MAINT-007 (001-004+006 vollständig, 005 P3 zurückgestellt, MAINT-007 neu/offen, Referenz FleetMS, 2026-09-09) |
| `10_maintenance.md` | MAINT-001 … MAINT-007 (001-004+006 vollständig, 005 P3 zurückgestellt, MAINT-007 ✅ umgesetzt 2026-09-10) |
| `11_defects.md` | DEFECT-001 … DEFECT-005 (vollständig) |
| `12_personnel.md` | PERS-001 … PERS-007 (vollständig) |
| `13_readiness.md` | READY-001 … READY-006 (001-005 vollständig, READY-006 offen/ungeplant, Referenz HiOrg-Server, 2026-09-09) |
| `13_readiness.md` | READY-001 … READY-006 (alle ✅ umgesetzt, READY-001 bewusst reduzierter Scope ohne Gewichtung) |
| `14_documents.md` | DOC-001 … DOC-005 (vollständig) |
| `15_mobile.md` | MOBILE-001 … MOBILE-005 (vollständig) |
| `16_operations.md` | OPS-001 … OPS-003 (bewusst nur Platzhalter, siehe Datei) |
| `17_zustaendigkeit.md` | ZUST-001 … ZUST-003 (001/002 vollständig, ZUST-003 offen/ungeplant, Referenz Open-Source-Vergleich, 2026-09-09) |
| `18_notifications.md` | NOTIF-001 … NOTIF-003 (001/002 vollständig, NOTIF-003 offen/ungeplant, Referenz Shelf.nu, 2026-09-09) |
| `16_operations.md` | OPS-001 … OPS-003 (Bedarf konkretisiert, ✅ als kombiniertes Feature umgesetzt 2026-09-10) |
| `17_zustaendigkeit.md` | ZUST-001 … ZUST-003 (alle ✅ umgesetzt) |
| `18_notifications.md` | NOTIF-001 … NOTIF-003 (alle ✅ umgesetzt) |
| `19_satelliten_server.md` | SAT-001 (Platzhalter, nachträglich ergänzt, bewusst zurückgestellt, Referenz Emergency Management Tool bestätigt Konzept 2026-09-09) |
| `20_ui_redesign.md` | UI-001 … UI-008 (vollständig umgesetzt, 2026-09-06) |
| `21_akte_redesign.md` | AKTE-001 … AKTE-003 (vollständig umgesetzt, 2026-09-06) |
| `22_ui_redesign_v2.md` | UI2-001 … UI2-010 (alle offen, 001-005 ergänzt 2026-09-08, 006-010 ergänzt 2026-09-09 aus vertiefter Analyse, Grundlage: ai-coding-starter-kit-v2) |
| `22_ui_redesign_v2.md` | UI2-001 … UI2-010 (alle ✅ umgesetzt 2026-09-10, Grundlage: ai-coding-starter-kit-v2) |
| `23_flutter_begleitapp.md` | FLUT-001 (✅ Prototyp läuft v0.5.0, P3, Ergebnis Kamera-Vergleich noch nicht ausgewertet — Code liegt nicht in diesem Repo) |
**Alle 22 Epics durchgegangen** (16 ursprüngliche + 17 Zuständigkeit/18 Notifications/19
+44 -2
View File
@@ -244,11 +244,53 @@ nicht detaillierten) siehe `00_index.md`.
berücksichtigt Qualifikations-Ablauf generisch bei der Diensteinteilung —
technische Entsprechung ist jetzt der gemeinsame Fristen-Mechanismus.
## FOUND-013 — Error-Tracking (GlitchTip, P2, geplant 2026-09-10)
- **Ziel:** Unbehandelte Exceptions in Backend UND Frontend zentral erfassen,
statt sie nur verstreut in `journalctl`/Browser-Konsole zu finden.
- **Entscheidung 2026-09-10:** GlitchTip statt Sentry-Cloud — self-hosted,
Sentry-API-kompatibel (beide SDKs `sentry-sdk`/`@sentry/react` funktionieren
unverändert, nur DSN zeigt auf die eigene Instanz statt sentry.io). Bei
Rettungsdienst-Kontext (potenzieller Art.-9-DSGVO-Bezug) bleiben Fehlerdaten
damit auf eigener Infrastruktur statt bei einem US-SaaS-Anbieter.
- **Standort — bewusst nicht festgeschrieben:** GlitchTip braucht nur eine
DSN-URL in Backend-`.env` (`SENTRY_DSN`) und Frontend-Build
(`VITE_SENTRY_DSN`) — läuft auf 192.168.1.238, einem separaten Server, oder
später sogar GlitchTips eigenem SaaS, ohne Codeänderung. Standortwechsel
ist reines Config-Ändern + Neustart, kein Redeploy-Zwang der MABEA-Business-
Logik. **Konkreter Zielserver noch offen** — DECISION REQUIRED vor
Inbetriebnahme (192.168.1.238 selbst, oder ein neuer/separater Host analog
zu 192.168.1.236 für Flutter).
- **Abhängigkeiten:** keine (additiv, keine bestehende Funktion betroffen)
- **Betrieb (GlitchTip selbst):** Docker Compose (GlitchTip-Container +
Postgres + Redis + optional Celery-Worker) — GlitchTip wird offiziell nur
als Docker-Image vertrieben, kein natives Debian-Paket. Widerspricht nicht
CLAUDE.md „kein Docker-Zwang" (das gilt für MABEA selbst, das bereits ohne
Docker läuft) — für GlitchTip als Fremdsoftware ist Docker die einzige
praktikable Betriebsart, isoliert vom restlichen Server-Setup.
- **Backend:** `sentry-sdk[fastapi]` als Dependency, Initialisierung in
`app/main.py` (DSN aus `app_settings.py`, No-Op wenn DSN leer/nicht
gesetzt — Fail-Safe, kein Fehler-Tracking bricht den Start nicht ab).
- **Frontend:** `@sentry/react`, Initialisierung in `main.tsx` (DSN aus
`VITE_SENTRY_DSN`, ebenfalls No-Op wenn ungesetzt).
- **Rechte/Zugriff:** GlitchTip hat eigene Benutzerverwaltung (kein
MABEA-Login-Bezug) — Zugriff auf die Fehler-Übersicht separat einzurichten.
- **Datenschutz:** IP-Adressen/Nutzerdaten in Fehlerberichten sind DSGVO-
relevant (`send_default_pii` explizit auf `False` lassen), Payload-Scrubbing
für bekannte sensible Felder (Login/Passwort-Felder) vor Rollout prüfen.
- **Akzeptanzkriterien:** eine absichtlich ausgelöste Backend-Exception UND
eine Frontend-Exception erscheinen in GlitchTip mit Stacktrace.
- **Tests:** keine (reine Infrastruktur-/Konfigurationsintegration).
- **DoD:** offen — Plan steht, **Zielserver-Entscheidung + tatsächliche
Docker-Compose-Inbetriebnahme ausstehend**, nicht ohne explizite
Bestätigung durchführen (Server-Deploy-Regel, CLAUDE.md).
---
**MABEA-Ist-Stand-Abgleich:** FOUND-001…006 sind in MABEA vollständig vorhanden
(FastAPI-Grundgerüst, Alembic-Migrationen, JWT-Login, `require_roles()`-Dependency,
einheitliches Fehlerformat + `/docs`, `historie`-Tabelle als Audit-Log). FOUND-007…012
(Konfiguration/Docker/CI/Backup/Tests/Doku) ebenfalls größtenteils vorhanden
(`app_settings.py`, `.env`, Gitea-CI `ci.yml`, `pytest`, README/DEVLOG) — kein Nachholbedarf
in diesem Epic.
(`app_settings.py`, `.env`, Gitea-CI `ci.yml`, `pytest`, README/DEVLOG). FOUND-013
(Error-Tracking) als einzige echte Lücke identifiziert und geplant (2026-09-10),
Umsetzung hängt an einer noch offenen Zielserver-Entscheidung.