diff --git a/docs/design/2026-08-21-cve-remediation.md b/docs/design/2026-08-21-cve-remediation.md
index 31b712f..92a39ee 100644
--- a/docs/design/2026-08-21-cve-remediation.md
+++ b/docs/design/2026-08-21-cve-remediation.md
@@ -178,3 +178,107 @@ brächte, eine ersparte Änderung. Gehört in das Runbook (Abnahmekriterium 4).
 Zwischen 2026.2 und 2026.8 liegt eine volle Fassungsreihe mit eigenen
 Datenbank-Migrationen; Authentik-Upgrades überspringen Fassungsreihen nicht
 folgenlos. Das ist zu belegen, nicht anzunehmen.
+
+## Gate 2 — Architecture: der Authentik-Sprung
+
+### Recherche-Ergebnis: gestuft ist Pflicht, Handarbeit fällt keine an
+
+Die Anleitung ist ausdrücklich:
+
+> *„**Upgrade sequence**: Upgrades must follow the sequence of major releases;
+> do not skip directly from an older major version to the most recent version."*
+> *„Always upgrade to the latest **minor** version … before upgrading to the next
+> major version."*
+
+Der Weg ist also **2026.2.3 → 2026.5.6 → 2026.8.0**, nicht verhandelbar.
+
+**Beide Fassungen sagen zugleich:** *„This release does not introduce any new
+requirements."* Ihre je eine Bruchstelle wurde gegen unseren Stand geprüft und
+trifft uns **nicht**:
+
+| Bruchstelle | Fassung | Bei uns |
+|---|---|---|
+| `AUTHENTIK_POSTGRESQL__CONN_OPTIONS` abgekündigt | 2026.5 | **nicht gesetzt** — weder im Cluster noch im Repo |
+| Option *„Prevent duplicate devices"* der WebAuthn-Stufe entfällt | 2026.8 | **nicht gesetzt**; unsere Blueprints referenzieren die Stufe nur |
+| Outposts müssen zur Server-Fassung passen | 2026.8 | **0 Outposts** im Cluster |
+
+### Wo der Gewinn sitzt — und das ändert die Reihenfolge
+
+Alle drei Images gescannt, das laufende aus den Metriken:
+
+| Fassung | CRITICAL | HIGH |
+|---|---|---|
+| 2026.2.3 (läuft) | 27 | 477 |
+| **2026.5.6** | **5** | **92** |
+| 2026.8.0 | 5 | 21 |
+
+⚠️ **Die Pflicht-Zwischenstufe trägt den gesamten CRITICAL-Gewinn** (−22) und
+385 der 456 HIGH. Stufe 2 liefert nur noch 71 HIGH. Die Zwischenstufe ist also
+kein Hindernis auf dem Weg zum Ziel, sondern **der Großteil des Ziels**.
+
+Das ist die Grundlage dafür, die beiden Stufen **trennen** zu dürfen: Wenn
+Stufe 2 warten muss, ist trotzdem alles Kritische erledigt.
+
+### Randbedingungen
+
+- ⚠️ **Sprengweite: der Anmeldeweg der gesamten Plattform.** MAS bezieht seine
+  Identitäten von Authentik; fällt Authentik aus, kommt auch in Matrix niemand
+  mehr hinein. Das ist kein Dienst unter vielen.
+- ⚠️ **Der Rückweg ist eine Datenbank-Wiederherstellung, kein Downgrade.** Die
+  Anleitung sagt es wörtlich: *„Make sure to back up your database in case you
+  need to revert an upgrade"* und *„If you see this entry, revert to your
+  database backup."* Sind die Migrationen einmal gelaufen, hilft ein
+  Zurücksetzen der Fassung allein nicht.
+- **Die Sicherung ist belegt**, nicht vermutet: nächtlich um 01:15 (drei Erfolge
+  in Folge, zuletzt 166,82 MB) und **im Restore geprobt** — #0030, 325.149
+  zurückgespielte Zeilen.
+- **Ausgerollt wird über Flux**, die Chart-Fassung steht in `gitops`. Der Rückweg
+  ist damit ein `git revert` **plus** Anstoßen der Quelle — die Lehre aus
+  #0088, Slice 1: ein Revert allein wirkt nicht.
+- ⚠️ **2026.8.0 ist drei Tage alt** (erschienen 2026-08-18). Die neueste Fassung
+  des Anmeldewegs am dritten Tag zu fahren, ist eine Entscheidung und keine
+  Selbstverständlichkeit.
+
+### Der Plan
+
+**Stufe 0 — unmittelbar davor.** Sicherung von Hand auslösen, nicht auf die
+nächtliche vertrauen: Zwischen 01:15 und dem Eingriff liegen Stunden, in denen
+Anmeldungen und Sitzungen entstanden sind. Erfolg am Protokoll belegen.
+
+**Stufe 1 — 2026.2.3 → 2026.5.6.** Ein Commit in `gitops`
+(`spec.chart.spec.version`), Flux rollt aus. Danach in dieser Reihenfolge prüfen:
+
+1. Migrationen im Worker-Protokoll gelaufen, **ohne** `migration inconsistency`.
+2. `server` und `worker` bereit, beide auf `2026.5.6`.
+3. `https://auth.axion1337.chat/-/health/ready/` antwortet 200.
+4. **Eine echte Anmeldung durch die ganze Kette** — Element → MAS → Authentik.
+   Nicht der Health-Endpunkt, sondern der Weg, den ein Nutzer geht.
+5. Blueprints vom Worker angewandt (Flows und Provider unverändert vorhanden).
+6. Nach dem nächsten Scan-Durchlauf: `trivy_vuln_info` für das Authentik-Image
+   von 27 auf **5** CRITICAL gefallen — der Nachweis am Dashboard, nicht am Tag.
+
+**Stufe 2 — 2026.5.6 → 2026.8.0.** Gleiche Schritte, gleiche Prüfpunkte.
+
+⚠️ **Empfehlung zur Trennung:** Stufe 1 jetzt, Stufe 2 nach einer Ruhezeit oder
+sobald 2026.8 eine Nachfolgefassung hat. Begründung ist gemessen, nicht
+vorsichtshalber: Stufe 1 bringt **alle 22 CRITICAL**, Stufe 2 nur noch HIGH —
+und der Anmeldeweg der Plattform ist der falsche Ort für eine drei Tage alte
+Fassung. Sollte 2026.8 aus anderen Gründen dringend sein, ist das eine
+Entscheidung mit bekanntem Preis, keine Überraschung.
+
+**Rückweg je Stufe:** `git revert` der Fassungsänderung **plus** Anstoßen der
+GitRepository-Quelle; wenn die Migrationen bereits liefen, zusätzlich die
+Datenbank aus der Sicherung von Stufe 0 zurückspielen (Stufe 3 in
+`notfallhandbuch/notfall.sh`). ⚠️ **In diesem Fall gehen Anmeldungen und
+Sitzungen seit der Sicherung verloren** — nicht die Konten, aber die Sitzungen;
+alle Nutzer müssen sich neu anmelden.
+
+### Nicht Teil dieses Sprungs
+
+- **`postgres:17.9-bookworm`** — Authentiks eigene Datenbank, mit 22 CRITICAL
+  der zweitgrößte Posten im Bestand, davon nur 3 behebbar. Ein Datenbank-Update
+  ist ein eigenes Risiko mit eigenem Rückweg und gehört nicht in denselben
+  Eingriff wie das Anwendungs-Update.
+- Die übrigen 18 laufenden Images aus Haufen A.
+
+> **STOP — Freigabe für Gate 2.**