Schreibgrenzen der Freigabestufe festgehalten

Lesen war geregelt, Schreiben nicht: bisher stand nirgends, dass jemand mit
Stufe 2 keine Stufe-4-Akte anlegen darf. Ohne die Regel erzeugt man Akten, die
man selbst nicht mehr sehen kann, und umgeht die Sichtbarkeitsprüfung.

Festgehalten in docs/03-auth-und-rechte.md, als Aufgaben in Phase 2:
Klassifizierung nie über der eigenen Stufe, Ändern und Löschen nur mit
Lesezugriff, Umklassifizierung mit SYSTEM-Eintrag und AuditLog. Eine
Herabstufung ist der heikelste Vorgang im System — sie macht Inhalte für Leute
sichtbar, die sie vorher nicht sehen durften.

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

TASKS.md

@@ -45,6 +45,12 @@ Das ist der schwierigste Teil. Wenn er steht, ist der Rest Formularbau.
 - [ ] Aktenansicht: Kopfdaten sofort, Verlauf und Chat in eigenen Suspense-Grenzen
 - [ ] 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
+      bis zur eigenen Stufe
+- [ ] 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
 - [ ] Audit-Log für alle schreibenden Aktionen und Lesezugriffe ab Stufe 3
 - [ ] Nachträgliche Änderungen an Verlaufseinträgen nach `docs/05-akten-und-vorlagen.md`:
       `CaseEntryVersion`, Karenzzeit, Pflichtbegründung, `bearbeitet · vN` mit Diff-Historie

docs/03-auth-und-rechte.md

@@ -73,6 +73,39 @@ Kein Zugriff bedeutet:
 - Ist die Stufe als `hiddenBelow` markiert: **404**, die Akte existiert für den Nutzer nicht.
 - Sonst: Eintrag in Listen sichtbar, Titel und Inhalt gesperrt, Detailseite zeigt Sperrhinweis.
 
+## Schreibende Zugriffe und die eigene Stufe
+
+Die Abschnitte oben regeln das Lesen. Fürs Schreiben gilt zusätzlich:
+
+**Niemand legt eine Akte über der eigenen Freigabestufe an.** Wer Stufe 2 hat, legt Akten bis
+Stufe 2 an, nicht bis Stufe 4. Sonst erzeugt man Akten, die man selbst nicht mehr sehen kann,
+und umgeht nebenbei die Sichtbarkeitsregel.
+
+**Ändern und Löschen setzt Lesezugriff voraus.** Was jemand nicht sehen darf, darf er nicht
+anfassen — auch nicht über einen direkten Aufruf der Server Action. Die Prüfung ist dieselbe
+wie beim Lesen (`visibleCaseWhere`), plus das nötige Recht.
+
+**Die Klassifizierung ist nachträglich änderbar**, mit denselben Grenzen:
+
+- die neue Stufe darf die eigene Stufe nicht übersteigen
+- die Akte muss vorher lesbar gewesen sein
+- es braucht das Recht `case.edit`
+- die Änderung erzeugt einen `SYSTEM`-Eintrag im Verlauf **und** einen `AuditLog`-Eintrag mit
+  alter und neuer Stufe. Eine Herabstufung ist der heikelste Vorgang im ganzen System:
+  sie macht Inhalte für Leute sichtbar, die sie vorher nicht sehen durften, und muss deshalb
+  ohne Nachfragen nachvollziehbar sein.
+
+Für Abschnitte und Verlaufseinträge gilt dasselbe eine Ebene tiefer: `minClearance` lässt sich
+nicht über die eigene Stufe heben, und eine Erhöhung wirkt rückwirkend auf alle Versionen
+(siehe `docs/05-akten-und-vorlagen.md`).
+
+**Ausnahmsweiser Zugang** läuft über `CaseParticipant`: wer als Beteiligter eingetragen ist,
+liest die Akte unabhängig von seiner Stufe. Das ist der vorgesehene Weg, jemanden gezielt
+hinzuzuziehen, ohne ihm allgemein eine höhere Stufe zu geben. Beteiligte hinzuzufügen setzt
+`case.edit` voraus und wird protokolliert.
+
+Die Gegenprobe bleibt der `CaseExclusion`: er schlägt jede Stufe und auch den Admin.
+
 ## Umsetzung in Prisma
 
 Die Prüfung wird nie in JavaScript nachgelagert. `lib/access/caseFilter.ts` liefert ein