docs(arbeitskacheln): Open-Source-/HiOrg-Vergleich ausgewertet, 14 neue Kacheln ausgearbeitet

Vergleich mit InvenTree, Snipe-IT, Grocy, Shelf.nu, Resgrid, KP Front, FleetMS,
HiOrg-Server ergibt neue Kacheln (ASSET-010 Custody, FILE-008 Hash-Audit-Journal,
FILE-009 Notizen, NOTIF-003, MAINT-007 Tankbuch, ZUST-003 Standort-Scoping,
FOUND-007 Import/Export, FOUND-008 Fristen-Dienst, READY-006 Statistik-Dashboard,
UI2-006..010) sowie Referenz-Ergänzungen bei bestehenden Lücken. Alle Design-
Entscheidungen (Datenmodell, Sicherheitsanforderungen bei ASSET-010) geklärt.

Neues Epic 23 (Flutter-Begleit-App, Sondierungs-Prototyp FLUT-001) inkl. geklärtem
TLS-Blocker (Domain mabea.perlbach-edv.de mit Let's-Encrypt-Zertifikat statt
selbstsigniertem Server-Zertifikat).

Alle Kacheln bleiben offen/ungeplant, nur ausgearbeitet, keine Implementierung.

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

arbeitskacheln/17_zustaendigkeit.md

@@ -1,6 +1,8 @@
 # Epic 17 — Zuständigkeit
 
-Details zu ZUST-001 … ZUST-002 (vollständig). Übernommen aus `arbeitskarten/01_rollen_zuordnung.md`
+Details zu ZUST-001 … ZUST-003. ZUST-001/002 vollständig, ZUST-003 ergänzt am 2026-09-09
+aus Open-Source-Vergleich, noch offen/ungeplant. Ü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).
@@ -62,12 +64,62 @@ war die Vorgängerlücke, diese hier ist die zweite gefundene Lücke).
 - **DoD:** deckt sich 1:1 mit MABEA (`Kontrollverantwortung`-Tabelle, admin-UI bereits
   produktiv).
 
+## ZUST-003 — Standort-Scoping für granulare Berechtigungen (P2, neu, geklärt 2026-09-09)
+
+- **Ziel:** Custom-Rollen-Berechtigungen (`Berechtigung`/`Rolle`/`RolleBerechtigung`,
+  Roadmap Phase 6) optional auf einen Standort/Depot einschränken können, statt immer
+  global zu gelten.
+- **Bedarf: bestätigt (2026-09-09)** — echte Anforderung, kein rein hypothetisches
+  Feature.
+- **Beschreibung:** Aktuell gilt jede über eine Custom-Rolle vergebene Berechtigung
+  systemweit — ein Nutzer mit „material.erstellen" darf das an JEDEM Standort, nicht nur
+  an dem, für den er zuständig ist. Erweiterung: optionales `standort_id` an
+  der Benutzer-Rollen-Zuordnung, `NULL` = weiterhin global (Rückwärtskompatibilität).
+- **Benutzerwert:** Ein Materialwart kann Rechte für seinen Standort bekommen, ohne
+  automatisch auch an allen anderen Standorten schreiben zu dürfen — relevant, sobald
+  mehrere Standorte/Depots von unterschiedlichen Personen verantwortet werden.
+- **Abhängigkeiten:** ZUST-001 (bestehendes Standort↔Verantwortlicher-Konzept), das
+  granulare Rechtesystem (`app/models/permission.py`)
+- **Datenmodell (entschieden 2026-09-09): 1:1, einfache Spalte statt
+  Zwischentabelle** — `benutzer_rolle_zuordnung.standort_id` (FK, nullable),
+  `NULL` = global. Begründung: Personen wechseln typischerweise komplett den
+  Standort (dann wird der Wert einfach aktualisiert, kein Neuanlegen/Löschen
+  nötig) statt dauerhaft mehreren Standorten gleichzeitig zugeordnet zu sein.
+  Braucht eine Person doch mehrere Standorte gleichzeitig: einfach eine zweite
+  Rollen-Zuweisung mit anderem `standort_id` anlegen (Custom-Rollen sind bereits
+  mehrfach zuweisbar) — kein n:m-Konstrukt nötig, deutlich einfachere
+  Rechteprüfungs-Logik.
+- **Backend:** Rechte-Check-Funktion (`require_roles_or_permission` o.ä.) um
+  Standort-Filter erweitern — prüft nicht nur „hat Berechtigung X", sondern „hat
+  Berechtigung X für Standort Y (oder global)"
+- **Frontend:** `RolleSection.tsx` — Standort-Auswahl bei der Benutzer-Zuordnung
+  ergänzen (optional, Default weiterhin global)
+- **Mobile:** kein Unterschied, wirkt sich nur auf Backend-Autorisierung aus
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** nein direkt
+- **Rechte:** Verwaltung: Administrator
+- **Audit:** Änderung der Standort-Zuordnung geloggt
+- **Akzeptanzkriterien:** Nutzer mit standortgebundenem Recht kann an zugewiesenem
+  Standort handeln, an anderem Standort wird derselbe Endpunkt korrekt abgelehnt;
+  bestehende globale Zuordnungen (`standort_id IS NULL`) funktionieren unverändert.
+- **Tests:** Positivtest (Standort passt), Negativtest (falscher Standort abgelehnt),
+  Regressionstest (bestehende globale Rechte weiterhin uneingeschränkt).
+- **DoD:** offen — beide Design-Entscheidungen geklärt (2026-09-09), bereit für
+  Implementierung. **Referenz (Open-Source-Vergleich 2026-09-09):** keines der
+  verglichenen Projekte (InvenTree, Snipe-IT, Grocy, Shelf.nu, Resgrid, KP Front,
+  FleetMS) hat ein sauber dokumentiertes Standort-/Objekt-Ebene-Rechtesystem — Snipe-IT
+  nur grobes Company-Scoping, Shelf.nu nur personenbezogene Sichtbarkeits-Toggles. Wäre
+  bei Umsetzung eine echte Differenzierung ggü. allen verglichenen Projekten, kein
+  Nachbau.
+
 ---
 
-**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.
+**MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-09):** ZUST-001/002 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.
+ZUST-003 (Standort-Scoping für Berechtigungen) neu ergänzt am 2026-09-09 aus
+Open-Source-Vergleich, offen/ungeplant.
 
 ## Referenzen
 Alte Arbeitskarten (übernommen, Karten-Dateien gelöscht): Karte 01 Rollen&Zuordnung,