diff --git a/docs/issues/0088-gitops-56-networkpolicy-ausgehender-verkehr-ist-unbesch.md b/docs/issues/0088-gitops-56-networkpolicy-ausgehender-verkehr-ist-unbesch.md
index 8695f40..6ffa820 100644
--- a/docs/issues/0088-gitops-56-networkpolicy-ausgehender-verkehr-ist-unbesch.md
+++ b/docs/issues/0088-gitops-56-networkpolicy-ausgehender-verkehr-ist-unbesch.md
@@ -33,3 +33,57 @@ Besonders relevant hier, weil wir **fremden Code ausführen**: Synapse-Module, C
 NetworkPolicies sind additiv und einzeln löschbar. Der Not-Aus ist das Entfernen der Default-Deny-Regel.
 
 *Gefunden am 2026-08-06 bei einer Bestandsaufnahme der Sicherheitslage.*
+
+## Schritt 1 erledigt 2026-08-19 — Bestandsaufnahme, und ein Beinahe-Fehler
+
+### Vorfrage zuerst: werden NetworkPolicies hier überhaupt durchgesetzt?
+
+**Ja, belegt.** In k3s laufen Flannel und der Policy-Controller *im k3s-Prozess*, nicht
+als Pods — ihre Abwesenheit in `kube-system` beweist also nichts. Gemessen statt
+gefolgert, mit Gegenprobe:
+
+| Von | nach `matrix-stack-postgres:5432` | Erwartung laut `allow-ingress-postgres` |
+|---|---|---|
+| `synapse-main` (matrix) | **verbunden** | erlaubt ✓ — beweist zugleich, dass dort etwas lauscht |
+| `authentik-server` (authentik) | **abgewiesen** | nicht erlaubt ✓ |
+
+Damit ist die bestehende Ingress-Absicherung echter Schutz — und Egress-Regeln werden
+echte Wirkung haben, im Guten wie im Schlechten.
+
+### Cluster-Eckdaten
+
+Pod-CIDR `10.42.0.0/24` (ein Knoten), Service-CIDR `10.43.0.0/16`, kube-dns
+`10.43.0.10`, API `10.43.0.1`. Pods: matrix 15, authentik 3, monitoring 2.
+
+### ⚠️ Der naheliegende erste Schritt wäre falsch gewesen
+
+Das übliche Muster lautet: Egress auf `0.0.0.0/0` freigeben, aber **RFC1918 und den
+Metadaten-Dienst ausnehmen**. Hier hätte das **zwei Dinge zerrissen**, beide über
+`10.0.0.3` (CFGMON im privaten Hetzner-Netz):
+
+1. **Die gesamte Überwachung.** Alloy schreibt nach `http://10.0.0.3:9090/api/v1/write`
+   und `http://10.0.0.3:3100/loki/api/v1/push` (`apps/monitoring/alloy-config.yaml`).
+   Ein RFC1918-Block hätte Metriken *und* Logs abgeschnitten — und zwar still, denn wer
+   meldet den Ausfall des Meldewegs?
+2. **Die TURN-Rotation.** Der CronJob erreicht Gitea über `hostAliases: 10.0.0.3 →
+   rohana.axion1337.de`, weil der öffentliche Weg unzuverlässig war (#0076). Ohne
+   privaten Egress kein Rotations-Push — genau die Kette, die wir am 2026-08-18 erst
+   wieder in Gang gebracht haben.
+
+**Nebenbefund, der #0008 endgültig schließt:** Dass der Cluster Prometheus und Loki über
+`10.0.0.3` erreicht, ist der harte Beleg dafür, dass 9090/3100 **öffentlich nicht
+gebraucht werden**. Die dortige Schlussfolgerung („Weg A ist gegenstandslos") steht damit
+nicht mehr nur auf der Abwesenheit einer Firewall-Regel.
+
+### Vorschlag für Schritt 2
+
+Nicht RFC1918 sperren. Der risikoarme, trotzdem wirksame erste Schnitt ist der
+**Metadaten-Dienst** (`169.254.0.0/16`, darin `169.254.169.254`): der klassische Weg, aus
+einem übernommenen Pod Instanz-Informationen zu ziehen. Kein Dienst hier braucht ihn.
+
+Je Namespace also eine Egress-Policy, die freigibt: DNS nach kube-system, das Cluster
+(`10.42.0.0/16`, `10.43.0.0/16`), und `0.0.0.0/0` **mit `except: 169.254.0.0/16`**.
+Föderation, ACME, SMTP, Registry und der private Weg zu `10.0.0.3` bleiben offen — der
+schwierige Teil aus Punkt 4 des Issues wird damit gar nicht erst angefasst.
+
+Rollback bleibt das Löschen der einen Policy je Namespace.