docs(arbeitskacheln): Open-Source-/HiOrg-Vergleich ausgewertet, 14 neue Kacheln ausgearbeitet
Vergleich mit InvenTree, Snipe-IT, Grocy, Shelf.nu, Resgrid, KP Front, FleetMS, HiOrg-Server ergibt neue Kacheln (ASSET-010 Custody, FILE-008 Hash-Audit-Journal, FILE-009 Notizen, NOTIF-003, MAINT-007 Tankbuch, ZUST-003 Standort-Scoping, FOUND-007 Import/Export, FOUND-008 Fristen-Dienst, READY-006 Statistik-Dashboard, UI2-006..010) sowie Referenz-Ergänzungen bei bestehenden Lücken. Alle Design- Entscheidungen (Datenmodell, Sicherheitsanforderungen bei ASSET-010) geklärt. Neues Epic 23 (Flutter-Begleit-App, Sondierungs-Prototyp FLUT-001) inkl. geklärtem TLS-Blocker (Domain mabea.perlbach-edv.de mit Let's-Encrypt-Zertifikat statt selbstsigniertem Server-Zertifikat). Alle Kacheln bleiben offen/ungeplant, nur ausgearbeitet, keine Implementierung. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CVgbozhYmuEhiEJHffRXCV
This commit is contained in:
Claude Sonnet 5
@@ -11963,3 +11963,458 @@ Keine Commits in dieser Session.
|
||||
- frontend/package.json | 6 +-
|
||||
|
||||
---
|
||||
## 2026-09-08 22:44 – 22:47 (2m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
- 3e39c3b fix(frontend): @vitejs/plugin-react auf v6 für Vite-8-Kompatibilität
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-08 22:47 – 22:47 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-08 22:49 – 22:49 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-08 22:49 – 22:50 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-08 23:28 – 23:28 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-08 23:30 – 23:30 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-08 23:33 – 23:33 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 08:41 – 08:41 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 08:41 – 08:41 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 08:42 – 08:42 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 08:43 – 08:44 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 08:43 – 08:44 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 08:43 – 08:44 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 08:47 – 08:48 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 08:48 – 08:48 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 08:50 – 08:50 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 08:54 – 08:54 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:19 – 09:19 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:20 – 09:20 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:23 – 09:24 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:24 – 09:24 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:25 – 09:25 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:26 – 09:26 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:26 – 09:27 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:27 – 09:27 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:27 – 09:28 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:30 – 09:31 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:32 – 09:33 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:34 – 09:35 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:35 – 09:35 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:12 – 00:13 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:15 – 00:15 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:16 – 00:16 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:19 – 00:22 (3m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** timemaster
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:23 – 00:24 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
|
||||
+24
-14
@@ -17,9 +17,8 @@ Kachel-Template und Nutzer-Vorgaben zur Methodik: siehe Memory
|
||||
self-hosted-tauglich) statt Resgrid-(.NET)/OpenFleet-(Node) Stack zu übernehmen.
|
||||
3. **QR-Code-Inhalt-Schema:** **entschieden — URL-Pfad** (`/akte/{ressourcentyp}/{id}`), kein
|
||||
signierter Token, keine Volldaten im QR.
|
||||
4. **Person/Benutzer-Trennung (PERS-001/002):** MABEA hat aktuell nur `Benutzer` (Login=Person
|
||||
verschmolzen). Echte Trennung ist ein Datenmodell-Bruch — Umfang vorher separat abschätzen,
|
||||
bevor verbindlich eingeplant.
|
||||
4. ✅ **Person/Benutzer-Trennung (PERS-001/002) — erledigt (2026-09-08):** echter Bedarf
|
||||
bestätigt, danach umgesetzt und deployed. Siehe `12_personnel.md`.
|
||||
5. ✅ **UNKNOWN-Readiness-Zustand (READY-002) — erledigt (2026-09-05):** war offen, wurde
|
||||
noch am selben Tag live gefixt. Nie kontrollierte Objekte zählen jetzt als `unbekannt`
|
||||
statt fälschlich als „einsatzbereit". Siehe `13_readiness.md`.
|
||||
@@ -82,6 +81,7 @@ für sicherheitskritische (owasp/jwt/oauth) und datenbanknahe (postgres/sql) The
|
||||
| 17 Zuständigkeit | Verantwortliche flexibel Standorten/Objekten zuordnen | P0 |
|
||||
| 18 Notifications | Benachrichtigung + Eskalation bei Fehlbestand | P1 |
|
||||
| 19 Satelliten-Server | Autarker Betrieb bei Verbindungsverlust (zurückgestellt) | P3 |
|
||||
| 23 Flutter-Begleit-App | Sondierungs-Prototyp, native App vs. PWA (Kamera-Vergleich) | P3 |
|
||||
|
||||
## Stand 2026-09-08: Code-Abgleich
|
||||
|
||||
@@ -127,6 +127,8 @@ 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 | 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) |
|
||||
@@ -150,6 +152,8 @@ 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-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`) |
|
||||
| ASSET-003 | Assets | Asset/AssetInstance | P0 | M | MEDIUM | ASSET-002, IDENT-001/002/004 | ✅ (`objekt.py`, `objektposition.py`, `geraet_instanz.py`) |
|
||||
@@ -159,6 +163,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) |
|
||||
| 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) |
|
||||
@@ -177,7 +182,7 @@ vergeben statt geraten.
|
||||
| WH-003 | Warehouse | Bestand je Lagerplatz | P1 | M | MEDIUM | WH-002, INV-003 | ✅ (`Bestand`-Modell referenziert WH-003) |
|
||||
| WH-004 | Warehouse | Einlagerung/Auslagerung | P1 | M | MEDIUM | WH-003 | ✅ (`services/lager.py` Ein-/Auslagerungsfunktionen referenzieren WH-004) |
|
||||
| WH-005 | Warehouse | Umlagerung | P1 | S | LOW | WH-004 | ✅ (`/lagerplaetze/.../umlagerung`-Endpunkt referenziert WH-005) |
|
||||
| WH-006 | Warehouse | Inventur & Bestandskorrektur | P2 | M | MEDIUM | WH-003 | 🔶 (Bestandskorrektur über Ein-/Auslagerung möglich, kein eigener Inventur-Workflow/Zählliste gefunden) |
|
||||
| WH-006 | Warehouse | Inventur & Bestandskorrektur | P2 | M | MEDIUM | WH-003 | 🔶 (Bestandskorrektur über Ein-/Auslagerung möglich, kein eigener Inventur-Workflow/Zählliste gefunden; Referenz: InvenTree Rolling-Stocktake als optionale Ergänzung) |
|
||||
| WH-007 | Warehouse | Materialbewegungsprotokoll | P1 | S | LOW | WH-004, FOUND-006 | ✅ (`Materialbewegung`, `lagerbewegung.py`, referenziert WH-007) |
|
||||
| LOAD-001 | Loadout | Soll-Beladung/Beladungsplan | P1 | M | MEDIUM | ASSET-003, INV-002/003 | ✅ (`vorlage.py` Beladungsvorlage, `BeladungsplanerBoard.tsx`) |
|
||||
| LOAD-002 | Loadout | Ist-Beladung | P1 | S | LOW | LOAD-001 | ✅ (Objektposition-Istmenge, `GeraeteInstanzenListe.tsx`) |
|
||||
@@ -197,6 +202,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) |
|
||||
| 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) |
|
||||
@@ -214,6 +220,7 @@ vergeben statt geraten.
|
||||
| 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) |
|
||||
| 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) |
|
||||
@@ -229,8 +236,10 @@ vergeben statt geraten.
|
||||
| OPS-003 | Operations | Einsatznachbereitung (Platzhalter) | P3 | L | HIGH | OPS-001 | ⬜ (kein Nachweis) |
|
||||
| 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) |
|
||||
| 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) |
|
||||
| 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)
|
||||
@@ -287,28 +296,29 @@ eigenes Modul (MAINT-\*, MABEA hat nur Prüfung, keine Wartung)**.
|
||||
|
||||
| Datei | Enthält Details für |
|
||||
|---|---|
|
||||
| `01_foundation.md` | FOUND-001 … FOUND-006 |
|
||||
| `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-007 (vollständig) |
|
||||
| `04_assets.md` | ASSET-001 … ASSET-009 (vollständig, ASSET-009 nachträglich ergänzt) |
|
||||
| `05_fleet.md` | FLEET-001 … FLEET-006 (vollständig) |
|
||||
| `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) |
|
||||
| `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-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) |
|
||||
| `11_defects.md` | DEFECT-001 … DEFECT-005 (vollständig) |
|
||||
| `12_personnel.md` | PERS-001 … PERS-007 (vollständig) |
|
||||
| `13_readiness.md` | READY-001 … READY-005 (vollständig) |
|
||||
| `13_readiness.md` | READY-001 … READY-006 (001-005 vollständig, READY-006 offen/ungeplant, Referenz HiOrg-Server, 2026-09-09) |
|
||||
| `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-002 (vollständig, nachträglich ergänzt) |
|
||||
| `18_notifications.md` | NOTIF-001 … NOTIF-002 (vollständig, nachträglich ergänzt) |
|
||||
| `19_satelliten_server.md` | SAT-001 (Platzhalter, nachträglich ergänzt, bewusst zurückgestellt) |
|
||||
| `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) |
|
||||
| `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-005 (offen, ergänzt 2026-09-08, Grundlage: Subagenten-Analyse ai-coding-starter-kit-v2) |
|
||||
| `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) |
|
||||
| `23_flutter_begleitapp.md` | FLUT-001 (Sondierungs-Prototyp, offen, P3, 2026-09-10 — TLS-Blocker beachten) |
|
||||
|
||||
**Alle 22 Epics durchgegangen** (16 ursprüngliche + 17 Zuständigkeit/18 Notifications/19
|
||||
Satelliten-Server/20 UI-Redesign/21 Akte-Redesign/22 UI-Redesign Runde 2, nachträglich
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
# Epic 01 — Foundation
|
||||
|
||||
Details zu FOUND-001 … FOUND-006. Übersichtstabelle mit allen FOUND-Kacheln (auch die noch
|
||||
Details zu FOUND-001 … FOUND-008. FOUND-007/008 ergänzt am 2026-09-09 aus
|
||||
HiOrg-Server-Vergleich, offen/ungeplant. Übersichtstabelle mit allen FOUND-Kacheln (auch die noch
|
||||
nicht detaillierten) siehe `00_index.md`.
|
||||
|
||||
---
|
||||
@@ -128,6 +129,102 @@ nicht detaillierten) siehe `00_index.md`.
|
||||
- **Tests:** Log-Eintrag wird bei simulierter Aktion erzeugt und ist abrufbar.
|
||||
- **DoD:** mind. ein reales Ereignis (z.B. Login) wird bereits geloggt.
|
||||
|
||||
## FOUND-007 — CSV/XLS-Import/Export für Objekt- und Materialstammdaten (P2, neu,
|
||||
Scope geklärt 2026-09-09)
|
||||
|
||||
- **Ziel:** Massenpflege von Objekt- UND Materialstammdaten statt Einzelanlage per
|
||||
UI.
|
||||
- **Scope (entschieden 2026-09-09):** beide Ebenen — `Objekt` (Behälter-Stammdaten:
|
||||
Rucksack/Fahrzeug/Standort) UND `GeraetInstanz` (Einzelgeräte mit Seriennummer
|
||||
darin). Passt zum Ursprungsfall Excel-Rucksackliste, wo beide Ebenen typischerweise
|
||||
in einer Tabelle stehen.
|
||||
- **Beschreibung:** Export bestehender Objekte+Geräteinstanzen als CSV, Import mit
|
||||
Validierung (Duplikat-Erkennung über Inventarnummer/Seriennummer, Fehlerliste bei
|
||||
ungültigen Zeilen statt Alles-oder-Nichts-Abbruch). Ein Import-Vorgang kann beide
|
||||
Ebenen in einer Datei abdecken (verschachtelte Struktur: Objekt-Zeile + zugehörige
|
||||
Geräte-Zeilen) oder zwei getrennte Dateien — Implementierungsdetail, nicht mehr
|
||||
Scope-Frage.
|
||||
- **Benutzerwert:** Direkter Nutzen für den Ursprungsfall von MABEA — Migration
|
||||
bestehender Excel-Rucksacklisten in Massenpflege statt Zeile für Zeile manuell
|
||||
nacherfassen, inklusive der darin enthaltenen Einzelgeräte.
|
||||
- **Abhängigkeiten:** ASSET-003, `GeraetInstanz`-Modell
|
||||
- **Datenmodell:** keins neu (nutzt bestehende Objekt-/GeraetInstanz-Tabellen)
|
||||
- **Backend:** `POST /objekte/import` + `POST /geraete/import` (oder kombinierter
|
||||
Endpunkt, je nach gewählter Dateistruktur), jeweils Dry-Run-Modus + Commit-Modus;
|
||||
`GET /objekte/export` + `GET /geraete/export`
|
||||
- **Frontend:** Upload-Dialog mit Fehlerliste-Anzeige vor endgültigem Import,
|
||||
Export-Button in Objektliste UND Geräte-/Materialansicht
|
||||
- **Mobile:** nein (Desktop-Verwaltungsaufgabe)
|
||||
- **QR-Code/Seriennummer/Inventarnummer:** Duplikat-Prüfung läuft darüber
|
||||
- **Akte:** nein direkt
|
||||
- **Rechte:** Administrator/Materialverantwortlicher
|
||||
- **Audit:** Import als Sammel-Ereignis geloggt (nicht jede Zeile einzeln)
|
||||
- **Akzeptanzkriterien:** Import mit teilweise fehlerhaften Zeilen zeigt genau welche
|
||||
Zeilen fehlschlugen, gültige Zeilen werden trotzdem übernommen (kein Alles-oder-
|
||||
Nichts); Export re-importierbar (Round-Trip-Test), sowohl für Objekte als auch
|
||||
für Geräteinstanzen; Geräte-Zeilen ohne zugehöriges Objekt werden abgelehnt
|
||||
(referenzielle Konsistenz).
|
||||
- **Tests:** Round-Trip-Test (Export→Import ergibt identischen Bestand) für beide
|
||||
Ebenen, Fehlerzeilen-Test (gemischt gültig/ungültig), Test für
|
||||
Objekt+zugehörige-Geräte in einem Import-Vorgang.
|
||||
- **DoD:** offen. **Referenz (HiOrg-Server-Vergleich 2026-09-09):** HiOrg bietet
|
||||
Import/Export für praktisch alle Datentypen (CSV/XLS/vCard/iCal) — MABEA hat dafür
|
||||
aktuell keinen erkennbaren Mechanismus außer direkter API-Nutzung.
|
||||
|
||||
## FOUND-008 — Generischer Fristen-Dienst (P3, neu, Schnittstelle geklärt 2026-09-09)
|
||||
|
||||
- **Ziel:** EINE Berechnungslogik für „läuft etwas bald ab/wird etwas bald fällig"
|
||||
statt mehrfach separat implementiert.
|
||||
- **Beschreibung:** MABEA hat Ablauf-/Fälligkeitslogik aktuell an drei Stellen
|
||||
unabhängig voneinander gebaut: Chargen-Ablaufdatum (INV-005), Qualifikations-
|
||||
Ablaufwarnung (PERS-007), Wartungsfälligkeit (MAINT-002/NOTIF-003). Ein
|
||||
gemeinsamer `Fristen`-Dienst (Interface: „gib mir alle Objekte mit Frist-Typ X,
|
||||
die den Dringlichkeitsgrad Y erreicht haben" — siehe Schnittstelle unten) würde
|
||||
die Berechnungslogik einmal statt dreimal pflegen.
|
||||
- **Benutzerwert:** Kein direkter Nutzerwert (reines Refactoring), aber weniger
|
||||
Wartungsaufwand/Inkonsistenz-Risiko bei künftigen Fristen-Arten (z.B. Vertrags-
|
||||
laufzeiten, TÜV-Termine).
|
||||
- **Abhängigkeiten:** INV-005, PERS-007, MAINT-002 (bestehende Implementierungen als
|
||||
Migrationsbasis)
|
||||
- **Datenmodell:** keins neu, gemeinsame `FristTyp`-Enum als Kategorisierung
|
||||
(`charge_ablauf`/`qualifikation_ablauf`/`wartung_faellig`/...)
|
||||
- **Schnittstelle (entschieden 2026-09-09, korrigiert 2026-09-10):** „Tage bis
|
||||
fällig" als gemeinsamer Nenner funktioniert NICHT für km/Betriebsstunden-Fristen
|
||||
— MABEA verfolgt keine Verbrauchsrate über Zeit (nur den aktuellen Zählerstand),
|
||||
eine Tage-Schätzung wäre erfunden/unbegründet. Stattdessen: gemeinsame
|
||||
`FristTreffer`-Struktur mit **Dringlichkeits-Ampel** statt einheitlicher
|
||||
Zeiteinheit — `{objekt_id, frist_typ, bezeichnung, dringlichkeit: enum
|
||||
(ok/bald/kritisch/ueberfaellig), rest_anzeige: str}`. `rest_anzeige` bleibt
|
||||
je Typ in seiner nativen Einheit (z.B. „in 12 Tagen" bei Datum-Fristen, „noch
|
||||
340 km" bei Kilometer-Fristen, „noch 15 Bh" bei Betriebsstunden) — nur die
|
||||
Ampel-Einstufung (ok/bald/kritisch/überfällig) ist typübergreifend einheitlich
|
||||
vergleichbar, die Restanzeige selbst bleibt nativ und ehrlich statt einer
|
||||
erfundenen Tage-Umrechnung. Jede der drei Implementierungen bringt ihre eigene
|
||||
Schwellenwert-Logik mit (z.B. „< 10% der Sollstrecke übrig" = kritisch bei km),
|
||||
`fristen.py` normalisiert nur auf die gemeinsame Ampel, nicht auf eine
|
||||
gemeinsame Zeiteinheit.
|
||||
- **Backend:** `app/services/fristen.py` als gemeinsame Schnittstelle, bestehende
|
||||
drei Implementierungen (`app/services/dashboard.py`, `app/services/akte.py`,
|
||||
`app/services/personal.py`, `app/services/wartung.py:faellige_wartungen_fuer_objekt`)
|
||||
schrittweise darauf umstellen (nicht big-bang) — jede liefert intern weiter ihre
|
||||
Rohdaten, `fristen.py` übernimmt nur die Normalisierung auf `FristTreffer`.
|
||||
- **Frontend:** keine Änderung sichtbar (reines Backend-Refactoring)
|
||||
- **Mobile:** keins
|
||||
- **QR-Code/Seriennummer/Inventarnummer:** nein
|
||||
- **Akte:** nein direkt
|
||||
- **Rechte:** keine Änderung
|
||||
- **Audit:** keine Änderung
|
||||
- **Akzeptanzkriterien:** alle drei bestehenden Fristen-Arten liefern nach Umstellung
|
||||
identische Ergebnisse wie vorher (Regressionstest), neue Fristen-Art ohne
|
||||
Duplikation der Kernlogik hinzufügbar.
|
||||
- **Tests:** Regressionstests der drei bestehenden Fristen-Berechnungen gegen die
|
||||
neue gemeinsame Implementierung.
|
||||
- **DoD:** offen, **P3 — reines Refactoring, kein MVP-Bestandteil**. Schnittstelle
|
||||
geklärt (2026-09-09), bereit für Implementierung. **Referenz
|
||||
(HiOrg-Server-Vergleich 2026-09-09):** HiOrg berücksichtigt Qualifikations-Ablauf
|
||||
generisch bei der Diensteinteilung — technische Entsprechung wäre bei MABEA ein
|
||||
gemeinsamer Fristen-Mechanismus statt drei getrennter Implementierungen.
|
||||
|
||||
---
|
||||
|
||||
**MABEA-Ist-Stand-Abgleich:** FOUND-001…006 sind in MABEA vollständig vorhanden
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# Epic 03 — Digital File (Akte)
|
||||
|
||||
Details zu FILE-001 … FILE-007 (vollständig).
|
||||
Details zu FILE-001 … FILE-009. FILE-001-007 vollständig, FILE-008 ergänzt am 2026-09-09
|
||||
aus Open-Source-Vergleich (KP Front/InvenTree), FILE-009 (Notizen) ergänzt am
|
||||
2026-09-10 — beide offen/ungeplant.
|
||||
|
||||
---
|
||||
|
||||
@@ -155,6 +157,72 @@ Details zu FILE-001 … FILE-007 (vollständig).
|
||||
Personal/Objekt-Änderungen ohne Audit-Eintrag) schon einmal real gefunden und gefixt
|
||||
wurde. Diese Kachel ist der methodische Nachfolgeschritt: systematisch statt punktuell.
|
||||
|
||||
## FILE-008 — Manipulationssicheres Audit-Journal (Hash-Kette, P2, neu)
|
||||
|
||||
- **Ziel:** Nachweisen können, dass ein Audit-Log-Eintrag nachträglich nicht verändert
|
||||
wurde — über reines Vorhandensein (FILE-007) hinaus.
|
||||
- **Beschreibung:** Jeder Audit-Log-Eintrag bekommt zusätzlich einen Hash über
|
||||
(Eintragsinhalt + Hash des Vorgängereintrags) — bricht die Kette erkennbar, sobald
|
||||
irgendein historischer Eintrag verändert wird. Betrifft insbesondere Kontroll-
|
||||
Ergebnisse, Wartungsprotokolle und Soll/Ist-Korrekturbuchungen (WH-006), wo
|
||||
BOS-Dokumentationspflichten Nachweisbarkeit verlangen.
|
||||
- **Benutzerwert:** Rechtssicherer Nachweis bei Prüfungen/Vorfällen, dass Protokolle
|
||||
echt und unverändert sind — nicht nur „es gibt einen Log-Eintrag", sondern „der
|
||||
Log-Eintrag ist beweisbar unverändert".
|
||||
- **Abhängigkeiten:** FOUND-006 (Audit-Log), FILE-007
|
||||
- **Datenmodell:** `historie.hash` (SHA-256 über Inhalt+Vorgänger-Hash) — **nicht**
|
||||
`audit_log`, MABEAs reale Tabelle heißt `historie` (`FOUND-006`). **Entschieden
|
||||
(2026-09-09): Kette läuft pro Ressource (Objekt-ID)**, nicht global — jedes
|
||||
Objekt hat seine eigene Kette, erster Eintrag je Objekt mit fixem
|
||||
Genesis-Wert. Verifikations-Endpoint prüft/meldet damit je Objekt einzeln statt
|
||||
eine einzige globale Bruchstelle für die ganze `historie`-Tabelle.
|
||||
- **Backend:** Hash-Berechnung beim Schreiben, Verifikations-Endpoint (Kette prüfen,
|
||||
Bruchstelle melden falls vorhanden)
|
||||
- **Frontend:** „Integrität geprüft ✓"-Anzeige im Akte-Historienbereich (FILE-005),
|
||||
Warnung bei Kettenbruch
|
||||
- **Mobile:** nein
|
||||
- **QR-Code/Seriennummer/Inventarnummer:** nein
|
||||
- **Akte:** Vertrauensanzeige im Historienbereich
|
||||
- **Rechte:** Verifikation: Administrator; Anzeige „geprüft"-Status: wie Lese-Recht
|
||||
- **Audit:** ist Gegenstand dieser Kachel selbst
|
||||
- **Akzeptanzkriterien:** nachträgliche Änderung eines historischen Eintrags (z.B. direkt
|
||||
in der DB) wird vom Verifikations-Lauf erkannt und gemeldet.
|
||||
- **Tests:** Kettenbruch-Erkennungstest (Eintrag nachträglich manipuliert → Verifikation
|
||||
schlägt fehl), Normalfall-Test (unveränderte Kette → Verifikation erfolgreich).
|
||||
- **DoD:** offen. **Referenz (Open-Source-Vergleich 2026-09-09):** KP Front
|
||||
(`feuerwehr-oberwil/kp-front`, AGPL-3.0-or-later — nur Muster) nutzt genau dieses
|
||||
Hash-Ketten-Prinzip für sein Einsatzjournal. Kombiniert mit InvenTree-Vorbild
|
||||
(lückenloser Stock-History-Trail bei jeder Bestandsänderung) — WH-006-Korrekturbuchungen
|
||||
sollten ebenfalls durch diese Kette laufen, sobald WH-006 umgesetzt wird.
|
||||
|
||||
## FILE-009 — Freitext-Notizen in der Akte (P2, neu, 2026-09-10)
|
||||
|
||||
- **Ziel:** Formlose, freie Notizen zu einer Ressource festhalten — Dinge, die in
|
||||
keinen strukturierten Teilbereich (Prüfung/Mangel/Wartung) passen.
|
||||
- **Beschreibung:** Einfaches Freitextfeld je Ressource, mehrere Notizen möglich
|
||||
(chronologische Liste, nicht nur ein einzelnes Textfeld), mit Autor+Zeitstempel.
|
||||
Kein Rich-Text/Formatierung nötig, reiner Text reicht.
|
||||
- **Benutzerwert:** Raum für Kontext, der sonst mündlich verlorengeht (z.B.
|
||||
„Funkgerät klemmt manchmal beim Einschalten, noch kein reproduzierbarer Fehler
|
||||
für ein Mangel-Ticket" oder „Rücksprache mit Hersteller am 12.03. — Ersatzteil
|
||||
in 2 Wochen").
|
||||
- **Abhängigkeiten:** FILE-001
|
||||
- **Datenmodell:** `akte_notiz` (id, entitaet_typ, entitaet_id, text, autor_id,
|
||||
erstellt_am) — polymorph wie `dokument` (DOC-001), gleiches Kopplungsmuster
|
||||
- **Backend:** POST/GET/DELETE (Löschen nur eigene Notiz oder Administrator)
|
||||
- **Frontend:** Notiz-Panel in der Akte (FILE-006-Übersichtsseite), Eingabefeld +
|
||||
chronologische Liste
|
||||
- **Mobile:** Anzeige + Erfassung (einfaches Textfeld, kein Zusatzaufwand)
|
||||
- **QR-Code/Seriennummer/Inventarnummer:** nein
|
||||
- **Akte:** ist dieser Bereich selbst
|
||||
- **Rechte:** Anlegen: Mitarbeiter+; Löschen: eigene Notiz oder Administrator
|
||||
- **Audit:** Anlegen/Löschen geloggt
|
||||
- **Akzeptanzkriterien:** mehrere Notizen chronologisch je Ressource sichtbar,
|
||||
Löschen nur durch Autor oder Administrator möglich.
|
||||
- **Tests:** CRUD-Test, Berechtigungstest (fremde Notiz nicht löschbar außer als
|
||||
Administrator).
|
||||
- **DoD:** offen.
|
||||
|
||||
---
|
||||
|
||||
**MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-05):** FILE-001…006 sind umgesetzt und
|
||||
|
||||
+144
-1
@@ -1,6 +1,7 @@
|
||||
# Epic 04 — Assets
|
||||
|
||||
Details zu ASSET-001 … ASSET-008 (vollständig).
|
||||
Details zu ASSET-001 … ASSET-010. ASSET-010 ergänzt am 2026-09-09 aus Open-Source-Vergleich
|
||||
(Shelf.nu Custody-Feature), noch offen/ungeplant.
|
||||
|
||||
---
|
||||
|
||||
@@ -146,6 +147,148 @@ Details zu ASSET-001 … ASSET-008 (vollständig).
|
||||
- **DoD:** mind. ein Set mit 2+ Mitgliedern funktionsfähig. **Lücke gegenüber MABEA:**
|
||||
Beladungsvorlage ist konzeptionell ähnlich, aber fest ans Objekt gebunden — kein
|
||||
eigenständiges, wiederverwendbares Set-Konzept.
|
||||
- **Referenz (Open-Source-Vergleich 2026-09-09):** Shelf.nu (`shelf-nu/shelf.nu`) nennt
|
||||
dasselbe Konzept „Kits" — Assets zu einer wiederverwendbaren Einheit bündeln
|
||||
(Laptop+Charger+Dock). Bestätigt den Bedarf, löst aber keine MABEA-spezifische Frage
|
||||
zusätzlich (Set-Aufbau bleibt wie hier beschrieben).
|
||||
|
||||
## ASSET-010 — Custody/Ausgabe an Person (P2, neu, vollständig ausgearbeitet 2026-09-09)
|
||||
|
||||
- **Ziel:** Nachvollziehen, welche Person ein bestimmtes Einzelgerät aktuell
|
||||
persönlich in Verwahrung hat — unabhängig vom Standort-/Objekt-bezogenen
|
||||
ZUST-001 und von der reinen Kontroll-**Zuständigkeit** in ZUST-002.
|
||||
- **Abgrenzung zu ZUST-002 (geklärt 2026-09-09):** ZUST-002 sagt „Max soll den
|
||||
Notfallkoffer #12 kontrollieren" — das Objekt bleibt am Standort, jeder darf es
|
||||
trotzdem kontrollieren, reine Empfehlung ohne Zugriffssperre. ASSET-010 sagt „Max
|
||||
hat Funkgerät #7 heute persönlich dabei" — das Gerät wandert physisch mit der
|
||||
Person, bis sie es zurückgibt; danach kann es an jemand anderen ausgegeben
|
||||
werden. Unterschiedliche Konzepte (Kontroll-Zuständigkeit vs. physischer Besitz),
|
||||
echter Bedarf bestätigt — kein Duplikat.
|
||||
- **Ziel-Entität (geklärt 2026-09-09): `GeraetInstanz`, nicht generisches `Objekt`.**
|
||||
`GeraetInstanz` hängt an einer `Objektposition` und trägt die eigene
|
||||
Seriennummer (`backend/app/models/geraet_instanz.py`) — genau das einzelne,
|
||||
seriennummerpflichtige Gerät (Funkgerät, Atemschutzgerät), das eine Person
|
||||
persönlich mitführt. Ein ganzes `Objekt` (z.B. ein Fahrzeug oder ein
|
||||
Materiallager) wird nicht „mitgeführt" — dafür ist Custody nicht gedacht.
|
||||
- **Beschreibung:** Ausgabe-/Rücknahme-Vorgang je `GeraetInstanz` an eine `Person`
|
||||
(PERS-001), mit Zeitstempel, Bestätigungsmechanismus (siehe unten) und Verlauf.
|
||||
- **Benutzerwert:** Bei Verlust/Defekt sofort klar, wer das Gerät zuletzt hatte,
|
||||
ohne Rückfrage-Runde.
|
||||
- **Bestätigungsmechanismus bei Ausgabe (überarbeitet 2026-09-09, final 2026-09-09
|
||||
— Unterschrift OPTIONAL pro Ausgabe, cross-device per QR-Scan):**
|
||||
- Unterschrift/Protokoll ist **keine Pflicht für jede Ausgabe**, sondern eine
|
||||
Entscheidung der ausgebenden Stelle im Moment der Ausgabe — Toggle „Mit
|
||||
Protokoll+Unterschrift" im Ausgabe-Dialog. Ohne Toggle: einfache,
|
||||
formlose Ausgabe wie ursprünglich geplant (nur Custody-Zeile, kein PDF, kein
|
||||
QR-Signier-Flow) — schnelle Übergabe für den Alltag. Mit Toggle: voller
|
||||
Signier-Flow inkl. PDF-Protokoll, gedacht für kritisches/hochwertiges
|
||||
Material oder wenn die ausgebende Stelle es für nötig hält.
|
||||
- **Ablauf (nur wenn „Mit Protokoll" gewählt):** Portal (Tablet/Desktop der
|
||||
ausgebenden Stelle) zeigt nach Auswahl
|
||||
von Gerät+Empfänger einen QR-Code an, der auf eine einmalig gültige,
|
||||
kurzlebige Signier-Seite verweist (Token-basiert, kein Login nötig — die
|
||||
Legitimation ist der physische Besitz des Tablets der ausgebenden Stelle +
|
||||
der QR-Code selbst). Empfänger scannt den QR-Code mit dem **eigenen** Handy,
|
||||
öffnet die Signier-Seite, unterschreibt dort per Touch-Canvas auf dem eigenen
|
||||
Gerät (hygienischer/praktischer als eine geteilte Tablet-Oberfläche), sendet
|
||||
ab. Das Portal erkennt den Abschluss (Polling auf den Ausgabe-Status) und
|
||||
zeigt „unterschrieben ✓" an, danach gilt die Ausgabe als abgeschlossen.
|
||||
- Signier-Token: einmalig verwendbar, kurze Lebensdauer (z.B. 5 Minuten), an
|
||||
genau einen Ausgabevorgang gebunden — verhindert Wiederverwendung/Weitergabe
|
||||
des Links.
|
||||
- Aus Signatur + Geräte-/Personendaten + Zeitstempel wird automatisch ein
|
||||
**Ausgabeprotokoll** (PDF) generiert und über den DOC-001-Mechanismus am
|
||||
Custody-Eintrag UND in der Akte des Geräts abgelegt.
|
||||
- Bei Rücknahme: dieselbe Wahl gilt spiegelbildlich — wurde die Ausgabe mit
|
||||
Protokoll gemacht, läuft die Rücknahme ebenfalls über QR-Code→eigenes
|
||||
Handy→Unterschrift→Rückgabeprotokoll. Wurde die Ausgabe formlos gemacht,
|
||||
ist auch die Rücknahme formlos (kein nachträglicher Zwang zum Protokoll).
|
||||
- **Sicherheitsanforderungen (Security-Review 2026-09-09, owasp-top10-expert —
|
||||
verbindlich für die Implementierung, kein Nice-to-have):**
|
||||
1. **Token:** `secrets.token_urlsafe(32)` (256 Bit), serverseitig nur als
|
||||
SHA-256-Hash gespeichert (wie ein Passwort-Reset-Token) — Klartext existiert
|
||||
nur im QR-Code/URL, nie in Logs. Access-Logs dieser Route ohne Query-String
|
||||
protokollieren.
|
||||
2. **Route:** Token als Pfad-Parameter (`/signieren/{token}`), nicht Query —
|
||||
Query-Strings landen häufiger in Logs/Referrer/Browser-History.
|
||||
`slowapi`-Rate-Limit pro IP UND pro Token (z.B. 10/Minute). Lookup
|
||||
ausschließlich über Token-Hash, niemals über fortlaufende Custody-ID (IDOR).
|
||||
3. **Race Condition:** Token-Verwendung als atomares DB-Update, nicht
|
||||
Read-then-Write — `UPDATE ... WHERE token_hash=$1 AND status='ausstehend'`,
|
||||
Rowcount prüfen statt separatem Check+Write.
|
||||
4. **QR-Abfoto-Risiko:** bewusst akzeptiertes Restrisiko, **kein zusätzlicher
|
||||
PIN-Schritt** (Entscheidung 2026-09-09 — Reibung im Feldeinsatz wiegt
|
||||
schwerer, Ausgabe findet ohnehin unter Aufsicht der ausgebenden Stelle
|
||||
statt, die den Vorgang beobachtet). 5-Minuten-Ablauf + Einmalverwendung des
|
||||
Tokens bleiben als Grundschutz bestehen.
|
||||
5. **Transport:** HTTPS zwingend (ohnehin nur über nginx-TLS erreichbar).
|
||||
`VITE_API_BASE_URL` bleibt relativ (`/api/v1`) — Empfänger-Handy nutzt
|
||||
dieselbe Domain/dasselbe TLS-Zertifikat. Explizit auf echtem Fremdgerät
|
||||
testen, nicht nur localhost.
|
||||
6. **Datensparsamkeit (DSGVO):** GET-Endpunkt der Signier-Seite liefert nur
|
||||
Minimaldaten (Gerätebezeichnung, Empfängername, Zeitfenster) — keine
|
||||
vollständige Custody-Historie, keine internen IDs. Bei ungültigem/
|
||||
abgelaufenem/bereits verwendetem Token identische generische Fehlermeldung
|
||||
(kein Enumerieren des Status). Signatur/PDF nach Abschluss nicht mehr über
|
||||
denselben Token abrufbar — Download nur im authentifizierten Portal-Bereich.
|
||||
7. **PDF-Generierung:** falls HTML-basiert (`weasyprint`) — Jinja2-Autoescape
|
||||
aktiv lassen, kein `|safe` auf Nutzereingaben. Signatur-Bild serverseitig
|
||||
validieren (Magic-Bytes/Größe/Dimensionen), bevor es ins PDF eingebettet
|
||||
wird — keine beliebigen Datei-URLs oder SVG mit Skript zulassen.
|
||||
- **Abhängigkeiten:** ASSET-003, PERS-001, DOC-001 (Ausgabeprotokoll-PDF), FOUND-002
|
||||
(Signier-Token braucht eigene, kurzlebige Tabelle/Cache)
|
||||
- **Datenmodell:** `geraet_instanz_custody` (geraet_instanz_id →
|
||||
`geraet_instanz.id`, person_id, ausgegeben_am, ausgegeben_von_benutzer_id,
|
||||
mit_protokoll: bool (Toggle-Entscheidung der ausgebenden Stelle),
|
||||
ausgabeprotokoll_dokument_id nullable FK auf `dokument` (nur bei
|
||||
`mit_protokoll=true`), zurueckgegeben_am nullable,
|
||||
zurueckgenommen_von_benutzer_id nullable, rueckgabeprotokoll_dokument_id
|
||||
nullable) — aktuelle Inhaberschaft = Zeile mit `zurueckgegeben_am IS NULL`.
|
||||
`signier_token` (token, custody_id, ablauf_am, verwendet: bool) — nur relevant
|
||||
wenn `mit_protokoll=true`, kurzlebig, kann nach Ablauf/Verwendung gelöscht
|
||||
werden (kein Langzeit-Speicherbedarf).
|
||||
- **Backend:** Ausgabe-Endpoint verzweigt nach `mit_protokoll` — `false`: Custody-
|
||||
Zeile direkt als abgeschlossen anlegen (formlose Ausgabe, wie ursprünglich
|
||||
geplant); `true`: Custody-Zeile unsigniert anlegen + Signier-Token erzeugen,
|
||||
QR-Code-Inhalt zurückgeben, öffentlicher (token-authentifizierter, kein Login)
|
||||
Signier-Endpoint nimmt Signatur-PNG entgegen, erzeugt PDF, markiert Custody als
|
||||
abgeschlossen, Status-Polling-Endpoint fürs Portal. In beiden Fällen: verhindert
|
||||
Doppel-Ausgabe (GeraetInstanz nur an eine Person gleichzeitig, DB-Constraint:
|
||||
max. eine offene Zeile je `geraet_instanz_id`); bei `mit_protokoll=true`
|
||||
zusätzlich Token-Ablauf serverseitig erzwungen (abgelaufene Tokens/unsignierte
|
||||
Ausgaben nach Timeout verwerfen)
|
||||
- **Frontend:** Ausgabe-Dialog am Gerät — Person auswählen, Toggle „Mit
|
||||
Protokoll+Unterschrift"; bei aktiviertem Toggle QR-Code anzeigen →
|
||||
Warten-auf-Signatur-Status, sonst sofortiger Abschluss. Separate mobile
|
||||
Signier-Seite (eigenständige Route, kein Admin-Layout, funktioniert auf jedem
|
||||
Handy-Browser ohne Login) nur relevant bei aktiviertem Toggle.
|
||||
- **Mobile:** Ausgabe-Start per QR-Scan am Gerät selbst (wie gehabt), Signatur
|
||||
läuft auf dem Empfänger-Handy über die separate Signier-Seite
|
||||
- **QR-Code:** zwei unterschiedliche QR-Codes im Spiel — (1) Geräte-QR zum
|
||||
Auswählen des Geräts (bestehender Mechanismus), (2) neuer Signier-Token-QR zum
|
||||
Öffnen der Signier-Seite auf dem Empfänger-Handy
|
||||
- **Seriennummer/Inventarnummer:** nutzt bestehende `GeraetInstanz`-Identität
|
||||
- **Akte:** eigener Custody-Verlauf im Akte-Historienbereich (FILE-005)
|
||||
- **Rechte:** Ausgabe/Rücknahme: Mitarbeiter+; Korrektur: Materialverantwortlicher+
|
||||
- **Audit:** jede Ausgabe/Rücknahme geloggt, inkl. Zeitpunkt der Signatur
|
||||
- **Akzeptanzkriterien:** Gerät kann nicht an zwei Personen gleichzeitig ausgegeben
|
||||
sein; formlose Ausgabe (`mit_protokoll=false`) ist sofort abgeschlossen, kein
|
||||
Signier-Flow ausgelöst; Ausgabe mit Protokoll ohne abgeschlossene Signatur gilt
|
||||
nicht als abgeschlossen (Gerät bleibt bis zur Signatur „in Ausgabe schwebend",
|
||||
nicht schon fest zugeordnet); abgelaufener/bereits verwendeter Signier-Token
|
||||
wird abgelehnt; Ausgabeprotokoll-
|
||||
PDF enthält Geräte-, Personen-, Zeit- und Signaturdaten; Verlauf zeigt lückenlose
|
||||
Kette.
|
||||
- **Tests:** Doppel-Ausgabe-Ablehnung, abgelaufener-Token-Ablehnungstest, bereits-
|
||||
verwendeter-Token-Ablehnungstest, PDF-Generierungstest, Ausgabe→Signatur→
|
||||
Rücknahme→Signatur→Neuausgabe-Zyklus, Race-Condition-Test (paralleler Request
|
||||
auf denselben Token, nur einer darf gewinnen), Rate-Limit-Test, IDOR-Test
|
||||
(Token-Lookup nur über Hash, keine ID-Erratbarkeit), Signatur-Bild-Validierungs-
|
||||
test (ungültige/manipulierte Datei wird abgelehnt).
|
||||
- **DoD:** offen — Design vollständig geklärt (2026-09-09), bereit für
|
||||
Implementierung. **Referenz (Open-Source-Vergleich 2026-09-09):** Shelf.nu
|
||||
(`shelf-nu/shelf.nu`, AGPL-3.0 — nur Konzeptvorbild, keine Codeübernahme wegen
|
||||
Copyleft) — „Custody"-Feature, Kernaussage „know who has what at all times".
|
||||
|
||||
## ASSET-008 — Consumable
|
||||
|
||||
|
||||
@@ -130,6 +130,11 @@ Details zu FLEET-001 … FLEET-006 (vollständig).
|
||||
- **Tests:** TBD.
|
||||
- **DoD:** **DECISION REQUIRED:** diese Kachel bleibt bewusst Platzhalter, erst bei
|
||||
tatsächlichem Angehen des Operations-Epics neu aufsetzen statt jetzt blind zu spezifizieren.
|
||||
- **Referenz (Open-Source-Vergleich 2026-09-09):** Resgrid (`Resgrid/Core`, .NET/Angular,
|
||||
Apache-2.0) nutzt für sein Unit/Personnel-Modell zusätzlich AVL (Automatic Vehicle
|
||||
Location, GPS-Tracking) und einen feingranularen Verfügbarkeits-Status. Kein aktueller
|
||||
MABEA-Bedarf (Materialmanagement, nicht Einsatzführung), aber falls das Operations-Epic
|
||||
je aktiviert wird, wäre AVL-Integration ein naheliegender Baustein für diese Kachel.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -92,6 +92,15 @@ Details zu INV-001 … INV-007 (vollständig).
|
||||
Objektposition (ein Wert, keine Liste) — mehrere Chargen gleichzeitig an derselben Position
|
||||
sind aktuell NICHT abbildbar. Diese Kachel wäre in MABEA kein reiner Nachzug, sondern ein
|
||||
Datenmodell-Umbau (1:1 → 1:n).
|
||||
- **Referenz (Open-Source-Vergleich 2026-09-09, Grocy `grocy/grocy`, MIT — lizenzseitig
|
||||
unkritisch, Stack inkompatibel):** zwei Verfeinerungen für den Umbau vormerken, falls
|
||||
INV-004 angegangen wird:
|
||||
1. **Umrechnungsfaktor Gebinde→Einzeleinheit** (z.B. 1 Packung = 20 Stück) statt Menge
|
||||
nur in einer Einheit zu führen — vermeidet Umrechnungsfehler bei Teil-Entnahme.
|
||||
2. **„Charge öffnen"-Aktion**: sobald eine Charge angebrochen wird, kann ein neues,
|
||||
kürzeres Verfallsdatum gesetzt werden (viele sterile/medizinische Produkte verlieren
|
||||
nach Anbruch ihre Haltbarkeit vorzeitig) — separat vom ursprünglichen
|
||||
Herstellerablaufdatum der ungeöffneten Charge.
|
||||
|
||||
## INV-005 — Ablaufdaten & Warnschwellen
|
||||
|
||||
|
||||
@@ -136,6 +136,12 @@ Details zu WH-001 … WH-007 (vollständig).
|
||||
- **DoD:** ein vollständiger Inventurzyklus durchgeführt. **Lücke:** MABEA hat kein
|
||||
Inventur-Konzept, nur Kontrolle (Soll/Ist je Objekt, nicht als eigener Lagerlauf mit
|
||||
Korrekturbuchung).
|
||||
- **Referenz (Open-Source-Vergleich 2026-09-09):** InvenTree (`inventree/InvenTree`) hat
|
||||
als Alternative zur Stichtags-Vollinventur ein „Rolling Stocktake"-Plugin — statt
|
||||
allem auf einmal wird laufend ein rotierender Teilbestand geprüft (Dashboard zeigt
|
||||
automatisch das nächste fällige Item). Für weniger kritisches Verbrauchsmaterial ggf.
|
||||
als optionaler zweiter Inventur-Modus neben dem hier beschriebenen Vollinventurlauf
|
||||
erwägenswert — kein Ersatz, sondern Ergänzung.
|
||||
|
||||
## WH-007 — Materialbewegungsprotokoll
|
||||
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# Epic 10 — Maintenance
|
||||
|
||||
Details zu MAINT-001 … MAINT-006 (vollständig).
|
||||
Details zu MAINT-001 … MAINT-007. MAINT-001-004+006 vollständig, MAINT-005 P3
|
||||
zurückgestellt, MAINT-007 ergänzt am 2026-09-09 aus Open-Source-Vergleich (FleetMS),
|
||||
ebenfalls P3/offen.
|
||||
|
||||
---
|
||||
|
||||
@@ -104,7 +106,7 @@ Details zu MAINT-001 … MAINT-006 (vollständig).
|
||||
`GET /wartungsauftraege?objekt_id=` liefert offene+erledigte, Akte zeigt
|
||||
beide getrennt in der neuen "Wartung"-Sektion.
|
||||
|
||||
## MAINT-005 — Ersatzteile/Kosten (P3)
|
||||
## MAINT-005 — Ersatzteile/Kosten (P3, umgesetzt 2026-09-08)
|
||||
|
||||
- **Ziel:** Welche Teile/Kosten bei einer Wartung angefallen sind.
|
||||
- **Beschreibung:** Ersatzteilliste + Kostenfeld je Wartungsauftrag.
|
||||
@@ -120,7 +122,8 @@ Details zu MAINT-001 … MAINT-006 (vollständig).
|
||||
- **Audit:** Änderung geloggt
|
||||
- **Akzeptanzkriterien:** Teile/Kosten erfassen, Summe korrekt.
|
||||
- **Tests:** Summen-Test.
|
||||
- **DoD:** **P3 — kann zurückgestellt werden**, kein MVP-Bestandteil.
|
||||
- **DoD:** ✅ umgesetzt (2026-09-08) — `WartungsauftragTeil` (Migration 0033),
|
||||
`/wartungsauftraege/{id}/teile`-CRUD, UI in `WartungSection.tsx`.
|
||||
|
||||
## MAINT-006 — Wartungsdokument-Anbindung
|
||||
|
||||
@@ -141,10 +144,40 @@ Details zu MAINT-001 … MAINT-006 (vollständig).
|
||||
- **DoD:** umgesetzt (2026-09-06). `entitaet_typ=wartungsauftrag` zur Whitelist
|
||||
ergänzt, `DokumentePanel` in der Wartung-Sektion der Akte je Auftrag.
|
||||
|
||||
## MAINT-007 — Tankbuch/Kraftstoffverbrauch (P3, neu)
|
||||
|
||||
- **Ziel:** Kraftstoffbetankungen je Fahrzeug erfassen, Verbrauch (l/100km) ableiten.
|
||||
- **Beschreibung:** Betankungs-Log (Datum, Menge, Kosten, Kilometerstand zum
|
||||
Betankungszeitpunkt) je Fahrzeug, Verbrauchsberechnung aus aufeinanderfolgenden
|
||||
Einträgen.
|
||||
- **Benutzerwert:** Budgetplanung, Auffälligkeiten (Mehrverbrauch als früher Hinweis auf
|
||||
technisches Problem) erkennbar.
|
||||
- **Abhängigkeiten:** FLEET-002 (`Fahrzeugdetails.kilometerstand`) — **nicht**
|
||||
ASSET-009, das laut eigenem Ist-Stand-Abgleich in `04_assets.md` weiterhin fehlt
|
||||
(kein generischer Zähler vorhanden, nur das Fahrzeug-Feld direkt)
|
||||
- **Datenmodell:** `tankbuch_eintrag` (objekt_id → `objekt.id`, datum, menge_liter,
|
||||
kosten, kilometerstand) — kein `asset`-Modell in MABEA, real heißt die Tabelle
|
||||
`objekt`
|
||||
- **Backend:** CRUD, Verbrauchsberechnung zwischen zwei Einträgen
|
||||
- **Frontend:** Tankbuch-Liste je Fahrzeug, Verbrauchsanzeige
|
||||
- **Mobile:** Erfassung nach dem Tanken
|
||||
- **QR-Code/Seriennummer/Inventarnummer:** nein
|
||||
- **Akte:** Wartungs-/Fahrzeugbereich
|
||||
- **Rechte:** jeder Nutzer darf erfassen, Korrektur Materialwart+
|
||||
- **Audit:** Änderung geloggt
|
||||
- **Akzeptanzkriterien:** zwei Einträge ergeben korrekten l/100km-Wert.
|
||||
- **Tests:** Verbrauchsberechnungstest.
|
||||
- **DoD:** offen, **P3 — kein MVP-Bestandteil**, analog MAINT-005-Priorisierung.
|
||||
**Referenz (Open-Source-Vergleich 2026-09-09):** FleetMS (`jmnda-dev/fleetms`,
|
||||
Elixir/Phoenix, AGPL-3.0 — Projekt selbst laut eigenem README unreif/Prototyp,
|
||||
nur als Ideengeber, kein Vorbild für Codequalität) führt ein einfaches Fuel-Log als
|
||||
eigenständiges Fahrzeug-Modul — Konzept übertragbar, MABEA hat aktuell keinerlei
|
||||
Kraftstoff-Tracking.
|
||||
|
||||
---
|
||||
|
||||
**MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-06):** MAINT-001..004+006
|
||||
**MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-09):** MAINT-001..006
|
||||
vollständig umgesetzt — echtes Wartungskonzept existiert jetzt (Wartungspläne,
|
||||
Intervalle, Werkstattaufträge intern/extern, Historie, Dokument-Anhang).
|
||||
MAINT-005 (Ersatzteile/Kosten-Detailliste) bleibt bewusst zurückgestellt (P3) —
|
||||
Kosten als einzelnes Feld am Auftrag reicht für den MVP.
|
||||
Intervalle, Werkstattaufträge intern/extern, Historie, Dokument-Anhang,
|
||||
Ersatzteile/Kosten je Auftrag seit 2026-09-08). MAINT-007 (Tankbuch) neu
|
||||
ergänzt am 2026-09-09, offen/ungeplant.
|
||||
|
||||
@@ -23,10 +23,9 @@ Details zu PERS-001 … PERS-007 (vollständig).
|
||||
- **Audit:** Änderung geloggt
|
||||
- **Akzeptanzkriterien:** Person ohne Benutzerkonto anlegbar.
|
||||
- **Tests:** CRUD-Test, Test „Person ohne Benutzer funktioniert".
|
||||
- **DoD:** **HIGH RISK** (siehe Decision Required #4 in `00_index.md`) — größter Umbau
|
||||
des gesamten Personal-Bereichs, da MABEA Person=Benutzer verschmolzen hat. Vor
|
||||
Umsetzung: echten Bedarf klären (gibt es in der Praxis tatsächlich Personen ohne
|
||||
Login-Bedarf, die trotzdem im System geführt werden müssen?).
|
||||
- **DoD:** ✅ umgesetzt (2026-09-08) — echter Bedarf via AskUserQuestion bestätigt,
|
||||
danach live deployed. `Person`-Modell (Migration 0034 mit Backfill bestehender
|
||||
Benutzer), `/personen`-CRUD, Admin-UI `PersonSection.tsx`.
|
||||
|
||||
## PERS-002 — Benutzer (technisch, verknüpft)
|
||||
|
||||
@@ -47,10 +46,10 @@ Details zu PERS-001 … PERS-007 (vollständig).
|
||||
- **Akzeptanzkriterien:** bestehende Benutzer funktionieren nach Migration unverändert.
|
||||
- **Tests:** Migrationstest (keine Datenverluste), Regressionstest bestehender
|
||||
Auth-Flows.
|
||||
- **DoD:** **DECISION REQUIRED** — das ist der eigentliche Bruch. Lohnt sich das, wenn
|
||||
aktuell niemand Personen ohne Login braucht? Empfehlung: zurückstellen bis konkreter
|
||||
Bedarf auftritt (z.B. Jugendgruppen-Verwaltung), dann als eigenes fokussiertes Vorhaben
|
||||
angehen, nicht „nebenbei" im Rahmen einer anderen Kachel.
|
||||
- **DoD:** ✅ umgesetzt (2026-09-08) — `Benutzer.person_id` FK (nullable), `/benutzer`
|
||||
verknüpft bestehende Person oder legt automatisch neue Person an, wenn keine
|
||||
`person_id` angegeben wird (Backward-Kompatibilität). Backfill bestehender Benutzer
|
||||
via `ROW_NUMBER()`-1:1-Positionsmatch statt Name-Join (Namenskollisionen vermieden).
|
||||
|
||||
## PERS-003 — Einheiten/Organisationsstruktur
|
||||
|
||||
@@ -160,10 +159,10 @@ Details zu PERS-001 … PERS-007 (vollständig).
|
||||
|
||||
---
|
||||
|
||||
**MABEA-Ist-Stand-Abgleich:** PERS-003, 005, 006, 007 sind vollständig in MABEA
|
||||
umgesetzt und größtenteils sogar schon live getestet. **PERS-001/002 (Person↔Benutzer-
|
||||
Trennung) bleiben der einzige echte offene Architekturentscheid im gesamten Backlog** —
|
||||
bewusst nicht einfach umgesetzt, sondern als Decision Required markiert, da der Nutzen
|
||||
(Personen ohne Login) bisher nicht als konkreter Bedarf geäußert wurde. **PERS-004
|
||||
**MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-09):** PERS-001…003, 005, 006, 007
|
||||
sind vollständig in MABEA umgesetzt und live deployed. PERS-001/002 (Person↔Benutzer-
|
||||
Trennung) waren der größte offene Architekturentscheid im gesamten Backlog — echter
|
||||
Bedarf wurde am 2026-09-08 bestätigt, danach umgesetzt und deployed (Details siehe
|
||||
PERS-001/002 oben). **PERS-004
|
||||
(fachliche Funktion innerhalb einer Einheit, z.B. „Zugführer") fehlt komplett** — leicht
|
||||
zu verwechseln mit den bestehenden System-Rollen, ist aber ein eigenständiges Konzept.
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
# Epic 13 — Readiness
|
||||
|
||||
Details zu READY-001 … READY-005 (vollständig).
|
||||
Details zu READY-001 … READY-006. READY-001-005 vollständig, READY-006 ergänzt am
|
||||
2026-09-09 aus HiOrg-Server-Vergleich, offen/ungeplant.
|
||||
|
||||
---
|
||||
|
||||
@@ -116,6 +117,50 @@ Details zu READY-001 … READY-005 (vollständig).
|
||||
kann komplett entfallen, wenn READY-001 zurückgestellt bleibt und ein fester
|
||||
Kriterienkatalog ausreicht.
|
||||
|
||||
## READY-006 — Statistik-/Reporting-Dashboard-Kachel (P2, neu)
|
||||
|
||||
- **Ziel:** Kennzahlen über Zeit statt nur Momentaufnahme des aktuellen Zustands.
|
||||
- **Beschreibung:** Neue Dashboard-Kachel mit Verlaufs-Kennzahlen: Bereitschaftsquote
|
||||
über Zeit (Anteil READY/LIMITED/NOT_READY/UNKNOWN je Zeitpunkt), Mängelquote je
|
||||
Standort, Anzahl offener Wartungen. Nutzt bereits vorhandene Daten
|
||||
(Einsatzbereitschaft, Mängel, Wartungsaufträge), aggregiert sie nur zeitlich/
|
||||
gruppiert statt nur aktuellen Stand zu zeigen.
|
||||
- **Benutzerwert:** Trends erkennbar („wird die Bereitschaft besser/schlechter") statt
|
||||
nur Snapshot — Grundlage für Leitungsentscheidungen (z.B. wo Ressourcen fehlen).
|
||||
- **Abhängigkeiten:** READY-004, `Mangel`-Modell, MAINT-003
|
||||
- **Datenmodell (entschieden 2026-09-10): täglicher Snapshot**, nicht
|
||||
Live-Berechnung — `readiness_snapshot` (Zeitpunkt, Standort, Zustand, Anzahl).
|
||||
Begründung: Live-Berechnung würde bedeuten, die READY-003-Regel-Logik
|
||||
rückwirkend auf jeden historischen Zeitpunkt anzuwenden (zeitpunktbezogener
|
||||
Nachbau der Ampel-Logik) — deutlich fehleranfälliger als ein simpler täglicher
|
||||
Snapshot. Tägliche Auflösung reicht für Trend-Reporting.
|
||||
- **Backend:** Aggregations-Endpunkt(e), periodischer Snapshot-Job via
|
||||
systemd-Timer (`mabea-readiness-snapshot.timer`, gleiches Muster wie
|
||||
`mabea-eskalation.timer` bei NOTIF-002) — Zeitplan über `OnCalendar` in der
|
||||
Timer-Unit auf dem Server jederzeit ohne Codeänderung/Deploy anpassbar
|
||||
(`systemctl edit` + `daemon-reload`), reine Betriebskonfiguration. Standard-
|
||||
Anzeigezeitraum im Frontend: letzte 90 Tage, mit Filter für längere Zeiträume.
|
||||
- **Frontend:** neue Dashboard-Kachel (react-grid-layout, wie bestehende Tiles),
|
||||
einfache Zeitreihen-Darstellung
|
||||
- **Mobile:** Anzeige, kein Erfassungsbedarf
|
||||
- **QR-Code/Seriennummer/Inventarnummer:** nein
|
||||
- **Akte (ergänzt 2026-09-10):** zusätzlich zum globalen Dashboard bekommt jedes
|
||||
einzelne Objekt einen Verlaufs-Abschnitt in seiner Akte (FILE-005-Bereich) —
|
||||
„Bereitschaftshistorie dieses Objekts" (z.B. „in den letzten 6 Monaten X Tage
|
||||
nicht einsatzbereit"). Nutzt dieselbe zugrundeliegende Datenquelle wie das
|
||||
globale Dashboard, nur gefiltert auf ein Objekt statt aggregiert über alle —
|
||||
andere Abfrage-Granularität, kein zweiter Datenspeicher nötig.
|
||||
- **Rechte:** Leitungsverantwortliche/Administration
|
||||
- **Audit:** nein (reine Auswertung)
|
||||
- **Akzeptanzkriterien:** mind. eine Kennzahl (z.B. Bereitschaftsquote) über
|
||||
mehrere Zeitpunkte hinweg korrekt dargestellt.
|
||||
- **Tests:** Aggregations-Test mit synthetischen Daten über mehrere Zeitpunkte.
|
||||
- **DoD:** offen — Design vollständig geklärt (2026-09-10), bereit für
|
||||
Implementierung. **Referenz (HiOrg-Server-Vergleich 2026-09-09):** HiOrg bietet
|
||||
dedizierte Statistiken über Dienste/Kurse — MABEA hat vergleichbare Rohdaten
|
||||
(Einsatzbereitschaft, Mängel, Wartung), aber keine Verlaufs-/Trend-Ansicht,
|
||||
nur den aktuellen Zustand (READY-004).
|
||||
|
||||
---
|
||||
|
||||
**MABEA-Ist-Stand-Abgleich:** Funktional ist Readiness in MABEA bereits gut abgedeckt
|
||||
|
||||
@@ -74,6 +74,16 @@ Details zu MOBILE-001 … MOBILE-005 (vollständig).
|
||||
- **DoD:** **HIGH RISK, P2 — komplexestes Mobile-Thema.** MABEA hat KEINE
|
||||
Offline-Fähigkeit (nur PWA-Shell-Caching via Vite-PWA-Plugin, keine Offline-Queue für
|
||||
Schreibvorgänge) — bei Netzausfall schlägt jede Aktion einfach fehl.
|
||||
- **Referenz (Open-Source-Vergleich 2026-09-09):** KP Front (`feuerwehr-oberwil/kp-front`,
|
||||
identischer Stack FastAPI/PostgreSQL/React-Vite-PWA, AGPL-3.0-or-later — nur Muster,
|
||||
keine Codeübernahme) löst das nicht als globale Offline-Queue, sondern als
|
||||
**Draft-first-Erfassung**: jede Eingabe (`captureDraft.ts`-Muster) wird sofort lokal als
|
||||
Entwurf mit eigenem Sync-Status gespeichert (statt nur bei Verbindungsverlust in eine
|
||||
Warteschlange zu fallen) — der Nutzer sieht pro Datensatz „lokal/synchronisiert" statt
|
||||
nur eines globalen Online-Banners. Für MABEA relevant, weil Kontrollen/Mängelmeldungen
|
||||
(MOBILE-004/005) so auch bei instabiler statt komplett fehlender Verbindung robust
|
||||
bleiben, nicht nur im reinen Offline-Fall. Empfehlung: MOBILE-003 auf dieses Muster hin
|
||||
konkretisieren statt generischer „Offline-Queue".
|
||||
|
||||
## MOBILE-004 — Mobile Mangelmeldung + Foto
|
||||
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# Epic 17 — Zuständigkeit
|
||||
|
||||
Details zu ZUST-001 … ZUST-002 (vollständig). Übernommen aus `arbeitskarten/01_rollen_zuordnung.md`
|
||||
Details zu ZUST-001 … ZUST-003. ZUST-001/002 vollständig, ZUST-003 ergänzt am 2026-09-09
|
||||
aus Open-Source-Vergleich, noch offen/ungeplant. Übernommen aus
|
||||
`arbeitskarten/01_rollen_zuordnung.md`
|
||||
und `arbeitskarten/04_organisationsstruktur.md` (Karte 01+04) — beide Karten hatten kein
|
||||
Gegenstück im ursprünglichen 16-Epic-Backlog (siehe `00_index.md`, DECISION REQUIRED Punkt 5
|
||||
war die Vorgängerlücke, diese hier ist die zweite gefundene Lücke).
|
||||
@@ -62,12 +64,62 @@ war die Vorgängerlücke, diese hier ist die zweite gefundene Lücke).
|
||||
- **DoD:** deckt sich 1:1 mit MABEA (`Kontrollverantwortung`-Tabelle, admin-UI bereits
|
||||
produktiv).
|
||||
|
||||
## ZUST-003 — Standort-Scoping für granulare Berechtigungen (P2, neu, geklärt 2026-09-09)
|
||||
|
||||
- **Ziel:** Custom-Rollen-Berechtigungen (`Berechtigung`/`Rolle`/`RolleBerechtigung`,
|
||||
Roadmap Phase 6) optional auf einen Standort/Depot einschränken können, statt immer
|
||||
global zu gelten.
|
||||
- **Bedarf: bestätigt (2026-09-09)** — echte Anforderung, kein rein hypothetisches
|
||||
Feature.
|
||||
- **Beschreibung:** Aktuell gilt jede über eine Custom-Rolle vergebene Berechtigung
|
||||
systemweit — ein Nutzer mit „material.erstellen" darf das an JEDEM Standort, nicht nur
|
||||
an dem, für den er zuständig ist. Erweiterung: optionales `standort_id` an
|
||||
der Benutzer-Rollen-Zuordnung, `NULL` = weiterhin global (Rückwärtskompatibilität).
|
||||
- **Benutzerwert:** Ein Materialwart kann Rechte für seinen Standort bekommen, ohne
|
||||
automatisch auch an allen anderen Standorten schreiben zu dürfen — relevant, sobald
|
||||
mehrere Standorte/Depots von unterschiedlichen Personen verantwortet werden.
|
||||
- **Abhängigkeiten:** ZUST-001 (bestehendes Standort↔Verantwortlicher-Konzept), das
|
||||
granulare Rechtesystem (`app/models/permission.py`)
|
||||
- **Datenmodell (entschieden 2026-09-09): 1:1, einfache Spalte statt
|
||||
Zwischentabelle** — `benutzer_rolle_zuordnung.standort_id` (FK, nullable),
|
||||
`NULL` = global. Begründung: Personen wechseln typischerweise komplett den
|
||||
Standort (dann wird der Wert einfach aktualisiert, kein Neuanlegen/Löschen
|
||||
nötig) statt dauerhaft mehreren Standorten gleichzeitig zugeordnet zu sein.
|
||||
Braucht eine Person doch mehrere Standorte gleichzeitig: einfach eine zweite
|
||||
Rollen-Zuweisung mit anderem `standort_id` anlegen (Custom-Rollen sind bereits
|
||||
mehrfach zuweisbar) — kein n:m-Konstrukt nötig, deutlich einfachere
|
||||
Rechteprüfungs-Logik.
|
||||
- **Backend:** Rechte-Check-Funktion (`require_roles_or_permission` o.ä.) um
|
||||
Standort-Filter erweitern — prüft nicht nur „hat Berechtigung X", sondern „hat
|
||||
Berechtigung X für Standort Y (oder global)"
|
||||
- **Frontend:** `RolleSection.tsx` — Standort-Auswahl bei der Benutzer-Zuordnung
|
||||
ergänzen (optional, Default weiterhin global)
|
||||
- **Mobile:** kein Unterschied, wirkt sich nur auf Backend-Autorisierung aus
|
||||
- **QR-Code/Seriennummer/Inventarnummer:** nein
|
||||
- **Akte:** nein direkt
|
||||
- **Rechte:** Verwaltung: Administrator
|
||||
- **Audit:** Änderung der Standort-Zuordnung geloggt
|
||||
- **Akzeptanzkriterien:** Nutzer mit standortgebundenem Recht kann an zugewiesenem
|
||||
Standort handeln, an anderem Standort wird derselbe Endpunkt korrekt abgelehnt;
|
||||
bestehende globale Zuordnungen (`standort_id IS NULL`) funktionieren unverändert.
|
||||
- **Tests:** Positivtest (Standort passt), Negativtest (falscher Standort abgelehnt),
|
||||
Regressionstest (bestehende globale Rechte weiterhin uneingeschränkt).
|
||||
- **DoD:** offen — beide Design-Entscheidungen geklärt (2026-09-09), bereit für
|
||||
Implementierung. **Referenz (Open-Source-Vergleich 2026-09-09):** keines der
|
||||
verglichenen Projekte (InvenTree, Snipe-IT, Grocy, Shelf.nu, Resgrid, KP Front,
|
||||
FleetMS) hat ein sauber dokumentiertes Standort-/Objekt-Ebene-Rechtesystem — Snipe-IT
|
||||
nur grobes Company-Scoping, Shelf.nu nur personenbezogene Sichtbarkeits-Toggles. Wäre
|
||||
bei Umsetzung eine echte Differenzierung ggü. allen verglichenen Projekten, kein
|
||||
Nachbau.
|
||||
|
||||
---
|
||||
|
||||
**MABEA-Ist-Stand-Abgleich:** beide Kacheln sind bereits vollständig umgesetzt und
|
||||
produktiv (`Zustaendigkeit` + `Kontrollverantwortung`, jeweils mit Admin-UI). Diese Epic-
|
||||
Datei existierte bislang nicht — reine Nachdokumentation von bereits gebauter Funktion, die
|
||||
im ursprünglichen 16-Epic-Backlog übersehen wurde.
|
||||
**MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-09):** ZUST-001/002 sind bereits
|
||||
vollständig umgesetzt und produktiv (`Zustaendigkeit` + `Kontrollverantwortung`, jeweils
|
||||
mit Admin-UI). Diese Epic-Datei existierte bislang nicht — reine Nachdokumentation von
|
||||
bereits gebauter Funktion, die im ursprünglichen 16-Epic-Backlog übersehen wurde.
|
||||
ZUST-003 (Standort-Scoping für Berechtigungen) neu ergänzt am 2026-09-09 aus
|
||||
Open-Source-Vergleich, offen/ungeplant.
|
||||
|
||||
## Referenzen
|
||||
Alte Arbeitskarten (übernommen, Karten-Dateien gelöscht): Karte 01 Rollen&Zuordnung,
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# Epic 18 — Notifications & Eskalation
|
||||
|
||||
Details zu NOTIF-001 … NOTIF-002 (vollständig). Übernommen aus `arbeitskarten/05_benachrichtigungen.md`
|
||||
Details zu NOTIF-001 … NOTIF-003. NOTIF-001/002 vollständig umgesetzt, NOTIF-003 ergänzt
|
||||
am 2026-09-09 aus Open-Source-Vergleich (Shelf.nu), noch offen/ungeplant. Übernommen aus
|
||||
`arbeitskarten/05_benachrichtigungen.md`
|
||||
und `arbeitskarten/12_eskalation.md` (Karte 05+12) — beide Karten hatten kein Gegenstück im
|
||||
ursprünglichen 16-Epic-Backlog, obwohl Karte 12 bereits vollständig implementiert ist.
|
||||
|
||||
@@ -56,6 +58,32 @@ ursprünglichen 16-Epic-Backlog, obwohl Karte 12 bereits vollständig implementi
|
||||
dem Zielserver per systemd-Timer (`mabea-eskalation.timer`), der den Prüf-Endpunkt
|
||||
periodisch aufruft.
|
||||
|
||||
## NOTIF-003 — Proaktive Wartungsfälligkeits-Benachrichtigung (P2, neu)
|
||||
|
||||
- **Ziel:** Verantwortlicher erfährt von bald fälliger/überfälliger Wartung, ohne aktiv
|
||||
`GET /objekte/{id}/faellige-wartungen` (MAINT-002) abfragen zu müssen.
|
||||
- **Beschreibung:** Gleiches Muster wie NOTIF-001 (Dashboard + E-Mail), aber Trigger ist
|
||||
Wartungsfälligkeit statt Fehlbestand. MAINT-002 berechnet die Fälligkeit bereits —
|
||||
hier fehlt nur die proaktive Zustellung.
|
||||
- **Benutzerwert:** Wartungstermine werden nicht verpasst, weil niemand aktiv nachschaut.
|
||||
- **Abhängigkeiten:** MAINT-002, NOTIF-001 (identisches Versandmuster wiederverwenden)
|
||||
- **Datenmodell:** kein neues zusätzlich zu MAINT-002; ggf. Tracking-Zeitstempel analog
|
||||
NOTIF-002 zur Mehrfachversand-Vermeidung
|
||||
- **Backend:** periodischer Prüflauf (systemd-Timer analog NOTIF-002), nutzt bestehende
|
||||
Fälligkeitsberechnung
|
||||
- **Frontend:** Dashboard-Kachel „Fällige Wartungen" (falls nicht bereits vorhanden)
|
||||
- **Mobile:** Dashboard-Ansicht
|
||||
- **QR-Code/Seriennummer/Inventarnummer:** nein
|
||||
- **Akte:** nein direkt
|
||||
- **Rechte:** Materialverantwortliche der jeweiligen Zuständigkeit
|
||||
- **Audit:** Versand nicht zwingend geloggt (wie NOTIF-001)
|
||||
- **Akzeptanzkriterien:** fällige Wartung löst einmalig E-Mail+Dashboard-Eintrag aus,
|
||||
kein Mehrfachversand für dieselbe Fälligkeit.
|
||||
- **Tests:** Trigger-Test analog NOTIF-001, Mehrfachversand-Schutz-Test analog NOTIF-002.
|
||||
- **DoD:** offen. **Referenz (Open-Source-Vergleich 2026-09-09):** Shelf.nu nennt dies
|
||||
„Schedule alerts for maintenance, calibration, warranty expiry" — bestätigt den
|
||||
Bedarf als verbreitetes Muster, MABEA-Umsetzung folgt dem eigenen NOTIF-001/002-Stil.
|
||||
|
||||
---
|
||||
|
||||
**MABEA-Ist-Stand-Abgleich (korrigiert 2026-09-06):** NOTIF-001 und NOTIF-002 sind
|
||||
|
||||
@@ -48,6 +48,13 @@ konkreten Datenmodell-Konsequenzen, die in keinem der 16 ursprünglichen Epics e
|
||||
Punkte vor Umsetzung: technischer Auslöser der Auslagerung (manuell vs. automatisch bei
|
||||
Verbindungsverlust), Vorab-Bestückung des Satelliten mit Stammdaten, Verhalten bei
|
||||
laufender Kontrolle während Auslagerung/Rückholung, Hardware-Anforderung.
|
||||
- **Referenz (Open-Source-Vergleich 2026-09-09):** Emergency Management Tool
|
||||
(`projekt-katastrophenschutz/emergency-management-tool`, verwaist seit 2016, nur als
|
||||
Konzeptbestätigung — keine brauchbare Codequalität) verfolgt unabhängig dieselbe
|
||||
Grundidee (Offline-first-Netzwerkbetrieb mit späterer Auto-Synchronisation zwischen
|
||||
Leitstellen-Instanzen). Bestätigt den Bedarf, liefert aber keine über SAT-001 hinausgehende
|
||||
Lösung — SAT-001s Konfliktvermeidung-statt-Konfliktlösung-Ansatz (feste
|
||||
Server-Zuordnung je Objekt) ist bereits ausgereifter als das, was dort skizziert ist.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,7 +1,9 @@
|
||||
# Epic 22 — UI-Redesign Runde 2 (Patterns aus ai-coding-starter-kit-v2)
|
||||
|
||||
Ausgangspunkt: Subagenten-Analyse von `gitea.perlbach24.de/scripte/ai-coding-starter-kit-v2`
|
||||
(2026-09-08), reines shadcn/ui-Komponenten-Skelett (Vite/React/TS, Tailwind v3, Radix,
|
||||
Details zu UI2-001 … UI2-010, alle offen/ungeplant (Backlog-Planung, bewusst noch nicht
|
||||
gestartet). Ausgangspunkt: Subagenten-Analyse von
|
||||
`gitea.perlbach24.de/scripte/ai-coding-starter-kit-v2` (2026-09-08), vertieft am
|
||||
2026-09-09, reines shadcn/ui-Komponenten-Skelett (Vite/React/TS, Tailwind v3, Radix,
|
||||
react-hook-form+zod). Kein Framework-Wechsel, kein Neubau — Epic 20 (UI-001..008) bleibt
|
||||
Grundlage, hier werden zusätzliche, im Code konkret nachgewiesene Lücken geschlossen.
|
||||
**Kein kompletter Frontend-Neubau** — bewusste Entscheidung, siehe Chat 2026-09-08.
|
||||
@@ -23,6 +25,13 @@ Grundlage, hier werden zusätzliche, im Code konkret nachgewiesene Lücken gesch
|
||||
- **Akzeptanzkriterien:** neue Tokens vorhanden, mind. Card-Komponente nutzt sie statt
|
||||
Hardcoded-Werten.
|
||||
- **Tests:** keine (reines Styling).
|
||||
- **ACHTUNG (QA-Review 2026-09-09, siehe CLAUDE.md „Wichtige Stolperfallen"):**
|
||||
Neue Token-Namen in `tokens.css` dürfen NIEMALS denselben Namen wie ein
|
||||
Tailwind-`@theme`-Token bekommen — führte in diesem Projekt bereits zweimal zu
|
||||
app-weit kaputten Farben (zirkuläre Custom-Properties, guaranteed-invalid
|
||||
value). Vor dem Anlegen von `--color-card` etc. gegen `tailwind.css`/`@theme`
|
||||
prüfen, keine Namenskollision. Diese Warnung gilt für UI2-001 als Basis
|
||||
genauso wie für UI2-010 (Dark-Mode-Vorbereitung), die direkt darauf aufbaut.
|
||||
- **DoD:** offen.
|
||||
|
||||
## UI2-002 — AdminPage Sidebar/Sheet-Umschaltung
|
||||
@@ -61,6 +70,29 @@ Grundlage, hier werden zusätzliche, im Code konkret nachgewiesene Lücken gesch
|
||||
unverändert.
|
||||
- **Tests:** bestehende Vitest-Tests bleiben grün.
|
||||
- **DoD:** offen.
|
||||
- **Referenz (vertiefte Starter-Kit-Analyse 2026-09-09):** `form.tsx` im Quell-Repo
|
||||
verdrahtet a11y konkret statt nur visuell — `FormLabel` wird bei Fehler rot,
|
||||
`FormControl` setzt `aria-invalid`, `FormMessage` nur bei vorhandenem Error gerendert,
|
||||
`aria-describedby` verlinkt zur Fehlermeldung. 1:1 mit MABEAs `useState`-Ansatz
|
||||
nachbaubar (kein react-hook-form/Context nötig) — sollte in den `FormField`-Baustein
|
||||
mit einfließen, nicht nur reines Layout.
|
||||
|
||||
## UI2-009 — Formular-Fehlerzustand-Verdrahtung (a11y, ergänzt UI2-003)
|
||||
|
||||
- **Ziel:** `aria-invalid`/`aria-describedby`/Fehlerfarbe systematisch statt nur visuell.
|
||||
- **Beschreibung:** siehe Referenz-Absatz bei UI2-003 — kein eigenständiges Feature,
|
||||
sondern eine konkrete Ausbaustufe von UI2-003, aus organisatorischen Gründen als
|
||||
eigene Kachel geführt (klar abhakbar, statt in UI2-003 zu verschwimmen).
|
||||
- **Benutzerwert:** Bessere Screenreader-/Assistive-Tech-Unterstützung, klarere
|
||||
Fehlererkennung bei schlechtem Licht/Handschuhen (Fehlerfarbe + Text statt nur Farbe).
|
||||
- **Abhängigkeiten:** UI2-003
|
||||
- **Backend:** keins
|
||||
- **Frontend:** `components/ui/form-field.tsx`
|
||||
- **Rechte:** keine Änderung
|
||||
- **Akzeptanzkriterien:** Fehlerfeld hat `aria-invalid="true"` und `aria-describedby`
|
||||
auf die Fehlermeldung, kein Verlust bestehender Funktionalität.
|
||||
- **Tests:** keine neuen (reines Markup/Attribut).
|
||||
- **DoD:** offen.
|
||||
|
||||
## UI2-004 — Skeleton-Loading für Dashboard-Kacheln
|
||||
|
||||
@@ -94,14 +126,99 @@ Grundlage, hier werden zusätzliche, im Code konkret nachgewiesene Lücken gesch
|
||||
- **Tests:** keine neuen.
|
||||
- **DoD:** offen.
|
||||
|
||||
## UI2-006 — Toast/Benachrichtigungskomponente
|
||||
|
||||
- **Ziel:** Aktionsfeedback (gespeichert/Fehler/Sync-Status) ohne Modal-Unterbrechung.
|
||||
- **Beschreibung:** Leichtgewichtige Toast-Komponente (kein `sonner`-Paket-Zwang,
|
||||
Pattern nachbaubar: Portal + Auto-Dismiss-Timer + Stapel-Anzeige bei mehreren
|
||||
gleichzeitigen Meldungen).
|
||||
- **Benutzerwert:** Häufige kleine Aktionen (Kontrolle bestätigen, Position speichern)
|
||||
unterbrechen den Arbeitsfluss nicht mit einem Wegklick-Dialog.
|
||||
- **Abhängigkeiten:** UI2-001
|
||||
- **Backend:** keins
|
||||
- **Frontend:** neue `components/ui/toast.tsx`, zentrale Toast-Provider-Einbindung
|
||||
- **Mobile:** Dauer konfigurierbar halten (bei schlechtem Netz/langsamer Interaktion
|
||||
reicht kurze Anzeigedauer sonst nicht)
|
||||
- **Rechte:** keine Änderung
|
||||
- **Akzeptanzkriterien:** Toast erscheint bei Erfolg/Fehler, verschwindet automatisch,
|
||||
mehrere gleichzeitige Toasts stapeln statt überschreiben.
|
||||
- **Tests:** keine neuen (reines UI).
|
||||
- **DoD:** offen.
|
||||
|
||||
## UI2-007 — Dialog/AlertDialog-Baustein für Bestätigungen
|
||||
|
||||
- **Ziel:** Einheitliche Bestätigungsdialoge (z.B. „Material löschen?") statt nativem
|
||||
`window.confirm()`.
|
||||
- **Beschreibung:** Radix-artiges Dialog-Pattern mit Fokus-Trap und Escape-zum-Schließen,
|
||||
große Touch-taugliche Buttons.
|
||||
- **Benutzerwert:** Konsistentes Aussehen statt Browser-natives, unstyliertes
|
||||
`confirm()`-Popup; Fokus-Trap verhindert versehentliches Wegtippen auf Tablet.
|
||||
- **Abhängigkeiten:** UI2-001
|
||||
- **Backend:** keins
|
||||
- **Frontend:** neue `components/ui/dialog.tsx`/`alert-dialog.tsx`, schrittweise
|
||||
bestehende `confirm()`-Aufrufe ersetzen
|
||||
- **Mobile:** Priorität — Fokus-Trap/Escape wichtig bei externer Tastatur an Tablets
|
||||
mit Kartenleser
|
||||
- **Rechte:** keine Änderung
|
||||
- **Akzeptanzkriterien:** mind. eine bestehende `confirm()`-Stelle ersetzt, Verhalten
|
||||
(Bestätigen/Abbrechen) unverändert.
|
||||
- **Tests:** bestehende Tests an der ersetzten Stelle bleiben grün.
|
||||
- **DoD:** offen.
|
||||
|
||||
## UI2-008 — Badge-Komponente für Status-Chips
|
||||
|
||||
- **Ziel:** Bestandsstatus/Ablaufdatum-Kennzeichnung visuell einheitlich statt
|
||||
Ad-hoc-Farbklassen je Stelle.
|
||||
- **Beschreibung:** Kleine `Badge`-Komponente mit Varianten (ok/warnung/kritisch/
|
||||
abgelaufen), nutzt UI2-001-Tokens.
|
||||
- **Benutzerwert:** Schneller visueller Überblick in Listen/Kacheln, geringer Aufwand.
|
||||
- **Abhängigkeiten:** UI2-001
|
||||
- **Backend:** keins
|
||||
- **Frontend:** neue `components/ui/badge.tsx`, Einsatz in Materiallisten/Dashboard
|
||||
- **Rechte:** keine Änderung
|
||||
- **Akzeptanzkriterien:** mind. eine Liste (z.B. Ablaufdatum-Übersicht) nutzt Badge
|
||||
statt Inline-Farbklassen.
|
||||
- **Tests:** keine neuen.
|
||||
- **DoD:** offen.
|
||||
|
||||
## UI2-010 — Dark-Mode-fähige Token-Struktur (Vorbereitung, kein Umschalter)
|
||||
|
||||
- **Ziel:** UI2-001-Tokens so anlegen, dass ein späterer Dark-Mode-Umschalter keinen
|
||||
Umbau der Token-Struktur erfordert — auch wenn der Umschalter selbst kein aktueller
|
||||
Bedarf ist (Tablet im Feld, meist Tageslicht).
|
||||
- **Beschreibung:** Je Token aus UI2-001 (`--color-card`, `--color-popover`, etc.)
|
||||
zusätzlich einen `.dark`/`[data-theme=dark]`-Override-Block in `tokens.css`
|
||||
vorsehen, auch wenn er anfangs mit denselben Werten wie Light gefüllt ist.
|
||||
- **Benutzerwert:** Kein nachträglicher Breaking-Umbau, falls Dark Mode später doch
|
||||
gebraucht wird (z.B. Nachteinsätze).
|
||||
- **Abhängigkeiten:** UI2-001
|
||||
- **Backend:** keins
|
||||
- **Frontend:** `styles/global/tokens.css`
|
||||
- **Rechte:** keine Änderung
|
||||
- **Akzeptanzkriterien:** jeder neue UI2-001-Token hat einen Dark-Override-Platzhalter,
|
||||
keine funktionale Änderung im Light-Modus.
|
||||
- **Tests:** keine neuen (reines CSS).
|
||||
- **DoD:** offen. **Achtung MABEA-spezifisch:** Cascade-Layer-Struktur beachten
|
||||
(`global-css`-Layer niedriger als Tailwind-Layer, siehe CLAUDE.md „Wichtige
|
||||
Stolperfallen") — Dark-Override darf keine Layer-Kollision mit Tailwinds `@theme`
|
||||
erzeugen, insbesondere keinen Tailwind-Token-Namen doppelt vergeben.
|
||||
|
||||
---
|
||||
|
||||
**Reihenfolge (empfohlen, nicht blockierend zwischen 002-005):** UI2-001 zuerst
|
||||
(Basis für alle), danach UI2-002..005 in beliebiger Reihenfolge nach Nutzerpriorität.
|
||||
**Reihenfolge (empfohlen, nicht blockierend innerhalb der Gruppen):** UI2-001 zuerst
|
||||
(Basis für alle). Danach zwei unabhängige Gruppen: UI2-002/003+009/010 (Struktur/
|
||||
Formulare/Tokens) und UI2-004/005/006/007/008 (einzelne UI-Bausteine) — Reihenfolge
|
||||
innerhalb der Gruppen nach Nutzerpriorität.
|
||||
|
||||
**Nicht-Ziele:** kein Wechsel auf react-hook-form/zod/Radix, kein kompletter
|
||||
Frontend-Neubau, keine Breaking Changes an bestehender Fachlogik/API.
|
||||
Frontend-Neubau, keine Breaking Changes an bestehender Fachlogik/API. Bewusst NICHT
|
||||
übernommen (Overkill/Desktop-lastig für ein Fach-Tool, siehe vertiefte Analyse
|
||||
2026-09-09): Command-Palette/Combobox, Navigation-Menu, Accordion/Collapsible, Avatar,
|
||||
Pagination, Tooltip (auf Touch unzuverlässig), Sidebar-Zusatzfeatures wie
|
||||
Cookie-Persistenz/Keyboard-Shortcuts.
|
||||
|
||||
## Referenzen
|
||||
Subagenten-Analyse `ai-coding-starter-kit-v2`, Chat 2026-09-08 (kein Frontend-Neubau,
|
||||
Patterns schrittweise als Kacheln übernehmen).
|
||||
Patterns schrittweise als Kacheln übernehmen). Vertiefte Analyse derselben Quelle
|
||||
2026-09-09 (vollständige Komponentenliste, a11y-Patterns, Dark-Mode-Struktur) ergab
|
||||
UI2-006..010.
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
# Epic 23 — Flutter-Begleit-App (Sondierung, P3)
|
||||
|
||||
**Bewusst nur als Sondierungs-Prototyp geplant, keine Grundsatzentscheidung.**
|
||||
Motivation: PWA (Epic 15 Mobile) deckt den Tablet-Feldeinsatz bereits weitgehend ab
|
||||
(MOBILE-001/002/004/005 fertig). Offen ist, ob native Kamera-API für den QR-Scan
|
||||
spürbar zuverlässiger ist als Browser-`getUserMedia`/`@zxing/browser` — das soll ein
|
||||
einzelner Prototyp-Screen klären, bevor irgendeine Grundsatzentscheidung
|
||||
(Ergänzung vs. Ablösung der PWA) fällt.
|
||||
|
||||
**Build-Umgebung**: separater Server `192.168.1.236` (Hostname `aicontrol`), Flutter+
|
||||
Android-SDK bereits installiert, unabhängig von MABEA-Infrastruktur — reiner
|
||||
Build-Host, kein Dauerbetrieb der App dort (App läuft auf Endgeräten).
|
||||
|
||||
---
|
||||
|
||||
## FLUT-001 — QR-Scan-Prototyp gegen MABEA-Backend (P3, Sondierung)
|
||||
|
||||
- **Ziel:** Klären, ob native Kamera-API (Flutter, z.B. `mobile_scanner`-Paket) den
|
||||
QR-Scan-Workflow spürbar zuverlässiger/schneller macht als die PWA-Lösung —
|
||||
KEIN Ersatz für MOBILE-002, nur Vergleichsdatenpunkt.
|
||||
- **Scope (bewusst minimal):** Login-Screen (JWT gegen `/api/v1/auth/login`) +
|
||||
EIN Screen QR-Scan → Objekt-Identifikation anzeigen. Kein voller
|
||||
Kontroll-Workflow, keine Offline-Fähigkeit, kein Produktionsanspruch.
|
||||
- **Abhängigkeiten:** MABEA-Backend-API (bestehend, unverändert nutzbar — FastAPI/
|
||||
REST ist stack-agnostisch, kein Rückbau nötig)
|
||||
- **TLS/Zertifikat — entschieden 2026-09-10: Option 1 (echte Domain + Let's
|
||||
Encrypt).** Domain `mabea.perlbach-edv.de` vorhanden, DNS zeigt bereits auf die
|
||||
öffentliche WAN-IP, gültiges Let's-Encrypt-Zertifikat existiert bereits
|
||||
(`CN=mabea.perlbach-edv.de`, Issuer Let's Encrypt) — läuft aber noch über einen
|
||||
vorgelagerten Reverse-Proxy (openresty, vermutlich Nginx Proxy Manager im
|
||||
Heimnetz des Nutzers), der aktuell nur auf sich selbst redirected statt auf
|
||||
MABEA (`192.168.1.238`) durchzuleiten. **Nutzer kümmert sich selbst** um den
|
||||
Proxy-Host-Eintrag (`mabea.perlbach-edv.de` → `192.168.1.238`) — liegt außerhalb
|
||||
des MABEA-Server-Zugriffs. Sobald das steht: `VITE_API_BASE_URL` bleibt für die
|
||||
PWA unverändert relativ (`/api/v1`, CLAUDE.md-Regel), die Flutter-App nutzt
|
||||
stattdessen `https://mabea.perlbach-edv.de/api/v1` als fest hinterlegte absolute
|
||||
Basis-URL — kein selbstsigniertes Zertifikat, kein Cert-Pinning, kein
|
||||
Sonderweg mehr nötig.
|
||||
- **Prüfschritt vor Implementierungsstart:** verifizieren, dass
|
||||
`https://mabea.perlbach-edv.de/api/v1/health` tatsächlich 200 liefert (nicht
|
||||
mehr den aktuell beobachteten Redirect-Loop), bevor die App-Basis-URL
|
||||
festgelegt wird.
|
||||
- **DECISION REQUIRED — App-Identität:** Package-Name (z.B. `de.<org>.mabea`),
|
||||
Anzeigename, Icon — noch nicht festgelegt, nicht kritisch für den Prototyp
|
||||
(Platzhalter-Werte reichen), aber nötig vor einem echten Android-Build.
|
||||
- **DECISION REQUIRED — Test-Instanz:** gegen Prod-Backend (192.168.1.238) direkt
|
||||
testen, oder separater Test-Zugang? Für einen reinen Kamera-Vergleichstest
|
||||
spricht wenig gegen Prod (nur Lesezugriff: Login + QR-Scan-Anzeige, keine
|
||||
Schreibaktionen im Scope).
|
||||
- **Nicht-Ziele:** kein Ersatz für die PWA, keine Offline-Fähigkeit, kein
|
||||
vollständiger Kontroll-Workflow, keine Store-Veröffentlichung (Sideload/interner
|
||||
Test-Build reicht für die Sondierung).
|
||||
- **DoD:** offen, **P3 — reine Sondierung, kein MVP-Bestandteil**. Ergebnis dieses
|
||||
Prototyps entscheidet, ob ein Folge-Epic (voller Kontroll-Workflow) überhaupt
|
||||
sinnvoll ist — nicht vorher committen.
|
||||
|
||||
---
|
||||
|
||||
## Referenzen
|
||||
Chat 2026-09-10: Motivation/Trade-offs erstmals besprochen (Offline-Fähigkeit,
|
||||
native Hardware-Zugriffe, App-Store-Distribution als Nachteil für internes
|
||||
BOS-Tool). Nutzer-Entscheidung: MABEA-Begleit-App, nur Build-Server, kein
|
||||
Dauerbetrieb auf `192.168.1.236`. TLS-Blocker entdeckt bei Server-Check
|
||||
`192.168.1.238` (`/etc/nginx/sites-enabled/mabea.conf`).
|
||||
@@ -12,3 +12,367 @@ Keine Commits in dieser Session.
|
||||
- arbeitskacheln/16_operations.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
---
|
||||
## 2026-09-09 09:42 – 09:44 (2m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:47 – 09:48 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:50 – 09:50 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:50 – 09:50 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:52 – 09:53 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:56 – 09:56 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 09:59 – 10:00 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 10:00 – 10:01 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 10:01 – 10:03 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 10:05 – 10:07 (2m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 10:09 – 10:11 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 10:47 – 10:47 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 11:45 – 11:45 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 11:46 – 11:46 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 11:48 – 11:49 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 11:50 – 11:50 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 12:27 – 12:28 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 12:38 – 12:38 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 12:40 – 12:41 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 13:04 – 13:05 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 13:06 – 13:06 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 13:10 – 13:12 (2m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 13:19 – 13:19 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 13:21 – 13:22 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 13:23 – 13:25 (2m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 13:27 – 13:27 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 13:32 – 13:32 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 13:32 – 13:33 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
|
||||
@@ -438,3 +438,289 @@ Keine Commits in dieser Session.
|
||||
- backend/tests/test_dokument.py | 10 +++++++---
|
||||
|
||||
---
|
||||
## 2026-09-09 12:09 – 12:09 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** src
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 12:12 – 12:12 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 12:14 – 12:14 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 13:51 – 13:54 (3m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 14:08 – 14:09 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 14:10 – 14:10 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 14:21 – 14:22 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 14:22 – 14:23 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 15:43 – 15:44 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 15:45 – 15:45 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 16:02 – 16:02 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 16:03 – 16:03 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 16:03 – 16:04 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 16:04 – 16:04 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 16:05 – 16:05 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 16:10 – 16:10 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 22:04 – 22:05 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 22:52 – 22:52 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 23:36 – 23:39 (2m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** timemaster
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 23:43 – 23:47 (3m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** timemaster
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:01 – 00:02 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:03 – 00:03 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** backend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
|
||||
@@ -827,3 +827,81 @@ Keine Commits in dieser Session.
|
||||
- frontend/src/components/WartungSection.tsx | 111 ++-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:27 – 00:32 (4m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** asb-material
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:32 – 00:34 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** frontend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:37 – 00:38 (1m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** frontend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:45 – 00:45 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** frontend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:45 – 00:46 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** frontend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-10 00:47 – 00:48 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** frontend
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
# src – Dev Log
|
||||
|
||||
## 2026-09-09 11:57 – 11:58 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** arbeitskacheln
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
## 2026-09-09 12:00 – 12:00 (0m)
|
||||
**Beschreibung:** Claude Code Session
|
||||
**Projekt:** src
|
||||
|
||||
### Commits
|
||||
Keine Commits in dieser Session.
|
||||
|
||||
### Geänderte Dateien
|
||||
- DEVLOG.md | 52 ++++++++++++++++++++++++++
|
||||
- frontend/package-lock.json | 229 ++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------
|
||||
- frontend/package.json | 2 +-
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user