bf-infra/docs/doku-cleanup-session.md

Doku-Aufräum-Session — teilprojekte.md auf den Stand nach dem Core-Cutover bringen

Vorbereitet 2026-08-14. Reine Doku-Session, kein Netz-Eingriff, kein Gerät wird angefasst. Auslöser: docs/teilprojekte.md beschreibt an mehreren Stellen noch die Topologie vor dem 2026-08-08 (ap1 = Router, sw1/sw2 lebendig, Omada aktiv, CAPsMAN). Das Dokument sagt über sich selbst: „ganze Liste braucht mal eine Aufräum-Session" — das hier ist sie.

Warum das kein Kosmetik-Thema ist

CLAUDE.md schickt jede frische TP-Session zuerst in docs/teilprojekte.md („kein anderer Kontext nötig"). Steht dort ein überholter Ist-Stand, plant die Session Arbeit ein, die es nicht mehr gibt — oder trifft Entscheidungen auf Basis einer Topologie, die seit einer Woche nicht mehr existiert. Am 2026-08-14 sind beim Statusbaum vier solcher Stellen aufgefallen und sofort korrigiert worden; die Liste unten ist der Rest.

Leitplanken (Projektkonvention, gilt für die ganze Session)

• Fortschreiben, nicht überschreiben. Historie bleibt lesbar — durchstreichen + datierter Nachtrag, so wie es TP1/TP2 mit ihrer Geräte-Abkündigung schon machen. Ein Doku-Stand, aus dem man nicht mehr rekonstruieren kann, warum etwas entschieden wurde, ist schlechter als ein veralteter.
• Quelle ist das Gerät, nicht die Doku. Wo ein Ist-Stand behauptet wird, vorher per MikroMCP nachsehen (dieselbe Regel, an der TP22 Schritt 5 hing).
• Zusammengehörige Marker mitziehen: Header-Marker, Abh.:-Zeile und die Erwähnung in „Reihenfolge / Abhängigkeiten" driften sonst auseinander.

---

Arbeitsliste

A — Der „Ist-Stand (Kurz)"-Block (Zeilen 21–25) 🔴 höchste Wirkung

Vier von fünf Zeilen sind Historie: ALLNET .11 als lebender Core, Omada-Controller .175 „🟢 live" (Container am 2026-07-16 gelöscht), ap1 .1 als Router + WAN-Edge, der Edge-Cutover-Pfad über sw1 gi16. Am 2026-08-14 wurde ein ⚠️-Vorspann davorgesetzt, der den Block als Historie markiert — die Neufassung steht aus.

Zu tun: Block neu schreiben gegen den echten Stand (crs326-core = L3 .99.1 / WAN vlan100 / 90.146.33.177, crs326-branch .99.2, ap1 .99.11 + ap2 .99.12 = reine APs, Nautobot GC als Config-Weg). Alte Fassung als datiertes Zitat darunter. Danach den ⚠️-Vorspann entfernen — er ist ausdrücklich ein Provisorium.

B — „Reihenfolge / Abhängigkeiten" (Zeilen ~664 ff.)

Die nummerierte Liste 1–7 ist inhaltlich tot, wird aber noch als Reihenfolge gelesen:

• Punkt 3 („Jetzt: Omada-PVID-Fix") — obsolet, Omada ist raus (User-Entscheid 2026-07-22, „nie wieder aufgreifen").
• Punkt 4 — TP5→TP6 stimmt inhaltlich, steht aber unter „Dann:" hinter einem obsoleten Punkt.
• Punkt 7 — „TP20 hängt an TP18 ①" ist überholt (Abhängigkeit am 2026-07-16 entfernt).

Zu tun: Liste auf den tatsächlichen Rest-Pfad eindampfen (TP5 → TP6, daneben TP19-Restarbeiten und die Research-getriebenen TPs), Erledigtes als durchgestrichene Historie behalten.

C — Stale „ap1 = Router"-Aussagen in noch aktiven TPs

Diese TPs sind nicht abgeschlossen, tragen aber die alte Rollenverteilung — hier ist das Risiko am größten, weil sie noch gelesen und umgesetzt werden:

Stelle	Was dort steht	Realität
TP16.1 (~Z. 431)	„Router bleibt ap1/ap2 rein für L3/WLAN"	ap1/ap2 sind reine APs; L3 = core
TP21 Scope-Grenze (~Z. 548)	„Router (ap1/ap2, dauerhaft) + beide CRS326"; „außerhalb bleibt Omada-WLAN"	Omada existiert nicht mehr; Rollen vertauscht
TP15 (~Z. 384)	„WLAN bleibt hAP ax²/CAPsMAN"	CAPsMAN am 2026-08-08 abgeschafft
TP15 Header (~Z. 364)	„Core-Tausch vorbereitet, Cutover = nächstes Wartungsfenster"	Cutover am 2026-08-08 vollzogen (TP21.1)
TP15 (~Z. 372)	„🔜 Als Nächstes: Core-Tausch = L3-Umzug"	erledigt
TP4 Header	„hAP#1 = Router + WAN-Edge"	Rolle auf crs326-core (Teil-Nachtrag existiert bereits)

D — Kleinkram mit eigener Halbwertszeit

• TP14.3 listet als offen: verwaister omada-mcp-Eintrag in ~/.claude.json (Server connectet nie mehr)
  • ungeprüfte CF-Ingress-Reste omada/omada-mcp. Beides in 10 Minuten erledigt oder abgehakt.
• TP19 trägt noch cudy1 als „aktiver VLAN1-Leak" — laut TP22 Schritt 5 hat core ether11 keinen Link, Nautobot-Status Offline. Verifizieren, dann Formulierung angleichen.
• Zeile 27 (Ziel-Absatz) nennt die ap2-frame-types-Härtung und st-main rrm/wnm als „Krücken, die mit VLAN1 rausfliegen". st-main ist seit TP3.3 (2026-08-13) fester Bestandteil der Golden Config — also keine Krücke mehr, sondern Zielzustand. Zeile entsprechend korrigieren.
• switch/ (ALLNET-Telnet-Runner) + switch/ui-guides/02-vlan99-mgmt-cutover.md: Gerät ausgebaut → als Archiv kennzeichnen (README-Kopf), nicht löschen.

E — Gegenprüfen, nicht blind übernehmen

• CLAUDE.md: Hardware-Tabelle ist aktuell gepflegt, aber die Gotcha-Liste enthält Sätze aus der ap1-als-Router-Zeit. TP3-Rebuild-Eintrag nennt „breiterer CLAUDE.md-Gotcha-Cleanup" bereits als offen.
• Memory-Dateien: project_wifi_rebuild_crs326_l3, project_tp15_core_cutover_blocked_20260805, project_tp20_tp21_fasttrack_20260716 beschreiben Zwischenstände, die überholt sind. Memories sind Momentaufnahmen — überholte nach der Konsolidierungs-Regel zusammenführen oder löschen, nicht doppeln.

---

Reihenfolge & Aufwand

A → B → C → D, danach E als eigener Durchgang (anderes Substrat: Memory + CLAUDE.md). A und C sind die zwei, die wirklich Fehlentscheidungen verhindern — wenn die Zeit knapp ist, nur die. Grobschätzung: A+B+C ≈ eine Session, D+E ≈ eine halbe.

Abnahme

1. Eine frische Session liest nur docs/teilprojekte.md und beschreibt daraus die Topologie korrekt: crs326-core als L3-Router, kein sw1/sw2, kein Omada, kein CAPsMAN, ap1/ap2 als APs.
2. grep -n "CAPsMAN\|Omada\|ap1.*Router" docs/teilprojekte.md — jeder Treffer ist entweder als Historie markiert oder korrekt.
3. Der ⚠️-Provisorium-Vorspann über Zeile 21 ist weg (weil überflüssig geworden).
4. Statusbaum (/projektstatus) unverändert plausibel — die Aufräumaktion darf keinen TP-Status ändern; sie ändert nur, wie präzise er begründet ist.