# 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.