diff --git a/STATUS.md b/STATUS.md
index d89ab3f..4301d67 100644
--- a/STATUS.md
+++ b/STATUS.md
@@ -86,7 +86,7 @@ Bedeutung der Meilensteine: siehe [roadmap.md](roadmap.md).
 
 | Design | Gate | Title |
 |---|---|---|
-| [2026-08-21-cve-remediation](docs/design/2026-08-21-cve-remediation.md) | gate-2 | Design: Den CVE-Bestand abarbeiten (#0051) |
+| [2026-08-21-cve-remediation](docs/design/2026-08-21-cve-remediation.md) | gate-4 | Design: Den CVE-Bestand abarbeiten (#0051) |
 
 ## ADRs (27)
 
diff --git a/docs/design/2026-08-21-cve-remediation.md b/docs/design/2026-08-21-cve-remediation.md
index 92a39ee..2e8d583 100644
--- a/docs/design/2026-08-21-cve-remediation.md
+++ b/docs/design/2026-08-21-cve-remediation.md
@@ -1,6 +1,6 @@
 ---
 type: design
-status: gate-2
+status: gate-4
 date: 2026-08-21
 size: L
 related:
@@ -282,3 +282,101 @@ alle Nutzer müssen sich neu anmelden.
 - Die übrigen 18 laufenden Images aus Haufen A.
 
 > **STOP — Freigabe für Gate 2.**
+
+> **Gate 2 freigegeben durch sorb, 2026-08-21**, samt Freigabe für **beide
+> Stufen** (2026.5.6 und 2026.8.0).
+
+## Gate 3 + 4 — Program Design und Slices
+
+**Zusammengelegt, mit Begründung:** Gate 3 verlangt Dateiorte, Signaturen und
+Aufrufwege. Hier gibt es eine Datei, eine Zeile und keine Signaturen — die
+Substanz dieses Vorhabens liegt in den Prüfpunkten und im Rückweg, also in
+Gate 4. Beides getrennt aufzuschreiben erzeugte zwei halbleere Abschnitte.
+
+### Dateien
+
+| Pfad | Änderung |
+|---|---|
+| `gitops/apps/authentik/authentik.yaml` Z. 11 | `version: "2026.2.3"` → `2026.5.6` → `2026.8.0` |
+| dieselbe Datei, `spec.upgrade.remediation` | `retries: 3` → `0` für die Dauer des Sprungs, danach zurück |
+
+Sonst nichts. Keine Werte, keine Blueprints, kein Postgres.
+
+### ⚠️ Der Fund, der die Reihenfolge bestimmt: Flux würde selbsttätig zurückrollen
+
+Der HelmRelease trägt `upgrade.remediation.retries: 3` **ohne** `strategy`. Die
+Flux-CRD sagt dazu wörtlich:
+
+```
+strategy:              Defaults to 'rollback'
+retries:               Remediation, using 'Strategy', is performed between each attempt
+remediateLastFailure:  Defaults to 'false' unless 'Retries' is greater than 0
+```
+
+Mit `retries: 3` ist damit **auch die Behebung des letzten Fehlschlags scharf**.
+Ein misslingendes Upgrade würde bis zu viermal auf **2026.2.3 zurückgerollt** —
+gegen eine Datenbank, die Django bereits nach vorne migriert hat. Das ist genau
+der Zustand `migration inconsistency`, vor dem die Anleitung warnt, und er würde
+**von unserer eigenen Konfiguration ausgelöst**.
+
+Für ein Upgrade ohne Datenbank-Migration ist diese Einstellung richtig. Für
+dieses ist sie gefährlich, und deshalb steht ihre Entschärfung **vor** der
+Fassungsänderung, in einem eigenen Commit.
+
+### Was die Prüfung zusichert
+
+Je Stufe, in dieser Reihenfolge — die letzte Zeile ist die einzige, die zählt,
+wenn eine der vorherigen täuscht:
+
+1. Worker-Protokoll: Migrationen gelaufen, **kein** `migration inconsistency`.
+2. `server` und `worker` bereit, beide auf der Zielfassung.
+3. `/-/health/ready/` antwortet 200.
+4. Blueprints angewandt, Flows und Provider unverändert vorhanden.
+5. **Eine echte Anmeldung durch die ganze Kette Element → MAS → Authentik.**
+6. Nach dem nächsten Scan-Durchlauf: Authentik-Image von 27 auf 5 CRITICAL.
+
+⚠️ Punkt 3 allein genügt **nicht**. Ein Health-Endpunkt sagt, dass der Prozess
+lebt — nicht, dass ein Nutzer hineinkommt. Genau diese Verwechslung hat heute
+Vormittag Stunden gekostet.
+
+### Slices
+
+**Slice 0 — die selbsttätige Rückrollung entschärfen.** `retries: 3` → `0`.
+Kein Verhaltensunterschied im Normalbetrieb; wirkt nur im Fehlerfall. Verify:
+`kubectl get helmrelease -n authentik authentik -o jsonpath='{.spec.upgrade.remediation.retries}'` = `0`.
+
+**Slice 1 — Sicherung von Hand.** `kubectl create job --from=cronjob/authentik-backup`.
+Verify: Job erfolgreich, Archivgröße im Protokoll plausibel (~166 MB).
+⚠️ Ohne diesen Schritt beginnt Slice 2 nicht.
+
+**Slice 2 — 2026.2.3 → 2026.5.6.** Fassungszeile, Commit, Push; Flux zieht
+binnen einer Minute (`authentik-apps`, Intervall 1m). Danach Prüfpunkte 1–6.
+
+**Slice 3 — 2026.5.6 → 2026.8.0.** Dieselben Schritte. Erst nach vollständig
+grünem Slice 2, nicht parallel.
+
+**Slice 4 — `retries` auf `3` zurück.** Der Normalbetrieb soll die Behebung
+wieder haben; sie war nur für die Migrationsfenster falsch.
+
+### Grenzen — DO NOT CHANGE
+
+- `spec.values` und `valuesFrom` des HelmRelease — keine Konfigurationsänderung
+  im selben Eingriff, sonst ist eine Störung nicht zuzuordnen.
+- `authentik-blueprints.yaml`, `postgresql`, `authentik-backup.yaml`.
+- Alles außerhalb des `authentik`-Namensraums.
+
+### Wackeligste Annahmen
+
+1. ⚠️ **Dass die Migrationen von 2026.2 auf 2026.5 durchlaufen.** Belegbar erst
+   im Vollzug. Deshalb Slice 1 vor Slice 2 und deshalb `retries: 0`.
+2. **Dass die Blueprints unverändert greifen.** Sie referenzieren Stufen über
+   `!Find`; verschwindet eine Stufe upstream, schlägt das Blueprint fehl statt
+   still zu wirken — das ist die gutartige Ausfallart, aber Prüfpunkt 4 muss sie
+   sehen.
+3. **Dass 2026.5.6 wirklich die letzte 2026.5 ist.** Aus dem Chart-Index
+   gelesen, nicht geraten — sollte zwischen Plan und Vollzug eine 2026.5.7
+   erscheinen, ist sie zu nehmen, weil die Anleitung „latest minor" verlangt.
+4. **Dass der Scan-Nachweis (Punkt 6) am selben Tag kommt.** Die Runde läuft
+   alle 24 h; der Beleg kann bis zum Folgetag dauern. Das ist kein Fehlschlag.
+
+> **STOP — Freigabe für Gate 3+4.**