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