claude.md: Pflichtlektüre + Master-Struktur gekürzt, Lessons for Sessions ergänzt
- Header (Z.1–23): Inventur-Hinweise rein, Master-Struktur (bf-infra/bf-network-r6/ bf-golden-config/blaueblueten-n8n) als eigener Block, terpene-Stand. - Pflichtlektüre-Reihenfolge explizit (1. teilprojekte.md Quick-Index, 2. handoff, 3. cf-tunnel-mapping/archiv bei Bedarf, 4. Inventur-Handoff). - 'Lessons for Sessions' als neuer Abschnitt am Ende: 4 Verhaltensregeln (Bestandsaufnahme vor Plan, große Fragenrunde, Master-Frage früh, Drift vor Lösungen) + Checkliste vor Edit-Vorschlägen.
This commit is contained in:
48
CLAUDE.md
48
CLAUDE.md
@@ -4,22 +4,34 @@
|
||||
DNS/DHCP-Ablösung, WLAN via **CAPsMAN auf dem Core** (TP28, 2026-08-17 — der Standalone-Entscheid von
|
||||
2026-07-22 ist revidiert), Firewall Least-Privilege (**TP5 deny-by-default scharf seit 2026-08-18**), Multi-Site VPN.
|
||||
|
||||
**Für jede TP-Session: zuerst `docs/teilprojekte.md` lesen** — enthält kanonischen Stand, Scope, Abhängigkeiten
|
||||
und Reihenfolge der **offenen** Teilprojekte. Kein anderer Kontext nötig.
|
||||
📚 **Abgeschlossene TPs stehen seit 2026-08-23 in `docs/teilprojekte-archiv.md`** (Volltext, unverändert,
|
||||
mit Inhaltsverzeichnis) — dort nachsehen, wenn man wissen will, *warum* etwas so entschieden wurde;
|
||||
für den Einstieg **nicht** nötig. Regel für beide Dateien: **ein TP wandert erst ins Archiv, wenn nichts
|
||||
mehr daran zu tun ist** — und der **Ist-Stand-Block wird bei jeder Änderung mitgezogen**, nicht nur der
|
||||
betroffene TP-Abschnitt.
|
||||
## Pflichtlektüre pro Sitzung (Reihenfolge)
|
||||
|
||||
🛠️ **TP-Management (2026-08-26):** Wenn während einer Session ein neues Teilprojekt, eine Abhängigkeit
|
||||
oder ein Querschnittsthema sichtbar wird, das bisher in keinem TP abgebildet ist:
|
||||
1. **`docs/teilprojekte.md`** (Quick-Index-Block) — kanonischer Stand, Scope, Abhängigkeiten, **offene** TPs. **1 Read reicht.**
|
||||
2. **`docs/handoff-*.md`** (neueste) — wo die letzte Session aufgehört hat.
|
||||
3. Bei Live-Writes oder Inventur: **`docs/cf-tunnel-mapping.md`**, **`docs/teilprojekte-archiv.md`**.
|
||||
4. Inventur-Befund 2026-08-27: [`docs/handoff-20260827-inventur-und-architektur.md`](docs/handoff-20260827-inventur-und-architektur.md) — Master-Struktur, Asymmetrie, Drift.
|
||||
|
||||
## Was du sofort wissen musst (Inventur 2026-08-27)
|
||||
|
||||
- **`bf-infra`** ist aktiver Master, **lokal, kein Gitea-Remote** (Working-Copy). Verloren bei Festplattencrash.
|
||||
- **`admin/bf-network-r6`** (Gitea) ist Archiv, letzte aktive Commits 2026-08-25 → read-only-Header.
|
||||
- **`admin/bf-golden-config`** (Gitea) ist Bot-Master (Nautobot 2×/Tag), nicht manuell.
|
||||
- **`admin/blaueblueten-n8n`** (Gitea) ist Master für terpene-Repo.
|
||||
- **`inventory/` ist tot** (Pipeline seit 2025-06 stale). Live-Daten aus MikroMCP/CF/Portainer.
|
||||
- **`mcp/INVENTORY.md`** ist BF-Netz-SSoT; `~/.claude.json`/`opencode.jsonc` sind globalere Werkzeugkästen.
|
||||
- **terpene.teilzeitladen.xyz**: Worker läuft auf Mac mini (`10.40.20.167:8890`), **kein Caddy-Block, kein CF-Tunnel** — Backfill via DB-Migration blockiert (Handoff 2026-08-27).
|
||||
|
||||
## TP-Management (2026-08-26)
|
||||
|
||||
Wenn während einer Session ein neues Teilprojekt, eine Abhängigkeit oder ein Querschnittsthema sichtbar wird, das bisher in keinem TP abgebildet ist:
|
||||
- Vorschlagen und mit dir abstimmen (nicht eigenmächtig anlegen).
|
||||
- Auf dein Okay hin anlegen: Quick-Index-Zeile + `### TP<n>`-Abschnitt mit Status `🔜`, Scope,
|
||||
Abhängigkeiten, Abgrenzung. Nächste freie Nummer vergeben (höchste vergebene + 1; Lücken aus
|
||||
verworfenen TPs bleiben frei).
|
||||
- Ist-Stand-Block mitziehen (Datum, betroffene Zeilen).
|
||||
|
||||
**Abgeschlossene TPs** stehen seit 2026-08-23 in `docs/teilprojekte-archiv.md` (Volltext, unverändert, mit Inhaltsverzeichnis). **Ein TP wandert erst ins Archiv, wenn nichts mehr daran zu tun ist** — und der **Ist-Stand-Block wird bei jeder Änderung mitgezogen**, nicht nur der betroffene TP-Abschnitt.
|
||||
|
||||
---
|
||||
|
||||
## VLAN-Modell (kanonisch)
|
||||
@@ -164,3 +176,21 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`,
|
||||
gilt der VLAN-übergreifende SNMP-Fall unten.
|
||||
- **P750W (Brother, VLAN30) läuft auf `dirtyvader-iot`** (User-bestätigt 2026-08-08) — **kein** Access-List-Pin nötig; die alte „nur am co-located L3-GW-AP erreichbar"-Logik ist mit L3-GW auf dem Core hinfällig. Coverage-Kanten/Terrasse grenzwertig (−76..−89 dBm); TX am AT-Max (18/15 dBm); echter Fix = Platzierung. SSoT `docs/wifi-p750w-coverage-and-map.md`. ⚠️ **Power-Save ist KEIN Thema dieses Netzes** — die früher hier stehende Merkregel „DHCP-geht-aber-Ping-nicht = ARP/Power-Save" war eine Fehldiagnose (2026-08-13 korrigiert: der Drucker war schlicht ausgeschaltet, das Ping-Symptom war WARP, s.u.). Nicht wieder einführen.
|
||||
- **Ping auf JEDE lokale IP tot, aber Web/App/Print (TCP) geht überall = WARP-Client lokal versehentlich noch aktiv** (2026-08-13 live beobachtet, BF vor Ort): `cloudflared`/WARP ist QUIC-Proxy, kann **kein ICMP**, reicht TCP aber durch — auch wenn man physisch im BF-LAN steht, nimmt der Client bei aktivem WARP trotzdem den Tunnel-Umweg. **Fix: WARP trennen**, kein Router-Eingriff nötig. **Vor jeder Firewall-/Mangle-/VLAN-Suche zuerst prüfen**, wenn das Symptom „Ping auf ALLES tot, TCP geht" lautet — das ist ein Client-, kein Netzproblem. Strukturell schließt **TP16.1** (natives WireGuard-CF-Mesh auf `crs326-core` statt cloudflared-QUIC) genau diese ICMP-Lücke. Memory `ref_warp_local_icmp_trap`.
|
||||
|
||||
---
|
||||
|
||||
## Lessons for Sessions (2026-08-27, aus der Inventur-Session)
|
||||
|
||||
Verhaltensregeln für nachfolgende AI-Sessions — kleiner, klarer, weniger Drift:
|
||||
|
||||
- **Bestandsaufnahme vor Plan.** Erst was ist da, wo ist der Schaden — dann Vorschläge. Nicht umgekehrt.
|
||||
- **Eine große Fragenrunde statt vieler kleiner.** Wenn der Plan von Annahmen abhängt, sammle die Annahmen in **einer** Runde, nicht in 3–4 Mikrorunden.
|
||||
- **Master-Frage früh stellen.** Bei jedem Repo, jeder Datei, jedem Tooling: „Was ist die SSoT, wo lebt der Master, was ist Mirror?" — **bevor** du eine Lösung vorschlägst.
|
||||
- **Drift zuerst, Lösungen später.** Drift-Tabelle posten + fragen, was richtig ist. Keine Lösungen vor dem Befund.
|
||||
|
||||
**Checkliste vor jedem Edit-Vorschlag:**
|
||||
|
||||
1. Habe ich die SSoT für die Datei/das Repo benannt?
|
||||
2. Habe ich die Drift zwischen Doku und Live dokumentiert (nicht stillschweigend korrigiert)?
|
||||
3. Habe ich **eine** Fragenrunde mit allen offenen Annahmen gestellt?
|
||||
4. Habe ich für jeden Edit **deine** Bestätigung eingeholt (nicht nur für den Plan-Output)?
|
||||
|
||||
Reference in New Issue
Block a user