docs(arbeitskacheln): 5 neue Kacheln aus vertieftem HiOrg-Server-Vergleich (PERS-008, ASSET-011/012, MAINT-008, LOAD-007)

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

arbeitskacheln/00_index.md

@@ -165,6 +165,8 @@ vergeben statt geraten.
 | ASSET-008 | Assets | Consumable | P1 | M | MEDIUM | ASSET-002 | ✅ (`MaterialTyp.standard`/`ablauf_charge` IST das Consumable-Konzept, kein separates Modell nötig) |
 | ASSET-009 | Assets | Nutzungszähler (Kilometer/Betriebsstunden generisch) | P1 | S | LOW | ASSET-003 | ✅ (`fahrzeugdetails.py` Kilometerstand, MAINT-002 nutzt es) |
 | ASSET-010 | Assets | Custody/Ausgabe an GeraetInstanz (neu, Referenz: Shelf.nu) | P2 | M | MEDIUM | ASSET-003, PERS-001, DOC-001 | ✅ (`geraet_instanz_custody`+`signier_token`, QR-Signier-Flow, `app/services/custody.py`) |
+| ASSET-011 | Assets | Externer Verleih mit Rückgabe-Tracking (neu, Referenz: HiOrg-Server) | P2 | M | MEDIUM | ASSET-003, ASSET-010 | ⬜ geplant 2026-09-10 |
+| ASSET-012 | Assets | Ressourcen-Buchungskalender (neu, Referenz: HiOrg-Server) | P2 | M | MEDIUM | ASSET-003 | ⬜ geplant 2026-09-10 |
 | FLEET-001 | Fleet | Fahrzeugtypen | P1 | XS | LOW | ASSET-002 | ✅ (Objekttyp deckt Fahrzeugtypen ab) |
 | FLEET-002 | Fleet | Fahrzeuge (Kennzeichen/Funkrufname) | P1 | S | LOW | ASSET-003, FLEET-001 | ✅ (`fahrzeugdetails.py`: Kennzeichen, Funkrufname, OPTA/Funkkennung) |
 | FLEET-003 | Fleet | Kilometerstand (Anwendung von ASSET-009) | P1 | XS | LOW | FLEET-002, ASSET-009 | ✅ (Kilometerstand-Feld + Wartungsintervall-Kopplung) |
@@ -191,6 +193,7 @@ vergeben statt geraten.
 | LOAD-004 | Loadout | Digitale Beladungskontrolle | P1 | M | MEDIUM | LOAD-003 | ✅ (`kontrollen.py`, `KontrollPage.tsx`) |
 | LOAD-005 | Loadout | Kontrollhistorie | P1 | S | LOW | LOAD-004, FOUND-006 | ✅ (`Kontrolle`-Modell append-only, Historie-Anbindung) |
 | LOAD-006 | Loadout | Readiness-Kopplung | P1 | S | MEDIUM | LOAD-003, READY-001 | ✅ (Fehlbestand fließt in `einsatzbereitschaft()`-Berechnung ein) |
+| LOAD-007 | Loadout | Gemeinsame Sollmenge über mehrere Standorte (neu, Referenz: HiOrg-Server) | P3 | M | MEDIUM | LOAD-002, WH-004 | ⬜ geplant 2026-09-10 |
 | INSP-001 | Inspections | Prüfarten-Stammdaten | P1 | S | LOW | ASSET-002 | ⬜ (kein eigenständiges Prüfart-Stammdatenmodell gefunden) |
 | INSP-002 | Inspections | Prüfintervalle | P1 | S | LOW | INSP-001 | 🔶 (`pruefintervall_monate` an Objektposition, aber nicht generisch je Prüfart) |
 | INSP-003 | Inspections | Prüfdurchführung/-ergebnis | P1 | M | MEDIUM | INSP-002 | 🔶 (Statuswechsel an Geräteinstanz inkl. `naechste_pruefung`, kein separates Prüfergebnis-Protokoll) |
@@ -204,6 +207,7 @@ vergeben statt geraten.
 | MAINT-005 | Maintenance | Ersatzteile/Kosten | P3 | M | MEDIUM | MAINT-003 | ✅ (`WartungsauftragTeil`, Migration 0033, `/wartungsauftraege/{id}/teile`-CRUD, UI in `WartungSection.tsx`) |
 | MAINT-006 | Maintenance | Wartungsdokument-Anbindung | P2 | XS | LOW | MAINT-003, DOC-001 | ✅ (Dokument polymorph, deckt Wartungsauftrag ab) |
 | MAINT-007 | Maintenance | Tankbuch/Kraftstoffverbrauch (neu, Referenz: FleetMS) | P3 | S | LOW | FLEET-002, ASSET-009 | ✅ (`tankbuch_eintrag`, `app/services/tankbuch.py`, Verbrauchsberechnung) |
+| MAINT-008 | Maintenance | Lieferanten-/Dienstleister-Verzeichnis (neu, Referenz: HiOrg-Server) | P3 | S | LOW | MAINT-003 | ⬜ geplant 2026-09-10 |
 | DEFECT-001 | Defects | Mangelmeldung + Foto | P1 | M | LOW | ASSET-003, DOC-001 | ✅ (`mangel.py`, `MangelListePage.tsx`, Dokument-Anhang möglich) |
 | DEFECT-002 | Defects | Priorität & Status-Workflow | P1 | S | LOW | DEFECT-001 | ✅ (`MangelStatus`, `MangelPrioritaet` Enums) |
 | DEFECT-003 | Defects | Verantwortlicher & Reparaturzuordnung | P1 | S | LOW | DEFECT-002, PERS-002 | ✅ (Zustaendigkeit/Kontrollverantwortung koppelt an Mangel-Objekt) |
@@ -216,6 +220,7 @@ vergeben statt geraten.
 | PERS-005 | Personnel | Qualifikationen/Lehrgänge | P1 | S | LOW | PERS-001 | ✅ (`Qualifikationstyp`, `BenutzerQualifikation`) |
 | PERS-006 | Personnel | Führerscheine/Berechtigungen mit Gültigkeit | P1 | M | MEDIUM | PERS-005, ASSET-002 | ✅ (`Qualifikationskategorie.fuehrerschein`, `ObjekttypQualifikationsanforderung`) |
 | PERS-007 | Personnel | Qualifikationsablauf-Warnungen | P1 | S | LOW | PERS-006 | ✅ (`QualifikationTile.tsx`, `/dashboard/qualifikationsablaeufe`) |
+| PERS-008 | Personnel | Einweisungspflicht vor Geräteausgabe (neu, Referenz: HiOrg-Server) | P2 | S | LOW | PERS-005, PERS-006, ASSET-010 | ⬜ geplant 2026-09-10 |
 | READY-001 | Readiness | Regel-Engine (Grundgerüst) | P1 | M | HIGH | ASSET-004 | ✅ (`readiness_regel`-Tabelle, sieben Kriterien an/abschaltbar, keine volle Gewichtungs-Engine — bewusst reduzierter Scope) |
 | READY-002 | Readiness | Zustände READY/LIMITED/NOT_READY/UNKNOWN | P1 | S | MEDIUM | READY-001 | ✅ (bereit/eingeschränkt/unbekannt/nicht_einsatzbereit in `services/dashboard.py`, laut DECISION-Abschnitt am 2026-09-05 live gefixt) |
 | READY-003 | Readiness | Regel-Kopplung (Prüfung/Wartung/Mangel/Beladung) | P1 | L | HIGH | READY-002, INSP-004, DEFECT-005, LOAD-006 | ✅ (`einsatzbereitschaft()` zieht Fehlbestand/Mangel/Gerätestatus zusammen) |

arbeitskacheln/04_assets.md

@@ -379,16 +379,109 @@ Details zu ASSET-001 … ASSET-010. ASSET-010 ergänzt am 2026-09-09 aus Open-So
 - **DoD:** mind. ein Fahrzeug UND ein Gerät (z.B. Stromerzeuger) nutzen denselben
   Mechanismus nachweisbar.
 
+## ASSET-011 — Externer Verleih mit Rückgabe-Tracking (P2, neu, Referenz: HiOrg-Server)
+
+- **Ziel:** Material nicht nur intern zuordnen (ASSET-010: Person innerhalb der
+  eigenen Organisation), sondern auch an EXTERNE Stellen (andere
+  Organisation/Ortsverein, Behörde, externer Ausbilder) verleihen, mit
+  Rückgabe-Nachverfolgung.
+- **Abgrenzung zu ASSET-010:** ASSET-010 ist auf `Person` (PERS-001, i.d.R.
+  eigenes Personal) ausgelegt — ein Verleiher ist keine `Person` im MABEA-Sinn,
+  sondern eine externe Organisation/Stelle ohne eigenen MABEA-Zugang. Eigene
+  Entität statt Zweckentfremdung von `Person`.
+- **Beschreibung:** `externe_stelle`-Stammdaten (Name, Kontakt, optional
+  Adresse) + `verleih`-Vorgang (Objekt/GeraetInstanz, externe_stelle_id,
+  verliehen_am, voraussichtliche_rueckgabe_am, tatsaechliche_rueckgabe_am
+  nullable, bemerkung). Solange `tatsaechliche_rueckgabe_am IS NULL` gilt das
+  Gerät als verliehen — analog zum "offene Zeile"-Muster aus ASSET-010
+  (`geraet_instanz_custody`).
+- **Benutzerwert:** Nachvollziehbar, was verliehen ist, an wen, und ob eine
+  Rückgabe überfällig ist — verhindert "vergessenes" Material bei Dritten.
+- **Abhängigkeiten:** ASSET-003, ASSET-010 (gleiches Konzept "offene
+  Inhaberschafts-Zeile", andere Zielentität)
+- **Datenmodell:** `externe_stelle` (id, name, kontakt, adresse), `verleih`
+  (id, objekt_id ODER geraet_instanz_id, externe_stelle_id, verliehen_am,
+  voraussichtliche_rueckgabe_am nullable, tatsaechliche_rueckgabe_am
+  nullable, bemerkung, verliehen_von_benutzer_id)
+- **Backend:** CRUD `externe_stelle`, `POST /verleih` (verleihen),
+  `POST /verleih/{id}/rueckgabe` (zurücknehmen), `GET /verleih?offen=true`
+  (Übersicht laufender Verleihe, ggf. mit Überfälligkeits-Kennzeichnung
+  analog zum bestehenden `_ablauf_status()`-Muster)
+- **Frontend:** Admin-Tab „Verleih" (analog Ausgabe/Custody-UI)
+- **Mobile:** keins (Verwaltungsvorgang)
+- **QR-Code/Seriennummer/Inventarnummer:** nutzt bestehende Objekt-/
+  Geräteinstanz-Identität
+- **Akte:** Verleih-Verlauf im Akte-Historienbereich
+- **Rechte:** Materialverantwortliche/Administration
+- **Audit:** Verleih/Rückgabe geloggt
+- **Akzeptanzkriterien:** ein Objekt kann nicht gleichzeitig zweimal offen
+  verliehen sein (DB-Constraint analog ASSET-010); überfälliger Verleih
+  (voraussichtliche_rueckgabe_am in der Vergangenheit, noch nicht
+  zurückgenommen) ist erkennbar.
+- **Tests:** CRUD-Test, Doppel-Verleih-Ablehnung, Überfälligkeits-Test.
+- **DoD:** offen.
+- **Referenz (HiOrg-Server-Vergleich 2026-09-10):** HiOrg-Server unterstützt
+  Materialverleih über die eigene Organisation hinaus mit Rückgabe-Tracking —
+  MABEAs ASSET-010 deckt nur die interne Zuordnung ab, keine echte Lücke bei
+  Bedarf, aber bisher nicht vorgesehen.
+
+## ASSET-012 — Ressourcen-Buchungskalender (P2, neu, Referenz: HiOrg-Server)
+
+- **Ziel:** Verhindern, dass dasselbe Material/Fahrzeug für zwei sich
+  überschneidende Termine gleichzeitig eingeplant wird — reine
+  Verfügbarkeits-/Konfliktprüfung.
+- **Bewusste Abgrenzung (wichtig, nicht verwässern):** Das ist KEINE
+  Personal-Dienstplanung/Schichtplanung — das bleibt explizit außerhalb
+  MABEAs Auftrags (siehe Epic 16 Operations, ursprüngliche
+  Nicht-Ziel-Festlegung). Es geht ausschließlich um "ist Ressource X am
+  Datum/Zeitraum Y schon verplant", nicht um Personaleinsatz.
+- **Beschreibung:** `ressourcenbuchung` (objekt_id, von, bis, zweck/bezeichnung,
+  gebucht_von_benutzer_id) — beim Anlegen einer neuen Buchung serverseitig auf
+  Zeitraumüberschneidung mit bestehenden Buchungen DESSELBEN Objekts prüfen,
+  bei Konflikt 409 mit den kollidierenden Buchungen in der Fehlerantwort.
+- **Benutzerwert:** Keine Doppelbuchung eines Fahrzeugs für zwei Lehrgänge/
+  Veranstaltungen am selben Tag, ohne dass das erst beim Abholen auffällt.
+- **Abhängigkeiten:** ASSET-003
+- **Datenmodell:** `ressourcenbuchung` (id, objekt_id, von: timestamptz,
+  bis: timestamptz, bezeichnung, gebucht_von_benutzer_id, erstellt_am) —
+  Überschneidungsprüfung über Standard-Intervall-Overlap
+  (`von < bestehende.bis AND bis > bestehende.von`), kein exotischer
+  Constraint-Typ nötig (PostgreSQL `tstzrange`+`EXCLUDE USING gist` wäre die
+  sauberere DB-native Lösung, Anwendungslogik reicht aber für den Bedarf).
+- **Backend:** `POST /ressourcenbuchungen` (mit Konfliktprüfung),
+  `GET /objekte/{id}/ressourcenbuchungen`, `DELETE /ressourcenbuchungen/{id}`
+- **Frontend:** einfache Listen-/Kalenderansicht je Objekt (kein volles
+  Kalender-Widget nötig für den MVP — Liste mit Von/Bis reicht,
+  Kalender-UI wäre spätere Ausbaustufe)
+- **Mobile:** keins
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Buchungsübersicht im Akte-Bereich (optional, nicht kritisch)
+- **Rechte:** Mitarbeiter+ (buchen), Materialverantwortliche+ (fremde
+  Buchungen löschen)
+- **Audit:** Buchung/Stornierung geloggt
+- **Akzeptanzkriterien:** überschneidende Buchung desselben Objekts wird mit
+  409 abgelehnt, nicht-überschneidende Buchungen verschiedener Zeiträume
+  funktionieren normal.
+- **Tests:** Überschneidungstest (exakte Deckung, Teilüberschneidung,
+  Randfall exakt aneinandergrenzend — grenzt NICHT als Konflikt, siehe
+  Standard-Intervall-Semantik).
+- **DoD:** offen.
+- **Referenz (HiOrg-Server-Vergleich 2026-09-10):** HiOrg-Server bietet
+  Ressourcen-/Terminverwaltung für Material und Fahrzeuge — bewusst nur der
+  Verfügbarkeitsprüfungs-Teil übernommen, keine volle
+  Termin-/Veranstaltungsverwaltung (das wäre Scope-Creep über MABEAs
+  Materialmanagement-Kernauftrag hinaus).
+
 ---
 
-**MABEA-Ist-Stand-Abgleich:** ASSET-001…004 entsprechen `Bereich`/`Kategorie`,
+**MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-10):** ASSET-001…004 entsprechen `Bereich`/`Kategorie`,
 `Objekttyp`, `Objekt`, `ObjektStatus` — vollständig vorhanden, inkl. des 5-stufigen
 Fahrzeug-Status als Beispiel für ASSET-004-Erweiterung. ASSET-005 (Suche/Filter) vorhanden
 in ObjektListPage/ObjektSection. ASSET-006 (Bewegungshistorie) vorhanden als
-`Lagerbewegung` (diente hier sogar als Vorbild). **ASSET-007 (AssetSet) und ASSET-008
-(Consumable als eigenständiges Konzept) fehlen** — echte Lücken, wie schon in der
-Gap-Analyse vorher notiert. **ASSET-009 (generischer Nutzungszähler) fehlt ebenfalls:**
-MABEA hat Kilometerstand/Betriebsstunden nur an `fahrzeugdetails` (1:1 zu Objekt mit
-`ist_zugfahrzeug`), Geräte wie Stromerzeuger/Pumpen (`GeraetInstanz`) haben aktuell KEIN
-Betriebsstunden-Feld — echte Lücke, wenn Wartung künftig betriebsstundenabhängig geplant
-werden soll (MAINT-002, Wartungs-Epic in MABEA ohnehin noch komplett offen).
+`Lagerbewegung` (diente hier sogar als Vorbild). ASSET-007 (Material-Sets), ASSET-008
+(Consumable-Abgrenzung) und ASSET-010 (Custody) sind inzwischen umgesetzt (siehe deren
+DoD-Einträge oben). **ASSET-009 (generischer Nutzungszähler) bleibt die verbleibende
+echte Lücke:** MABEA hat Kilometerstand/Betriebsstunden nur an `fahrzeugdetails` (1:1 zu
+Objekt mit `ist_zugfahrzeug`), Geräte wie Stromerzeuger/Pumpen (`GeraetInstanz`) haben
+aktuell KEIN Betriebsstunden-Feld. ASSET-011/012 (2026-09-10 aus vertieftem
+HiOrg-Server-Vergleich ergänzt) sind neu und offen.

arbeitskacheln/08_loadout.md

@@ -137,11 +137,67 @@ Details zu LOAD-001 … LOAD-006 (vollständig).
 - **DoD:** deckt sich mit MABEA (Fehlbestand ist bereits ein Grund in
   `dashboard.einsatzbereitschaft()`).
 
+## LOAD-007 — Gemeinsame Sollmenge über mehrere Standorte (P3, neu, Referenz: HiOrg-Server)
+
+- **Ziel:** Mehrere Objektpositionen (dasselbe Material an verschiedenen
+  Standorten/Objekten) können sich EINE gemeinsame Sollmenge teilen, statt
+  je Standort einzeln gepflegt zu werden.
+- **Beschreibung:** Aktuell hat jede `Objektposition` ihre eigene
+  `sollmenge_override`/`sollmenge_vorlage` — unabhängig davon, ob dasselbe
+  Material an mehreren Objekten/Standorten geführt wird. Bedarf (laut
+  HiOrg-Server-Beispiel): eine Organisation will z.B. "insgesamt 50 Stück
+  Material X über alle Standorte verteilt" als EINE Sollvorgabe pflegen,
+  nicht 50 einzeln pro Standort aufteilen und bei Verschiebung zwischen
+  Standorten die Einzelwerte manuell nachziehen.
+- **Benutzerwert:** Weniger Pflegeaufwand bei organisationsweiten
+  Sollmengen-Vorgaben, kein manuelles Nachziehen bei Standort-übergreifenden
+  Umlagerungen.
+- **Abhängigkeiten:** LOAD-002 (Objektposition), WH-004 (Materialbewegung/
+  Umlagerung)
+- **Datenmodell:** `sollmengen_gruppe` (id, material_id, gemeinsame_sollmenge)
+  — `Objektposition` bekommt ein optionales `sollmengen_gruppe_id` (nullable
+  FK); ist es gesetzt, gilt für die Ist/Soll-Bewertung dieser Position die
+  SUMME der Istmengen aller Positionen derselben Gruppe gegen die eine
+  gemeinsame Sollmenge, statt jede Position einzeln gegen ihre eigene
+  Sollmenge zu prüfen. **DECISION REQUIRED:** wie wird ein Fehlbestand
+  einer Gruppe einem KONKRETEN Standort zugeordnet, wenn die Summe unter der
+  gemeinsamen Sollmenge liegt, aber nicht klar ist, an welchem Standort das
+  Material fehlt? (Denkbarer Ansatz: Fehlbestand wird nicht pro Standort,
+  sondern auf Gruppenebene gemeldet — abweichend vom bisherigen Muster, wo
+  jeder Fehlbestand einem `objekt_id` zugeordnet ist.)
+- **Backend:** Kontroll-/Fehlbestand-Logik (`app/services/kontrolle/erfassung.py`)
+  müsste die Gruppen-Summe statt der Einzelmenge prüfen, wenn eine Position
+  einer Gruppe angehört — Umbau an einer fachlich zentralen Stelle, nicht
+  additiv nachrüstbar wie die meisten anderen Kacheln dieser Session.
+- **Frontend:** Sollmengen-Gruppe in der Vorlagen-/Objektposition-Verwaltung
+  anzeigen/zuordnen
+- **Mobile:** Anzeige „Gruppen-Sollmenge" statt Einzelwert bei Kontrolle
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Beladungsbereich zeigt Gruppen-Zugehörigkeit, falls vorhanden
+- **Rechte:** Materialverantwortliche/Administration (Gruppen anlegen)
+- **Audit:** Änderung der Gruppen-Zuordnung/-Sollmenge geloggt
+- **Akzeptanzkriterien:** zwei Objektpositionen derselben Gruppe ergeben in
+  Summe korrekt gegen die gemeinsame Sollmenge geprüft; Positionen ohne
+  Gruppen-Zuordnung funktionieren unverändert wie bisher (Rückwärts-
+  kompatibilität, kein Zwang zur Migration bestehender Daten).
+- **Tests:** Gruppen-Summen-Test, Regressionstest für Positionen ohne Gruppe.
+- **DoD:** offen — **P3, kleinste Priorität der fünf HiOrg-Nachträge**, da die
+  offene Fehlbestand-Zuordnungsfrage eine echte fachliche Vorentscheidung
+  braucht (nicht nur technische Umsetzung) und das bisher am weitesten
+  ausgereifte Epic im Backlog berührt — höheres Sorgfaltsbedürfnis vor einer
+  Umsetzung.
+- **Referenz (HiOrg-Server-Vergleich 2026-09-10):** HiOrg-Server führte
+  2026-07 eine "gemeinsame Sollmenge" für sein Materialsystem ein — bestätigt
+  den Bedarf als real genug, um aufzunehmen, auch wenn MABEA aktuell nur eine
+  Organisation bedient (kleinerer, konkreter Nutzen als READY-001s volle
+  Konfigurierbarkeit).
+
 ---
 
-**MABEA-Ist-Stand-Abgleich:** Das komplette Loadout-Epic ist in MABEA vorhanden und **das
-am weitesten ausgereifte Epic im ganzen Backlog** — Beladungsvorlage/-versionierung,
-Objektposition, automatische Fehlbestand-Erkennung, der komplette Kontroll-Flow (inkl.
-Sperre gegen Parallelkontrolle, Sofort-Nachfüllung während der Kontrolle, digitale
-Signatur), letzte-Kontrolle-Anzeige und Readiness-Kopplung sind alle bereits produktiv im
-Einsatz. Keine offenen Lücken in diesem Epic.
+**MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-10):** Das komplette Loadout-Epic ist in
+MABEA vorhanden und **das am weitesten ausgereifte Epic im ganzen Backlog** —
+Beladungsvorlage/-versionierung, Objektposition, automatische Fehlbestand-Erkennung, der
+komplette Kontroll-Flow (inkl. Sperre gegen Parallelkontrolle, Sofort-Nachfüllung während
+der Kontrolle, digitale Signatur), letzte-Kontrolle-Anzeige und Readiness-Kopplung sind
+alle bereits produktiv im Einsatz. LOAD-007 (2026-09-10 aus vertieftem
+HiOrg-Server-Vergleich ergänzt) ist die einzige offene Lücke, bewusst niedrige Priorität.

arbeitskacheln/10_maintenance.md

@@ -181,6 +181,50 @@ ebenfalls P3/offen.
   eigenständiges Fahrzeug-Modul — Konzept übertragbar, MABEA hat aktuell keinerlei
   Kraftstoff-Tracking.
 
+## MAINT-008 — Lieferanten-/Dienstleister-Verzeichnis (P3, neu, Referenz: HiOrg-Server)
+
+- **Ziel:** Strukturierte Stammdaten für Lieferanten/Wartungsdienstleister/
+  Verleiher statt Freitext.
+- **Beschreibung:** `wartungsauftrag.werkstatt_name` ist aktuell reines
+  Freitextfeld (kein Kontakt, keine Wiederverwendbarkeit, Tippfehler-
+  Duplikate möglich, z.B. "Autohaus Müller" vs. "Autohaus Mueller"). Eine
+  einfache Stammdatentabelle `dienstleister` (Name, Kontakt, Telefon,
+  E-Mail, Adresse, Kategorie: Werkstatt/Lieferant/Verleiher) löst das
+  Freitextfeld ab, verknüpfbar mit `Wartungsauftrag` UND optional mit
+  ASSET-011 (`externe_stelle` könnte sogar dieselbe Tabelle sein statt einer
+  Dopplung — **DECISION REQUIRED** bei Implementierung: `dienstleister` und
+  `externe_stelle` (ASSET-011) zusammenlegen oder getrennt halten? Beide sind
+  im Kern "externe Organisation mit Kontaktdaten", eine gemeinsame
+  Stammdatentabelle mit einer Kategorie-Unterscheidung wäre naheliegend, um
+  keine zwei Adressbücher zu pflegen).
+- **Benutzerwert:** Wiederverwendbare Kontaktdaten statt jedes Mal neu
+  eintippen, Grundlage für „wer hat das zuletzt gewartet/geliefert".
+- **Abhängigkeiten:** MAINT-003 (Wartungsauftrag existiert bereits)
+- **Datenmodell:** `dienstleister` (id, name, kontakt, telefon, email,
+  adresse, kategorie) — `Wartungsauftrag.werkstatt_name` wird bei
+  Implementierung durch `dienstleister_id` (nullable FK, Freitext bleibt als
+  Fallback für nicht erfasste Dienstleister) ergänzt, nicht ersetzt (kein
+  Zwang zur Vollmigration bestehender Freitext-Einträge).
+- **Backend:** CRUD `dienstleister`, `Wartungsauftrag`-Erstellen/Ändern
+  akzeptiert optional `dienstleister_id`
+- **Frontend:** Admin-Stammdaten-Tab „Dienstleister", Dropdown im
+  Wartungsauftrag-Formular (mit Freitext-Fallback)
+- **Mobile:** keins
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Wartungsbereich zeigt strukturierten Dienstleister statt nur
+  Freitext, falls verknüpft
+- **Rechte:** Materialverantwortliche/Administration
+- **Audit:** Änderung geloggt
+- **Akzeptanzkriterien:** Dienstleister anlegen, einem Wartungsauftrag
+  zuordnen, bestehende Freitext-Einträge bleiben unverändert lesbar.
+- **Tests:** CRUD-Test, Test dass ein Wartungsauftrag ohne `dienstleister_id`
+  (nur Freitext) weiterhin funktioniert.
+- **DoD:** offen.
+- **Referenz (HiOrg-Server-Vergleich 2026-09-10):** HiOrg-Server führt ein
+  Adressbuch für Lieferanten/Dienstleister, verknüpfbar mit Material-/
+  Wartungsvorgängen — MABEA hat dafür aktuell nur Freitext, kleine, aber
+  konkrete Lücke.
+
 ---
 
 **MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-09):** MAINT-001..006

arbeitskacheln/12_personnel.md

@@ -157,6 +157,55 @@ Details zu PERS-001 … PERS-007 (vollständig).
 - **DoD:** deckt sich 1:1 mit MABEA
   (`dashboard.bevorstehende_qualifikationsablaeufe()`, bereits umgesetzt).
 
+## PERS-008 — Einweisungspflicht vor Geräteausgabe (P2, neu, Referenz: HiOrg-Server)
+
+- **Ziel:** Ein Gerät darf erst an eine Person ausgegeben werden (ASSET-010),
+  wenn eine erforderliche Einweisung nachgewiesen ist — nicht nur anzeigen,
+  dass sie fehlt (das kann PERS-006 bereits), sondern die Ausgabe aktiv
+  blockieren/warnen.
+- **Beschreibung:** Kein neues Datenmodell nötig — „Einweisung Beatmungsgerät
+  XY" ist einfach ein weiterer `Qualifikationstyp` (PERS-005), verknüpft über
+  das bestehende `objekttyp_qualifikationsanforderung` (PERS-006). Die Lücke
+  ist rein workflow-seitig: der bestehende Berechtigungsprüfungs-Endpunkt
+  (`GET /objekte/{id}/berechtigung/{benutzer_id}`) wird aktuell nirgends
+  aufgerufen, bevor ein Gerät ausgegeben wird.
+- **Benutzerwert:** Kein Gerät gelangt versehentlich an jemanden ohne
+  nachgewiesene Einweisung — Haftungs-/Sicherheitsrelevanz bei medizinischem
+  Gerät oder Fahrzeugen.
+- **Abhängigkeiten:** PERS-005, PERS-006, ASSET-010 (Custody/Ausgabe)
+- **Datenmodell:** keins neu — reine Wiederverwendung von PERS-005/006.
+- **Backend:** `custody.ausgeben()` (ASSET-010) ruft vor dem eigentlichen
+  Anlegen der Custody-Zeile die bestehende Berechtigungsprüfung
+  (`app/services/personal.py` o.ä., je nachdem wo PERS-006 aktuell liegt) für
+  `objekt_id` (über `GeraetInstanz→Objektposition→Objekt`) und die
+  ausgewählte `person_id` auf — **DECISION REQUIRED:** blockiert eine fehlende
+  Einweisung die Ausgabe hart (422), oder ist es nur eine Warnung im
+  Ausgabe-Dialog, die die ausgebende Stelle bewusst übergehen kann (analog zur
+  bereits getroffenen Entscheidung bei ASSET-010, den PIN-Schritt aus
+  Praktikabilitätsgründen wegzulassen)? Nicht vor Implementierung klären wäre
+  ein Fehler — dieselbe Praktikabilitäts-vs-Sicherheit-Abwägung wie bei ASSET-010.
+- **Frontend:** `CustodyDialog.tsx` zeigt eine Warnung/Blockade, wenn die
+  gewählte Person die erforderliche Qualifikation nicht hat.
+- **Mobile:** kein eigener Workflow (Ausgabe läuft übers Portal).
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** nein direkt (nutzt bestehende Qualifikationsanzeige)
+- **Rechte:** wie ASSET-010 (Ausgabe: Mitarbeiter+)
+- **Audit:** Ausgabe trotz fehlender Einweisung (falls als Warnung statt
+  Blockade umgesetzt) sollte im Historie-Log vermerkt werden, damit ein
+  bewusster Override nachvollziehbar bleibt.
+- **Akzeptanzkriterien:** Ausgabe an eine Person ohne erforderliche
+  Qualifikation löst die Ampel/Warnung/Blockade korrekt aus; Ausgabe an eine
+  Person MIT gültiger Qualifikation läuft unverändert durch.
+- **Tests:** Positiv-/Negativtest (mit/ohne/abgelaufene Einweisung).
+- **DoD:** offen — Design größtenteils klar (bestehende Infrastruktur
+  wiederverwenden), EINE offene Entscheidung (hart blockieren vs. Warnung)
+  vor Implementierungsstart mit dem Nutzer klären.
+- **Referenz (HiOrg-Server-Vergleich 2026-09-10):** HiOrg-Server kann
+  hinterlegen, dass ein Dienst/eine Materialzuordnung erst nach nachgewiesener
+  Geräte-Einweisung möglich ist ("Dienst nur mit Material-Einweisung
+  möglich") — bestätigt den Bedarf, MABEA hat die Datengrundlage bereits,
+  nur die Durchsetzung im Ausgabe-Workflow fehlt.
+
 ---
 
 **MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-09):** PERS-001…003, 005, 006, 007