From 91e48a3420c19f2123ea90b29dea82df8e5daec2 Mon Sep 17 00:00:00 2001 From: patrick Date: Thu, 3 Sep 2026 22:13:04 +0200 Subject: [PATCH] =?UTF-8?q?Letzte=20offene=20fachliche=20Fragen=20kl=C3=A4?= =?UTF-8?q?ren:=20keine=20Kontrollintervall-F=C3=A4lligkeit=20(nur=20Ablau?= =?UTF-8?q?fdatum),=20Zust=C3=A4ndigkeit=20vererbt=20sich=20vom=20Standort?= =?UTF-8?q?,=20Zuweisung=20ist=20reine=20Sichtbarkeit;=20Kleinigkeiten=20(?= =?UTF-8?q?=C3=9Cberbestand-Regel,=20Signatur-Vermerk,=20Server-Seed)=20do?= =?UTF-8?q?kumentiert?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01L85hmKbvX7Cqkq47KnQhFt --- DEVLOG.md | 13 +++++++++ GESAMTDOKUMENT.md | 31 ++++++++++++--------- arbeitskarten/01_rollen_zuordnung.md | 4 +-- arbeitskarten/04_organisationsstruktur.md | 8 +++--- ergebnisse/01_anforderungsanalyse.md | 8 +++--- ergebnisse/12_verantwortlichen_dashboard.md | 3 ++ ergebnisse/16_kontrollabschluss.md | 5 ++-- ergebnisse/21_api.md | 2 +- ergebnisse/testphasen.md | 1 + 9 files changed, 49 insertions(+), 26 deletions(-) diff --git a/DEVLOG.md b/DEVLOG.md index 7bc46b7..3a0b786 100644 --- a/DEVLOG.md +++ b/DEVLOG.md @@ -784,3 +784,16 @@ Keine Änderungen ermittelbar. - 23_papieraloesung.md | 35 ---------- --- +## 2026-09-03 21:55 – 21:57 (1m) +**Beschreibung:** Claude Code Session +**Projekt:** asb-material + +### Commits +- d9ef67c Testphasen-Plan ergänzen (Phase 0-5 + Phase S Satelliten-PoC, Excel-Import-Mapping) + +### Geänderte Dateien +- DEVLOG.md | 102 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +- GESAMTDOKUMENT.md | 153 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- +- ergebnisse/testphasen.md | 146 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +--- diff --git a/GESAMTDOKUMENT.md b/GESAMTDOKUMENT.md index 934b8ff..656a9a0 100644 --- a/GESAMTDOKUMENT.md +++ b/GESAMTDOKUMENT.md @@ -47,8 +47,8 @@ Grundsätzlich darf jeder Mitarbeiter jedes Rucksack/Fahrzeug kontrollieren (kei - 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. +## 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. --- @@ -81,7 +81,7 @@ Materialverantwortlicher darf Sollmengen (Beladungsvorlagen) selbst ändern – # Karte 04 – Organisationsstruktur / Zuständigkeiten -**Status:** entschieden, Detail noch offen +**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. @@ -91,9 +91,9 @@ Keine starre zentrale ODER dezentrale Struktur vorgeben. Administrator muss Zust - 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? +## 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). --- @@ -352,10 +352,10 @@ Heute: Papierlisten pro Rucksack/Fahrzeug (Beispiele: Handball Rucksack, Rettung - Kein Push in V1 (Karte 05) kann bei zeitkritischen Fehlbeständen zu Verzögerung führen, falls Verantwortlicher E-Mail/Dashboard nicht zeitnah prüft — als bekanntes Risiko für Roadmap (Eskalation, Karte 12) vermerkt. ## 6. Offene Fragen (vor Prompt 02–05 weiter zu klären) -- Muss zugewiesene Kontrollverantwortung (Karte 01) eine Pflichtkontrolle erzwingen, oder bleibt sie reine Sichtbarkeits-/Priorisierungshilfe? -- Kann ein Objekt mehrere gleichzeitig zuständige Verantwortliche haben, und vererbt sich Zuständigkeit vom Standort automatisch auf alle dortigen Objekte (Karte 04)? -- Wie granular soll der Objekttyp/Kategorie-Baum sein (Karte 11) — flache Liste (Rettungsdienst, Betreuung, Technik, ...) oder hierarchisch mit Unterkategorien? -- Welche Kontrollintervalle/Fristen sind organisatorisch vorgesehen (täglich, wöchentlich, nach Einsatz)? — relevant für Prompt 02 und spätere Eskalation. +- ~~Muss zugewiesene Kontrollverantwortung (Karte 01) eine Pflichtkontrolle erzwingen, oder bleibt sie reine Sichtbarkeits-/Priorisierungshilfe?~~ **Geklärt:** reine Sichtbarkeits-/Priorisierungshilfe, kein Zwang. Schutzmechanismus gegen Doppelarbeit ist die Objekt-Sperre (Prompt 02.8), nicht die Zuweisung. +- ~~Kann ein Objekt mehrere gleichzeitig zuständige Verantwortliche haben, und vererbt sich Zuständigkeit vom Standort automatisch auf alle dortigen Objekte (Karte 04)?~~ **Geklärt:** ja, mehrere Verantwortliche gleichzeitig möglich (n:m). Standort-Zuordnung vererbt sich automatisch auf alle Objekte an diesem Standort; zusätzliche objektspezifische Zuordnung ist eine feinere Ergänzung, kein Widerspruch. +- Wie granular soll der Objekttyp/Kategorie-Baum sein (Karte 11) — flache Liste (Rettungsdienst, Betreuung, Technik, ...) oder hierarchisch mit Unterkategorien? *(weiterhin offen, unkritisch für Schema — Kategorie hat bereits optionale Selbstreferenz für Hierarchie, Prompt 20)* +- ~~Welche Kontrollintervalle/Fristen sind organisatorisch vorgesehen (täglich, wöchentlich, nach Einsatz)?~~ **Geklärt:** V1 hat KEINE eigene Kontrollintervall-/Fälligkeitslogik. Einzige System-getriebene Aufforderung zur Kontrolle ist der bereits bestehende Ablaufdatum-Mechanismus (Prompt 14: bald ablaufend/abgelaufen). Reguläre Kontrollintervalle bleiben rein organisatorisch (Dienstplan/Anweisung), vom System nur dokumentiert (Zeitpunkt letzte Kontrolle sichtbar), nicht berechnet oder erzwungen. ## Referenzen Arbeitskarten: [[01_rollen_zuordnung]], [[02_rechte_stammdaten]], [[03_sollmengen_recht]], [[04_organisationsstruktur]], [[05_benachrichtigungen]], [[06_geraet_pc_mobil]], [[07_sofort_nachfuellung]], [[08_mindermenge_gueltigkeit]], [[09_authentifizierung]], [[10_qr_barcode]], [[11_systemumfang_ressourcenmanagement]], [[12_eskalation]] @@ -1003,6 +1003,9 @@ Materialverantwortlicher, Leitungsverantwortlicher, Administration (Prompt 05). - Globale Suche über Objekte/Material (Name, Artikelnummer, Code/QR-ID). - Schnellzugriff auf ein bestimmtes Objekt unabhängig vom Fehlbestand-Kontext. +## 6a. Klarstellung: keine Kontrollintervall-Fälligkeit in V1 +Nutzerentscheidung (Prompt 01, offene Frage geklärt): V1 berechnet KEINE eigene Kontrollfälligkeit/„überfällige Kontrolle"-Kennzahl. Die einzige system-getriebene Aufforderung zur (Wieder-)Kontrolle ist der bestehende Ablaufdaten-Mechanismus (Punkt 2/„bevorstehende Ablaufdaten", Prompt 14). Reguläre Kontrollrhythmen bleiben rein organisatorisch, vom System nur dokumentiert (letzter Kontrollzeitpunkt je Objekt sichtbar), nicht berechnet oder als Kennzahl geführt. + ## 6. Vorbereitung Eskalation (Karte 12, Roadmap) - Alter-Spalte und -Filter bereits jetzt vorhanden (siehe oben), liefert Datenbasis. - Kein automatischer Eskalations-Trigger/Benachrichtigung an Leitung in V1 (Karte 05: kein Push, nur Dashboard+E-Mail bei Entstehung), aber visuelle Hervorhebung alter offener Fehlbestände (z. B. rote Markierung ab konfigurierbarer Schwelle) als einfache Vorstufe sinnvoll und ohne Zusatzaufwand umsetzbar. @@ -1151,7 +1154,8 @@ Eine Kontrolle gilt als abgeschlossen, wenn Mitarbeiter jede Position mindestens ## 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). +- 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. + - **V1-Vereinfachung (Vermerk):** Datenmodell hat bereits das Feld `kontrolle.signatur` (Prompt 20) – eine eigene Einstellungs-Entität „Signatur pro Standort/Organisation ein/aus" existiert in V1 NICHT. Für V1 reicht: Feld ist da und wird nur befüllt, wenn UI eine Unterschrift anbietet; echte Ein/Aus-Konfigurierbarkeit pro Standort ist Roadmap (Prompt 24). - 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. @@ -1161,7 +1165,7 @@ Eine Kontrolle gilt als abgeschlossen, wenn Mitarbeiter jede Position mindestens **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. +- Objekt bleibt im Zustand vor Kontrollbeginn (bzw. „nicht kontrolliert seit Datum X") – rein informativ, keine automatische Fälligkeits-/Überfällig-Logik in V1 (siehe Prompt 12.6a). - Grund für Abbruch optional erfassbar (Freitext, z. B. „Einsatzalarmierung"). ## Referenzen @@ -1757,7 +1761,7 @@ Fehlte bisher, obwohl in der Berechtigungsmatrix (Prompt 05) gefordert. ## 9. Validierung/Fehlerfälle (Beispiele) - Mindermenge genehmigen ohne Begründung → 422, Feld `begruendung` Pflicht (Prompt 04). - Mindermenge genehmigen durch Mitarbeiter-Rolle → 403 (Prompt 05). -- Nachfüllung mit Menge, die Ist über Soll hebt → 422 oder Warnung (fachlich zu entscheiden bei Umsetzung, aus Prompt 02 nicht explizit als Fehler definiert – konservativ: erlauben, aber als „Überbestand“-Info kennzeichnen, kein Fehlbestand). +- Nachfüllung mit Menge, die Ist über Soll hebt → **entschieden:** erlauben (kein 422), Response kennzeichnet den Fall als „Überbestand"-Info (Prompt 02.4), löst keinen Fehlbestand aus. - Kontrolle abschließen, obwohl Positionen unbearbeitet → 409, Liste fehlender Positionen im Response. - Doppeltes Duplizieren mit gleichem Code → 409 (Code muss eindeutig sein, Prompt 09). @@ -1922,6 +1926,7 @@ Grundprinzip: Tests werden **phasenweise** aufgebaut, parallel zur Implementieru - Separate **Test-Datenbank** (eigene PostgreSQL-Datenbank, Schema via Alembic-Migrationen aufgesetzt, nie gegen Dev-/Produktiv-DB) - Test-Fixtures: frische DB pro Testklasse (Transaction-Rollback oder Drop/Create), Standard-Stammdaten-Set (1 Bereich, 2 Standorte, 3 Objekttypen, ~10 Materialien aller 3 Typen, 1 Vorlage mit Positionen, 2 Objekte, 4 Benutzer = 1 je Rolle) - CI-Job (Gitea Actions): install → migrate → pytest → Coverage-Report; Blocker bei Rot +- **Seed-Datensatz `systemknoten`:** `objekt.zustaendiger_server_id`, `kontrolle.erzeugt_von_server_id`, `fehlbestand.erzeugt_von_server_id`, `historie.erzeugt_von_server_id` sind NOT NULL (Prompt 20) – V1 braucht daher zwingend einen Seed-Datensatz `systemknoten (typ='haupt')` VOR dem ersten Datensatz jeder Art, plus eine Konfigurations-Referenz im Backend (z. B. Umgebungsvariable/Settings-Wert `SYSTEMKNOTEN_ID`), die der Anwendungscode bei jedem Insert einsetzt. Ohne diesen Seed schlägt der allererste Insert fehl – gehört in die Migrations-/Setup-Reihenfolge von Phase 0, nicht erst bei Satelliten-Umsetzung (Phase S) relevant. **Abnahmekriterium:** `pytest` läuft grün (auch wenn erst 1 Smoke-Test existiert), CI schlägt bei Testfehler fehl. diff --git a/arbeitskarten/01_rollen_zuordnung.md b/arbeitskarten/01_rollen_zuordnung.md index 0b297eb..1fc597e 100644 --- a/arbeitskarten/01_rollen_zuordnung.md +++ b/arbeitskarten/01_rollen_zuordnung.md @@ -10,5 +10,5 @@ Grundsätzlich darf jeder Mitarbeiter jedes Rucksack/Fahrzeug kontrollieren (kei - 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. +## 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/04_organisationsstruktur.md b/arbeitskarten/04_organisationsstruktur.md index 35ea550..2ee4fc0 100644 --- a/arbeitskarten/04_organisationsstruktur.md +++ b/arbeitskarten/04_organisationsstruktur.md @@ -1,6 +1,6 @@ # Karte 04 – Organisationsstruktur / Zuständigkeiten -**Status:** entschieden, Detail noch offen +**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. @@ -10,6 +10,6 @@ Keine starre zentrale ODER dezentrale Struktur vorgeben. Administrator muss Zust - 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? +## 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/ergebnisse/01_anforderungsanalyse.md b/ergebnisse/01_anforderungsanalyse.md index 2b9f1e7..283aac6 100644 --- a/ergebnisse/01_anforderungsanalyse.md +++ b/ergebnisse/01_anforderungsanalyse.md @@ -63,10 +63,10 @@ Heute: Papierlisten pro Rucksack/Fahrzeug (Beispiele: Handball Rucksack, Rettung - Kein Push in V1 (Karte 05) kann bei zeitkritischen Fehlbeständen zu Verzögerung führen, falls Verantwortlicher E-Mail/Dashboard nicht zeitnah prüft — als bekanntes Risiko für Roadmap (Eskalation, Karte 12) vermerkt. ## 6. Offene Fragen (vor Prompt 02–05 weiter zu klären) -- Muss zugewiesene Kontrollverantwortung (Karte 01) eine Pflichtkontrolle erzwingen, oder bleibt sie reine Sichtbarkeits-/Priorisierungshilfe? -- Kann ein Objekt mehrere gleichzeitig zuständige Verantwortliche haben, und vererbt sich Zuständigkeit vom Standort automatisch auf alle dortigen Objekte (Karte 04)? -- Wie granular soll der Objekttyp/Kategorie-Baum sein (Karte 11) — flache Liste (Rettungsdienst, Betreuung, Technik, ...) oder hierarchisch mit Unterkategorien? -- Welche Kontrollintervalle/Fristen sind organisatorisch vorgesehen (täglich, wöchentlich, nach Einsatz)? — relevant für Prompt 02 und spätere Eskalation. +- ~~Muss zugewiesene Kontrollverantwortung (Karte 01) eine Pflichtkontrolle erzwingen, oder bleibt sie reine Sichtbarkeits-/Priorisierungshilfe?~~ **Geklärt:** reine Sichtbarkeits-/Priorisierungshilfe, kein Zwang. Schutzmechanismus gegen Doppelarbeit ist die Objekt-Sperre (Prompt 02.8), nicht die Zuweisung. +- ~~Kann ein Objekt mehrere gleichzeitig zuständige Verantwortliche haben, und vererbt sich Zuständigkeit vom Standort automatisch auf alle dortigen Objekte (Karte 04)?~~ **Geklärt:** ja, mehrere Verantwortliche gleichzeitig möglich (n:m). Standort-Zuordnung vererbt sich automatisch auf alle Objekte an diesem Standort; zusätzliche objektspezifische Zuordnung ist eine feinere Ergänzung, kein Widerspruch. +- Wie granular soll der Objekttyp/Kategorie-Baum sein (Karte 11) — flache Liste (Rettungsdienst, Betreuung, Technik, ...) oder hierarchisch mit Unterkategorien? *(weiterhin offen, unkritisch für Schema — Kategorie hat bereits optionale Selbstreferenz für Hierarchie, Prompt 20)* +- ~~Welche Kontrollintervalle/Fristen sind organisatorisch vorgesehen (täglich, wöchentlich, nach Einsatz)?~~ **Geklärt:** V1 hat KEINE eigene Kontrollintervall-/Fälligkeitslogik. Einzige System-getriebene Aufforderung zur Kontrolle ist der bereits bestehende Ablaufdatum-Mechanismus (Prompt 14: bald ablaufend/abgelaufen). Reguläre Kontrollintervalle bleiben rein organisatorisch (Dienstplan/Anweisung), vom System nur dokumentiert (Zeitpunkt letzte Kontrolle sichtbar), nicht berechnet oder erzwungen. ## Referenzen Arbeitskarten: [[01_rollen_zuordnung]], [[02_rechte_stammdaten]], [[03_sollmengen_recht]], [[04_organisationsstruktur]], [[05_benachrichtigungen]], [[06_geraet_pc_mobil]], [[07_sofort_nachfuellung]], [[08_mindermenge_gueltigkeit]], [[09_authentifizierung]], [[10_qr_barcode]], [[11_systemumfang_ressourcenmanagement]], [[12_eskalation]] diff --git a/ergebnisse/12_verantwortlichen_dashboard.md b/ergebnisse/12_verantwortlichen_dashboard.md index 982e970..bd054f0 100644 --- a/ergebnisse/12_verantwortlichen_dashboard.md +++ b/ergebnisse/12_verantwortlichen_dashboard.md @@ -40,6 +40,9 @@ Materialverantwortlicher, Leitungsverantwortlicher, Administration (Prompt 05). - Globale Suche über Objekte/Material (Name, Artikelnummer, Code/QR-ID). - Schnellzugriff auf ein bestimmtes Objekt unabhängig vom Fehlbestand-Kontext. +## 6a. Klarstellung: keine Kontrollintervall-Fälligkeit in V1 +Nutzerentscheidung (Prompt 01, offene Frage geklärt): V1 berechnet KEINE eigene Kontrollfälligkeit/„überfällige Kontrolle"-Kennzahl. Die einzige system-getriebene Aufforderung zur (Wieder-)Kontrolle ist der bestehende Ablaufdaten-Mechanismus (Punkt 2/„bevorstehende Ablaufdaten", Prompt 14). Reguläre Kontrollrhythmen bleiben rein organisatorisch, vom System nur dokumentiert (letzter Kontrollzeitpunkt je Objekt sichtbar), nicht berechnet oder als Kennzahl geführt. + ## 6. Vorbereitung Eskalation (Karte 12, Roadmap) - Alter-Spalte und -Filter bereits jetzt vorhanden (siehe oben), liefert Datenbasis. - Kein automatischer Eskalations-Trigger/Benachrichtigung an Leitung in V1 (Karte 05: kein Push, nur Dashboard+E-Mail bei Entstehung), aber visuelle Hervorhebung alter offener Fehlbestände (z. B. rote Markierung ab konfigurierbarer Schwelle) als einfache Vorstufe sinnvoll und ohne Zusatzaufwand umsetzbar. diff --git a/ergebnisse/16_kontrollabschluss.md b/ergebnisse/16_kontrollabschluss.md index c25d6f4..b7a17de 100644 --- a/ergebnisse/16_kontrollabschluss.md +++ b/ergebnisse/16_kontrollabschluss.md @@ -22,7 +22,8 @@ Eine Kontrolle gilt als abgeschlossen, wenn Mitarbeiter jede Position mindestens ## 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). +- 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. + - **V1-Vereinfachung (Vermerk):** Datenmodell hat bereits das Feld `kontrolle.signatur` (Prompt 20) – eine eigene Einstellungs-Entität „Signatur pro Standort/Organisation ein/aus" existiert in V1 NICHT. Für V1 reicht: Feld ist da und wird nur befüllt, wenn UI eine Unterschrift anbietet; echte Ein/Aus-Konfigurierbarkeit pro Standort ist Roadmap (Prompt 24). - 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. @@ -32,7 +33,7 @@ Eine Kontrolle gilt als abgeschlossen, wenn Mitarbeiter jede Position mindestens **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. +- Objekt bleibt im Zustand vor Kontrollbeginn (bzw. „nicht kontrolliert seit Datum X") – rein informativ, keine automatische Fälligkeits-/Überfällig-Logik in V1 (siehe Prompt 12.6a). - Grund für Abbruch optional erfassbar (Freitext, z. B. „Einsatzalarmierung"). ## Referenzen diff --git a/ergebnisse/21_api.md b/ergebnisse/21_api.md index 6793a79..9d19bbf 100644 --- a/ergebnisse/21_api.md +++ b/ergebnisse/21_api.md @@ -96,7 +96,7 @@ Fehlte bisher, obwohl in der Berechtigungsmatrix (Prompt 05) gefordert. ## 9. Validierung/Fehlerfälle (Beispiele) - Mindermenge genehmigen ohne Begründung → 422, Feld `begruendung` Pflicht (Prompt 04). - Mindermenge genehmigen durch Mitarbeiter-Rolle → 403 (Prompt 05). -- Nachfüllung mit Menge, die Ist über Soll hebt → 422 oder Warnung (fachlich zu entscheiden bei Umsetzung, aus Prompt 02 nicht explizit als Fehler definiert – konservativ: erlauben, aber als „Überbestand“-Info kennzeichnen, kein Fehlbestand). +- Nachfüllung mit Menge, die Ist über Soll hebt → **entschieden:** erlauben (kein 422), Response kennzeichnet den Fall als „Überbestand"-Info (Prompt 02.4), löst keinen Fehlbestand aus. - Kontrolle abschließen, obwohl Positionen unbearbeitet → 409, Liste fehlender Positionen im Response. - Doppeltes Duplizieren mit gleichem Code → 409 (Code muss eindeutig sein, Prompt 09). diff --git a/ergebnisse/testphasen.md b/ergebnisse/testphasen.md index 1e72419..22702a6 100644 --- a/ergebnisse/testphasen.md +++ b/ergebnisse/testphasen.md @@ -13,6 +13,7 @@ Grundprinzip: Tests werden **phasenweise** aufgebaut, parallel zur Implementieru - Separate **Test-Datenbank** (eigene PostgreSQL-Datenbank, Schema via Alembic-Migrationen aufgesetzt, nie gegen Dev-/Produktiv-DB) - Test-Fixtures: frische DB pro Testklasse (Transaction-Rollback oder Drop/Create), Standard-Stammdaten-Set (1 Bereich, 2 Standorte, 3 Objekttypen, ~10 Materialien aller 3 Typen, 1 Vorlage mit Positionen, 2 Objekte, 4 Benutzer = 1 je Rolle) - CI-Job (Gitea Actions): install → migrate → pytest → Coverage-Report; Blocker bei Rot +- **Seed-Datensatz `systemknoten`:** `objekt.zustaendiger_server_id`, `kontrolle.erzeugt_von_server_id`, `fehlbestand.erzeugt_von_server_id`, `historie.erzeugt_von_server_id` sind NOT NULL (Prompt 20) – V1 braucht daher zwingend einen Seed-Datensatz `systemknoten (typ='haupt')` VOR dem ersten Datensatz jeder Art, plus eine Konfigurations-Referenz im Backend (z. B. Umgebungsvariable/Settings-Wert `SYSTEMKNOTEN_ID`), die der Anwendungscode bei jedem Insert einsetzt. Ohne diesen Seed schlägt der allererste Insert fehl – gehört in die Migrations-/Setup-Reihenfolge von Phase 0, nicht erst bei Satelliten-Umsetzung (Phase S) relevant. **Abnahmekriterium:** `pytest` läuft grün (auch wenn erst 1 Smoke-Test existiert), CI schlägt bei Testfehler fehl.