diff --git a/docs/issues/0074-gitops-39-cleanup-checkliste-laufend.md b/docs/issues/0074-gitops-39-cleanup-checkliste-laufend.md
index 3206d43..da5942a 100644
--- a/docs/issues/0074-gitops-39-cleanup-checkliste-laufend.md
+++ b/docs/issues/0074-gitops-39-cleanup-checkliste-laufend.md
@@ -63,3 +63,21 @@ Einschränkung galt für dieses Konto also gar nicht.
 Damit sind von der Liste zwei Punkte erledigt (`@bojeledoggo` deaktiviert, `Boje`
 gelöscht). Offen bleiben die Testräume aus der Session 2026-07-27/28 und
 `clark`/`lucky`, beide in Synapse weiterhin aktiv.
+
+### `lucky` gesperrt 2026-08-18 (Entscheidung sorb)
+
+`mas-cli manage lock-user lucky` (MAS `locked_at = 2026-08-18 19:57`) plus
+`kill-sessions`: eine OAuth-2.0- und zwei Browser-Sessions beendet, Geräte-Sync
+angestoßen. Anmelden ist damit nicht mehr möglich.
+
+⚠️ **Gesperrt ist nicht deaktiviert.** `deactivated_at` ist leer — `lucky` steht
+jetzt wie `scanner-test`, nicht wie `@bojeledoggo` (dort ist `deactivated_at`
+gesetzt und Synapse führt `deactivated = 1`). Der Unterschied: Sperren ist
+reversibel (`unlock-user`), Deaktivieren räumt Profil, Geräte und Raum-Mitgliedschaften
+ab und ist es nicht.
+
+**Warum nur gesperrt:** Die hier laufende MAS-Version kennt im CLI kein
+`deactivate-user` (`mas-cli manage` bietet nur `lock-user`/`unlock-user`). Volle
+Deaktivierung läuft über die Admin-API bzw. Element Admin und damit über ein
+Admin-Token — das gehört nicht in eine Session. Wenn `lucky` endgültig weg soll,
+ist das ein Klick in Element Admin; das Sperren nimmt bis dahin die Wirkung vorweg.