# 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.