Dateien nach "/" hochladen

09_authentifizierung.md

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

10_qr_barcode.md

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

11_systemumfang_ressourcenmanagement.md

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

12_eskalation.md

@@ -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).

13_satelliten_server.md

@@ -0,0 +1,37 @@
+# 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 alle am Satelliten neu entstandenen Datensätze (Kontrollen, Fehlbestände, Nachfüllungen, Historie) an den Hauptserver, 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 (Materialstamm, Vorlagen der betroffenen Objekte) bestückt werden, bevor er getrennt wird?
+- 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]]