From 8a8f9894ef94818e13b539da89253b21e3267c8c Mon Sep 17 00:00:00 2001 From: patrick Date: Thu, 3 Sep 2026 17:24:58 +0200 Subject: [PATCH] Dateien nach "/" hochladen --- 09_authentifizierung.md | 10 +++++++ 10_qr_barcode.md | 27 ++++++++++++++++++ 11_systemumfang_ressourcenmanagement.md | 18 ++++++++++++ 12_eskalation.md | 17 ++++++++++++ 13_satelliten_server.md | 37 +++++++++++++++++++++++++ 5 files changed, 109 insertions(+) create mode 100644 09_authentifizierung.md create mode 100644 10_qr_barcode.md create mode 100644 11_systemumfang_ressourcenmanagement.md create mode 100644 12_eskalation.md create mode 100644 13_satelliten_server.md diff --git a/09_authentifizierung.md b/09_authentifizierung.md new file mode 100644 index 0000000..f89bb85 --- /dev/null +++ b/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. diff --git a/10_qr_barcode.md b/10_qr_barcode.md new file mode 100644 index 0000000..9850126 --- /dev/null +++ b/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. diff --git a/11_systemumfang_ressourcenmanagement.md b/11_systemumfang_ressourcenmanagement.md new file mode 100644 index 0000000..0327610 --- /dev/null +++ b/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. diff --git a/12_eskalation.md b/12_eskalation.md new file mode 100644 index 0000000..c11b35f --- /dev/null +++ b/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). diff --git a/13_satelliten_server.md b/13_satelliten_server.md new file mode 100644 index 0000000..6702b18 --- /dev/null +++ b/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]]