Dateien nach "/" hochladen

15_lager.md

@@ -0,0 +1,26 @@
+# Prompt 15 – Zukünftige Lagerintegration
+
+Bezug: [[06_datenmodell]], [[07_materialstamm]], [[02_prozess_kontrolle]]. Status: Roadmap-Konzept, NICHT MVP (V1 bleibt bewusst einfach).
+
+## 1. Grundprinzip
+Klare Trennung: Fahrzeug-/Rucksackbestand (Objektposition, operativ) vs. Lagerbestand (zentral, disponierend). V1 kennt nur „aus dem Lager nachgefüllt" als Aktion, ohne echte Lagerbestandsführung.
+
+## 2. Zukünftige Lager-Entität (analog Objekt)
+- **Lagerort** – eigener Standort-Typ, z. B. „Zentrallager Wache 1".
+- **Lagerbestand** – Materialstamm-Referenz + Lagerort-Referenz + Menge, gleiche Materialstamm-Basis wie Objektpositionen (Prompt 06 Designziel: keine Duplizierung der Stammdaten).
+
+## 3. Prozesse (Roadmap)
+- **Materialentnahme**: Nachfüllung eines Objekts (Prompt 02) bucht künftig automatisch vom Lagerbestand ab, statt nur zu dokumentieren „nachgefüllt". Fehlt Lagerbestand → System warnt vor Entnahme, statt sie zu blockieren (keine harte Sperre, damit Einsatzfähigkeit nie durch Software blockiert wird).
+- **Nachfüllung des Lagers selbst**: eigener Vorgang, Bestellung/Wareneingang erhöht Lagerbestand (Details Prompt 24).
+- **Mindestbestände**: je Lagerbestand konfigurierbarer Schwellenwert, System warnt Lagerverantwortlichen (Roadmap-Rolle, Prompt 05) bei Unterschreitung.
+- **Automatische Hinweise**: Dashboard-Erweiterung (Prompt 12) um „Lager unter Mindestbestand", analog zu Fehlbestand-Logik, aber eigener Vorgangstyp (nicht zu verwechseln mit Fehlbestand am Fahrzeug/Rucksack).
+
+## 4. Warum nicht in V1
+- Erfordert zusätzliche Prozesse (Wareneingang, Bestellwesen, Mindestbestands-Pflege), die den MVP-Umfang sprengen (Grundprinzip: „Version 1 soll bewusst klein und praxistauglich bleiben").
+- V1-Nachfüllung bleibt bewusst simpel: Mitarbeiter bestätigt „habe nachgefüllt", ohne dass System prüft, ob Lager das hergibt.
+
+## 5. Vorbereitung im Datenmodell (falls sinnvoll, ohne V1 zu verkomplizieren)
+- Keine zwingende Vorbereitung nötig, da Lagerbestand strukturell wie ein weiteres „Objekt" mit eigenem Bestand modellierbar ist (Wiederverwendung Prompt 06) – kein Schema-Umbau bei späterer Einführung erwartet, nur neue Entität „Lagerort/Lagerbestand" + neuer Prozess „Entnahme bucht ab".
+
+## Referenzen
+Bezug: [[06_datenmodell]], [[07_materialstamm]], [[02_prozess_kontrolle]], [[05_rollen_rechte]] (Roadmap-Rolle Lagerverantwortlicher)

16_kontrollabschluss.md

@@ -0,0 +1,39 @@
+# Prompt 16 – Kontrolle abschließen
+
+Bezug: [[02_prozess_kontrolle]], [[03_fehlbestandsmanagement]], [[11_kontroll_ui]].
+
+## 1. Wann gilt eine Kontrolle als abgeschlossen
+Eine Kontrolle gilt als abgeschlossen, wenn Mitarbeiter jede Position mindestens einmal bewertet hat (bestätigt „passt" oder Ist-Menge eingetragen) und aktiv „Kontrolle abschließen" bestätigt (Prompt 11, Screen 6). Offene Fehlbestände sind KEIN Blocker für den Abschluss.
+
+## 2. Verhalten bei offenen Abweichungen
+- Kontrolle wird trotz offener Fehlbestände abgeschlossen (Status „abgeschlossen").
+- Jeder offene Fehlbestand bleibt als eigenständiger, von der Kontrolle entkoppelter Vorgang bestehen (Prompt 03) – Abschluss der Kontrolle ändert seinen Status nicht.
+- Während der Kontrolle nachgefülltes Material: wird als behobene Abweichung dokumentiert (Fehlbestand entsteht und wird im selben Moment erledigt, Historieneintrag zeigt beide Ereignisse, Karte 07/Prompt 02).
+
+## 3. Abschlussanzeige (Screen 6, Prompt 11 vertieft)
+- Zusammenfassung: Gesamtzahl Positionen, davon ok, davon abweichend, davon sofort nachgefüllt, davon weiterhin offen.
+- Liste der weiterhin offenen Fehlbestände mit direktem Link zur Detailansicht (Dashboard, Prompt 12).
+- Deutlicher Hinweis: „X Fehlbestände bleiben offen und sind für Verantwortliche sichtbar" – kein falscher Eindruck von „alles erledigt".
+
+## 4. Bestätigung
+- Einmalige, eindeutige Bestätigungsaktion (Button „Kontrolle abschließen"), kein Doppel-Abschluss möglich (Status-Übergang „in Bearbeitung" → „abgeschlossen" ist einmalig terminal für diese Kontrollinstanz).
+- Nach Abschluss keine Änderung an bereits erfassten Kontrollpositionen mehr möglich (Snapshot-Prinzip, Prompt 06/13) – Korrekturen nur durch neue Kontrolle oder durch separate Nachfüllung/Fehlbestand-Bearbeitung außerhalb der Kontrolle.
+
+## 5. Kontrollnachweis
+- Nach Abschluss automatisch erzeugtes, unveränderliches Dokument/Datensatz: wer, wann, Objekt, Ergebnis je Position (Snapshot), Liste ausgelöster Fehlbestände.
+- Standard-Nachweis: Login-gebundene Zuordnung (wer eingeloggt war und die Aktion ausgeführt hat) gilt als Unterschriftsersatz, kein Zusatzschritt nötig.
+- Optional/konfigurierbar (Nutzerentscheidung): **Touch-Unterschrift** (Zeichenfeld auf Tablet/Smartphone, als Bild mit Kontrolle verknüpft gespeichert) einschaltbar, falls von übergeordneter Stelle (z. B. Kreisverband, Behörde) gefordert. Kein Zwang für alle Standorte – als abschaltbare Option pro Organisation/Standort vorgesehen, nicht MVP-Pflicht, aber Datenmodell sollte optionales Signaturbild-Feld am Kontrollnachweis vorsehen (kein Schema-Umbau später nötig).
+- Dient als digitaler Ersatz der bisherigen Papier-Unterschrift (Prompt 23 vertieft Migration).
+- Einsehbar in Objekt-Historie (Prompt 13) und für Audit-Zwecke durch Verantwortliche/Administration.
+
+## 6. Abgebrochene Kontrolle (Antwort auf offene Frage aus Prompt 02)
+**Frage war:** Braucht abgebrochene Kontrolle eine Aufbewahrung als Teil-Historie, oder wird sie komplett verworfen?
+
+**Entscheidung:** Abgebrochene Kontrolle wird NICHT komplett verworfen, aber auch nicht als gültiger Kontrollnachweis gezählt:
+- Status „abgebrochen" bleibt als Datensatz erhalten (wer hat wann begonnen und abgebrochen), rein zur Nachvollziehbarkeit (z. B. „warum wurde Rucksack X seit 3 Tagen nicht fertig kontrolliert").
+- Keine Ist-Werte aus der abgebrochenen Kontrolle werden auf das Objekt übernommen, kein Fehlbestand wird daraus ausgelöst.
+- Objekt bleibt im Zustand vor Kontrollbeginn (bzw. „nicht kontrolliert seit Datum X"), zählt weiterhin als fällig für Kontrolle.
+- Grund für Abbruch optional erfassbar (Freitext, z. B. „Einsatzalarmierung").
+
+## Referenzen
+Bezug: [[02_prozess_kontrolle]], [[03_fehlbestandsmanagement]], [[11_kontroll_ui]], [[13_historie_audit]]

17_mobile_offline.md

@@ -0,0 +1,44 @@
+# Prompt 17 – Mobile und Offline-Nutzung
+
+Bezug: [[11_kontroll_ui]], Karte [[06_geraet_pc_mobil]]. Rein fachliches Konzept, keine Technologiewahl (folgt Prompt 19).
+
+## 1. Ausgangslage
+Rettungsdienst/KatS-Umfeld: wechselnde Fahrzeuge/Wachen, Netzabdeckung nicht durchgängig gesichert (Annahme aus Prompt 01). Kontrolle darf nicht an fehlendem Netz scheitern.
+
+## 2. Bewertung: braucht V1 echtes Offline?
+- Voll-Offline (mehrstündig, mit späterer Synchronisierung inkl. Konfliktlösung) ist komplex und erhöht MVP-Umfang erheblich (Grundprinzip: V1 klein halten).
+- Praxisrelevanter Fall ist eher **kurzzeitiger Netzausfall/-lücke während einer laufenden Kontrolle**, nicht stundenlange Komplett-Offline-Nutzung ganzer Wachen.
+- Entscheidung: V1 unterstützt **robuste Kurzzeit-Unterbrechung** (siehe 3.), aber KEIN vollwertiges Offline-Konzept mit Mehrgeräte-Konfliktlösung. Vollwertiges Offline = Roadmap (Prompt 24).
+
+## 3. Konzept für V1 (Kurzzeit-Netzausfall)
+- Eingaben in der Kontroll-UI (Prompt 11) werden lokal im Gerät zwischengespeichert, sobald eingegeben – nicht erst bei Übertragung an Server verworfen, wenn Verbindung kurz fehlt.
+- Bei wiederhergestellter Verbindung: automatische Übertragung der zwischengespeicherten Eingaben, ohne dass Mitarbeiter erneut eintippen muss.
+- Deutliche Statusanzeige in der UI: „nicht gespeichert/wird übertragen" vs. „gespeichert" je Position, damit Mitarbeiter erkennt, ob Eintrag schon serverseitig gesichert ist.
+- Kontrolle kann nicht abgeschlossen werden (Prompt 16), solange nicht alle Positionen serverseitig bestätigt gespeichert sind – Abschluss-Button wartet/blockiert mit Hinweis, statt fälschlich „abgeschlossen" bei unvollständiger Übertragung zu melden.
+
+## 4. Was V1 NICHT leisten muss
+- Mehrstündige Offline-Nutzung ohne jede Verbindung.
+- Bearbeitung derselben Kontrolle durch mehrere Geräte gleichzeitig mit Konfliktauflösung (ohnehin in Prompt 02 ausgeschlossen: eine Kontrolle = eine Person zu einem Zeitpunkt).
+- Vollständige lokale Kopie des Materialstamms/aller Objekte für Offline-Betrieb.
+
+## 5. Kennzeichnung nicht synchronisierter Daten
+- Solange lokale Zwischenspeicherung nicht bestätigt an Server übertragen ist: eindeutiges visuelles Merkmal (z. B. Uhr-Symbol) an betroffenen Positionen/Kontrolle in der UI.
+- Kein „stiller" Datenverlust: Verbindungsabbruch mitten in Eingabe darf Eingabe nicht kommentarlos verwerfen.
+
+## 6. Roadmap-Erweiterung (Prompt 24)
+- Echtes Offline-Modell (z. B. ganze Schicht ohne Netz arbeiten, spätere Synchronisierung mehrerer Geräte, Konfliktbehandlung bei parallelen Änderungen) als spätere Ausbaustufe, sobald reale Nutzung zeigt, ob Bedarf über Kurzzeit-Unterbrechung hinausgeht.
+- Technisch möglicher Weg dahin (unverbindliche Notiz, Entscheidung erst Prompt 19): App (native oder PWA mit Service Worker) mit lokaler Datenhaltung auf dem Gerät, Synchronisierung bei wiederhergestellter Verbindung. Erfordert lokale Kopie relevanter Stammdaten (Materialstamm/Objekte des Nutzers) sowie Konfliktlösung bei paralleler Bearbeitung.
+
+## 7. Erweiterung: Satelliten-Server bei längerem/vollständigem Internetausfall (Karte 13, Nutzerentscheidung)
+Über die reine Kurzzeit-Unterbrechung (Punkt 3) hinaus wurde eine zweite, unabhängige Lösung für **längere oder vollständige Trennung vom Hauptserver** entschieden – relevant vor allem für KatS-Einsatzlagen (Zeltlager/Einsatzort ohne Internet) und Wachen mit dauerhaft schlechter Anbindung.
+
+- **Ansatz:** Kein Client-seitiges Offline-Caching für diesen Fall, sondern ein **Satelliten-Server** – ein vollwertiger, kleiner Klon des Hauptservers (gleiche Software/API/Datenbank), der lokal am Einsatzort/an der Wache läuft.
+- **Autark-Dauer:** bewusst nicht zeitlich begrenzt (kann Stunden bis mehrere Tage/unbestimmt sein) – kein System-Zwang zur Rücksynchronisation nach fester Frist.
+- **Mehrbenutzerfähigkeit:** mehrere Mitarbeiter können gleichzeitig am selben Satelliten arbeiten, da dieser funktional wie ein eigener Hauptserver arbeitet (keine reine Cache-Lösung).
+- **Konfliktvermeidung statt Konfliktlösung:** jedes Objekt ist während der Trennung exakt einem Server (Haupt- oder Satellit) fest zugeordnet und am jeweils anderen für Schreibzugriffe gesperrt. Dadurch entstehen strukturell keine Synchronisationskonflikte.
+- Details, offene Punkte (Auslagerungs-Auslöser, Stammdaten-Vorbereitung des Satelliten, Hardware) siehe [[13_satelliten_server]].
+- Abgrenzung zu Punkt 3: Kurzzeit-Pufferung im Browser bleibt für kurze Netzlücken während einer einzelnen Kontrolle; Satelliten-Server ist die Lösung für ganze Standorte/Einsatzorte über längere Zeiträume.
+
+## Referenzen
+Bezug: [[11_kontroll_ui]]
+Arbeitskarten: [[06_geraet_pc_mobil]], [[13_satelliten_server]]

18_version_1.md

@@ -0,0 +1,53 @@
+# Prompt 18 – MVP definieren
+
+Bezug: alle Ergebnisse 01-17. Letzter fachlicher Prompt vor der Technikphase (19-22).
+
+## 1. Ziel MVP
+Papierlisten bei Rucksack-/Fahrzeugkontrollen möglichst weitgehend ersetzen, Grundprinzip: „Version 1 soll bewusst klein und praxistauglich bleiben."
+
+## 2. Must-have (zwingend für V1)
+
+| Bereich | Umfang |
+|---|---|
+| Materialstamm | Alle 3 Materialtypen (Standard, Ablaufdatum/Charge, Gerät-mit-SN), Basisfelder (Prompt 07) |
+| Kategorien/Bereich | Bereichsoffenes Modell (Karte 11), aber V1 produktiv nur Rettungsdienst/KatS befüllt |
+| Rucksäcke/Fahrzeuge (Objekte) | Anlegen, Duplizieren (Prompt 09), Code-Feld für QR/Barcode vorbereitet (nicht Scan-Funktion selbst) |
+| Beladungsvorlagen | Erstellen, Versionieren, Zuweisen (Prompt 08) |
+| Individuelle Anpassungen | Sollmengen-Override, Material hinzufügen/entfernen je Objekt (Prompt 10) |
+| Digitale Kontrolle | Voller Workflow inkl. Statusmaschine, Abweichung, Nachfüllung während Kontrolle (Prompt 02, 11) |
+| Automatische Fehlbestände | Vollständige Statusmaschine (Prompt 03) |
+| Nachfüllung | Innerhalb und außerhalb der Kontrolle (Prompt 02) |
+| Mindermengen-Ausnahmen | Genehmigung, Gültigkeit bis nächste Kontrolle, Historie (Prompt 04) |
+| Rollen/Rechte | Alle 4 Rollen, Berechtigungsmatrix (Prompt 05) |
+| Verantwortlichen-Dashboard | Kennzahlen, Listen, Filter (Prompt 12) |
+| Historie/Audit | Vollständige Protokollierung aller Ereignistypen (Prompt 13) |
+| Ablaufdaten | Warnzeiträume, 3 Zustände, Anzeige in Kontrolle+Dashboard (Prompt 14) |
+| Kontrollabschluss | Regeln, Kontrollnachweis, abgebrochene Kontrolle (Prompt 16) |
+| Authentifizierung | Echtes Login (Passwort/PIN), Karte 09 |
+| Benachrichtigung | Dashboard + E-Mail bei neuem Fehlbestand, kein Push (Karte 05) |
+| Bedienbarkeit | PC und Smartphone/Tablet, responsive statt getrennte Codebasen (Prompt 11) |
+| Netzstabilität | Robuste Kurzzeit-Unterbrechung, keine Datenverluste bei kurzem Netzausfall (Prompt 17) |
+
+## 3. Should-have (wünschenswert, aber verschiebbar ohne V1 zu gefährden)
+- Feingranulare Zusatzrechte über Basismatrix hinaus (Prompt 05, Punkt 4) – Basismatrix reicht für V1.
+- Standard-Warnzeiträume je Material individuell überschreibbar (Prompt 14) – globaler Standardwert reicht zunächst.
+- Serien-Duplizieren mehrerer Objekte auf einmal (Prompt 09, Punkt 6) – Einzel-Duplizieren ist Pflicht, Serie ist Komfort.
+
+## 4. Später/Roadmap (bewusst NICHT in V1, siehe jeweilige Prompts)
+- QR-/Barcode-Scan-Funktion selbst (Karte 10) – nur Datenmodell-Vorbereitung in V1.
+- Label-Design/Druck-Umsetzung (Karte 10) – Anforderung dokumentiert, Umsetzung Prompt 24.
+- Automatische Eskalationslogik (Karte 12) – nur Datenbasis („entstanden am") in V1, Alter-Sortierung im Dashboard als einfache Vorstufe.
+- Generische Ausweitung auf weitere Ressourcentypen über Rettungsdienst/KatS hinaus (Karte 11) – Modell ist offen, aber V1 befüllt nur einen Bereich.
+- Lagerverwaltung mit eigenen Lagerorten/Mindestbeständen (Prompt 15).
+- Vollwertiges Offline-Konzept mit Mehrgeräte-Sync/Konfliktlösung (Prompt 17).
+- Satelliten-Server-Betrieb (Auslagerung/Synchronisation, Karte 13) – Datenmodell bereits vorbereitet (UUID-Primärschlüssel auf sync-relevanten Tabellen, Objekt-Zuordnungsfeld), tatsächlicher Betrieb/UI für Auslagern-Zurückholen ist Roadmap.
+- Push-Benachrichtigungen (Karte 05).
+- Medikamente/Betäubungsmittel-Sonderregeln, Mehrfach-Chargen (Prompt 14).
+- Prüfungen/Prüfintervalle als eigener Vorgangstyp (vorbereitet in Prompt 07, nicht umgesetzt).
+- Roadmap-Rollen: Lagerverantwortlicher, Prüforgan, Bereichsleitung, Read-only-Auditor (Prompt 05).
+
+## 5. Abgrenzung zur bisherigen Papierlösung
+V1 deckt den kompletten heutigen Papierprozess ab (Kontrolle, Abweichung, Nachfüllung, Unterschrift-Äquivalent = Kontrollnachweis) und fügt zusätzlich automatische Fehlbestandsverfolgung + Mindermengen-Historie hinzu, was auf Papier nicht bestand. Vertiefende Migrationsbetrachtung folgt in Prompt 23.
+
+## Referenzen
+Bezug: Ergebnisse 01-17, alle Arbeitskarten