Initiale fachliche Konzeption MABEA (Prompts 01-23, Arbeitskarten 01-13)

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

arbeitskarten/13_satelliten_server.md

@@ -0,0 +1,39 @@
+# 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]]