management/docs/issues/0027-audit-01-acht-widersprueche-aus-dem-labnet-02.md

type, id, status, created, milestone, priority, area, gitlab_iid, related

type	id	status	created	milestone	priority	area	gitlab_iid	related
issue	0027	open	2026-08-02	M2	medium	infrastructure	27	docs/adr/0008-agenten-sessions-root-aequivalent.md

AUDIT-01: Acht Widersprüche aus dem LABNET-02-Nachlauf (Selbst-Audit CFGMON-Session)

Import aus management#27 (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).

Selbst-Audit der CFGMON-Session (2026-08-02) auf sorbs Bitte: eigene Arbeit gegen CLAUDE.md, ADR-0005 und die Verfahren geprüft. Regel dieses Issues: Widersprüche werden dokumentiert und referenziert, nicht still aufgelöst. Auflösung einzeln oder gesammelt im Struktur-Workshop (#17). Alle Messungen von heute sind als solche gekennzeichnet.

W1 — ADR-0004 (as-built) vs. tatsächliche Split-DNS-Konfiguration

ADR-0004, CFGMON-Zeile: „Split-DNS nur ~lab → 10.58.73.1". Real (seit 2026-08-01 spätabends, auf sorbs Ansage, /etc/wireguard/lab.conf + CFGMON-AAR Nachtrag 2): vier Zonen — ~lab, ~lab.de, ~axion1337.de, ~axionlabs.de. Das ADR beschreibt den As-built-Stand also unvollständig. Brisanz: ~axion1337.de über den Lab-Resolver betrifft auch rohana.axion1337.de (Gitea-Mirror!) — löst der Lab-DNS die Zone anders auf als öffentlich, ändert sich unbemerkt der Pfad zum Mirror. Auflösung: ADR nachführen oder Zonen auf ~lab zurückbauen — Entscheidung sorb.

W2 — dokumentierte Bootstrap-Routen sind seit der Einzäunung nicht reproduzierbar

CFGMON-AAR Nachtrag 2 dokumentiert die CA-Verifikation über ca.axionlabs.de:666 (step-ca, health + roots.pem, Fingerprint-Abgleich). Messung heute von CFGMON: :666 = Timeout (Einzäunung greift, erwartungsgemäß), git.lab:443 = HTTP 302 ✓, ICMP zu 10.58.73.17 = 100 % Verlust. Konsequenzen: (a) Die im AAR beschriebene Verifikationsroute funktioniert nicht mehr — ein künftiger Truststore-Neuaufbau bräuchte eine bewusste Firewall-Ausnahme (ADR-Pflicht laut CLAUDE.md). (b) Erreichbarkeits-Checks von CFGMON müssen per HTTPS statt ping laufen — alle bisherigen Runbook-Gewohnheiten (ping 10.58.73.17) schlagen fehl, obwohl alles gesund ist. Fehldiagnose-Falle für die nächste Session.

W3 — hosts/cfgmon.md widerspricht sich selbst und der Realität

Die Dienste-Tabelle (Zeile 27) listet runner | gitea/act_runner:0.6.1 als laufenden Container — die eigene Historie derselben Datei (CFGMON-11-Abschnitt) meldet ihn als am 2026-07-31 restlos entfernt. „Stand: 2026-07-30" deckt zudem nicht: WireGuard-Tunnel (wg-quick@lab + systemd-Drop-in 10-after-docker.conf), aXionLabs-Root-CA im Truststore, git.lab-Zugang via ~/.netrc. Wenn hosts/ „Bestand + Historie" ist (CLAUDE.md), ist der Bestand-Teil veraltet; wenn er eingefroren sein soll, fehlt die Kennzeichnung. Nicht von mir korrigiert — erst klären, was „Bestand" hier heißen soll.

W4 — Schließung von #16 vs. Inhalt von #16 und CLAUDE.md-Secrets-Regel

Der Schlusskommentar von #16 nennt „die drei hier gesammelten Nacharbeiten (Feinschliff)". Das Issue enthielt fünf Punkte plus einen Korrektur-Kommentar der CFGMON-Session. Still mitgeschlossen wurden: Punkt 4 (Repo-Zuhause für lab.conf, systemd-Drop-in, Root-CA — Reproduzierbarkeit) und Punkt 5 (Schlüsselrotation). Bei Punkt 5 kollidiert die Schließung mit der Secrets-Regel der CLAUDE.md („anzeigen = Exposure = Rotation"): Der aktive WG-Private-Key und beide git.lab-PATs liefen im Klartext durch den Chat bzw. das buffer-Repo. Das buffer-Repo ist vernichtet ✓, aber Chat-/Session-Transkripte existieren weiter. Nach der Regel ist die Rotation nicht optional — auch mein eigener Kommentar in #15 („regulär rotieren") war daran gemessen zu lasch. Auflösung: entweder sorb bestätigt die Schließung ausdrücklich für alle fünf Punkte (dann ist die Secrets-Regel für diesen Fall bewusst ausgesetzt → ADR-Pflicht für die Ausnahme), oder Punkte 4+5 werden als eigenes Issue reaktiviert.

W5 — Secrets-Regel vs. gelebte Bootstrap-Praxis der LABNET-02-Nacht

CLAUDE.md: „Token-/Secret-Werte niemals […] in Dateien echoen; echte Credentials tippt/legt sorb selbst an; Sessions referenzieren sie nur über Dateipfade." Praxis: Die CFGMON-Session (ich) hat beide PATs selbst in ~/.netrc geschrieben und den WG-Private-Key nach /etc/wireguard/ — es gab schlicht keinen anderen Übergabekanal auf einen headless Host. Der Widerspruch ist strukturell, nicht böswillig: Die Regel kennt den Fall „sorb kann die Datei auf dem Zielhost nicht selbst anlegen" nicht. Auflösung: Bootstrap-Klausel in die Regel (erlaubt, aber Exposure gilt ⇒ Rotationspflicht + dokumentieren wo), oder Verfahren definieren (z. B. sorb legt per SSH selbst ab, Session referenziert Pfad).

W6 — AAR-Vorlage vs. Nachtrag-Praxis

verfahren/aar-vorlage.md: fünf Abschnitte, Gebot „Kurz", Befund-Status mit Issue-Referenz („notiert · Issue"). Der CFGMON-AAR hat inzwischen acht Abschnitte (drei Nachträge) und eine Befunde-Tabelle ohne Issue-Referenzen (Befund 3 → heute #14; die Issues entstanden erst nach dem AAR). Die Nachtrag-Mechanik — die sich zweimal bewährt hat (Reboot-Korrektur, Auflösung) — ist nirgends im Verfahren definiert. Auflösung: Vorlage um eine Nachtrag-Regel ergänzen (append-only, datiert, Fundstellen verweisen auf den Nachtrag) oder Nachträge verbieten und Folge-AARs verlangen. Die Befunde-Tabellen der beiden LABNET-02-AARs könnten danach um Issue-Refs ergänzt werden (reine Vervollständigung).

W7 — Commit-Autorschaft: drei Identitäten, keine Konvention

Im management-Repo committen Agenten-Sessions unter drei Identitäten: sorb <gamemaster@axion1337.de> ohne Agent-Kennzeichnung (CFGMON-Session: e8e1b36, 28cd06c, 001f59f; auch b647645 der Mac-Session), und seit heute Thore Cimbal <cfx@riot.8shield.net> mit Co-Authored-By: Claude-Trailer (09bdd94, ae982cd, …). Das Kanonisierungs-Verfahren betont Autorschafts-Erhalt als Wert — der ist wenig wert, wenn dieselbe Person/verschiedene Agenten unter wechselnden Identitäten schreiben. Eigenes Versäumnis der CFGMON-Session eingeschlossen: der Claude-Trailer fehlt bei meinen Commits. Auflösung: eine Zeile in CLAUDE.md — welcher Author-Name, welche E-Mail, Trailer ja/nein.

W8 — UDM-SSH: aktivierte Reständerung ohne Doku

Für die Fehlersuche wurde SSH auf der UDM aktiviert (root@10.58.73.1, eigenes Passwort). Der Lab-AAR erwähnt es nicht, kein Issue trägt es, Status vermutlich „noch an". Root-Shell-Zugang auf dem zentralen Gateway ist ein sicherheitsrelevanter Dauerzustand, wenn er bleibt. Auflösung: deaktivieren oder bewusst belassen und als Bestand dokumentieren (analog zur docker-Gruppen-Entscheidung in #14).

---

Konform befunden (der Vollständigkeit halber): AAR-Pflicht nach Deploy mit Übergabe ✓ (beide AARs), Kanonisierungs-Weg statt Gitea-Push ✓ (alle vier CFGMON-Commits über git.lab, Mirror verifiziert), Redlichkeits-Regeln ✓ (Verifiziert/Vermutet getrennt, eigene Fehlannahme per Nachtrag korrigiert statt geglättet), chirurgische Config-Edits ✓ (sed + wg-quick strip-Validierung), Übergabe-Ausnahme auf Gitea während der Nacht ✓ (durch ADR-0002 gedeckt, seit heute per #13 migriert und zurückgebaut).

Blocker entfallen 2026-08-15 — Workshop hat stattgefunden

Das Issue wartete auf die Auflösung „im Struktur-Workshop (#17)". Der hat stattgefunden (2026-08-06) und drei ADRs hervorgebracht: 0008 (Agenten-Sessions root-äquivalent — löst den zu W-gehörenden Teil und damit #0014), 0009 (Commit-Konventionen) und 0010 (Härtung als eigener Meilenstein M5). Damit ist der Wartegrund hinfällig → open.

Die Widersprüche sind damit aber nicht alle abgeräumt. Zwei stichprobenartig gegengeprüft, beide bestehen fort:

• W1 offen: docs/adr/0004-* nennt weiterhin „Split-DNS nur ~lab → 10.58.73.1". Die real konfigurierten vier Zonen (~lab, ~lab.de, ~axion1337.de, ~axionlabs.de) stehen dort nicht — inklusive der im Issue benannten Brisanz, dass ~axion1337.de auch rohana.axion1337.de (Gitea-Mirror, Flux-Quelle!) über den Lab-Resolver zieht.
• W3 offen: docs/wiki/admin/cfgmon.md listet in der Dienste-Tabelle (Zeile 33) weiterhin runner | gitea/act_runner:0.6.1 als laufend — obwohl dieselbe Datei ihn als am 2026-07-31 entfernt meldet.

W4/W5 (Rotationspflicht nach der Secrets-Regel) haben mit #0015 teilweise ein Zuhause; ob damit alle dort genannten Schlüssel abgedeckt sind, gehört zur Auflösung.

Nächster Schritt: W1–W8 einzeln durchgehen und je Punkt entweder auflösen (ADR/Doku nachziehen) oder bewusst verwerfen — die Regel des Issues („dokumentieren, nicht still auflösen") bleibt dabei gültig.

Auflösungsstand 2026-08-15 — vier abgearbeitet, vier brauchen eine Entscheidung

Durchgang gemäß der Regel dieses Issues: dokumentiert und referenziert, nicht still aufgelöst.

Erledigt

W2 — Bootstrap-Routen / Ping-Falle. Teil (b) ist bereits dokumentiert: die Ping-Falle steht als Textbaustein in docs/wiki/admin/textbloecke.md („Ping auf 10.58.73.17 schlägt IMMER fehl … das ist kein Fehler"), Erreichbarkeit wird über HTTPS geprüft. Teil (a) — Firewall-Ausnahme für einen künftigen Truststore-Neuaufbau — ist bedingt und tritt erst ein, wenn er gebraucht wird; die ADR-Pflicht dafür steht in AGENTS.md und muss hier nicht vorweggenommen werden. → geschlossen.

W3 — cfgmon.md widersprach sich selbst. Die Dienste-Tabelle listete runner | gitea/act_runner:0.6.1 als laufend, obwohl er am 2026-08-01 mit dem CI-Umzug zurückgebaut wurde (belegt: thread-net-git-README und die Compose enthalten ihn nicht mehr). Zeile entfernt, Hinweis auf den Rückbau ergänzt, Stand auf 2026-08-15 gezogen. Zugleich die Bedeutungsfrage beantwortet, statt sie offen zu lassen: Die Dienste-Tabelle ist Ist-Zustand und wird nachgeführt; die Abschnitte darunter sind Historie und bleiben stehen. Das steht jetzt in der Kopfzeile der Seite. → geschlossen.

W6 — AAR-Nachträge waren nirgends definiert. Die Praxis hat sich mehrfach bewährt und wurde zuletzt erneut genutzt (Wiki.js-AAR). Statt sie zu verbieten, ist sie jetzt Regel in docs/aar/template.md: append-only, datiert, mit Verweis von der korrigierten Stelle auf den Nachtrag — der ursprüngliche Stand bleibt lesbar, sonst verschwindet genau der Irrtum, aus dem man lernen wollte. Ab ~drei Nachträgen gehört das Thema in ein Folge-AAR. Befunde-Tabellen dürfen ohne Nachtrag um Issue-Referenzen ergänzt werden. → geschlossen.

W7 — Commit-Autorschaft. Rückwirkend durch ADR-0009 gelöst (251 Commits, Identitäten vereinheitlicht), und die gelebte Praxis ist seither einheitlich. Es fehlte aber genau das, was W7 verlangte: die benannte Regel. AGENTS.md sagte nur „kanonische Autor-Identität", ohne sie zu nennen. Jetzt konkret: Autor Thore Cimbal <cfx@riot.8shield.net> plus Trailer Co-Authored-By: <Modell> <noreply@anthropic.com>; Ausnahme turn-secret-rotation-Bot. → geschlossen.

Brauchen eine Entscheidung von sorb

W1 — ADR-0004 vs. vier Split-DNS-Zonen. Nachgeprüft: ADR-0004 sagt weiterhin „Split-DNS nur ~lab → 10.58.73.1", real sind es vier Zonen. ⚠️ ADRs sind nach Annahme eingefroren — der As-built-Stand lässt sich also nicht einfach hineinschreiben; nötig wäre ein ablösender ADR (oder der Rückbau auf ~lab). Die im Issue benannte Brisanz besteht unverändert: ~axion1337.de über den Lab-Resolver betrifft auch rohana.axion1337.de — die Flux-Quelle. Löst der Lab-DNS die Zone anders auf als öffentlich, ändert sich unbemerkt der Pfad zum Mirror.

W4 — Schließung von #16 deckte drei von fünf Punkten. Still mitgeschlossen: Punkt 4 (Repo-Zuhause für lab.conf/Drop-in/Root-CA) und Punkt 5 (Schlüsselrotation). Entweder sorb bestätigt die Schließung ausdrücklich für alle fünf (dann ist die Secrets-Regel für diesen Fall bewusst ausgesetzt → ADR-Pflicht für die Ausnahme), oder 4+5 werden reaktiviert. Der Token-Teil hat mit #0015 teilweise ein Zuhause; ob der WG-Private-Key davon abgedeckt ist, gehört zur Antwort.

W5 — Secrets-Regel kennt den Bootstrap-Fall nicht. Strukturell, nicht böswillig: auf einem headless Host gab es keinen anderen Übergabekanal. Zu entscheiden: Bootstrap-Klausel in die Regel (erlaubt, aber Exposure gilt ⇒ Rotationspflicht + festhalten wo) oder ein Verfahren (sorb legt per SSH selbst ab, die Session referenziert nur den Pfad). Solange die Regel den Fall nicht kennt, wird sie beim nächsten Bootstrap wieder gebrochen — eine Regel, die man nur durch Verstoß erfüllen kann, ist keine.

W8 — UDM-SSH. Root-Shell auf dem zentralen Gateway, vermutlich noch aktiv, nirgends dokumentiert. Vom Mac nicht prüfbar. Entweder deaktivieren oder bewusst belassen und als Bestand dokumentieren — analog zur docker-Gruppen-Entscheidung (ADR-0008). Von den vier offenen Punkten der sicherheitsrelevanteste.

Update 2026-08-15 (2) — W8 erledigt, W1 präzisiert

W8 — UDM-SSH: erledigt. sorb bestätigt: der SSH-Zugang auf der UDM ist schon lange wieder abgestellt. Der im Audit vermutete Dauerzustand besteht nicht; es bleibt nichts zu entscheiden oder zu dokumentieren. → geschlossen.

W1 — Befund verschärft: die Zone hängt an der Zertifikatserneuerung

Bei der Recherche zu W1 kam ein Zusammenhang heraus, den das Audit noch nicht sehen konnte, weil er erst 2026-08-14 entstanden ist:

Auf CFGMON leitet Split-DNS ~axion1337.de an den Lab-Resolver 10.58.73.1 (UDM). Seit #0007 erneuert Traefik die Zertifikate per DNS-01 — und ein DNS-01-Lauf prüft, ob der _acme-challenge-TXT-Record öffentlich sichtbar geworden ist. Fragte er dafür den System-Resolver, ginge die Prüfung für *.axion1337.de an die UDM. Antwortet die dort autoritativ (im Lab wurde genau das beobachtet: lokale Antworten mit gesetztem aa-Flag), sähe Traefik den frisch gesetzten TXT nie — die Erneuerung liefe in den Timeout, und zwar still, bis die Zertifikate ablaufen.

Die Konfiguration nagelt die Prüf-Resolver ohnehin fest (--certificatesresolvers.letsencrypt.acme.dnschallenge.resolvers=1.1.1.1:53,8.8.8.8:53, thread-net-git 8d089e2), womit die Frage für den ACME-Pfad praktisch nicht auftritt.

⚠️ Korrektur (gleicher Tag, nach der Messung unten): Ich hatte diese Zeile hier zunächst als tragend bezeichnet — also behauptet, ohne sie bräche die Zertifikatserneuerung. Das war überzogen: die Messung zeigt, dass der Lab-Resolver die Zone live nach oben weiterreicht und den TXT damit sehr wahrscheinlich sähe. Die Festnagelung bleibt gute Praxis (deterministisch, umgeht Negativ-Caching), ist aber kein Sicherheitsnetz gegen W1. Die Hypothese war plausibel und ist widerlegt — sie stand hier eine Stunde lang als Tatsache.

Was weiterhin ungeprüft ist: was die UDM für axion1337.de tatsächlich zurückgibt. Prüfbefehle (auf CFGMON):

resolvectl domain            # zeigt die tatsächlich gerouteten Zonen
dig +short rohana.axion1337.de @10.58.73.1     # Antwort des Lab-Resolvers
dig +short rohana.axion1337.de                 # Antwort über den Split-DNS-Pfad
# Erwartung (öffentlich, per DoH geprüft 2026-08-15): 188.245.193.243

Weichen die Antworten ab, betrifft das jeden Zugriff von CFGMON auf *.axion1337.de — darunter rohana (Gitea/Registry) und selendis (Grafana), also Hosts, die CFGMON selbst bereitstellt.

Die Entscheidung bleibt unverändert offen: ablösender ADR mit dem As-built-Stand (vier Zonen, mit Begründung warum ~axion1337.de überhaupt ins Lab zeigt) oder Rückbau auf ~lab. Für den Rückbau spricht, dass der Zweck der übrigen drei Zonen nirgends festgehalten ist; für das Nachführen spricht, dass sie auf sorbs Ansage entstanden sind — es gab also einen Grund, er steht nur nicht im ADR.

W1 — gemessen 2026-08-15: keine Abweichung, reines Doku-Problem

Der Lab-Resolver wurde direkt abgefragt (vom Mac aus dem Lab-VLAN 10.58.73.26, UDM 10.58.73.1:53 erreichbar) und Record für Record gegen die öffentliche Sicht (DoH) gestellt:

Abfrage	UDM	öffentlich
rohana A	188.245.193.243	identisch
selendis A	188.245.193.243	identisch
axion1337.de MX / TXT (SPF)	10 mx00/mx01.ionos.de / v=spf1 …~all	identisch
_dmarc TXT, s1-ionos._domainkey CNAME	vorhanden	identisch
status, crypt A (nur öffentlich existent)	korrekt	identisch
gestern angelegt: rohana MX 0 ., _dmarc.rohana, rohana SPF -all	vorhanden	identisch
gestern gelöscht: www.rohana, ftp	leer	leer

Ergebnis: keine einzige Abweichung — auch nicht bei Records, die erst gestern entstanden bzw. gelöscht wurden. Die UDM hält keine eigene Zone, sondern reicht live nach oben durch; das gesetzte aa-Flag ist eine Eigenheit des UniFi-Resolvers und war der irreführende Teil, der die Hypothese überhaupt nahegelegt hat.

Damit ist die im Audit befürchtete Brisanz ausgeräumt: Der Pfad zum Gitea-Mirror ändert sich nicht unbemerkt, weil der Lab-Resolver dieselben Daten liefert. W1 ist ein reines Dokumentationsproblem, kein Betriebsrisiko.

Was bleibt: ADR-0004 beschreibt eine Zone, real sind es vier — und der Zweck der drei Zusatzzonen ist nirgends festgehalten. Das ist die eigentliche Lücke: Ohne diesen Grund kann niemand entscheiden, ob ein Rückbau auf ~lab etwas kaputtmacht. Empfehlung daher: ablösender ADR mit dem As-built-Stand samt Begründung (sorb kennt sie), statt eines Rückbaus ins Blinde. Die Messung oben gehört als Beleg hinein — sie zeigt, dass die Zonen heute schadlos sind.

W1 erledigt 2026-08-15 — ADR-0017

Festgehalten als ADR-0017. Er korrigiert ausschließlich die Split-DNS-Zeile aus ADR-0004 (die VPN-Architektur bleibt gültig) und begründet jede Zone einzeln durch Messung statt sie pauschal zu dokumentieren:

• ~lab notwendig — git.lab/wiki.lab → 10.58.73.17, öffentlich NXDOMAIN.
• ~axionlabs.de notwendig — ca.axionlabs.de löst intern auf 10.58.73.13 auf, öffentlich auf 91.195.241.232: echtes Split-Horizon auf die interne step-ca.
• ~axion1337.de notwendig — git.axion1337.de existiert nur intern (10.58.73.13); für alle übrigen Namen wirkungslos, aber schadlos (Messung: keine Abweichung).
• ~lab.de → wird entfernt: kein interner Name darunter, keine Fundstelle im Repo, und es leitet eine fremde öffentliche Domain (lab.de, 52.59.124.117) über den Lab-Resolver. Heute schadlos, aber eine Umleitung ohne Zweck pflegt niemand.

Damit ist auch die Rückbau-Option aus dem Audit beantwortet: Ein Rückbau auf ~lab allein hätte die interne CA- und git-Auflösung gebrochen — er wäre ins Blinde gegangen, weil der Zweck der Zonen nirgends stand. Genau diese Lücke schließt der ADR.

⚠️ Offene Handlung (klein): ~lab.de aus /etc/wireguard/lab.conf auf CFGMON entfernen, Dienst neu laden, mit resolvectl domain gegenprüfen.

Stand der acht Widersprüche: W1, W2, W3, W6, W7, W8 erledigt — offen nur noch W4 und W5 (Schließung von #16 bestätigen bzw. Punkte 4+5 reaktivieren; Bootstrap-Klausel in der Secrets-Regel). Beide hängen an der Schlüsselrotation und passen zu #0015.

W5 erledigt / W4 präzisiert — 2026-08-15

W5 erledigt. Die Secrets-Regel in AGENTS.md hat jetzt eine Bootstrap-Ausnahme: Wo sorb die Datei auf dem Zielhost nicht selbst anlegen kann und kein anderer Übergabekanal existiert, darf eine Session das Credential schreiben. Bedingungen: der Wert gilt damit als exponiert und rotationspflichtig, es wird festgehalten welches Credential wohin ging (Pfad + Zweck, nie der Wert), und die Rotation bekommt ein Issue mit Fälligkeit. Die Ausnahme deckt nur das Ablegen — Anzeigen in Logs, Chat oder Commits bleibt verboten.

Damit ist der strukturelle Widerspruch aufgelöst: Die Regel war bisher auf einem headless Host nur durch Verstoß erfüllbar, was sie als Regel entwertet hat. Jetzt benennt sie den Fall und knüpft ihn an Auflagen.

W4 — zwei Teile, unterschiedlicher Stand:

• Punkt 5 (Rotation) ist inhaltlich #0015, das gerade bearbeitet wird (Bestandsaufnahme der 24 git.lab-PATs und der sechs Mirrors liegt dort). ⚠️ Der in der LABNET-02-Nacht exponierte WireGuard-Private-Key ist davon nicht abgedeckt (kein API-Token) und muss separat rotiert werden.
• Punkt 4 (Repo-Zuhause für lab.conf, systemd-Drop-in, Root-CA) ist nachweislich offen: gitops:host-config/ existiert als genau dafür gedachtes Muster, enthält aber nur maintenance-notify. Die Schließung von #16 war für diesen Punkt verfrüht — hier braucht es keine Bestätigung, sondern die Arbeit.

Damit bleibt von den acht Widersprüchen nur W4 offen, und zwar als konkrete Aufgabe statt als Klärungsfrage: Host-Config ins Repo (Punkt 4) + WG-Key rotieren (Punkt 5, neben #0015).