Kein Löschen von Akten, Hochstufen bei eigener Stufe gedeckelt

Zwei Festlegungen, beide in docs/13-entscheidungen.md begründet.

case.delete ist gestrichen. Der Lebenszyklus kennt ARCHIVED und SEALED, und
eine Akte mit Verlaufseinträgen liesse sich ohnehin nicht hart löschen, weil
CaseEntry nach Regel 2 unlöschbar ist und der Fremdschlüssel das Kaskadieren
blockiert. Das ist die konsequente Fortsetzung von Regel 2 eine Ebene höher.

Niemand klassifiziert eine Akte höher als die eigene Freigabestufe. Sonst
entstehen Akten, die ihr Urheber nicht mehr sehen kann, und die Frage "wer
konnte das lesen" wird im Nachhinein schwer beantwortbar.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

TASKS.md

@@ -46,8 +46,8 @@ Das ist der schwierigste Teil. Wenn er steht, ist der Rest Formularbau.
 - [ ] Vermerk anlegen, optimistisch, mit clientseitiger UUIDv7
 - [ ] Statusübergänge mit Rechteprüfung und automatischem Systemeintrag
 - [ ] Schreibgrenzen nach `docs/03-auth-und-rechte.md`: keine Akte über der eigenen Stufe
-      anlegen, Ändern und Löschen nur mit Lesezugriff, Klassifizierung nachträglich änderbar
+      anlegen, Ändern nur mit Lesezugriff, Klassifizierung nachträglich änderbar bis zur
-      bis zur eigenen Stufe
+      eigenen Stufe. Kein Löschen von Akten, nur `ARCHIVED` und `SEALED`
 - [ ] Umklassifizierung erzeugt `SYSTEM`-Eintrag und `AuditLog` mit alter und neuer Stufe
 - [ ] Negativtests dazu: Stufe 2 kann keine Stufe-4-Akte anlegen, nicht ändern, nicht
       hochstufen, auch nicht über einen direkten Aufruf der Server Action

docs/03-auth-und-rechte.md

@@ -38,7 +38,7 @@ einem prozesslokalen LRU-Cache (60 s TTL) gehalten. Der Cache wird bei `pg_notif
 Rechte-Enum:
 
 ```
-case.read case.create case.edit case.close case.reopen case.delete
+case.read case.create case.edit case.close case.reopen
 case.edit_closed          # Änderungen an abgeschlossenen Fällen
 entry.create entry.correct
 entry.edit_own            # eigene Einträge nachträglich ändern

docs/13-entscheidungen.md

@@ -133,6 +133,29 @@ Das ist kein theoretisches Problem gewesen: die Testläufe der Phase 1 hatten in
 Entwicklungsdatenbank 70 erfundene Rollen, 112 Nutzer und 40 Akten hinterlassen, was die
 Rollenverwaltung unbrauchbar machte.
 
+## Fallakten werden nicht gelöscht
+
+`03-auth-und-rechte.md` führte ein Recht `case.delete`, der Lebenszyklus in
+`05-akten-und-vorlagen.md` kennt aber kein Löschen, nur `ARCHIVED` und `SEALED`. Dazu kommt
+eine technische Sperre: eine Akte mit Verlaufseinträgen lässt sich gar nicht hart löschen,
+weil `CaseEntry` nach harter Regel 2 unlöschbar ist und der Fremdschlüssel das Kaskadieren
+blockiert.
+
+Aufgelöst zugunsten des Lebenszyklus: **`case.delete` ist gestrichen.** Eine Akte, die weg
+soll, wird archiviert (schreibgeschützt) oder versiegelt (nur Stufe 5 und Admin). Nichts
+verschwindet je aus einer Akte. Das ist die konsequente Fortsetzung von Regel 2 auf die Ebene
+darüber und passt zu einer Abteilung, die Korruption aufdeckt.
+
+## Hochstufen ist bei der eigenen Stufe gedeckelt
+
+Niemand klassifiziert eine Akte höher, als seine eigene Freigabestufe reicht — auch nicht,
+um einen Fund zu schützen. Wer Stufe 3 hat, stuft höchstens auf 3 ein; für mehr muss jemand
+mit entsprechender Stufe ran.
+
+Die Alternative wäre gewesen, das Hochstufen zu erlauben und den Zugriff dabei zu verlieren.
+Das erzeugt aber Akten, die ihr Urheber nicht mehr sehen kann, und macht die Frage „wer
+konnte das lesen" im Nachhinein schwer beantwortbar.
+
 ## Prisma 7
 
 Die Dokumente nennen nur „Prisma + PostgreSQL 16". Eingesetzt wird Prisma 7, die

web/lib/auth/permissions.ts

@@ -9,7 +9,6 @@ export const PERMISSIONS = [
   'case.edit',
   'case.close',
   'case.reopen',
-  'case.delete',
   'case.edit_closed',
   'entry.create',
   'entry.correct',