diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md
index 14753ac..24870fc 100644
--- a/docs/teilprojekte.md
+++ b/docs/teilprojekte.md
@@ -267,7 +267,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
 - Abh.: TP3. (Research erledigt, s. TP-R.)
 
 ### TP9 — Gateway-/Router-HA ▸ ❌ OBSOLET (User-Entscheid 2026-08-08)
-- ❌ **Verworfen: `crs326-core` bleibt bewusster Single Point of Failure — kein Router-/Gateway-HA gewollt.** Der HA-Aufwand (DHCP/DNS/Firewall/NAT identisch auf zwei Geräten gepflegt, VRRP-Sync) steht nicht im Verhältnis zum Heim-Nutzen; DR-Weg = Config-Backup-Restore (+ ggf. AP-Reprovisionierung). Die VRRP-Skizze unten ist damit nur noch historische Recherche.
+- ❌ **Verworfen (User-Begründung 2026-08-08, „ganz klar nein"):** am `crs326-core` führt ohnehin **nie ein Weg vorbei** — er ist der unumgängliche L3-Durchleitungspunkt. Ein zweites Gerät / VRRP **beseitigt diesen SPOF nicht**, sondern baut nur **zusätzliche Sollbruchstellen** ein (2× Config-Sync für DHCP/DNS/Firewall/NAT, Split-Brain-Risiko, VRRP-Eigenfehler) → netto ein Zuverlässigkeits-**Verlust**, kein -Gewinn. Die Frage ist nicht „Aufwand vs. Nutzen", sondern „mehr Fehlerquellen einbauen?" → nein. DR-Weg = Config-Backup-Restore (+ ggf. AP-Reprovisionierung). VRRP-Skizze unten = nur noch historische Recherche.
 - **„Was, wenn ap1 ausfällt?"** → **VRRP** löst Gateway-Failover je VLAN ~gratis (kreuzweise Master/Backup).
   ⚠️ **Haken (nicht Last):** DHCP/Firewall/NAT/DNS müssen auf **BEIDEN** APs **identisch** gepflegt sein, sonst „Gateway up, Internet tot".
   **Empfehlung:** VRRP nur für **MAIN/INFRA**, sonst ap2 als **Kalt-Ersatz** + Backup. DHCP/DNS schon redundant (Split + 2 Resolver).