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

arbeitskacheln/01_foundation.md

@@ -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