#0103 abgeschlossen: der gruppenlose Zustand ist jetzt erkennbar

Aufraeumteil durch sorb erledigt (wiki-zugang geloescht, die vermutete tote App
gab es nicht). Letztes Abnahmekriterium umgesetzt: taeglicher CronJob zaehlt
Wiki-Nutzer ohne Gruppe und schreibt das Ergebnis nach Loki.

Beide Zweige geprueft - der Warn-Zweig laeuft nur, wenn etwas kaputt ist, also
genau dann, wenn er funktionieren muss.

Nebenfund mit Reichweite ueber dieses Issue hinaus: Die NetworkPolicy-Regeln fuer
einen neu erzeugten Pod sind beim Containerstart noch nicht programmiert. Im
selben Pod gemessen - sofort abgewiesen, nach 20 s erfolgreich. Betrifft
moeglicherweise auch wikijs-backup, synapse-backup und restore-drill.

STATUS.md

@@ -2,13 +2,13 @@
 
 <!-- Generated by scripts/gen_status.py — do not edit. -->
 
-## Issues (55 open, 44 closed)
+## Issues (54 open, 45 closed)
 
-Verteilung: M1 9 · M2 16 · M3 4 · M4 11 · M5 15
+Verteilung: M1 8 · M2 16 · M3 4 · M4 11 · M5 15
 
 Bedeutung der Meilensteine: siehe [roadmap.md](roadmap.md).
 
-### M1 (9)
+### M1 (8)
 
 | Issue | Priorität | Status | Title |
 |---|---|---|---|
@@ -18,7 +18,6 @@ Bedeutung der Meilensteine: siehe [roadmap.md](roadmap.md).
 | [0078](docs/issues/0078-gitops-45-cve-meldeweg-v2-metriken-grafana-dashboard-al.md) | medium | open | CVE-Meldeweg v2: Metriken, Grafana-Dashboard, Alerts in eigenen Matrix-Raum |
 | [0083](docs/issues/0083-gitops-50-monitoring-deploy-geaenderte-configs-greifen.md) | medium | open | Monitoring-Deploy: geaenderte Configs greifen nicht ohne --force-recreate (Inode-Falle bei Einzeldatei-Mounts) |
 | [0088](docs/issues/0088-gitops-56-networkpolicy-ausgehender-verkehr-ist-unbesch.md) | medium | open | NetworkPolicy: ausgehender Verkehr ist unbeschränkt (13 Ingress-Regeln, 1 Egress) |
-| [0103](docs/issues/0103-wiki-zugang-ohne-gruppe-endet-stumm.md) | medium | open | Wiki: Anmeldung ohne Gruppe endet stumm — `wiki-anwender` hat null Mitglieder |
 | [0004](docs/issues/0004-overmind-02-e1000e-nic-hang-beobachtung-nach.md) | low | waiting | OVERMIND-02: e1000e-NIC-Hang — Beobachtung nach EEE-Fix + Firmware-Update |
 | [0072](docs/issues/0072-gitops-34-dsgvo-datenschutz-compliance-konkretisieren.md) | low | open | DSGVO/Datenschutz-Compliance konkretisieren |
 

docs/issues/0103-wiki-zugang-ohne-gruppe-endet-stumm.md

@@ -1,7 +1,7 @@
 ---
 type: issue
 id: "0103"
-status: open
+status: done
 created: 2026-08-18
 milestone: M1
 priority: medium
@@ -178,3 +178,64 @@ 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.
+
+## Abgeschlossen 2026-08-20
+
+### Aufräumteil erledigt
+
+Entscheidung und Ausführung sorb: Die Gruppe `wiki-zugang` ist gelöscht, die vermutete
+tote Authentik-Anwendung `wiki` existierte nicht. Der offene Punkt aus dem Nachtrag vom
+2026-08-19 entfällt damit.
+
+### Das letzte Abnahmekriterium ist erfüllt
+
+> *Der Fall „angemeldet, aber ohne Gruppe" ist erkennbar: mindestens eine Logzeile oder
+> ein Zähler, damit der nächste Fall nicht wieder erst auffällt, wenn sich jemand
+> beschwert.*
+
+Neuer CronJob `wikijs-gruppenpruefung` (`gitops:apps/production/wikijs-gruppenpruefung.yaml`,
+täglich 06:15). Er zählt Wiki-Nutzer ohne Gruppenmitgliedschaft und schreibt das Ergebnis
+nach stdout, von wo Alloy es nach Loki trägt. Suchbegriff für Abfrage oder Panel:
+**`Wiki-Nutzer ohne Gruppe`**.
+
+Bewusst eine tägliche Stichprobe auf der Datenbank statt einer Instrumentierung des
+Logins: Wiki.js meldet diesen Zustand nirgends, ein Patch am Anmeldeweg wäre dafür
+unverhältnismäßig, und ein Tag Verzug ist hinnehmbar — vorher lag der Fall tagelang
+unbemerkt.
+
+**Beide Zweige geprüft, nicht nur der gute:** Der Warn-Zweig läuft nur, wenn etwas kaputt
+ist, also genau dann, wenn er funktionieren muss. Mit einer rein lesenden Simulation
+gegen die laufende Datenbank getestet — er nennt die Betroffenen mit Id und Adresse und
+den Behebungsweg. Der gute Fall meldet `OK: kein Wiki-Nutzer ohne Gruppe (4 geprueft)`.
+
+### Nebenfund: NetworkPolicy-Wettlauf bei kurzlebigen Pods
+
+Der erste echte Lauf scheiterte mit `Connection refused` — obwohl Service, Endpunkt,
+Portname, Pod-Marken und die (eigens ergänzte) Policy-Regel alle korrekt waren.
+
+Im selben Pod nacheinander gemessen:
+
+| Zeitpunkt | Ergebnis |
+|---|---|
+| sofort nach Container-Start | `psql` abgewiesen, roher TCP-Test zu |
+| nach 20 Sekunden | `psql` erfolgreich |
+
+**Die NetworkPolicy-Regeln für einen neu erzeugten Pod sind beim Start des Containers
+noch nicht programmiert.** In diesem Fenster wird der Verkehr abgewiesen. Ein früherer
+`nc`-Test aus einem separaten Pod lief zufällig spät genug, sah sauber aus und hat die
+Diagnose zunächst in die falsche Richtung geschickt — die Lehre ist, den Test im selben
+Pod und zum selben Zeitpunkt zu fahren wie die eigentliche Arbeit.
+
+Der Job wartet jetzt bis zu 60 Sekunden auf Erreichbarkeit. Ohne das scheiterte er jede
+Nacht an einem Wettlauf, und man gewöhnt sich an den roten Job — genau die Abstumpfung,
+die #0104 abgestellt hat.
+
+⚠️ **Dieselbe Klasse kann andere kurzlebige Jobs im Namespace treffen** —
+`wikijs-backup`, `synapse-backup`, `restore-drill`. Nicht geprüft; wenn dort nachts
+sporadische Fehlschläge auftreten, ist das der erste Verdacht.
+
+### Stand
+
+Alle vier Abnahmekriterien erfüllt: Auto-Enrollment aktiv und in der Datenbank
+gegengeprüft (`wiki-anwender` hat Mitglieder), `betrieb/*` unverändert abgeschottet,
+der gruppenlose Zustand ist erkennbar, und @apo kommt herein.