diff --git a/arbeitskacheln/00_index.md b/arbeitskacheln/00_index.md index 067e4c3..897c51e 100644 --- a/arbeitskacheln/00_index.md +++ b/arbeitskacheln/00_index.md @@ -50,6 +50,9 @@ Epic, einzelne Kacheln können abweichen: | 14 Documents | owasp-top10-expert (Upload-Sicherheit/MIME-Whitelist, bereits Thema bei DOC-001), fastapi-expert | | 15 Mobile | kein Backend-Subagent zentral (Frontend/PWA-lastig) | | 16 Operations | noch offen, erst bei Angehen des Epics zuordnen | +| 17 Zuständigkeit | postgres-expert (n:m-Vererbungslogik) | +| 18 Notifications | fastapi-expert, owasp-top10-expert (E-Mail-Injection bei Trigger-Inhalten) | +| 19 Satelliten-Server | postgres-expert, sql-expert (Sync Insert/Upsert), docker-expert | **Wie einbeziehen:** vor Implementierungsbeginn einer Kachel kurz prüfen, ob einer der zugeordneten Subagenten als Review-Instanz (nach Fertigstellung) oder als Umsetzungs- @@ -76,6 +79,9 @@ für sicherheitskritische (owasp/jwt/oauth) und datenbanknahe (postgres/sql) The | 14 Documents | Dokumentenverwaltung | P2 | | 15 Mobile | QR-Scan-Workflow, PWA | P1 | | 16 Operations | Einsatzverwaltung (Ausblick) | P3 | +| 17 Zuständigkeit | Verantwortliche flexibel Standorten/Objekten zuordnen | P0 | +| 18 Notifications | Benachrichtigung + Eskalation bei Fehlbestand | P1 | +| 19 Satelliten-Server | Autarker Betrieb bei Verbindungsverlust (zurückgestellt) | P3 | ## Vollständige Kachel-Liste @@ -187,6 +193,11 @@ für sicherheitskritische (owasp/jwt/oauth) und datenbanknahe (postgres/sql) The | OPS-001 | Operations | Einsatzverwaltung (Platzhalter) | P3 | L | HIGH | FILE-001 | | OPS-002 | Operations | Einsatzmittel-Verknüpfung | P3 | M | MEDIUM | OPS-001, ASSET-003 | | OPS-003 | Operations | Einsatznachbereitung (Platzhalter) | P3 | L | HIGH | OPS-001 | +| ZUST-001 | Zuständigkeit | Objekt/Standort ↔ Verantwortlicher | P0 | S | LOW | FOUND-002, ASSET-003 | +| ZUST-002 | Zuständigkeit | Objekt ↔ Benutzer/Gruppe (Kontrollzuweisung) | P1 | S | LOW | ZUST-001, PERS-003 | +| NOTIF-001 | Notifications | Benachrichtigung bei neuem Fehlbestand | P1 | S | LOW | INV-006 | +| NOTIF-002 | Notifications | Eskalation lange offener Fehlbestände | P1 | M | MEDIUM | INV-006, NOTIF-001 | +| SAT-001 | Satelliten-Server | Hauptserver mit Satelliten-Servern | P3 | L | HIGH | FOUND-002, ASSET-003, MOBILE-003 | ## Abhängigkeitsgraph (Epic-Ebene) @@ -221,15 +232,16 @@ MAINTENANCE │ ## MVP-Abgrenzung (P0 + P1) **P0 (zwingend, Foundation):** FOUND-001…011, IDENT-001/002/004/006/007/008, -FILE-001/002/003/005/006, ASSET-001…004, PERS-002. +FILE-001/002/003/005/006, ASSET-001…004, PERS-002, ZUST-001. **P1 (MVP-Funktionsumfang):** Fleet (komplett), Inventory (komplett), Warehouse (komplett), Loadout (komplett), Inspections (komplett), Defects (komplett), Personnel (bis auf PERS-004), Readiness (bis auf READY-005), Mobile (bis auf MOBILE-003), DOC-001 (nur Grundgerüst, -Rest P2). +Rest P2), ZUST-002, Notifications (komplett). **Bewusst außerhalb MVP:** Maintenance (P2, außer Kern optional), Documents-Feinschliff -(Versionierung/Zugriffsrechte, P2), Operations komplett (P3). +(Versionierung/Zugriffsrechte, P2), Operations komplett (P3), Satelliten-Server komplett +(P3, bewusst zurückgestellt). Deckt sich das MVP praktisch mit dem, was in MABEA schon existiert — Lücken laut diesem Backlog gegenüber MABEA-Ist-Stand: **PERS-001 (Person getrennt von Benutzer)**, @@ -257,5 +269,20 @@ eigenes Modul (MAINT-\*, MABEA hat nur Prüfung, keine Wartung)**. | `14_documents.md` | DOC-001 … DOC-005 (vollständig) | | `15_mobile.md` | MOBILE-001 … MOBILE-005 (vollständig) | | `16_operations.md` | OPS-001 … OPS-003 (bewusst nur Platzhalter, siehe Datei) | +| `17_zustaendigkeit.md` | ZUST-001 … ZUST-002 (vollständig, nachträglich ergänzt) | +| `18_notifications.md` | NOTIF-001 … NOTIF-002 (vollständig, nachträglich ergänzt) | +| `19_satelliten_server.md` | SAT-001 (Platzhalter, nachträglich ergänzt, bewusst zurückgestellt) | **Alle 16 Epics durchgegangen.** Detaillierungsphase abgeschlossen (2026-09-05). + +## Nachtrag: Abgleich mit alten Arbeitskarten (2026-09-05) + +Alle 14 `arbeitskarten/*.md` (Karte 01–14, Vorgänger-Planungsstand) gegen dieses Backlog +geprüft und danach gelöscht — der komplette Ordner ist damit aufgelöst, `arbeitskarten/` +enthält nur noch den auf "aufgelöst" aktualisierten Index. Sieben Karten waren inhaltlich +vollständig abgedeckt (Karte 02, 03, 06, 09, 10, 11, 14 — jeweils in FOUND-003/004, +LOAD-001/002, MOBILE-001, IDENT-\*, ASSET-Grundprämisse bzw. INSP-Epic aufgegangen). Sechs +Karten enthielten Inhalte, die in keinem der 16 Epics vorkamen — daraus wurden drei neue +Epics (17 Zuständigkeit, 18 Notifications, 19 Satelliten-Server) sowie zwei Ergänzungen an +INV-006 (Sofort-Nachfüllung, Mindermengen-Gültigkeit). Quell-Karten: 01, 04, 05, 07, 08, +12, 13 — ihr Inhalt lebt jetzt in den genannten Epic-Dateien weiter. diff --git a/arbeitskacheln/06_inventory.md b/arbeitskacheln/06_inventory.md index 03d9cda..21da6ec 100644 --- a/arbeitskacheln/06_inventory.md +++ b/arbeitskacheln/06_inventory.md @@ -120,7 +120,12 @@ Details zu INV-001 … INV-007 (vollständig). - **Ziel:** Automatische Erkennung, wenn Ist < Soll. - **Beschreibung:** Sollmenge je Material/Ort, Vergleich mit Istmenge, automatischer - Fehlbestand-Vorgang bei Abweichung. + Fehlbestand-Vorgang bei Abweichung. Sonderfall Sofort-Nachfüllung (übernommen aus + `arbeitskarten/07_sofort_nachfuellung.md`, Karte 07): füllt die Besatzung eine + Fehlmenge noch während der laufenden Kontrolle direkt aus dem Lager nach, entsteht der + Fehlbestand-Vorgang trotzdem und wird im selben Moment als erledigt markiert — kein + "verschwindet spurlos", Statuswechsel offen→erledigt muss auch innerhalb derselben + Kontrollsitzung möglich sein, mit vollständiger Zeitstempel-Historie. - **Benutzerwert:** Kern der ganzen Bestandskontrolle — keine manuelle Dauerüberwachung nötig. - **Abhängigkeiten:** INV-003, LOAD-001 (Soll kommt oft aus dem Beladungsplan) @@ -131,14 +136,21 @@ Details zu INV-001 … INV-007 (vollständig). - **Mobile:** Nachfüllen im Feld - **QR-Code/Seriennummer/Inventarnummer:** nein - **Akte:** eigener Bereich bzw. Teil des Bestandsverlaufs -- **Rechte:** Melden/Nachfüllen: Mitarbeiter+; Mindermenge genehmigen: Verantwortliche +- **Rechte:** Melden/Nachfüllen: Mitarbeiter+; Mindermenge genehmigen: Verantwortliche. + Genehmigte Mindermenge (übernommen aus `arbeitskarten/08_mindermenge_gueltigkeit.md`, + Karte 08) gilt automatisch nur bis zur nächsten Kontrolle des betroffenen Objekts — kein + festes Ablaufdatum, kein unbefristetes Gelten. Bei nächster Kontrolle wird die Ist-Menge + neu erfasst; besteht die Abweichung weiterhin, muss neu entschieden werden (neue + Genehmigung oder Fehlbestand wieder aktiv). - **Audit:** Entstehung/Erledigung geloggt - **Akzeptanzkriterien:** Abweichung erzeugt Fehlbestand automatisch, Nachfüllung - reduziert Fehlmenge korrekt, bei 0 automatisch erledigt. -- **Tests:** Erkennungstest, Nachfüll-Test, Mindermenge-Sonderfall. -- **DoD:** deckt sich 1:1 mit MABEA (Fehlbestand-Kernmodul inkl. Mindermenge-Genehmigung) - — eines der am weitesten ausgereiften Module im gesamten Projekt, bereits vollständig - umgesetzt. + reduziert Fehlmenge korrekt, bei 0 automatisch erledigt — auch wenn Entstehung und + Erledigung in derselben Kontrollsitzung liegen. +- **Tests:** Erkennungstest, Nachfüll-Test, Mindermenge-Sonderfall, Sofort-Nachfüllung + innerhalb derselben Kontrollsitzung. +- **DoD:** deckt sich 1:1 mit MABEA (Fehlbestand-Kernmodul inkl. Mindermenge-Genehmigung + und Sofort-Nachfüllung-Sonderfall) — eines der am weitesten ausgereiften Module im + gesamten Projekt, bereits vollständig umgesetzt. ## INV-007 — Ausgabe/Rückgabe diff --git a/arbeitskacheln/17_zustaendigkeit.md b/arbeitskacheln/17_zustaendigkeit.md new file mode 100644 index 0000000..e12c7c1 --- /dev/null +++ b/arbeitskacheln/17_zustaendigkeit.md @@ -0,0 +1,74 @@ +# Epic 17 — Zuständigkeit + +Details zu ZUST-001 … ZUST-002 (vollständig). Übernommen aus `arbeitskarten/01_rollen_zuordnung.md` +und `arbeitskarten/04_organisationsstruktur.md` (Karte 01+04) — beide Karten hatten kein +Gegenstück im ursprünglichen 16-Epic-Backlog (siehe `00_index.md`, DECISION REQUIRED Punkt 5 +war die Vorgängerlücke, diese hier ist die zweite gefundene Lücke). + +--- + +## ZUST-001 — Objekt/Standort ↔ Verantwortlicher (Zuständigkeit) + +- **Ziel:** Administrator kann Verantwortliche flexibel Standorten und/oder Objekten + zuordnen, ohne starre zentrale/dezentrale Struktur vorzugeben. +- **Beschreibung:** Zuständigkeit ist n:m (Verantwortlicher(e) ↔ Standort und/oder Objekt), + kein Hardcoding "eine Wache = ein Verantwortlicher". Ein Objekt kann mehrere + Verantwortliche gleichzeitig haben. Zuständigkeit vererbt sich vom Standort automatisch + auf alle Objekte an diesem Standort; eine zusätzliche objektspezifische Zuordnung ist + eine feinere Ergänzung obendrauf, kein Ersatz — Auswertelogik: ein Benutzer ist für ein + Objekt zuständig, wenn ENTWEDER eine Standort-Zeile für dessen Standort ODER eine + Objekt-Zeile für das Objekt selbst existiert (Vereinigung, keine Überschreibung). +- **Benutzerwert:** Verantwortlichkeiten lassen sich so einteilen, wie die Organisation + tatsächlich arbeitet, nicht wie ein starres Schema es vorgibt. +- **Abhängigkeiten:** FOUND-002, ASSET-003 +- **Datenmodell:** `zustaendigkeit` (benutzer_id, standort_id NULLABLE, objekt_id NULLABLE) +- **Backend:** CRUD, Auswertelogik (Vereinigung Standort-/Objekt-Zuordnung) +- **Frontend:** Verwaltungs-UI (Liste + Suche) +- **Mobile:** keine eigene UI, wirkt sich auf Sichtbarkeit/Priorisierung aus +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** Verantwortlichkeitsbereich (FILE-004) +- **Rechte:** Administrator verwaltet +- **Audit:** Änderung geloggt +- **Akzeptanzkriterien:** Zuordnung auf Standort-Ebene wirkt auf alle zugehörigen Objekte, + zusätzliche Objekt-Zuordnung erweitert statt überschreibt. +- **Tests:** Vererbungslogik-Test (Standort-Zuordnung + separate Objekt-Zuordnung + gleichzeitig). +- **DoD:** deckt sich 1:1 mit MABEA (`Zustaendigkeit`-Tabelle, admin-UI mit Suche bereits + produktiv). + +## ZUST-002 — Objekt ↔ Benutzer/Gruppe (Kontrollzuweisung, freiwillig) + +- **Ziel:** Verantwortliche können Objekte gezielt einer Einzelperson oder Gruppe + zuweisen, ohne dass dies eine Pflichtkontrolle erzwingt. +- **Beschreibung:** Grundsätzlich darf jeder Mitarbeiter jedes Objekt kontrollieren (keine + feste Pflichtzuordnung). Zuweisung ist reine Empfehlung/Sichtbarkeit/Priorisierung, kein + Zugriffsschutz — Schutz vor Doppelarbeit übernimmt die Objekt-Sperre nach Scan/ + Kontrollstart, nicht die Zuweisung. +- **Benutzerwert:** Klare Orientierung, wer für was zuständig ist, ohne andere + auszuschließen (wichtig bei Vertretung/Ausfall). +- **Abhängigkeiten:** ZUST-001, PERS-003 (Gruppe) +- **Datenmodell:** `kontrollverantwortung` (objekt_id, benutzer_id NULLABLE, gruppe + NULLABLE) +- **Backend:** CRUD +- **Frontend:** Verwaltungs-UI +- **Mobile:** zugewiesene Objekte ggf. hervorgehoben/priorisiert in der Liste +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** Verantwortlichkeitsbereich +- **Rechte:** Administrator/Verantwortliche verwalten, Mitarbeiter sieht alle Objekte +- **Audit:** Änderung geloggt +- **Akzeptanzkriterien:** Zuweisung sichtbar/priorisiert, verhindert aber nicht, dass ein + anderer Mitarbeiter das Objekt trotzdem kontrolliert. +- **Tests:** Zuweisungs-CRUD-Test. +- **DoD:** deckt sich 1:1 mit MABEA (`Kontrollverantwortung`-Tabelle, admin-UI bereits + produktiv). + +--- + +**MABEA-Ist-Stand-Abgleich:** beide Kacheln sind bereits vollständig umgesetzt und +produktiv (`Zustaendigkeit` + `Kontrollverantwortung`, jeweils mit Admin-UI). Diese Epic- +Datei existierte bislang nicht — reine Nachdokumentation von bereits gebauter Funktion, die +im ursprünglichen 16-Epic-Backlog übersehen wurde. + +## Referenzen +Alte Arbeitskarten (übernommen, Karten-Dateien gelöscht): Karte 01 Rollen&Zuordnung, +Karte 04 Organisationsstruktur/Zuständigkeit. diff --git a/arbeitskacheln/18_notifications.md b/arbeitskacheln/18_notifications.md new file mode 100644 index 0000000..bf36a83 --- /dev/null +++ b/arbeitskacheln/18_notifications.md @@ -0,0 +1,68 @@ +# Epic 18 — Notifications & Eskalation + +Details zu NOTIF-001 … NOTIF-002 (vollständig). Übernommen aus `arbeitskarten/05_benachrichtigungen.md` +und `arbeitskarten/12_eskalation.md` (Karte 05+12) — beide Karten hatten kein Gegenstück im +ursprünglichen 16-Epic-Backlog, obwohl Karte 12 bereits vollständig implementiert ist. + +--- + +## NOTIF-001 — Benachrichtigung bei neuem Fehlbestand + +- **Ziel:** Verantwortlicher erfährt zeitnah von neuem Fehlbestand, ohne aktiv nachschauen + zu müssen. +- **Beschreibung:** Zwei Kanäle: Dashboard-Anzeige (Portal) und E-Mail. Kein Push/App in V1. +- **Benutzerwert:** Kein Fehlbestand geht unbemerkt unter. +- **Abhängigkeiten:** INV-006, FOUND-002 +- **Datenmodell:** keins zusätzlich (E-Mail-Versand ist zustandslos, triggert bei + Statuswechsel "offen") +- **Backend:** E-Mail-Versand-Komponente, Trigger bei Fehlbestand-Entstehung +- **Frontend:** Dashboard-Kachel (Pflichtbestandteil) +- **Mobile:** Dashboard-Ansicht +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** nein direkt +- **Rechte:** Verantwortliche erhalten Benachrichtigung für ihre Zuständigkeit +- **Audit:** Versand nicht zwingend geloggt (kein fachlicher Vorgang, nur Benachrichtigung) +- **Akzeptanzkriterien:** neuer Fehlbestand löst E-Mail an zuständigen Verantwortlichen aus + und erscheint im Dashboard. +- **Tests:** Trigger-Test (Fehlbestand-Entstehung → E-Mail-Mock aufgerufen). +- **DoD:** **Lücke in MABEA** — Dashboard-Anzeige existiert, aber kein E-Mail-Versand bei + Fehlbestand-Entstehung. Nur die Eskalationsstufen (NOTIF-002) versenden aktuell E-Mails. + +## NOTIF-002 — Eskalation lange offener Fehlbestände + +- **Ziel:** Automatische Eskalation, wenn ein Fehlbestand zu lange offen bleibt. +- **Beschreibung:** Zwei Stufen — Erinnerung an Materialverantwortliche nach X Tagen, + Eskalation an Leitungsverantwortliche/Administration nach Y Tagen. Zeitschwellen + konfigurierbar, nicht fix im Code. +- **Benutzerwert:** Verschleppte Fehlbestände werden nicht endlos ignoriert. +- **Abhängigkeiten:** INV-006, NOTIF-001 +- **Datenmodell:** `eskalation_konfiguration` (Singleton-Zeile, Zeitschwellen je Stufe), + Tracking-Zeitstempel je Stufe an `fehlbestand` (verhindert Mehrfachversand) +- **Backend:** `app/services/eskalation.py` (zweistufige Logik), `GET/PUT + /api/v1/eskalation/konfiguration` (admin-editierbar), `POST /api/v1/eskalation/pruefen` + (admin-only, Prüflauf anstoßen) +- **Frontend:** Admin-UI zur Konfiguration + manueller "Jetzt prüfen"-Trigger +- **Mobile:** nein +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** nein direkt +- **Rechte:** Konfiguration/manueller Prüflauf: Administrator +- **Audit:** Eskalationsversand nachvollziehbar über Tracking-Zeitstempel +- **Akzeptanzkriterien:** Fehlbestand über Schwelle X löst Erinnerung aus, über Schwelle Y + Eskalation, kein Mehrfachversand derselben Stufe. +- **Tests:** Schwellenwert-Tests (genau an der Grenze), Mehrfachversand-Schutz-Test. +- **DoD:** deckt sich 1:1 mit MABEA — bereits vollständig umgesetzt und produktiv. + **Scheduling (Cron) ist Betriebsaufgabe**, kein eigener Scheduler-Prozess im Code — auf + dem Zielserver per systemd-Timer (`mabea-eskalation.timer`), der den Prüf-Endpunkt + periodisch aufruft. + +--- + +**MABEA-Ist-Stand-Abgleich:** NOTIF-002 (Eskalation) ist vollständig umgesetzt und +produktiv. **NOTIF-001 hat eine echte Lücke:** E-Mail bei Erst-Entstehung eines +Fehlbestands fehlt — aktuell wird nur bei Eskalationsstufen gemailt, nicht sofort beim +ersten Auftreten. Diese Epic-Datei existierte bislang nicht — reine Nachdokumentation +plus eine offene Lücke, die im ursprünglichen 16-Epic-Backlog übersehen wurde. + +## Referenzen +Alte Arbeitskarten (übernommen, Karten-Dateien gelöscht): Karte 05 Benachrichtigungen, +Karte 12 Eskalation offener Fehlbestände. diff --git a/arbeitskacheln/19_satelliten_server.md b/arbeitskacheln/19_satelliten_server.md new file mode 100644 index 0000000..d300b0c --- /dev/null +++ b/arbeitskacheln/19_satelliten_server.md @@ -0,0 +1,63 @@ +# Epic 19 — Satelliten-Server + +Details zu SAT-001 (Platzhalter/Architektur-Vorbereitung). Übernommen aus +`arbeitskarten/13_satelliten_server.md` (Karte 13) — die größte gefundene Lücke im +16-Epic-Backlog: eine bereits "entschieden" gewertete Architektur-Erweiterung mit +konkreten Datenmodell-Konsequenzen, die in keinem der 16 ursprünglichen Epics erwähnt war. + +--- + +## SAT-001 — Hauptserver mit Satelliten-Servern + +- **Ziel:** Zusätzlich zum Hauptserver können Satelliten-Server existieren, die lokal + (Einsatzort/Wache) laufen und temporär vom Hauptserver getrennt sind — für KatS- + Einsatzlagen ohne Internet, Wachen mit dauerhaft schlechter Anbindung, oder reinen + Ausfallschutz. +- **Beschreibung:** Satellit ist funktional ein vollwertiger, kleiner Hauptserver-Klon + (gleiche Software/API/DB), kein reiner Cache — mehrere Mitarbeiter können gleichzeitig + am Satelliten arbeiten. Autark-Dauer bewusst nicht zeitlich begrenzt (Stunden bis Tage). + Konfliktvermeidung statt Konfliktlösung: jedes Objekt ist während einer Trennung fest + genau einem Server zugeordnet (Haupt- oder ein bestimmter Satellit), am jeweils anderen + für Schreibzugriffe gesperrt — dadurch strukturell kein "wer gewinnt"-Problem. +- **Benutzerwert:** Betrieb bleibt auch bei längerem/vollständigem Verbindungsverlust + einsatzfähig, ohne Datenkonflikte beim späteren Zusammenführen. +- **Abhängigkeiten:** FOUND-002, ASSET-003, MOBILE-003 (Abgrenzung: Satellit ist die + Lösung für ganze Standorte über längere Zeit, MOBILE-003 für Kurzzeit-Netzlücken + innerhalb einer einzelnen Kontrolle) +- **Datenmodell:** Objekt braucht Feld "aktuell zugeordneter Server" (Hauptserver-ID oder + Satelliten-ID), änderbar nur durch bewussten Auslagerungs-/Rückhol-Vorgang. IDs + systemweit eindeutig von Anfang an (kein lokal generierter, kollisionsanfälliger Schlüssel) + — Voraussetzung für widerspruchsfreies Zusammenführen. Sync überträgt neu entstandene + Datensätze per Insert und geänderte bestehende Zeilen (offene Fehlbestände, aktive + Mindermengen-Genehmigungen, Objektpositionen) per Upsert. +- **Backend:** Auslagerungs-/Rückhol-Endpunkte, Sync-Logik (Insert+Upsert), Schreibsperre + für ausgelagerte Objekte am Hauptserver +- **Frontend:** Admin-UI zum Auslagern/Zurückholen +- **Mobile:** kein Unterschied — Satellit spricht dieselbe API +- **QR-Code/Seriennummer/Inventarnummer:** nein +- **Akte:** zeigt ggf. aktuellen Server-Zuordnungsstatus +- **Rechte:** Auslagerung/Rückholung: Administrator +- **Audit:** Auslagerung/Rückholung geloggt, Sync-Vorgänge nachvollziehbar +- **Akzeptanzkriterien:** Objekt an Satellit auslagern → am Hauptserver für Schreiben + gesperrt; nach Rückholung sind alle am Satelliten entstandenen/geänderten Daten korrekt + im Hauptserver. +- **Tests:** Sync-Test (Insert neuer Datensätze + Upsert geänderter bestehender Zeilen), + Schreibsperre-Test während Auslagerung. +- **DoD:** **DECISION REQUIRED zum Umsetzungszeitpunkt** — Nutzer-Entscheidung aus + früherer Session: "erstmal nur mit Hauptserver", also bewusst zurückgestellt. Offene + Punkte vor Umsetzung: technischer Auslöser der Auslagerung (manuell vs. automatisch bei + Verbindungsverlust), Vorab-Bestückung des Satelliten mit Stammdaten, Verhalten bei + laufender Kontrolle während Auslagerung/Rückholung, Hardware-Anforderung. + +--- + +**MABEA-Ist-Stand-Abgleich:** nicht umgesetzt, bewusst zurückgestellt (Nutzer-Entscheidung +"erstmal nur mit main server gemacht"). Diese Epic-Datei existierte bislang nicht — reine +Nachdokumentation der bereits getroffenen Architektur-Entscheidung, damit sie im Backlog +nicht verloren geht, bis ein konkreter Bedarf zur Umsetzung führt. + +## Referenzen +Alte Arbeitskarte (übernommen, Karten-Datei gelöscht): Karte 13 Hauptserver mit +Satelliten-Servern. +Weiterhin gültige Detail-Referenz (nicht gelöscht, eigenständiges Prompt-Ergebnisdokument): +`ergebnisse/17_mobile_offline.md` Abschnitt 7, `ergebnisse/20_datenbank_schema.md` Punkt 10. diff --git a/arbeitskacheln/DEVLOG.md b/arbeitskacheln/DEVLOG.md new file mode 100644 index 0000000..92c50be --- /dev/null +++ b/arbeitskacheln/DEVLOG.md @@ -0,0 +1,14 @@ +# arbeitskacheln – Dev Log + +## 2026-09-05 17:00 – 17:02 (1m) +**Beschreibung:** Claude Code Session +**Projekt:** asb-material + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +- arbeitskacheln/00_index.md | 3 ++- +- arbeitskacheln/16_operations.md | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +--- diff --git a/arbeitskarten/00_index.md b/arbeitskarten/00_index.md index 122d637..965fd33 100644 --- a/arbeitskarten/00_index.md +++ b/arbeitskarten/00_index.md @@ -1,24 +1,16 @@ -# Arbeitskarten – Index +# Arbeitskarten – Index (aufgelöst, 2026-09-05) -Status: entstanden aus Klärungsrunde vor Prompt 01. Jede Karte = ein entschiedener oder offener Punkt, mit Bezug zu `prompts.md`. +**Dieser Ordner ist aufgelöst.** Alle 14 Karten (01–14) wurden gegen das neue +Epic-/Kachel-Backlog in `arbeitskacheln/` geprüft und übernommen: -| 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 | -| 14 | [Prüf- und wartungspflichtige Geräte](14_pruef_wartungspflicht.md) | Datenmodell entschieden, Umsetzung offen (geraet_instanz-Tabelle nötig) | Prompt 06, 10, 24 | +- Karte 02, 03, 06, 09, 10, 11, 14 — inhaltlich bereits vollständig in bestehenden Epics + abgedeckt (FOUND-003/004, LOAD-001/002, MOBILE-001, IDENT-\*, ASSET-Grundprämisse, + INSP-Epic), Karten-Dateien gelöscht. +- Karte 01, 04, 05, 07, 08, 12, 13 — enthielten Inhalte ohne Gegenstück im Backlog, daraus + entstanden `arbeitskacheln/17_zustaendigkeit.md`, `18_notifications.md`, + `19_satelliten_server.md` sowie zwei Ergänzungen in `06_inventory.md` (INV-006). + Karten-Dateien gelöscht. -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. +Siehe `arbeitskacheln/00_index.md`, Abschnitt "Nachtrag: Abgleich mit alten +Arbeitskarten" für Details. Alle fachlichen Entscheidungen leben jetzt ausschließlich in +`arbeitskacheln/` weiter — dieser Ordner wird nicht mehr gepflegt. diff --git a/arbeitskarten/01_rollen_zuordnung.md b/arbeitskarten/01_rollen_zuordnung.md deleted file mode 100644 index 1fc597e..0000000 --- a/arbeitskarten/01_rollen_zuordnung.md +++ /dev/null @@ -1,14 +0,0 @@ -# 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. - -## Geklärt (vormals offen) -- Zuweisung erzwingt KEINE Pflichtkontrolle – reine Empfehlung/Sichtbarkeit/Priorisierung. Schutz vor Doppelarbeit übernimmt die Objekt-Sperre nach Scan/Kontrollstart (Prompt 02.8), nicht die Zuweisung. diff --git a/arbeitskarten/02_rechte_stammdaten.md b/arbeitskarten/02_rechte_stammdaten.md deleted file mode 100644 index 4b5d717..0000000 --- a/arbeitskarten/02_rechte_stammdaten.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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). diff --git a/arbeitskarten/03_sollmengen_recht.md b/arbeitskarten/03_sollmengen_recht.md deleted file mode 100644 index 94b07e5..0000000 --- a/arbeitskarten/03_sollmengen_recht.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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). diff --git a/arbeitskarten/04_organisationsstruktur.md b/arbeitskarten/04_organisationsstruktur.md deleted file mode 100644 index 2ee4fc0..0000000 --- a/arbeitskarten/04_organisationsstruktur.md +++ /dev/null @@ -1,15 +0,0 @@ -# Karte 04 – Organisationsstruktur / Zuständigkeiten - -**Status:** entschieden - -## 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). - -## Geklärt (vormals offen) -- Ein Objekt kann mehrere Verantwortliche gleichzeitig haben (n:m, kein Limit). -- Zuständigkeit vererbt sich vom Standort automatisch auf alle Objekte an diesem Standort. Zusätzliche objektspezifische Zuordnung (`zustaendigkeit.objekt_id` gesetzt) ist eine feinere Ergänzung obendrauf, kein Ersatz – Auswertelogik: ein Benutzer ist für ein Objekt zuständig, wenn ENTWEDER eine Standort-Zeile für dessen Standort ODER eine Objekt-Zeile für das Objekt selbst existiert (Vereinigung, keine Überschreibung). diff --git a/arbeitskarten/05_benachrichtigungen.md b/arbeitskarten/05_benachrichtigungen.md deleted file mode 100644 index e4f2e08..0000000 --- a/arbeitskarten/05_benachrichtigungen.md +++ /dev/null @@ -1,15 +0,0 @@ -# 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). diff --git a/arbeitskarten/06_geraet_pc_mobil.md b/arbeitskarten/06_geraet_pc_mobil.md deleted file mode 100644 index a998e9c..0000000 --- a/arbeitskarten/06_geraet_pc_mobil.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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. diff --git a/arbeitskarten/07_sofort_nachfuellung.md b/arbeitskarten/07_sofort_nachfuellung.md deleted file mode 100644 index 611c642..0000000 --- a/arbeitskarten/07_sofort_nachfuellung.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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. diff --git a/arbeitskarten/08_mindermenge_gueltigkeit.md b/arbeitskarten/08_mindermenge_gueltigkeit.md deleted file mode 100644 index 3d9f6ae..0000000 --- a/arbeitskarten/08_mindermenge_gueltigkeit.md +++ /dev/null @@ -1,11 +0,0 @@ -# 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). diff --git a/arbeitskarten/09_authentifizierung.md b/arbeitskarten/09_authentifizierung.md deleted file mode 100644 index f89bb85..0000000 --- a/arbeitskarten/09_authentifizierung.md +++ /dev/null @@ -1,10 +0,0 @@ -# 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/arbeitskarten/10_qr_barcode.md b/arbeitskarten/10_qr_barcode.md deleted file mode 100644 index 1da8c8e..0000000 --- a/arbeitskarten/10_qr_barcode.md +++ /dev/null @@ -1,42 +0,0 @@ -# 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. - -## Umsetzungsstand (2026-09-04) -- Backend: `objektposition.code`-Feld, Lookup-/Vorschlag-Endpunkte, PDF-Label-Erzeugung (`app/services/label.py`) fertig. -- Frontend/Flutter: Kamera-Scan (Objekt-Code, Scan-First) fertig. -- **Offen: Label-Druck-Test mit echten Geräten** (physischer Schritt, nicht per Code erledigbar). Test-PDF erzeugen: `python -m scripts.test_label_erzeugen` im Backend-venv. - -### Test-Checkliste (pro Labelgröße/-material einmal durchgehen) -1. Test-Label drucken (`test_label_erzeugen.py`, mind. eine Größe pro geplantes Labelformat). -2. Auf Ziel-Untergrund kleben/befestigen (Rucksack-Stoff, Fahrzeuglack o. Ä. – reale Anbringung testen, nicht nur Tisch/Papier). -3. Mit jedem vorgesehenen Scan-Gerät testen (PWA im Handy-/Tablet-Browser, Flutter-App auf Android): - - Normalabstand (~15–20 cm) und Winkel 0° - - Schräger Winkel (~30°) - - Schwaches Licht / Gegenlicht -4. Bei Fehlschlag: Modulbreite/Ruhezone in `_BARCODE_OPTIONEN` (`app/services/label.py`) erhöhen, neues Test-Label drucken, erneut testen. -5. Ergebnis (Gerät, Abstand/Winkel, Erfolg/Fehlschlag) hier oder in einer neuen Notiz festhalten, bevor Seriendruck freigegeben wird. diff --git a/arbeitskarten/11_systemumfang_ressourcenmanagement.md b/arbeitskarten/11_systemumfang_ressourcenmanagement.md deleted file mode 100644 index 0327610..0000000 --- a/arbeitskarten/11_systemumfang_ressourcenmanagement.md +++ /dev/null @@ -1,18 +0,0 @@ -# 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/arbeitskarten/12_eskalation.md b/arbeitskarten/12_eskalation.md deleted file mode 100644 index 365ce9e..0000000 --- a/arbeitskarten/12_eskalation.md +++ /dev/null @@ -1,22 +0,0 @@ -# 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). - -## Umsetzungsstand (2026-09-04) -- `app/services/eskalation.py`: zwei Stufen (Erinnerung an Materialverantwortliche, Eskalation an Leitungsverantwortliche/Administration), Tracking-Zeitstempel je Stufe verhindert Mehrfachversand. -- Zeitschwellen in `eskalation_konfiguration` (DB, Singleton-Zeile) statt fix im Code - admin-editierbar über `GET/PUT /api/v1/eskalation/konfiguration`. -- Prüflauf selbst per `POST /api/v1/eskalation/pruefen` (admin-only) angestoßen - **Scheduling (Cron) ist weiterhin Betriebsaufgabe**, kein eigener Scheduler-Prozess im Code (Prompt 19 Deployment-Regel). Auf dem Zielserver z. B. per systemd-Timer/Cron, der diesen Endpunkt periodisch mit Admin-Token aufruft. diff --git a/arbeitskarten/13_satelliten_server.md b/arbeitskarten/13_satelliten_server.md deleted file mode 100644 index 5657c58..0000000 --- a/arbeitskarten/13_satelliten_server.md +++ /dev/null @@ -1,39 +0,0 @@ -# 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]] diff --git a/arbeitskarten/14_pruef_wartungspflicht.md b/arbeitskarten/14_pruef_wartungspflicht.md deleted file mode 100644 index c0b56a8..0000000 --- a/arbeitskarten/14_pruef_wartungspflicht.md +++ /dev/null @@ -1,98 +0,0 @@ -# Karte 14 – Prüf- und wartungspflichtige Geräte - -**Status:** Konzeptphase, Datenmodell entschieden (2026-09-04), Umsetzung offen - -## Entscheidung -Das Portal deckt nicht nur Bestandskontrolle (Soll/Ist-Mengen, Verbrauchsmaterial- -Nachschub) ab, sondern auch gesetzlich/betrieblich prüf- und wartungspflichtige -Geräte (z. B. Feuerlöscher, Defibrillatoren, Leitern, Atemschutzgeräte, Pulsoxymeter) -mit wiederkehrenden Prüfintervallen und Fristen. Das ist fachlich etwas anderes als -Ablaufdatum (einmaliges festes Datum) oder Charge (Identifikation) – hier geht es -um einen wiederkehrenden Prüfzyklus mit Ergebnis pro Durchgang, UND um mehrere -Geräte-Exemplare desselben Materials im selben Objekt. - -## Kernproblem im aktuellen Datenmodell -`objektposition.seriennummer` ist ein Einzelfeld – kann nur EIN Gerät pro -Materialtyp pro Objekt erfassen. Bei z. B. 2 Pulsoxymetern im selben Rucksack -gibt es keine Möglichkeit, beide Seriennummern zu speichern. Das ist ein echtes -Datenmodell-Defizit, kein UI-Problem – erfordert eine neue Entität. - -## Datenmodell (entschieden) - -Neue Tabelle `geraet_instanz` ersetzt `objektposition.seriennummer` für -`materialtyp='geraet_sn'`: - -```sql -CREATE TABLE geraet_instanz ( - id UUID PRIMARY KEY DEFAULT gen_random_uuid(), - objektposition_id UUID NOT NULL REFERENCES objektposition(id), - seriennummer TEXT NOT NULL, - pruefdatum DATE, -- letzte Prüfung - naechste_pruefung DATE, -- fällige Prüfung - status TEXT NOT NULL DEFAULT 'einsatzbereit', -- einsatzbereit / defekt / in_reparatur - bemerkung TEXT, - UNIQUE (objektposition_id, seriennummer) -); -``` - -- `objektposition.seriennummer` entfällt (Migration: bestehende Werte nach - `geraet_instanz` überführen, dann Spalte droppen). -- Ist-Menge bei `geraet_sn` wird nicht mehr als Zahl geführt/eingegeben, sondern - als Anzahl der `geraet_instanz`-Zeilen mit `status='einsatzbereit'` berechnet. -- `objektposition`: neues Feld `pruefintervall_monate` (int, nullable) – - **individuell überschreibbar** je Objektposition (wie `sollmenge_override`), - Vorlage/Material kann einen Standard vorgeben, einzelne Objektposition kann - abweichen (z. B. älteres Gerät mit kürzerer Frist). -- `naechste_pruefung` je `geraet_instanz` wird nach jeder erfassten Prüfung neu - berechnet (`pruefdatum + pruefintervall_monate`). - -## "Nicht bestanden" / defekt → Fehlbestand (entschieden) -**Pro Gerät entscheidbar, nicht global fix.** Beim Setzen von -`status='defekt'` oder `status='in_reparatur'` an einer `geraet_instanz` wird -im selben Dialog gefragt/entschieden, ob daraus ein Fehlbestand entsteht (nutzt -die bestehende Fehlbestand-/Eskalations-Infrastruktur weiter, kein Parallel- -Konzept). Die ganze bestehende Fehlbestand-Logik (Kette Fehlbestand → -Nachfüllung/Mindermenge → Historie) wird dabei mitgenutzt, nicht neu gebaut – -ein "defektes Gerät" ist fachlich einfach ein Fehlbestand mit Fehlmenge=1 an -dieser Position. - -## Erfassungs-UI für `geraet_sn` (komplett neu, kein Mengenfeld mehr) - -Statt Mengenfeld + "Passt"-Button: Instanz-Liste pro Position. - -``` -┌─────────────────────────────────────────┐ -│ Pulsoxymeter Modell X (Soll: 2) │ -├─────────────────────────────────────────┤ -│ ✓ SN-001 [Prüfdatum: 2025-03-15] [OK] │ -│ ✓ SN-002 [Prüfdatum: 2025-06-22] [OK] │ -│ + Gerät hinzufügen (SN scannen/eingeben) │ -└─────────────────────────────────────────┘ -``` - -Buttons pro Instanz: -- **OK** – Gerät ist da, einsatzbereit. -- **Fehlt/Defekt** – Dialog: Grund (fehlt/defekt/in Reparatur), Bemerkung → - Instanz-Status ändern, bei "fehlt"/"defekt" optional Fehlbestand erzeugen - (siehe oben, pro Gerät entscheidbar). - -`materialtyp='ablauf_charge'` und `'standard'` bleiben unverändert (Mengenfeld -+ Passt-Button wie bisher) – nur `geraet_sn` bekommt diese neue Erfassungsart. - -## Eskalation bei überfälliger Prüfung -Bestehende Zwei-Stufen-Mechanik (`app/services/eskalation.py`) um eine zweite -Datenquelle erweitern: überfällige `geraet_instanz.naechste_pruefung` statt -`fehlbestand.entstanden_am`. Eigene Konfigurationszeile/-spalten, damit -Prüf-Fristen unabhängig von Fehlbestand-Fristen einstellbar sind (TÜV-Fristen -unterscheiden sich je nach Gerätetyp). - -## Umsetzungsschritte (grobe Reihenfolge) -1. Migration: `geraet_instanz`-Tabelle, `objektposition.pruefintervall_monate`, - Daten-Migration bestehender `seriennummer`-Werte, danach Spalte droppen. -2. Backend: `geraet_instanz`-Model + Service (CRUD, Status ändern inkl. - optionaler Fehlbestand-Erzeugung, Ist-Menge-Berechnung für `geraet_sn`). -3. Backend: Eskalation um Prüf-Fälligkeit erweitern. -4. Frontend: neue Instanz-Listen-UI für `geraet_sn` in der Kontroll-Erfassung - (`PositionCard.tsx`/`KontrollPage.tsx`), Scan-Integration (Karte 10) für - SN-Eingabe wiederverwenden. -5. Frontend: Admin-Pflege der Geräte-Instanzen (analog `ObjektPositionenPanel`).