Christoph Emsenhuber
9a777a6d5c
Eine frische Session hat nach Core und CAPsMAN gefragt, weil die Datei sich selbst widersprach. Ursache war nicht fehlende Information, sondern dass bei Statuswechseln jeweils nur der neue Abschnitt geschrieben und der alte Header stehengelassen wurde: - TP3 trug im Header "beide hAP ax2 sind reine Standalone-APs, CAPsMAN abgeschafft", und sein Lesehinweis verwies als "Ist-Stand" auf den 08-08-Eintrag. Wer die WLAN-Frage hatte, landete zuerst dort -- und bekam die falsche Antwort. TP3 ist jetzt als vollstaendig historisch markiert und verweist auf TP28. - TP3.3 stand als "TODO (neue Session)", obwohl es seit 08-17 in TP25 aufgegangen ist. - TP28 selbst trug unter dem Header "KOMPLETT" noch einen Punkt "OFFEN -- das GC-Modell beschreibt weiter Standalone-APs" mit der stale Zahl 76/76. Das war mein Rest vom 18.: Header umgeschrieben, Punkte darunter nicht. - Die Abnahme in doku-cleanup-session.md verlangte woertlich "kein CAPsMAN" -- ein Kriterium, das den falschen Zielzustand beschreibt, bestaetigt genau die Session, die den ueberholten Stand wiedergibt. - Dazu HW-Refresh-Zeile und die ft-over-ds-Notiz in TP25 nachgezogen. Merkregel, die jetzt an drei Stellen im Dokument steht: bei einem Statuswechsel nicht nur den Header umschreiben, sondern die Punkte darunter mitziehen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
140 lines
9.9 KiB
Markdown
140 lines
9.9 KiB
Markdown
# 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.
|