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

221 lines
14 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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.