Letzte offene fachliche Fragen klären: keine Kontrollintervall-Fälligkeit (nur Ablaufdatum), Zuständigkeit vererbt sich vom Standort, Zuweisung ist reine Sichtbarkeit; Kleinigkeiten (Überbestand-Regel, Signatur-Vermerk, Server-Seed) dokumentiert

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L85hmKbvX7Cqkq47KnQhFt

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]]

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.

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

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

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.