docs: alte arbeitskarten (Karte 01-14) gegen arbeitskacheln-Backlog abgeglichen

7 Karten (02,03,06,09,10,11,14) inhaltlich bereits abgedeckt - gelöscht.
7 Karten (01,04,05,07,08,12,13) enthielten nicht erfasste Inhalte:
- neues Epic 17 Zuständigkeit (Karte 01+04)
- neues Epic 18 Notifications/Eskalation (Karte 05+12)
- neues Epic 19 Satelliten-Server (Karte 13, zurückgestellt)
- INV-006 ergänzt um Sofort-Nachfüllung (Karte 07) + Mindermengen-Gültigkeit (Karte 08)

arbeitskarten/ ist damit aufgelöst, nur Index mit Verweis auf arbeitskacheln bleibt.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVgbozhYmuEhiEJHffRXCV

arbeitskacheln/00_index.md

@@ -50,6 +50,9 @@ Epic, einzelne Kacheln können abweichen:
 | 14 Documents | owasp-top10-expert (Upload-Sicherheit/MIME-Whitelist, bereits Thema bei DOC-001), fastapi-expert |
 | 15 Mobile | kein Backend-Subagent zentral (Frontend/PWA-lastig) |
 | 16 Operations | noch offen, erst bei Angehen des Epics zuordnen |
+| 17 Zuständigkeit | postgres-expert (n:m-Vererbungslogik) |
+| 18 Notifications | fastapi-expert, owasp-top10-expert (E-Mail-Injection bei Trigger-Inhalten) |
+| 19 Satelliten-Server | postgres-expert, sql-expert (Sync Insert/Upsert), docker-expert |
 
 **Wie einbeziehen:** vor Implementierungsbeginn einer Kachel kurz prüfen, ob einer der
 zugeordneten Subagenten als Review-Instanz (nach Fertigstellung) oder als Umsetzungs-
@@ -76,6 +79,9 @@ für sicherheitskritische (owasp/jwt/oauth) und datenbanknahe (postgres/sql) The
 | 14 Documents | Dokumentenverwaltung | P2 |
 | 15 Mobile | QR-Scan-Workflow, PWA | P1 |
 | 16 Operations | Einsatzverwaltung (Ausblick) | P3 |
+| 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 |
 
 ## Vollständige Kachel-Liste
 
@@ -187,6 +193,11 @@ für sicherheitskritische (owasp/jwt/oauth) und datenbanknahe (postgres/sql) The
 | OPS-001 | Operations | Einsatzverwaltung (Platzhalter) | P3 | L | HIGH | FILE-001 |
 | OPS-002 | Operations | Einsatzmittel-Verknüpfung | P3 | M | MEDIUM | OPS-001, ASSET-003 |
 | OPS-003 | Operations | Einsatznachbereitung (Platzhalter) | P3 | L | HIGH | OPS-001 |
+| ZUST-001 | Zuständigkeit | Objekt/Standort ↔ Verantwortlicher | P0 | S | LOW | FOUND-002, ASSET-003 |
+| ZUST-002 | Zuständigkeit | Objekt ↔ Benutzer/Gruppe (Kontrollzuweisung) | P1 | S | LOW | ZUST-001, PERS-003 |
+| NOTIF-001 | Notifications | Benachrichtigung bei neuem Fehlbestand | P1 | S | LOW | INV-006 |
+| NOTIF-002 | Notifications | Eskalation lange offener Fehlbestände | P1 | M | MEDIUM | INV-006, NOTIF-001 |
+| SAT-001 | Satelliten-Server | Hauptserver mit Satelliten-Servern | P3 | L | HIGH | FOUND-002, ASSET-003, MOBILE-003 |
 
 ## Abhängigkeitsgraph (Epic-Ebene)
 
@@ -221,15 +232,16 @@ MAINTENANCE   │
 ## MVP-Abgrenzung (P0 + P1)
 
 **P0 (zwingend, Foundation):** FOUND-001…011, IDENT-001/002/004/006/007/008,
-FILE-001/002/003/005/006, ASSET-001…004, PERS-002.
+FILE-001/002/003/005/006, ASSET-001…004, PERS-002, ZUST-001.
 
 **P1 (MVP-Funktionsumfang):** Fleet (komplett), Inventory (komplett), Warehouse (komplett),
 Loadout (komplett), Inspections (komplett), Defects (komplett), Personnel (bis auf PERS-004),
 Readiness (bis auf READY-005), Mobile (bis auf MOBILE-003), DOC-001 (nur Grundgerüst,
-Rest P2).
+Rest P2), ZUST-002, Notifications (komplett).
 
 **Bewusst außerhalb MVP:** Maintenance (P2, außer Kern optional), Documents-Feinschliff
-(Versionierung/Zugriffsrechte, P2), Operations komplett (P3).
+(Versionierung/Zugriffsrechte, P2), Operations komplett (P3), Satelliten-Server komplett
+(P3, bewusst zurückgestellt).
 
 Deckt sich das MVP praktisch mit dem, was in MABEA schon existiert — Lücken laut diesem
 Backlog gegenüber MABEA-Ist-Stand: **PERS-001 (Person getrennt von Benutzer)**,
@@ -257,5 +269,20 @@ eigenes Modul (MAINT-\*, MABEA hat nur Prüfung, keine Wartung)**.
 | `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) |
 
 **Alle 16 Epics durchgegangen.** Detaillierungsphase abgeschlossen (2026-09-05).
+
+## Nachtrag: Abgleich mit alten Arbeitskarten (2026-09-05)
+
+Alle 14 `arbeitskarten/*.md` (Karte 01–14, Vorgänger-Planungsstand) gegen dieses Backlog
+geprüft und danach gelöscht — der komplette Ordner ist damit aufgelöst, `arbeitskarten/`
+enthält nur noch den auf "aufgelöst" aktualisierten Index. Sieben Karten waren inhaltlich
+vollständig abgedeckt (Karte 02, 03, 06, 09, 10, 11, 14 — jeweils in FOUND-003/004,
+LOAD-001/002, MOBILE-001, IDENT-\*, ASSET-Grundprämisse bzw. INSP-Epic aufgegangen). Sechs
+Karten enthielten Inhalte, die in keinem der 16 Epics vorkamen — daraus wurden drei neue
+Epics (17 Zuständigkeit, 18 Notifications, 19 Satelliten-Server) sowie zwei Ergänzungen an
+INV-006 (Sofort-Nachfüllung, Mindermengen-Gültigkeit). Quell-Karten: 01, 04, 05, 07, 08,
+12, 13 — ihr Inhalt lebt jetzt in den genannten Epic-Dateien weiter.

arbeitskacheln/06_inventory.md

@@ -120,7 +120,12 @@ Details zu INV-001 … INV-007 (vollständig).
 
 - **Ziel:** Automatische Erkennung, wenn Ist < Soll.
 - **Beschreibung:** Sollmenge je Material/Ort, Vergleich mit Istmenge, automatischer
-  Fehlbestand-Vorgang bei Abweichung.
+  Fehlbestand-Vorgang bei Abweichung. Sonderfall Sofort-Nachfüllung (übernommen aus
+  `arbeitskarten/07_sofort_nachfuellung.md`, Karte 07): füllt die Besatzung eine
+  Fehlmenge noch während der laufenden Kontrolle direkt aus dem Lager nach, entsteht der
+  Fehlbestand-Vorgang trotzdem und wird im selben Moment als erledigt markiert — kein
+  "verschwindet spurlos", Statuswechsel offen→erledigt muss auch innerhalb derselben
+  Kontrollsitzung möglich sein, mit vollständiger Zeitstempel-Historie.
 - **Benutzerwert:** Kern der ganzen Bestandskontrolle — keine manuelle Dauerüberwachung
   nötig.
 - **Abhängigkeiten:** INV-003, LOAD-001 (Soll kommt oft aus dem Beladungsplan)
@@ -131,14 +136,21 @@ Details zu INV-001 … INV-007 (vollständig).
 - **Mobile:** Nachfüllen im Feld
 - **QR-Code/Seriennummer/Inventarnummer:** nein
 - **Akte:** eigener Bereich bzw. Teil des Bestandsverlaufs
-- **Rechte:** Melden/Nachfüllen: Mitarbeiter+; Mindermenge genehmigen: Verantwortliche
+- **Rechte:** Melden/Nachfüllen: Mitarbeiter+; Mindermenge genehmigen: Verantwortliche.
+  Genehmigte Mindermenge (übernommen aus `arbeitskarten/08_mindermenge_gueltigkeit.md`,
+  Karte 08) gilt automatisch nur bis zur nächsten Kontrolle des betroffenen Objekts — kein
+  festes Ablaufdatum, kein unbefristetes Gelten. Bei nächster Kontrolle wird die Ist-Menge
+  neu erfasst; besteht die Abweichung weiterhin, muss neu entschieden werden (neue
+  Genehmigung oder Fehlbestand wieder aktiv).
 - **Audit:** Entstehung/Erledigung geloggt
 - **Akzeptanzkriterien:** Abweichung erzeugt Fehlbestand automatisch, Nachfüllung
-  reduziert Fehlmenge korrekt, bei 0 automatisch erledigt.
-- **Tests:** Erkennungstest, Nachfüll-Test, Mindermenge-Sonderfall.
-- **DoD:** deckt sich 1:1 mit MABEA (Fehlbestand-Kernmodul inkl. Mindermenge-Genehmigung)
-  — eines der am weitesten ausgereiften Module im gesamten Projekt, bereits vollständig
-  umgesetzt.
+  reduziert Fehlmenge korrekt, bei 0 automatisch erledigt — auch wenn Entstehung und
+  Erledigung in derselben Kontrollsitzung liegen.
+- **Tests:** Erkennungstest, Nachfüll-Test, Mindermenge-Sonderfall, Sofort-Nachfüllung
+  innerhalb derselben Kontrollsitzung.
+- **DoD:** deckt sich 1:1 mit MABEA (Fehlbestand-Kernmodul inkl. Mindermenge-Genehmigung
+  und Sofort-Nachfüllung-Sonderfall) — eines der am weitesten ausgereiften Module im
+  gesamten Projekt, bereits vollständig umgesetzt.
 
 ## INV-007 — Ausgabe/Rückgabe
 

arbeitskacheln/17_zustaendigkeit.md

@@ -0,0 +1,74 @@
+# Epic 17 — Zuständigkeit
+
+Details zu ZUST-001 … ZUST-002 (vollständig). Ü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).
+
+---
+
+## ZUST-001 — Objekt/Standort ↔ Verantwortlicher (Zuständigkeit)
+
+- **Ziel:** Administrator kann Verantwortliche flexibel Standorten und/oder Objekten
+  zuordnen, ohne starre zentrale/dezentrale Struktur vorzugeben.
+- **Beschreibung:** Zuständigkeit ist n:m (Verantwortlicher(e) ↔ Standort und/oder Objekt),
+  kein Hardcoding "eine Wache = ein Verantwortlicher". Ein Objekt kann mehrere
+  Verantwortliche gleichzeitig haben. Zuständigkeit vererbt sich vom Standort automatisch
+  auf alle Objekte an diesem Standort; eine zusätzliche objektspezifische Zuordnung ist
+  eine feinere Ergänzung obendrauf, kein Ersatz — Auswertelogik: ein Benutzer ist für ein
+  Objekt zuständig, wenn ENTWEDER eine Standort-Zeile für dessen Standort ODER eine
+  Objekt-Zeile für das Objekt selbst existiert (Vereinigung, keine Überschreibung).
+- **Benutzerwert:** Verantwortlichkeiten lassen sich so einteilen, wie die Organisation
+  tatsächlich arbeitet, nicht wie ein starres Schema es vorgibt.
+- **Abhängigkeiten:** FOUND-002, ASSET-003
+- **Datenmodell:** `zustaendigkeit` (benutzer_id, standort_id NULLABLE, objekt_id NULLABLE)
+- **Backend:** CRUD, Auswertelogik (Vereinigung Standort-/Objekt-Zuordnung)
+- **Frontend:** Verwaltungs-UI (Liste + Suche)
+- **Mobile:** keine eigene UI, wirkt sich auf Sichtbarkeit/Priorisierung aus
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Verantwortlichkeitsbereich (FILE-004)
+- **Rechte:** Administrator verwaltet
+- **Audit:** Änderung geloggt
+- **Akzeptanzkriterien:** Zuordnung auf Standort-Ebene wirkt auf alle zugehörigen Objekte,
+  zusätzliche Objekt-Zuordnung erweitert statt überschreibt.
+- **Tests:** Vererbungslogik-Test (Standort-Zuordnung + separate Objekt-Zuordnung
+  gleichzeitig).
+- **DoD:** deckt sich 1:1 mit MABEA (`Zustaendigkeit`-Tabelle, admin-UI mit Suche bereits
+  produktiv).
+
+## ZUST-002 — Objekt ↔ Benutzer/Gruppe (Kontrollzuweisung, freiwillig)
+
+- **Ziel:** Verantwortliche können Objekte gezielt einer Einzelperson oder Gruppe
+  zuweisen, ohne dass dies eine Pflichtkontrolle erzwingt.
+- **Beschreibung:** Grundsätzlich darf jeder Mitarbeiter jedes Objekt kontrollieren (keine
+  feste Pflichtzuordnung). Zuweisung ist reine Empfehlung/Sichtbarkeit/Priorisierung, kein
+  Zugriffsschutz — Schutz vor Doppelarbeit übernimmt die Objekt-Sperre nach Scan/
+  Kontrollstart, nicht die Zuweisung.
+- **Benutzerwert:** Klare Orientierung, wer für was zuständig ist, ohne andere
+  auszuschließen (wichtig bei Vertretung/Ausfall).
+- **Abhängigkeiten:** ZUST-001, PERS-003 (Gruppe)
+- **Datenmodell:** `kontrollverantwortung` (objekt_id, benutzer_id NULLABLE, gruppe
+  NULLABLE)
+- **Backend:** CRUD
+- **Frontend:** Verwaltungs-UI
+- **Mobile:** zugewiesene Objekte ggf. hervorgehoben/priorisiert in der Liste
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Verantwortlichkeitsbereich
+- **Rechte:** Administrator/Verantwortliche verwalten, Mitarbeiter sieht alle Objekte
+- **Audit:** Änderung geloggt
+- **Akzeptanzkriterien:** Zuweisung sichtbar/priorisiert, verhindert aber nicht, dass ein
+  anderer Mitarbeiter das Objekt trotzdem kontrolliert.
+- **Tests:** Zuweisungs-CRUD-Test.
+- **DoD:** deckt sich 1:1 mit MABEA (`Kontrollverantwortung`-Tabelle, admin-UI bereits
+  produktiv).
+
+---
+
+**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.
+
+## Referenzen
+Alte Arbeitskarten (übernommen, Karten-Dateien gelöscht): Karte 01 Rollen&Zuordnung,
+Karte 04 Organisationsstruktur/Zuständigkeit.

arbeitskacheln/18_notifications.md

@@ -0,0 +1,68 @@
+# Epic 18 — Notifications & Eskalation
+
+Details zu NOTIF-001 … NOTIF-002 (vollständig). Ü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.
+
+---
+
+## NOTIF-001 — Benachrichtigung bei neuem Fehlbestand
+
+- **Ziel:** Verantwortlicher erfährt zeitnah von neuem Fehlbestand, ohne aktiv nachschauen
+  zu müssen.
+- **Beschreibung:** Zwei Kanäle: Dashboard-Anzeige (Portal) und E-Mail. Kein Push/App in V1.
+- **Benutzerwert:** Kein Fehlbestand geht unbemerkt unter.
+- **Abhängigkeiten:** INV-006, FOUND-002
+- **Datenmodell:** keins zusätzlich (E-Mail-Versand ist zustandslos, triggert bei
+  Statuswechsel "offen")
+- **Backend:** E-Mail-Versand-Komponente, Trigger bei Fehlbestand-Entstehung
+- **Frontend:** Dashboard-Kachel (Pflichtbestandteil)
+- **Mobile:** Dashboard-Ansicht
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** nein direkt
+- **Rechte:** Verantwortliche erhalten Benachrichtigung für ihre Zuständigkeit
+- **Audit:** Versand nicht zwingend geloggt (kein fachlicher Vorgang, nur Benachrichtigung)
+- **Akzeptanzkriterien:** neuer Fehlbestand löst E-Mail an zuständigen Verantwortlichen aus
+  und erscheint im Dashboard.
+- **Tests:** Trigger-Test (Fehlbestand-Entstehung → E-Mail-Mock aufgerufen).
+- **DoD:** **Lücke in MABEA** — Dashboard-Anzeige existiert, aber kein E-Mail-Versand bei
+  Fehlbestand-Entstehung. Nur die Eskalationsstufen (NOTIF-002) versenden aktuell E-Mails.
+
+## NOTIF-002 — Eskalation lange offener Fehlbestände
+
+- **Ziel:** Automatische Eskalation, wenn ein Fehlbestand zu lange offen bleibt.
+- **Beschreibung:** Zwei Stufen — Erinnerung an Materialverantwortliche nach X Tagen,
+  Eskalation an Leitungsverantwortliche/Administration nach Y Tagen. Zeitschwellen
+  konfigurierbar, nicht fix im Code.
+- **Benutzerwert:** Verschleppte Fehlbestände werden nicht endlos ignoriert.
+- **Abhängigkeiten:** INV-006, NOTIF-001
+- **Datenmodell:** `eskalation_konfiguration` (Singleton-Zeile, Zeitschwellen je Stufe),
+  Tracking-Zeitstempel je Stufe an `fehlbestand` (verhindert Mehrfachversand)
+- **Backend:** `app/services/eskalation.py` (zweistufige Logik), `GET/PUT
+  /api/v1/eskalation/konfiguration` (admin-editierbar), `POST /api/v1/eskalation/pruefen`
+  (admin-only, Prüflauf anstoßen)
+- **Frontend:** Admin-UI zur Konfiguration + manueller "Jetzt prüfen"-Trigger
+- **Mobile:** nein
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** nein direkt
+- **Rechte:** Konfiguration/manueller Prüflauf: Administrator
+- **Audit:** Eskalationsversand nachvollziehbar über Tracking-Zeitstempel
+- **Akzeptanzkriterien:** Fehlbestand über Schwelle X löst Erinnerung aus, über Schwelle Y
+  Eskalation, kein Mehrfachversand derselben Stufe.
+- **Tests:** Schwellenwert-Tests (genau an der Grenze), Mehrfachversand-Schutz-Test.
+- **DoD:** deckt sich 1:1 mit MABEA — bereits vollständig umgesetzt und produktiv.
+  **Scheduling (Cron) ist Betriebsaufgabe**, kein eigener Scheduler-Prozess im Code — auf
+  dem Zielserver per systemd-Timer (`mabea-eskalation.timer`), der den Prüf-Endpunkt
+  periodisch aufruft.
+
+---
+
+**MABEA-Ist-Stand-Abgleich:** NOTIF-002 (Eskalation) ist vollständig umgesetzt und
+produktiv. **NOTIF-001 hat eine echte Lücke:** E-Mail bei Erst-Entstehung eines
+Fehlbestands fehlt — aktuell wird nur bei Eskalationsstufen gemailt, nicht sofort beim
+ersten Auftreten. Diese Epic-Datei existierte bislang nicht — reine Nachdokumentation
+plus eine offene Lücke, die im ursprünglichen 16-Epic-Backlog übersehen wurde.
+
+## Referenzen
+Alte Arbeitskarten (übernommen, Karten-Dateien gelöscht): Karte 05 Benachrichtigungen,
+Karte 12 Eskalation offener Fehlbestände.

arbeitskacheln/19_satelliten_server.md

@@ -0,0 +1,63 @@
+# Epic 19 — Satelliten-Server
+
+Details zu SAT-001 (Platzhalter/Architektur-Vorbereitung). Übernommen aus
+`arbeitskarten/13_satelliten_server.md` (Karte 13) — die größte gefundene Lücke im
+16-Epic-Backlog: eine bereits "entschieden" gewertete Architektur-Erweiterung mit
+konkreten Datenmodell-Konsequenzen, die in keinem der 16 ursprünglichen Epics erwähnt war.
+
+---
+
+## SAT-001 — Hauptserver mit Satelliten-Servern
+
+- **Ziel:** Zusätzlich zum Hauptserver können Satelliten-Server existieren, die lokal
+  (Einsatzort/Wache) laufen und temporär vom Hauptserver getrennt sind — für KatS-
+  Einsatzlagen ohne Internet, Wachen mit dauerhaft schlechter Anbindung, oder reinen
+  Ausfallschutz.
+- **Beschreibung:** Satellit ist funktional ein vollwertiger, kleiner Hauptserver-Klon
+  (gleiche Software/API/DB), kein reiner Cache — mehrere Mitarbeiter können gleichzeitig
+  am Satelliten arbeiten. Autark-Dauer bewusst nicht zeitlich begrenzt (Stunden bis Tage).
+  Konfliktvermeidung statt Konfliktlösung: jedes Objekt ist während einer Trennung fest
+  genau einem Server zugeordnet (Haupt- oder ein bestimmter Satellit), am jeweils anderen
+  für Schreibzugriffe gesperrt — dadurch strukturell kein "wer gewinnt"-Problem.
+- **Benutzerwert:** Betrieb bleibt auch bei längerem/vollständigem Verbindungsverlust
+  einsatzfähig, ohne Datenkonflikte beim späteren Zusammenführen.
+- **Abhängigkeiten:** FOUND-002, ASSET-003, MOBILE-003 (Abgrenzung: Satellit ist die
+  Lösung für ganze Standorte über längere Zeit, MOBILE-003 für Kurzzeit-Netzlücken
+  innerhalb einer einzelnen Kontrolle)
+- **Datenmodell:** Objekt braucht Feld "aktuell zugeordneter Server" (Hauptserver-ID oder
+  Satelliten-ID), änderbar nur durch bewussten Auslagerungs-/Rückhol-Vorgang. IDs
+  systemweit eindeutig von Anfang an (kein lokal generierter, kollisionsanfälliger Schlüssel)
+  — Voraussetzung für widerspruchsfreies Zusammenführen. Sync überträgt neu entstandene
+  Datensätze per Insert und geänderte bestehende Zeilen (offene Fehlbestände, aktive
+  Mindermengen-Genehmigungen, Objektpositionen) per Upsert.
+- **Backend:** Auslagerungs-/Rückhol-Endpunkte, Sync-Logik (Insert+Upsert), Schreibsperre
+  für ausgelagerte Objekte am Hauptserver
+- **Frontend:** Admin-UI zum Auslagern/Zurückholen
+- **Mobile:** kein Unterschied — Satellit spricht dieselbe API
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** zeigt ggf. aktuellen Server-Zuordnungsstatus
+- **Rechte:** Auslagerung/Rückholung: Administrator
+- **Audit:** Auslagerung/Rückholung geloggt, Sync-Vorgänge nachvollziehbar
+- **Akzeptanzkriterien:** Objekt an Satellit auslagern → am Hauptserver für Schreiben
+  gesperrt; nach Rückholung sind alle am Satelliten entstandenen/geänderten Daten korrekt
+  im Hauptserver.
+- **Tests:** Sync-Test (Insert neuer Datensätze + Upsert geänderter bestehender Zeilen),
+  Schreibsperre-Test während Auslagerung.
+- **DoD:** **DECISION REQUIRED zum Umsetzungszeitpunkt** — Nutzer-Entscheidung aus
+  früherer Session: "erstmal nur mit Hauptserver", also bewusst zurückgestellt. Offene
+  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.
+
+---
+
+**MABEA-Ist-Stand-Abgleich:** nicht umgesetzt, bewusst zurückgestellt (Nutzer-Entscheidung
+"erstmal nur mit main server gemacht"). Diese Epic-Datei existierte bislang nicht — reine
+Nachdokumentation der bereits getroffenen Architektur-Entscheidung, damit sie im Backlog
+nicht verloren geht, bis ein konkreter Bedarf zur Umsetzung führt.
+
+## Referenzen
+Alte Arbeitskarte (übernommen, Karten-Datei gelöscht): Karte 13 Hauptserver mit
+Satelliten-Servern.
+Weiterhin gültige Detail-Referenz (nicht gelöscht, eigenständiges Prompt-Ergebnisdokument):
+`ergebnisse/17_mobile_offline.md` Abschnitt 7, `ergebnisse/20_datenbank_schema.md` Punkt 10.

arbeitskacheln/DEVLOG.md

@@ -0,0 +1,14 @@
+# arbeitskacheln – Dev Log
+
+## 2026-09-05 17:00 – 17:02 (1m)
+**Beschreibung:** Claude Code Session
+**Projekt:** asb-material
+
+### Commits
+Keine Commits in dieser Session.
+
+### Geänderte Dateien
+- arbeitskacheln/00_index.md      |  3 ++-
+- arbeitskacheln/16_operations.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+---

arbeitskarten/00_index.md

@@ -1,24 +1,16 @@
-# Arbeitskarten – Index
+# Arbeitskarten – Index (aufgelöst, 2026-09-05)
 
-Status: entstanden aus Klärungsrunde vor Prompt 01. Jede Karte = ein entschiedener oder offener Punkt, mit Bezug zu `prompts.md`.
+**Dieser Ordner ist aufgelöst.** Alle 14 Karten (01–14) wurden gegen das neue
+Epic-/Kachel-Backlog in `arbeitskacheln/` geprüft und übernommen:
 
-| Nr | Karte | Status | Bezug |
-|----|-------|--------|-------|
-| 01 | [Rollen & Zuordnung](01_rollen_zuordnung.md) | entschieden | Prompt 05 |
-| 02 | [Rechte: Stammdaten vs. Ist-Menge](02_rechte_stammdaten.md) | entschieden | Prompt 05 |
-| 03 | [Sollmengen-Recht Materialverantwortlicher](03_sollmengen_recht.md) | entschieden | Prompt 04, 05 |
-| 04 | [Organisationsstruktur / Zuständigkeiten](04_organisationsstruktur.md) | entschieden, Detail offen | Prompt 05, 06 |
-| 05 | [Benachrichtigungen](05_benachrichtigungen.md) | entschieden | Prompt 12 |
-| 06 | [Geräteanforderung PC/Mobil](06_geraet_pc_mobil.md) | entschieden | Prompt 11, 17 |
-| 07 | [Sofort-Nachfüllung während Kontrolle](07_sofort_nachfuellung.md) | entschieden | Prompt 02, 03 |
-| 08 | [Mindermengen-Gültigkeit](08_mindermenge_gueltigkeit.md) | entschieden | Prompt 04 |
-| 09 | [Authentifizierung](09_authentifizierung.md) | entschieden | Prompt 05, 19 |
-| 10 | [QR-Code / Barcode](10_qr_barcode.md) | Roadmap, Datenmodell-Vorbereitung nötig | Prompt 06, 24 |
-| 11 | [Systemumfang: generisches Ressourcenmanagement](11_systemumfang_ressourcenmanagement.md) | entschieden, grundlegend | Prompt 06, 07 |
-| 12 | [Eskalation offener Fehlbestände](12_eskalation.md) | Roadmap, Datenmodell-Vorbereitung nötig | Prompt 03, 24 |
-| 13 | [Hauptserver mit Satelliten-Servern](13_satelliten_server.md) | entschieden, Betrieb Roadmap, Datenmodell-Vorbereitung nötig | Prompt 17, 19, 20 |
-| 14 | [Prüf- und wartungspflichtige Geräte](14_pruef_wartungspflicht.md) | Datenmodell entschieden, Umsetzung offen (geraet_instanz-Tabelle nötig) | Prompt 06, 10, 24 |
+- Karte 02, 03, 06, 09, 10, 11, 14 — inhaltlich bereits vollständig in bestehenden Epics
+  abgedeckt (FOUND-003/004, LOAD-001/002, MOBILE-001, IDENT-\*, ASSET-Grundprämisse,
+  INSP-Epic), Karten-Dateien gelöscht.
+- Karte 01, 04, 05, 07, 08, 12, 13 — enthielten Inhalte ohne Gegenstück im Backlog, daraus
+  entstanden `arbeitskacheln/17_zustaendigkeit.md`, `18_notifications.md`,
+  `19_satelliten_server.md` sowie zwei Ergänzungen in `06_inventory.md` (INV-006).
+  Karten-Dateien gelöscht.
 
-Nächster Schritt: Prompt `01_anforderungsanalyse` unter Berücksichtigung aller entschiedenen Karten bearbeiten.
-
-**Hinweis (Gesamtprüfung):** Wiki-Link-Aliase (`[[name]]`) sind uneinheitlich benannt (z. B. Datei `10_individuelle_beladung.md` wird teils als `[[10_individuelle_beladung]]`, teils sinngemäß referenziert). Vor Code-Umsetzung/Migration einmal Alias-Konsistenz gegen tatsächliche Dateinamen prüfen.
+Siehe `arbeitskacheln/00_index.md`, Abschnitt "Nachtrag: Abgleich mit alten
+Arbeitskarten" für Details. Alle fachlichen Entscheidungen leben jetzt ausschließlich in
+`arbeitskacheln/` weiter — dieser Ordner wird nicht mehr gepflegt.

arbeitskarten/01_rollen_zuordnung.md

@@ -1,14 +0,0 @@
-# Karte 01 – Rollen & Zuordnung
-
-**Status:** entschieden
-
-## Entscheidung
-Grundsätzlich darf jeder Mitarbeiter jedes Rucksack/Fahrzeug kontrollieren (keine feste Pflichtzuordnung). Zusätzlich können Verantwortliche gezielt zuweisen – entweder an eine Einzelperson oder an eine Gruppe.
-
-## Konsequenz für Datenmodell / Fachkonzept
-- Zuweisung ist optional, nicht Pflichtfeld.
-- Zuweisungsmodell muss sowohl Einzelperson als auch Gruppe unterstützen (z. B. Tabelle Zuweisung: Objekt ↔ Benutzer ODER Objekt ↔ Gruppe).
-- UI: Mitarbeiter sieht alle Objekte, ggf. zugewiesene hervorgehoben/priorisiert.
-
-## Geklärt (vormals offen)
-- Zuweisung erzwingt KEINE Pflichtkontrolle – reine Empfehlung/Sichtbarkeit/Priorisierung. Schutz vor Doppelarbeit übernimmt die Objekt-Sperre nach Scan/Kontrollstart (Prompt 02.8), nicht die Zuweisung.

arbeitskarten/02_rechte_stammdaten.md

@@ -1,10 +0,0 @@
-# Karte 02 – Rechte: Stammdaten vs. Ist-Menge
-
-**Status:** entschieden
-
-## Entscheidung
-Mitarbeiter/Kontrollorgan darf nur die tatsächliche Ist-Menge melden. Materialstammdaten (Bezeichnung, Artikelnummer usw.) sind für diese Rolle gesperrt.
-
-## Konsequenz
-- Rechtematrix (Prompt 05): Mitarbeiter = Ist-Menge erfassen, keine Stammdaten-Schreibrechte.
-- Stammdatenpflege bleibt Administration bzw. ggf. Materialverantwortlichem vorbehalten (siehe Karte 03).

arbeitskarten/03_sollmengen_recht.md

@@ -1,11 +0,0 @@
-# Karte 03 – Sollmengen-Recht Materialverantwortlicher
-
-**Status:** entschieden
-
-## Entscheidung
-Materialverantwortlicher darf Sollmengen (Beladungsvorlagen) selbst ändern – nicht nur Mindermengen genehmigen.
-
-## Konsequenz
-- Rechtematrix (Prompt 05): Materialverantwortlicher = Mindermengen genehmigen UND Sollmengen/Vorlagen bearbeiten.
-- Prompt 08 (Beladungsvorlagen): Vorlagenänderung muss diese Rolle als Berechtigten vorsehen, nicht nur Administration.
-- Historie/Audit (Prompt 13): Sollmengenänderungen durch Materialverantwortlichen müssen protokolliert werden (wer, wann, alt/neu).

arbeitskarten/04_organisationsstruktur.md

@@ -1,15 +0,0 @@
-# Karte 04 – Organisationsstruktur / Zuständigkeiten
-
-**Status:** entschieden
-
-## Entscheidung
-Keine starre zentrale ODER dezentrale Struktur vorgeben. Administrator muss Zuständigkeiten (welcher Verantwortliche für welchen Standort/welches Objekt) flexibel selbst einteilen können.
-
-## Konsequenz für Datenmodell
-- Zuständigkeit ist eigene, konfigurierbare Zuordnung: Verantwortlicher(e) ↔ Standort und/oder Objekt (Rucksack/Fahrzeug), n:m-Beziehung.
-- Kein Hardcoding von "eine Wache = ein Verantwortlicher".
-- Administration benötigt UI/Funktion zum Verwalten dieser Zuordnungen (Prompt 05).
-
-## Geklärt (vormals offen)
-- Ein Objekt kann mehrere Verantwortliche gleichzeitig haben (n:m, kein Limit).
-- Zuständigkeit vererbt sich vom Standort automatisch auf alle Objekte an diesem Standort. Zusätzliche objektspezifische Zuordnung (`zustaendigkeit.objekt_id` gesetzt) ist eine feinere Ergänzung obendrauf, kein Ersatz – Auswertelogik: ein Benutzer ist für ein Objekt zuständig, wenn ENTWEDER eine Standort-Zeile für dessen Standort ODER eine Objekt-Zeile für das Objekt selbst existiert (Vereinigung, keine Überschreibung).

arbeitskarten/05_benachrichtigungen.md

@@ -1,15 +0,0 @@
-# Karte 05 – Benachrichtigungen
-
-**Status:** entschieden
-
-## Entscheidung
-Bei neuem Fehlbestand wird Verantwortlicher benachrichtigt über:
-- Dashboard (Portal)
-- E-Mail
-
-Kein Push/App in V1.
-
-## Konsequenz
-- Prompt 12 (Dashboard): Dashboard-Anzeige ist Pflichtbestandteil.
-- Technische Architektur (Prompt 19): E-Mail-Versand-Komponente einplanen (z. B. Trigger bei Statuswechsel "offen").
-- Push/App bleibt spätere Ausbaustufe (Roadmap, Prompt 24).

arbeitskarten/06_geraet_pc_mobil.md

@@ -1,11 +0,0 @@
-# Karte 06 – Geräteanforderung PC/Mobil
-
-**Status:** entschieden
-
-## Entscheidung
-Kontrolle muss sowohl auf PC als auch auf Smartphone/Tablet funktionieren – kein "mobile-only" oder "PC-only".
-
-## Konsequenz
-- Prompt 11 (Mitarbeiter-UI): Responsive Design, keine reine Mobile-App-Annahme.
-- Prompt 17 (Mobile/Offline): Offline-Fähigkeit bleibt separat zu bewerten, unabhängig von Geräteklasse.
-- Technische Architektur (Prompt 19): Web-basiert sinnvoll, um beide Geräteklassen mit einer Codebasis abzudecken.

arbeitskarten/07_sofort_nachfuellung.md

@@ -1,10 +0,0 @@
-# Karte 07 – Sofort-Nachfüllung während Kontrolle
-
-**Status:** entschieden
-
-## Entscheidung
-Wenn Besatzung Fehlmenge noch während laufender Kontrolle direkt aus Lager nachfüllt, gilt: Fehlbestand entsteht trotzdem als Vorgang und wird im selben Moment als erledigt markiert. Kein "verschwindet spurlos".
-
-## Konsequenz
-- Prompt 03 (Fehlbestandsmanagement): Statuswechsel "offen" → "erledigt" muss auch innerhalb derselben Kontrollsitzung möglich sein (nicht nur über mehrere Kontrollen hinweg).
-- Historie (Prompt 13) muss diesen Fall abbilden: Fehlmenge festgestellt, Fehlbestand angelegt, Nachfüllung, erledigt – alles mit Zeitstempel, auch wenn zeitlich sehr nah beieinander.

arbeitskarten/08_mindermenge_gueltigkeit.md

@@ -1,11 +0,0 @@
-# Karte 08 – Mindermengen-Gültigkeit
-
-**Status:** entschieden
-
-## Entscheidung
-Genehmigte Mindermenge gilt automatisch nur bis zur nächsten Kontrolle des betroffenen Objekts – kein festes Ablaufdatum, kein unbefristetes Gelten.
-
-## Konsequenz
-- Prompt 04 (Mindermengen): Genehmigung ist an "nächste Kontrolle" gekoppelt, nicht an Kalenderdatum.
-- Bei nächster Kontrolle: Ist-Menge wird neu erfasst; ist die Abweichung weiterhin vorhanden, muss neu entschieden werden (neuer Genehmigungsvorgang oder Fehlbestand wieder aktiv).
-- Datenmodell: Genehmigung referenziert die Kontrolle, ab der sie NICHT mehr automatisch gilt (z. B. "gültig_bis_kontrolle_id" oder Statuslogik beim Kontrollabschluss).

arbeitskarten/09_authentifizierung.md

@@ -1,10 +0,0 @@
-# Karte 09 – Authentifizierung
-
-**Status:** entschieden
-
-## Entscheidung
-Version 1 benötigt echte Benutzerkonten mit Login (Passwort/PIN) – keine einfache Namensauswahl ohne Absicherung.
-
-## Konsequenz
-- Prompt 05 (Rollen/Rechte) und Prompt 19 (Architektur): Authentifizierungskomponente ist Pflichtbestandteil des MVP, nicht optional.
-- Zurechenbarkeit von Kontrollen/Genehmigungen/Änderungen (Prompt 13, Historie) basiert auf echtem Login, nicht auf Selbstauskunft.

arbeitskarten/10_qr_barcode.md

@@ -1,42 +0,0 @@
-# Karte 10 – QR-Code / Barcode
-
-**Status:** Roadmap-Feature, Datenmodell-Vorbereitung schon in V1 nötig
-
-## Entscheidung
-QR/Barcode-Scan ist gewünschte spätere Funktion:
-- Objekt-Code (Rucksack/Fahrzeug) → Direktsprung ins Kontroll-Screen (statt Portal → Standort → Fahrzeug → Rucksack suchen).
-- Geräte-Code (Einzelgerät) → automatische Seriennummer-Erkennung.
-
-## Konsequenz für V1 (jetzt schon vorsehen)
-- Prompt 06 (Datenmodell): Objekt (Rucksack/Fahrzeug) und Einzelgerät bekommen je ein eindeutiges Code-/ID-Feld, auch wenn Scan-UI erst später kommt.
-- Kein Schema-Umbau später nötig, nur Scan-Funktion (Kamera/Reader) ergänzen.
-
-## Umsetzung
-- Eigentliche Scan-Funktion → Prompt 24 (Roadmap), nicht MVP.
-
-## Barcode-Format (Nutzerentscheidung)
-- Standard: **Code128**, eindimensional, weit verbreitet.
-- Bewusste Wahl statt proprietärem/2D-Format, um Geräteauswahl offen zu halten.
-- Konsequenz Datenmodell: Code-Feld (Objekt/Gerät) muss Code128-kompatiblen Zeichensatz aufnehmen können (alphanumerisch, keine Sonderzeichen-Einschränkung nötig, Code128 deckt ASCII ab).
-- Zusatzanforderung: Code muss per Tablet-/Smartphone-Kamera lesbar sein (Software-Scan). Code128 ist per Kamera grundsätzlich lesbar, aber empfindlicher gegenüber Druckqualität/Abstand/Winkel als 2D-Codes wie QR. Konsequenz: Drucklayout (Größe, Kontrast) muss auf Kamera-Scan getestet werden.
-
-## Label-Design (offener Punkt, Prompt 24 vertiefend)
-- Physisches Label-Design (Größe, Material, Kontrast, Schriftgröße Klartext unter Code, Anbringungsort am Objekt) muss mit aufgenommen werden, nicht nur der Code-Inhalt selbst.
-- Anforderungen an Label aus Einsatzumfeld: witterungsbeständig/abriebfest (Rucksäcke/Fahrzeuge im Rettungsdiensteinsatz), Kontrast/Größe für zuverlässigen Kamera-Scan (siehe oben).
-- Klartext-Fallback auf Label empfohlen (Code + lesbare Objekt-ID), falls Scan mal ausfällt.
-- Konkretes Layout/Material erst bei Umsetzung (Prompt 24) final festlegen, hier nur als Anforderung vermerkt.
-
-## Umsetzungsstand (2026-09-04)
-- Backend: `objektposition.code`-Feld, Lookup-/Vorschlag-Endpunkte, PDF-Label-Erzeugung (`app/services/label.py`) fertig.
-- Frontend/Flutter: Kamera-Scan (Objekt-Code, Scan-First) fertig.
-- **Offen: Label-Druck-Test mit echten Geräten** (physischer Schritt, nicht per Code erledigbar). Test-PDF erzeugen: `python -m scripts.test_label_erzeugen` im Backend-venv.
-
-### Test-Checkliste (pro Labelgröße/-material einmal durchgehen)
-1. Test-Label drucken (`test_label_erzeugen.py`, mind. eine Größe pro geplantes Labelformat).
-2. Auf Ziel-Untergrund kleben/befestigen (Rucksack-Stoff, Fahrzeuglack o. Ä. – reale Anbringung testen, nicht nur Tisch/Papier).
-3. Mit jedem vorgesehenen Scan-Gerät testen (PWA im Handy-/Tablet-Browser, Flutter-App auf Android):
-   - Normalabstand (~15–20 cm) und Winkel 0°
-   - Schräger Winkel (~30°)
-   - Schwaches Licht / Gegenlicht
-4. Bei Fehlschlag: Modulbreite/Ruhezone in `_BARCODE_OPTIONEN` (`app/services/label.py`) erhöhen, neues Test-Label drucken, erneut testen.
-5. Ergebnis (Gerät, Abstand/Winkel, Erfolg/Fehlschlag) hier oder in einer neuen Notiz festhalten, bevor Seriendruck freigegeben wird.

arbeitskarten/11_systemumfang_ressourcenmanagement.md

@@ -1,18 +0,0 @@
-# Karte 11 – Systemumfang: generisches Ressourcenmanagement
-
-**Status:** entschieden, grundlegend (beeinflusst Benennung + Datenmodell)
-
-## Entscheidung
-System wird konzeptionell nicht als "Rettungsdienst-Materialverwaltung" gedacht, sondern als generisches **Ressourcen- und Materialmanagement**. Rettungsdienst/KatS sind ein Bereich davon, nicht der gesamte Scope.
-
-Perspektivisch zu verwaltende Objekttypen (Beispiele, nicht abschließend):
-Fahrzeuge, Rucksäcke, Zelte, Feldbetten, Stromerzeuger, Funkgeräte, Aggregate, Sanitätsmaterial, Betreuungsmaterial.
-
-## Konsequenz für Datenmodell (Prompt 06/07)
-- "Bereich" bzw. "Kategorie" wird eigene Dimension über dem Objekttyp – nicht Rettungsdienst hartcodiert.
-- Objekt-Entität (aktuell "Rucksack/Fahrzeug") sollte generisch als "Ressource"/"Ausrüstungsobjekt" modelliert werden, mit Typ als Attribut/Unterklasse statt eigener Tabelle je Objektart.
-- Materialstamm (Prompt 07) muss über Sanitätsmaterial hinaus erweiterbar bleiben (z. B. Betreuungsmaterial, technisches Material).
-
-## Auswirkung auf bestehende Prompts
-- Prompt 01 (Anforderungsanalyse): Scope-Beschreibung entsprechend generisch formulieren, nicht auf Rettungsdienst verengen.
-- Prompt 06 (Datenmodell): "Bereich" als Grunddimension explizit einführen.

arbeitskarten/12_eskalation.md

@@ -1,22 +0,0 @@
-# Karte 12 – Eskalation offener Fehlbestände
-
-**Status:** Roadmap-Feature, Datenmodell-Vorbereitung schon in V1 sinnvoll
-
-## Entscheidung
-Später gewünscht: automatische Eskalation bei lange offenen Fehlbeständen, z. B.:
-- Erinnerung nach X Tagen (🟡)
-- Eskalation an Leitungsverantwortlichen nach Y Tagen (🔴)
-
-Zeitschwellen konfigurierbar, nicht fix.
-
-## Konsequenz für V1
-- Prompt 03 (Fehlbestandsmanagement): Fehlbestand-Entität muss Zeitstempel "entstanden am" führen, damit "Alter" später berechenbar ist, ohne Modelländerung.
-- Kein Eskalationsmechanismus selbst in V1/MVP (Prompt 18) – nur Datenbasis dafür vorhalten.
-
-## Umsetzung
-- Eskalationslogik (Jobs, Schwellenwerte, Empfängerlogik) → Prompt 24 (Roadmap).
-
-## Umsetzungsstand (2026-09-04)
-- `app/services/eskalation.py`: zwei Stufen (Erinnerung an Materialverantwortliche, Eskalation an Leitungsverantwortliche/Administration), Tracking-Zeitstempel je Stufe verhindert Mehrfachversand.
-- Zeitschwellen in `eskalation_konfiguration` (DB, Singleton-Zeile) statt fix im Code - admin-editierbar über `GET/PUT /api/v1/eskalation/konfiguration`.
-- Prüflauf selbst per `POST /api/v1/eskalation/pruefen` (admin-only) angestoßen - **Scheduling (Cron) ist weiterhin Betriebsaufgabe**, kein eigener Scheduler-Prozess im Code (Prompt 19 Deployment-Regel). Auf dem Zielserver z. B. per systemd-Timer/Cron, der diesen Endpunkt periodisch mit Admin-Token aufruft.

arbeitskarten/13_satelliten_server.md

@@ -1,39 +0,0 @@
-# Karte 13 – Hauptserver mit Satelliten-Servern
-
-**Status:** Entschieden (Architektur-Erweiterung), betrifft Prompt 17 (Offline) und Prompt 19 (Architektur).
-
-## Entscheidung
-Zusätzlich zum Hauptserver können **Satelliten-Server** existieren, die lokal (am Einsatzort/an einer Wache) laufen und temporär vom Hauptserver getrennt sind.
-
-## Einsatzfälle
-1. KatS-Einsatzlage (Zeltlager/Einsatzort ohne Internet) – Satellit läuft autark vor Ort.
-2. Wache mit dauerhaft schlechter Anbindung – Satellit als Regelbetrieb, nicht nur Notfall.
-3. Reiner Ausfallschutz – Satellit übernimmt nur bei Komplettausfall Hauptserver/Internet.
-
-## Autark-Dauer
-Bewusst **nicht zeitlich begrenzt** – System darf keine feste Obergrenze annehmen (z. B. "nach 3 Tagen zwingend Sync nötig"). Trennung kann Stunden bis mehrere Tage/unbestimmt dauern.
-
-## Mehrbenutzerfähigkeit am Satelliten
-Satellit ist funktional ein vollwertiger, kleiner Hauptserver-Klon (gleiche Software/API), kein reiner Cache. Mehrere Mitarbeiter können gleichzeitig am selben Satelliten arbeiten – braucht keine eigene Konfliktlösung, da er wie der Hauptserver selbst funktioniert.
-
-## Konfliktvermeidung (statt Konfliktlösung)
-Zentrale Design-Entscheidung: Konflikte beim Zurücksynchronisieren **sollen strukturell nicht vorkommen**, nicht nachträglich aufgelöst werden.
-- Jedes Objekt (Rucksack/Fahrzeug) ist während einer Trennung **fest genau einem Server zugeordnet** – entweder Hauptserver oder ein bestimmter Satellit, nie beiden gleichzeitig.
-- Objekte, die einem Satelliten zugeteilt sind, werden am Hauptserver für Schreibzugriffe gesperrt/als "ausgelagert" markiert, bis Rücksynchronisation erfolgt ist.
-- Dadurch kein "wer gewinnt"-Problem – es gibt pro Objekt nur eine schreibende Quelle zu jedem Zeitpunkt.
-
-## Konsequenz für Datenmodell/Architektur (Vorbereitung, Details Prompt 19/20 zu vertiefen)
-- Objekt braucht Feld "aktuell zugeordneter Server" (Hauptserver-ID oder Satelliten-ID).
-- Zuordnung ändert sich nur durch bewussten Vorgang ("Objekt X an Satellit Y auslagern" / "Objekt X zurückholen"), nicht automatisch.
-- Historie/Fehlbestände/Kontrollen, die am Satelliten entstehen, tragen von Anfang an die eindeutigen IDs des Gesamtsystems (nicht lokal generierte, kollisionsanfällige IDs) – Voraussetzung für widerspruchsfreies Zusammenführen beim Sync.
-- Synchronisation überträgt beim Reconnect neu entstandene Datensätze (Kontrollen, Nachfüllungen, Historie, neue Objektpositionen/Zuständigkeiten) per Insert **und** am Satelliten geänderte, bereits vorher existierende Zeilen (Objektpositionen, offene Fehlbestände, aktive Mindermengen-Genehmigungen) per Upsert an den Hauptserver – kein reiner Append-Vorgang (konkretes SQL/Reihenfolge siehe [[20_datenbank_schema]] Punkt 10). Danach wird die Objekt-Zuordnung zurückgesetzt.
-
-## Offene Punkte für weitere Ausarbeitung
-- Wie wird eine Auslagerung technisch ausgelöst/verwaltet (manuell durch Administration vor einem Einsatz, oder automatisch bei Verbindungsverlust)?
-- Muss der Satellit vorab mit den relevanten Stammdaten bestückt werden, bevor er getrennt wird? Dazu gehören: Materialstamm, Vorlagen, betroffene Objekte/Objektpositionen, **sowie deren offene Fehlbestände und aktive Mindermengen-Genehmigungen** (ohne diese kann am Satelliten weder korrekt nachgefüllt noch genehmigt werden).
-- Was passiert, wenn beim Auslagern bereits eine Kontrolle am Hauptserver „in Bearbeitung" ist, bzw. wenn ein Objekt zurückgeholt werden soll, während am Satelliten noch eine Kontrolle läuft? – noch keine Regel definiert, vor Umsetzung zu klären (Vorschlag: Auslagerung/Rückholung nur bei Kontrollstatus „nicht gestartet" oder „abgeschlossen" zulassen).
-- Erzwingung von `objektposition.zuletzt_geaendert_am`: aktuell nur Spalten-Default, keine Garantie, dass jeder UPDATE-Pfad den Wert tatsächlich aktualisiert. Vorschlag: DB-Trigger `BEFORE UPDATE` statt Anwendungsdisziplin, um stillschweigend übersehene Änderungen beim Delta-Sync auszuschließen.
-- Hardware-Anforderung an Satelliten-Server (kleiner lokaler Rechner/Mini-PC vor Ort, Prompt 19 zu ergänzen).
-
-## Referenzen
-Bezug: [[17_mobile_offline]], [[19_technische_architektur]]

arbeitskarten/14_pruef_wartungspflicht.md

@@ -1,98 +0,0 @@
-# Karte 14 – Prüf- und wartungspflichtige Geräte
-
-**Status:** Konzeptphase, Datenmodell entschieden (2026-09-04), Umsetzung offen
-
-## Entscheidung
-Das Portal deckt nicht nur Bestandskontrolle (Soll/Ist-Mengen, Verbrauchsmaterial-
-Nachschub) ab, sondern auch gesetzlich/betrieblich prüf- und wartungspflichtige
-Geräte (z. B. Feuerlöscher, Defibrillatoren, Leitern, Atemschutzgeräte, Pulsoxymeter)
-mit wiederkehrenden Prüfintervallen und Fristen. Das ist fachlich etwas anderes als
-Ablaufdatum (einmaliges festes Datum) oder Charge (Identifikation) – hier geht es
-um einen wiederkehrenden Prüfzyklus mit Ergebnis pro Durchgang, UND um mehrere
-Geräte-Exemplare desselben Materials im selben Objekt.
-
-## Kernproblem im aktuellen Datenmodell
-`objektposition.seriennummer` ist ein Einzelfeld – kann nur EIN Gerät pro
-Materialtyp pro Objekt erfassen. Bei z. B. 2 Pulsoxymetern im selben Rucksack
-gibt es keine Möglichkeit, beide Seriennummern zu speichern. Das ist ein echtes
-Datenmodell-Defizit, kein UI-Problem – erfordert eine neue Entität.
-
-## Datenmodell (entschieden)
-
-Neue Tabelle `geraet_instanz` ersetzt `objektposition.seriennummer` für
-`materialtyp='geraet_sn'`:
-
-```sql
-CREATE TABLE geraet_instanz (
-    id                 UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    objektposition_id  UUID NOT NULL REFERENCES objektposition(id),
-    seriennummer       TEXT NOT NULL,
-    pruefdatum         DATE,                                    -- letzte Prüfung
-    naechste_pruefung  DATE,                                    -- fällige Prüfung
-    status             TEXT NOT NULL DEFAULT 'einsatzbereit',   -- einsatzbereit / defekt / in_reparatur
-    bemerkung          TEXT,
-    UNIQUE (objektposition_id, seriennummer)
-);
-```
-
-- `objektposition.seriennummer` entfällt (Migration: bestehende Werte nach
-  `geraet_instanz` überführen, dann Spalte droppen).
-- Ist-Menge bei `geraet_sn` wird nicht mehr als Zahl geführt/eingegeben, sondern
-  als Anzahl der `geraet_instanz`-Zeilen mit `status='einsatzbereit'` berechnet.
-- `objektposition`: neues Feld `pruefintervall_monate` (int, nullable) –
-  **individuell überschreibbar** je Objektposition (wie `sollmenge_override`),
-  Vorlage/Material kann einen Standard vorgeben, einzelne Objektposition kann
-  abweichen (z. B. älteres Gerät mit kürzerer Frist).
-- `naechste_pruefung` je `geraet_instanz` wird nach jeder erfassten Prüfung neu
-  berechnet (`pruefdatum + pruefintervall_monate`).
-
-## "Nicht bestanden" / defekt → Fehlbestand (entschieden)
-**Pro Gerät entscheidbar, nicht global fix.** Beim Setzen von
-`status='defekt'` oder `status='in_reparatur'` an einer `geraet_instanz` wird
-im selben Dialog gefragt/entschieden, ob daraus ein Fehlbestand entsteht (nutzt
-die bestehende Fehlbestand-/Eskalations-Infrastruktur weiter, kein Parallel-
-Konzept). Die ganze bestehende Fehlbestand-Logik (Kette Fehlbestand →
-Nachfüllung/Mindermenge → Historie) wird dabei mitgenutzt, nicht neu gebaut –
-ein "defektes Gerät" ist fachlich einfach ein Fehlbestand mit Fehlmenge=1 an
-dieser Position.
-
-## Erfassungs-UI für `geraet_sn` (komplett neu, kein Mengenfeld mehr)
-
-Statt Mengenfeld + "Passt"-Button: Instanz-Liste pro Position.
-
-```
-┌─────────────────────────────────────────┐
-│ Pulsoxymeter Modell X (Soll: 2)          │
-├─────────────────────────────────────────┤
-│ ✓ SN-001  [Prüfdatum: 2025-03-15] [OK]   │
-│ ✓ SN-002  [Prüfdatum: 2025-06-22] [OK]   │
-│ + Gerät hinzufügen (SN scannen/eingeben) │
-└─────────────────────────────────────────┘
-```
-
-Buttons pro Instanz:
-- **OK** – Gerät ist da, einsatzbereit.
-- **Fehlt/Defekt** – Dialog: Grund (fehlt/defekt/in Reparatur), Bemerkung →
-  Instanz-Status ändern, bei "fehlt"/"defekt" optional Fehlbestand erzeugen
-  (siehe oben, pro Gerät entscheidbar).
-
-`materialtyp='ablauf_charge'` und `'standard'` bleiben unverändert (Mengenfeld
-+ Passt-Button wie bisher) – nur `geraet_sn` bekommt diese neue Erfassungsart.
-
-## Eskalation bei überfälliger Prüfung
-Bestehende Zwei-Stufen-Mechanik (`app/services/eskalation.py`) um eine zweite
-Datenquelle erweitern: überfällige `geraet_instanz.naechste_pruefung` statt
-`fehlbestand.entstanden_am`. Eigene Konfigurationszeile/-spalten, damit
-Prüf-Fristen unabhängig von Fehlbestand-Fristen einstellbar sind (TÜV-Fristen
-unterscheiden sich je nach Gerätetyp).
-
-## Umsetzungsschritte (grobe Reihenfolge)
-1. Migration: `geraet_instanz`-Tabelle, `objektposition.pruefintervall_monate`,
-   Daten-Migration bestehender `seriennummer`-Werte, danach Spalte droppen.
-2. Backend: `geraet_instanz`-Model + Service (CRUD, Status ändern inkl.
-   optionaler Fehlbestand-Erzeugung, Ist-Menge-Berechnung für `geraet_sn`).
-3. Backend: Eskalation um Prüf-Fälligkeit erweitern.
-4. Frontend: neue Instanz-Listen-UI für `geraet_sn` in der Kontroll-Erfassung
-   (`PositionCard.tsx`/`KontrollPage.tsx`), Scan-Integration (Karte 10) für
-   SN-Eingabe wiederverwenden.
-5. Frontend: Admin-Pflege der Geräte-Instanzen (analog `ObjektPositionenPanel`).