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

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.