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

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

✅ AUSGEFÜHRT 2026-08-16 — Punkte A, B, C, D vollständig; E weitgehend

Punkt	Status	Was passiert ist
A Ist-Stand-Block	✅	Neu geschrieben gegen den live geprüften Stand (MikroMCP: Identity, /ip/address, Interface-States). Alte Fassung als ausklappbare Historie erhalten, ⚠️-Provisorium-Vorspann entfernt. Zusätzlich die stale IP-Block-Zeile darüber korrigiert.
B Reihenfolge/Abhängigkeiten	✅	Auf den echten Rest-Pfad TP5 → TP6 eingedampft, plus „Follow-ups nebenher", „Nachgelagert" und „Durch". Die alte 1–7-Liste samt fortgeschriebenem Vorspann liegt als Historie im <details>.
C stale „ap1 = Router"	✅	TP4-Header, TP15 (Header + „als Nächstes" + CAPsMAN), TP16.1, TP21-Scope-Grenze korrigiert — fortgeschrieben, nicht überschrieben. Zusätzlich: TP3-Header (CAPsMAN → Standalone), TP-R-Sweep, TP15-Mgmt-Renumber-Zeile.
D Kleinkram	✅	omada-mcp + CF-Ingress live gegengeprüft → beides sauber, Punkt abgehakt. cudy1-Formulierung an den Live-Befund angeglichen. switch/README.md als Archiv-Kopf angelegt. (st-main war bereits korrekt.)
E CLAUDE.md + Memories	🟡	CLAUDE.md: Mac-mini-IP .41.167→.20.167 (war stale), branch-Uplink sw1 GE8→core ether8, ALLNET-/Omada-Gotchas als Historie, Nautobot-Zeile auf TP22-Stand, MCP-„nach Neustart"-Hinweise weg. Memories: 4 überholte mit Superseded-Kopf + Index nachgezogen. Offen: keine.

Zwei Live-Befunde nebenbei (in teilprojekte.md eingetragen, kein Eingriff): CF-Tunnel-HA ist degradiert (bf-nas/bf-pve haben nur je 1 Connector, s. TP16) und vier tote Alt-Tunnel mit VLAN1-Origins — darunter die Auflösung des „unidentifizierten VLAN1-Geräts .41.133" aus TP19.

Scope-Änderung am selben Tag: die DC-USV ist aus TP15 herausgelöst und heißt jetzt TP24.

✅ NACHLAUF 2026-08-18/19 — die Liste ist abgeschlossen

Zwischen dem 16. und dem 19. sind zwei Runden Drift dazugekommen, beide durch echte Arbeit und nicht durch Nachlässigkeit — die Doku hinkt hier naturgemäß einen Tag hinterher.

Runde	was driftete	erledigt
08-18 (Commit 0ec812c)	der „Ist-Stand (Kurz)"-Block war an vier Stellen überholt (Standalone statt CAPsMAN, 7.19.5/7.23 statt 7.24, 1.1.1.1 statt DoH, 68/68 statt 92/92); TP26 + TP27 existierten nur als Commits ohne Abschnitt	✅
08-19 (diese Session)	Rest-Selbstwiderspruch im kritischen Pfad · docs/ip-plan.md führte ap1 als Router und sw1 als lebend · TP13-Technikteil beschrieb Standalone-APs · Memories + Index ohne TP28-Nachtrag	✅

Die Lehre aus der ersten Runde ist die wichtigere: nachgezogen wurden damals die TP-Abschnitte und CLAUDE.md — ausgerechnet der Block, den eine frische Session zuerst liest, blieb stehen. Merkregel: der Ist-Stand-Block wird bei jeder Änderung mitgezogen, nicht nur der betroffene TP.

Punkt E ist damit geschlossen. Neu entstanden statt weiterer Aufräumarbeit: vier ausführbare Runbooks (tp6-praemisse-messrunbook, tp16.3-nautobot-mesh-only, tp14.4-cf-access-token, tp13-botschafts-wlan) — die TPs standen als Einzeiler da, aus denen niemand losarbeiten konnte.

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 und CAPsMAN-Manager, kein sw1/sw2, kein Omada, ap1/ap2 als reine CAPs. ⚠️ Korrigiert am 2026-08-19: hier stand bis dahin „kein CAPsMAN" — als Abnahmekriterium. Ein Kriterium, das den falschen Zielzustand beschreibt, macht jede Prüfung wertlos; es hätte eine Session bestätigt, die den überholten Stand wiedergibt. Seit TP28 (2026-08-17) ist CAPsMAN zurück.
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.

---

Punkt F — Aufteilen der teilprojekte.md ▸ ✅ AUSGEFÜHRT 2026-08-23

✅ Ergebnis — die Liste ist damit vollständig abgearbeitet (A–F)

	vorher	nachher
docs/teilprojekte.md	2217 Zeilen	~765 (Rahmen + kritischer Pfad + 16 offene TPs)
docs/teilprojekte-archiv.md	—	~1780 (34 abgeschlossene TPs, Volltext + Inhaltsverzeichnis)
TP25	393 Zeilen	~100 (Stand/Offenes/Merkregeln; Langfassung im Archiv)

Gemacht wie empfohlen: nach ZUSTAND getrennt, nicht nach TP. Die Zuordnungsregel ist mechanisch und steht jetzt in beiden Dateien und in CLAUDE.md: ein TP wandert erst dann ins Archiv, wenn nichts mehr daran zu tun ist. Wo nur ein Sub-TP offen war, blieb dieses in der Hauptdatei und das erledigte Eltern-TP ging ins Archiv (TP17.2 ↔ TP17, TP20.1 ↔ TP20).

Kein Inhalt verloren: maschinell gegengeprüft — von 2218 Originalzeilen tauchen alle in einer der beiden Dateien wieder auf, bis auf 7 bewusste Korrekturen (VLAN-Tabelle „Public-IP an ap1" → crs326-core · Compliance 100/100 → 104/104, live geprüft · der überholte „Nächster Schritt"-Kopf · ## Teilprojekte → ## Offene Teilprojekte · zwei ####→### bei den herausgelösten Sub-TPs).

Zwei Drift-Funde nebenbei — beide aus derselben Klasse wie die Lehre vom 08-18 (der Ist-Stand-Block wird zuletzt nachgezogen): die Compliance-Zahl im Ist-Stand war seit TP6.1 einen Tag alt (100/100 bei 25 Rules statt 104/104 bei 26, live gegen die Nautobot-API korrigiert), und die VLAN-Tabelle trug noch immer „Public-IP an ap1" — ein Rest aus Punkt C, den vier Durchgänge übersehen hatten, weil er in einer Tabellenzelle steckt und nicht in einem TP-Absatz.

Und eine sachliche Korrektur im kritischen Pfad: die DOCSIS-Erklärung aus dem TP6-Abschluss stand dort noch als Begründung — TP6.1 hat sie am selben Tag widerlegt. Als datierter Nachtrag eingetragen, nicht überschrieben.

Live gegengeprüft statt abgeschrieben (Leitplanke „Quelle ist das Gerät"): Compliance 104/104 / 0 Drifts über die Nautobot-API, und crs326-branch trägt keine 192.168.88.x-Adresse mehr — damit ist der letzte offene Aufräum-Punkt aus TP21.1 geschlossen und das TP durfte ins Archiv.

Ursprünglicher Auftrag (User-Anstoss 2026-08-23)

Christophs Beobachtung: „die teilprojekte.md beginnt zu explodieren. sollten wir sie nicht besser aufsplitten in übersicht + 1 MD / teilprojekt“

Zahlen zum Zeitpunkt der Frage (wc -l = 2205):

	Zeilen	Anteil
abgeschlossene TPs (✅/📜/❌ im Kopf)	1071	49 %
offene TPs	981	44 %
Rahmen (VLAN-Modell, Ist-Stand, Reihenfolge)	~150	7 %

Groesster Einzelposten: TP25 mit 393 Zeilen (18 % der Datei allein).

Empfehlung: nach ZUSTAND splitten, nicht nach TP

🔴 Gegen „1 MD pro Teilprojekt“ — es waeren ~35 Dateien, und CLAUDE.md verspricht ausdruecklich „Kein anderer Kontext noetig“. Beim Schnitt pro TP muesste eine frische Session vorher raten, welche Dateien sie braucht — und genau die Querbezuege, die dieses Dokument wertvoll machen (Reihenfolge, Abhaengigkeiten, „TP23 haengt an TP5 in beide Richtungen“), leben von der Naehe im selben Text. Der Schnitt wuerde die teuerste Eigenschaft der Datei zerstoeren, um ihr billigstes Problem zu loesen.

✅ Stattdessen:

• docs/teilprojekte.md — Rahmen + kritischer Pfad + offene TPs in voller Tiefe
• docs/teilprojekte-archiv.md — abgeschlossene TPs, aus der Uebersicht verlinkt

Begruendung: das Wachstum kommt nicht aus der Zahl der TPs, sondern aus der Historie erledigter. Deren bleibender Wert sind die Gotchas — und die stehen ohnehin destilliert in CLAUDE.md und den Memories. Ein abgeschlossenes TP wird gelesen, wenn jemand gezielt danach sucht; dafuer reicht eine verlinkte Archivdatei.

Zweiter Hebel im selben Zug: TP25 kondensieren — Funde A–D sind erledigt und brauchen keine Vollausfuehrung mehr, nur Ergebnis + Merkregel. Zusammen landet die Hauptdatei bei ~700 Zeilen.

⚠️ Abnahme wie bei Punkt A: eine frische Session liest nur die neue teilprojekte.md und kann daraus den kritischen Pfad und den Ist-Stand korrekt wiedergeben. Kann sie das nicht, ist zu viel ins Archiv gewandert.

📌 Hinweis zur Herkunft: der Vorschlag stammt aus der TP6/TP6.1-Sitzung vom 2026-08-23. Dieselbe Sitzung hat der Datei ~150 Zeilen hinzugefuegt (TP6-Abschluss, TP6.1) — der Split sollte deshalb nicht von der Sitzung gemacht werden, die gerade Inhalt beigesteuert hat.