## Ist-Zustand `EinsatzService::create()` übernimmt den Status ungeprüft aus dem Request: ```php // src/EinsatzService.php:858 $status = $this->validateStatus($data['status'] ?? 'neu'); ``` `validateStatus()` prüft nur, ob der Wert im Katalog steht — **nicht**, ob der Anlegende ihn setzen darf. Damit gilt beim **Anlegen**: - kein `einsatz.status`-Gate (anders als seit #201 in `update()`, `einsatz-status.php` und `einsatz-bulk.php`) - kein `einsatz.abschluss`-Gate — ein POST mit `status=abgeschlossen` legt einen **direkt abgeschlossenen** Einsatz an und umgeht damit das Vier-Augen-Prinzip `public/einsaetze/edit.php` filtert die Option `abgeschlossen` nur beim Rendern (Defense-in-Depth), der Server nimmt sie trotzdem an. `update()` hat den Gegencheck bereits (`src/EinsatzService.php:1068`), `create()` nicht. **Einordnung:** Bestandsproblem, nicht durch #201 entstanden. Ausnutzbar nur mit `einsatz.create`; der so angelegte Einsatz trägt keine Historie, die einen regulären Abschluss belegen würde. Standard-Rollen mit `einsatz.create` tragen ohnehin auch `einsatz.status`, verhaltensrelevant ist es also für Custom-Rollen — dieselbe Befund-Klasse wie #201/#202. ## Aufgabe - [ ] In `create()` dieselben Gates ziehen wie in `update()`: Status abweichend vom Default → `einsatz.status` nötig; `abgeschlossen` → zusätzlich `einsatz.abschluss` - [ ] Prüfen, ob ein Anlegen direkt als `abgeschlossen` fachlich überhaupt erlaubt sein soll, oder ob der Status beim Anlegen grundsätzlich auf die frühen Stufen begrenzt gehört - [ ] Alarm-/Mail-Pfade gegenprüfen: Diese legen Einsätze systemseitig an und dürfen durch das Gate nicht brechen (sie laufen ohne echten User bzw. mit System-Kontext) - [ ] Test analog zu den Gate-Zusicherungen aus #201 ## Bezug Gefunden im Abnahme-Review zu Welle 1 des v4.5-Zyklus (code-reviewer, Befund S6). Gehört thematisch zu #201/#202 und zur Wurzel-Ursache: `setStatus()` prüft selbst kein Recht, jeder Aufrufer muss es mitbringen — genau das ist mehrfach schiefgegangen. _Planungsrunde v4.5, 20.07.2026._