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
2026-09-03 21:35:13 +02:00
commit 7c68eb8a7e
46 changed files with 4655 additions and 0 deletions
@@ -0,0 +1,23 @@
+# Arbeitskarten – Index
+
+Status: entstanden aus Klärungsrunde vor Prompt 01. Jede Karte = ein entschiedener oder offener Punkt, mit Bezug zu `prompts.md`.
+
+| 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 |
+
+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.
@@ -0,0 +1,14 @@
+# 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.
+
+## Offen
+- Muss Zuweisung fällige Kontrollen "erzwingen" (Pflichtkontrolle) oder ist sie nur Empfehlung/Sichtbarkeit? → bei Prompt 02/05 klären.
@@ -0,0 +1,10 @@
+# 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).
@@ -0,0 +1,11 @@
+# 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).
@@ -0,0 +1,15 @@
+# Karte 04 – Organisationsstruktur / Zuständigkeiten
+
+**Status:** entschieden, Detail noch offen
+
+## 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).
+
+## Offen
+- Kann ein Objekt mehrere Verantwortliche gleichzeitig haben? (Vermutlich ja, klären bei Prompt 05/06.)
+- Vererbt sich Zuständigkeit vom Standort auf alle Objekte am Standort automatisch, oder muss sie separat je Objekt gesetzt werden?
@@ -0,0 +1,15 @@
+# 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).
@@ -0,0 +1,11 @@
+# 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.
@@ -0,0 +1,10 @@
+# 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.
@@ -0,0 +1,11 @@
+# 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).
@@ -0,0 +1,10 @@
+# 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.
@@ -0,0 +1,27 @@
+# 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.
@@ -0,0 +1,18 @@
+# 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.
@@ -0,0 +1,17 @@
+# 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).
@@ -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]]