--- type: aar status: open date: 2026-08-09 related: [] --- # AAR — Refinement, Betrieb voranbringen, Git-Historie anonymisiert **Datum:** 2026-08-09 · **Host/Stack:** git.lab, Gitea, K3s-Cluster (Authentik, Synapse, Element Web) · **Auftrag:** Backlog-Refinement, danach gezielt den Betrieb von ThreadNet voranbringen statt weiter Befunde anzuhäufen ## 1. Ergebnis **Live und verifiziert:** - MFA-Pflicht für die Gruppe `authentik Admins` — Stage, Bindung und Gruppenzuordnung in der Datenbank geprüft, Standard-Login für alle anderen unverändert - `matrix-recovery-flow`-Blueprint läuft erfolgreich — `SELECT … WHERE status <> 'successful'` liefert 0 Zeilen - Web-Client zeigt einen Fehlerbericht-Weg, der **lokal** bleibt (`bug_report_endpoint_url: "local"`) — vorher unbemerkt an element.io - 251 Commits über vier Repos auf 12:00-UTC-Zeitstempel umgeschrieben, Force- gepusht, Mirrors und Flux verifiziert synchron - Stillstandsprüfung läuft täglich per Zeitplan, fand beim ersten Lauf zwei vorher unbekannte Repos ohne Push-Mirror - `game-operating` gespiegelt und secret-frei verifiziert (Coolify- Magievariablen, keine echten Werte) - Call-Widget stempelt sich mit Paketversion + Commit statt „dev" - `@concierge`-Bot für Gäste-Einladungen gebaut und deployt **Bewusst nicht live:** - Desktop-Client hat den lokalen Fehlerbericht-Weg erst mit dem nächsten Build (Config geändert, kein Rebuild ausgelöst) - `@concierge` läuft nicht — wartet auf Matrix-Konto, Authentik-Token, Einladungsraum, zwei Gruppen, Secret (alles Zugangsdaten, sorbs Seite) - Authentik-Teil der Stillstandsprüfung übersprungen ohne Token (Fehlen wird ausgewiesen, nicht verschwiegen) - `gameserver` weiterhin ohne Mirror — zwei Repos gleichen Namens mit unterschiedlichem Stand, Klärung vor jedem Eingriff nötig ## 2. Befunde | # | Befund | Schwere | Status | |---|---|---|---| | 1 | `matrix-recovery-flow`-Blueprint scheiterte seit Tagen bei jedem Lauf, während Flux grün meldete | HIGH | behoben | | 2 | Ursache des Blueprint-Fehlers war zweifach verdeckt: `!KeyOf` löst beim Fehlschlag gegen ein leeres Blueprint auf und wirft dieselbe Ausnahme erneut — die echte Meldung ging im eigenen Logging unter | HIGH | behoben, `!Find` statt `!KeyOf` | | 3 | Web-Client sendete Fehlerberichte an `rageshakes.element.io` — die Desktop-Bereinigung vom 2026-08-01 hatte den Web-Build nie erreicht, weil der beim Bauen Elements eigene `develop/config.json` kopiert | HIGH | behoben, `"local"` gesetzt | | 4 | `game-operating` und `gameserver` ohne Push-Mirror; bei `gameserver` liegt auf Gitea ein anderer Stand als auf git.lab | MEDIUM | `game-operating` behoben, `gameserver` offen (management#32) | | 5 | Nach dem Privat-Stellen von `game-operating` auf Gitea übersprang die Stillstandsprüfung den Mirror-Abgleich klaglos, statt es als Befund zu werten | MEDIUM | behoben | | 6 | Header-Hilfsfunktion baute `Authorization: token: ` (doppelter Doppelpunkt) — still ungültig, hätte beim Eintragen des Authentik-Tokens wie ein falscher Token ausgesehen | MEDIUM | behoben, vor dem ersten echten Einsatz gefunden | | 7 | Gitops-Leitfaden 04 nannte 7 Themes mit teils erfundenen Namen (`Gruvbox Dark`, `Wal`); tatsächlich 17 | LOW | behoben | | 8 | threadnet-call-Doku beschrieb einen manuellen npm-Publish, der seit 2026-08-06 automatisiert läuft | LOW | behoben | | 9 | `overmind.md` nannte „sechs gespiegelte Repos" — nach dem Mirror für `game-operating` sind es sieben | LOW | behoben | | 10 | Neu angelegter Deployment-Guide (`@concierge`) fehlte im eigenen Index | LOW | behoben | | 11 | Tag-Push (Force, für die Historien-Anonymisierung) löste in ThreadNet-Web drei Release-Pipelines neu aus; nur weil die geschützten Registry-Variablen im Zeitfenster fehlten, wurde `v0.4.0` nicht mit heutigem Code überschrieben | HIGH | Sperre nachgezogen (ThreadNet-Web#14), Ursache war Zufall, nicht Schutz | ## 3. Verdachtsfälle mit Entwarnung - **`game-operating` öffentlich auf Gitea** — Secret-Scan über alle fünf öffentlich gewordenen Dateien: kein echter Credential-Wert, ausschließlich Coolify-Magievariablen und ein leeres `api_key`-Feld. Erste Prüfung lieferte fälschlich „sauber", weil der Rohpfad falsch war (5×11-Byte-„Not found"- Antworten) — erst nach Gegenprobe der Dateigrößen als Fehlmessung erkannt und mit korrektem Pfad wiederholt. - **Meine erste Diagnose zu #60** („Passwort-Wiederherstellung vermutlich tot") — falsch. Der Flow hatte durchgehend alle sechs Bindungen, der Blueprint- Fehler betraf nur künftige Blueprint-Läufe, nicht die längst angelegten Objekte. ## 4. Was die Befunde ermöglicht hat - **Direktes Auslesen der Authentik-Datenbank statt Vertrauen auf den Flux-Status.** Blueprint-Fehler #1/#2 waren nur so sichtbar — Flux, die ConfigMap und der Cluster-Zustand insgesamt meldeten durchgehend grün. - **`ak apply_blueprint` von Hand** hat den durch das eigene Logging verdeckten Fehler #2 erst zugänglich gemacht — der reguläre Weg (Worker-Log) zeigte nur die Folgeausnahme. - **Den Ist-Zustand vor einer Änderung auslesen statt der Issue-Beschreibung zu glauben** hat Befund #3 aufgedeckt — die Annahme im Issue betraf nur den Desktop-Client, `config.json` auf dem Web-Server sagte etwas anderes. - **Die Stillstandsprüfung selbst** (aus der gestrigen Retro gebaut) hat Befund #4 im ersten Lauf gefunden — eine dynamische Projektliste statt einer im Code gepflegten hat zwei Repos zutage gebracht, die niemand auf dem Schirm hatte. - **Content-Length-Gegenprobe nach dem Secret-Scan** hat die eigene Fehlmessung beim `game-operating`-Check aufgedeckt, bevor sie als „sauber" ins Protokoll ging. - **Baumvergleich (Tree-Hash) vor und nach jedem Rewrite-Schritt** — 251 von 251 Paaren über Tree *und* Commit-Nachricht verifiziert, keine Annahme. ## 5. Offen - **`@concierge` aktivieren** — fünf Zugangsdaten-Schritte, Checkliste in gitops#48 - **`gameserver`-Mirror** — Standklärung nötig, management#32 - **Stillstandsprüfung Authentik-Teil** — `AUTHENTIK_URL`/`AUTHENTIK_TOKEN`, management#31, bewusst aufgeschoben (sorb, 2026-08-09) - **Rageshake vs. Zammad** — durch den lokalen Fix entschärft, aber nicht entschieden, ThreadNet-Web#9 - **`report_event.admin_message_md`** nicht gesetzt — wer Inhalte meldet, sieht keinen Kontaktweg; braucht nur eine Angabe (welcher Raum/Kontakt) von sorb, dann eine Zeile Config - **Desktop-Build** für den lokalen Fehlerbericht-Weg noch ausständig - **ADR-0009** (Commit-Konventionen/Anonymisierung) nachträglich verfasst — Lehre aus der Retro, in `decisions/` dokumentiert