diff --git a/docs/issues/0008-cfgmon-03-prometheus-remote-write-und-loki.md b/docs/issues/0008-cfgmon-03-prometheus-remote-write-und-loki.md
index 04e118e..5ca4d1a 100644
--- a/docs/issues/0008-cfgmon-03-prometheus-remote-write-und-loki.md
+++ b/docs/issues/0008-cfgmon-03-prometheus-remote-write-und-loki.md
@@ -79,3 +79,35 @@ echter Gruppen-Call.
 Hetzner-Console. Das Skript sagt, *was* von außen erreichbar ist; welche Regeln das
 bewirken und ob sie bewusst so stehen, sagt nur die Console. Erst danach ist das
 Issue erledigt.
+
+## Console-Einblick 2026-08-19 — Matrix-Host gesehen, CFGMON weiterhin nicht
+
+sorb hat die Hetzner-Console gezeigt: **`fw-matrix-cx42`, 15 Regeln, vollständig
+angewandt.** Das ist der **Matrix-Host**, nicht CFGMON — die Frage dieses Issues
+(welche Regel hält 9090/3100 auf CFGMON zu?) ist damit **noch offen**. Gemessen sind
+beide Ports zu; *warum*, weiß weiterhin niemand.
+
+Der Einblick war trotzdem wertvoll, in zwei Richtungen.
+
+**Sauber gelöst:** SSH (2248) und die Kubernetes-API (6443) sind quellbeschränkt auf
+sorbs Anschluss (`178.25.213.70`, `2a02:8108:0:2f::/64`), nicht für alle offen. Das hat
+auch einen Fehler in `pruefe-ports.sh` aufgedeckt: Die Liste führte 2248 schlicht als
+„offen", womit das Skript aus jedem anderen Netz zwei Falschbefunde gemeldet hätte.
+Behoben — beide gelten jetzt als `quellbeschraenkt` und werden berichtet, aber nicht
+gewertet.
+
+**Die Firewall ist deutlich weiter offen als die Plattform.** Von außen gemessen
+antwortet auf diesen Regeln nichts:
+
+| Regel | Befund |
+|---|---|
+| `smtp` TCP **587 eingehend**, Any | **Vermutlich versehentlich.** Der Host verschickt Mail *ausgehend*; eingehende Regeln helfen dabei nicht (Hetzner filtert nur eingehend). Der Deployment-Guide dokumentiert genau dieses Debugging („465 blockiert, 587 geht") — die Regel sieht nach dessen Rest aus. |
+| `mRTC SFU muxed` UDP **30000–65535** | ~35.500 Ports für einen benötigten (30002). |
+| `mRTC SFU TCP` TCP **30000–60000** | ~30.000 Ports für einen benötigten (30001). |
+| `RTC SFU 1` 6789, `RTC SFU 2` 7880, `mRTC Auth` 8080, je Any | nichts lauscht; die Dienste laufen über den Ingress auf 443. |
+
+Kein akutes Risiko — aber eine unnötig breite *erklärte* Angriffsfläche: Sobald dort je
+etwas horcht, ist es sofort weltweit erreichbar, ohne dass jemand eine Regel anfassen
+müsste. Festgehalten in `notfallhandbuch:ports-soll.md`.
+
+**Zum Abschluss dieses Issues fehlt weiterhin:** der Blick auf die **CFGMON**-Firewall.
diff --git a/docs/issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md b/docs/issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md
index 870dd95..e3d3b45 100644
--- a/docs/issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md
+++ b/docs/issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md
@@ -98,3 +98,27 @@ Richtlinie verschärfen** — umgekehrt zerlegt es den Versand unbemerkt.
 - `notfallhandbuch:dns-soll.md` und `pruefe-dns.sh` tragen den neuen Soll-Stand;
   der bisherige Satz „Härtung vorgeschlagen, aber nicht entschieden" wird
   ersetzt.
+
+## Blocker aufgelöst 2026-08-19 — `maintenance-notify` sendet unter `.de`
+
+Die offene Frage („worüber verschickt `maintenance-notify` tatsächlich?") steht in der
+Doku, nicht auf dem Host: `gitops:docs/deployment-guides/07-host-maintenance-notifications.md`,
+Abschnitt Stolpersteine.
+
+> **Absender-Domain ≠ Matrix-Server-Domain.** […] bei axion1337 z.B. Mail unter `.de`,
+> Matrix unter `.chat` — `MAIL_FROM` und der `user`/`from` in `msmtprc` müssen zur
+> tatsächlichen Mail-Domain passen.
+
+Der Versand läuft über **IONOS auf 587/STARTTLS** (465 ist ausgehend blockiert, ebenfalls
+dort dokumentiert). Die `MAIL_FROM="wartung@axion1337.chat"` in `config.example` ist ein
+**Beispiel**, nicht der Betriebsstand.
+
+**Folge für dieses Issue:** Eine Härtung von `axion1337.chat` berührt
+`maintenance-notify` nicht — dessen Absenderdomain `.de` trägt bereits `p=reject`
+(#0006). Damit bleibt als einziger `.chat`-Absender **Authentik** (`gamemaster@`,
+IONOS-SMTP, DKIM über die drei `*.dkim.ionos.com`-CNAMEs gedeckt).
+
+Der Vorschlag im Issue ist damit ohne die befürchtete Nebenwirkung umsetzbar: eigener
+`_dmarc`-TXT statt IONOS-CNAME, zunächst `p=quarantine` mit `rua=`, danach `p=reject`;
+Null-MX und `-all` auf den sieben Service-Namen. Abnahme unverändert: Authentik-Testmail
+und eine Wartungsmeldung müssen **nachweislich** ankommen.
diff --git a/docs/issues/0103-wiki-zugang-ohne-gruppe-endet-stumm.md b/docs/issues/0103-wiki-zugang-ohne-gruppe-endet-stumm.md
index 4f7d97b..11e58f1 100644
--- a/docs/issues/0103-wiki-zugang-ohne-gruppe-endet-stumm.md
+++ b/docs/issues/0103-wiki-zugang-ohne-gruppe-endet-stumm.md
@@ -147,3 +147,34 @@ zugeordnet.
 entschieden. Solange die Punkte oben offen sind, bleibt für diese Konten der stumme
 Fall bestehen — das ist der Grund, warum dieses Issue nicht mit den Freigaben
 erledigt ist.
+
+## Umgesetzt 2026-08-19 — Auto-Enrollment aktiv
+
+Entscheidung sorb, und sie stand schon in **#0049**: normale Authentik-Nutzer lesen die
+Anwenderdoku, Admins sind Admins („Betrieb = Admin"). Das Rollenmodell war umgesetzt,
+der **Weg hinein** nicht — deshalb dieser Fall.
+
+`autoEnrollGroups` der OIDC-Strategy zeigt jetzt auf `wiki-anwender`
+(`gitops:apps/production/wikijs-config.py`, Commit `dfb88a3`). Der Konfig-Job wurde neu
+angestoßen (Job löschen → Flux legt ihn an, wie im Dateikopf beschrieben) und meldet:
+`Auto-Enrollment in wiki-anwender, id 4`.
+
+**In der laufenden Datenbank gegengeprüft**, nicht am Logtext:
+
+```
+OIDC-Strategy  selfRegistration=t  autoEnrollGroups={"v":[4]}    # 4 = wiki-anwender
+local          selfRegistration=f  autoEnrollGroups={"v":[]}     # Break-Glass, unverändert
+```
+
+Admins bleiben Handarbeit in Authentik: Mitgliedschaft in `authentik Admins` kommt über
+den `groups`-Claim und wird von dieser Grundausstattung nicht berührt. `betrieb/*`
+behält sein Default-Deny — die in #0049 end-to-end verifizierte Abschottung gilt
+unverändert, sie greift nur nicht mehr gegen Leute, die gar nicht erst hereingelassen
+wurden.
+
+Der Skript-Teil bricht ab, wenn `wiki-anwender` fehlt, statt in eine leere Gruppe zu
+enrollen — das wäre genau der Fehler, den dieses Issue beschreibt.
+
+**Offen bleibt der Aufräumteil:** die tote Authentik-Anwendung `wiki` ohne Provider und
+die Gruppe `wiki-zugang` (4 Mitglieder), die Rechte an ihr verteilt. Beides fasse ich
+erst auf Zuruf an, weil es Authentik-Konfiguration ist.