TP44 nachgezogen + TP37/34/36-Plan (native Modelle, erst planen)

- Seeder tp36-cf-estate-seed.py -> tp44-cf-estate-seed.py (+ Referenzen, Docstring)
- teilprojekte.md: TP44 Quick-Index + Abschnitt (Anker), Ist-Stand 09-06,
  TP34/36/37 auf korrigierten Stand (TP37 P3 via TP44 erledigt; P1+2 offen)
- Plan-Runbook handoff-20260906-tp37-34-36-plan.md (native Modelle, Compliance-Gegenprobe)
- 09-02-Handoff + cf-tunnel-mapping: Referenzen/TODOs nachgezogen
- TP23-Quick-Index-Zeile (fremde, korrekte Aenderung) auf User-Okay mit uebernommen

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/teilprojekte.md

@@ -37,6 +37,15 @@ ap1-Provisioning-Zeilen wieder aufgenommen → Transaktion `TP25-kanalplan-ap1-l
 `ft=no` on-air; Bring-up-Quelle `tp28-ap3-phase2-cap.rsc` um `!security.ft` ergänzt (s. Fund-E-Block).
 *(Die Fassung vom 2026-08-16 stand bis zum 18. hier und war an vier Stellen überholt. Wer diesen Block
 liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
+- 🗺️ **TP37/34/36-Strang geplant + TP44-Drift bereinigt (2026-09-06, „erst planen, nichts bauen"):**
+  Live gegen Nautobot geprüft — **TP37 Punkt 3 (CF-Connectoren) ist faktisch durch TP44 erledigt**
+  (native `nautobot.cloud`-Modelle, Etappe 1 live: Account 1/ResType 6/Network 4/Service 14). Echt offen
+  bleibt **TP37 Punkt 1+2** (Substrat: pve/NAS/macmini-Hosts + LXC/Docker als `virtualization.VM`, Dienste
+  als `ipam.Service` — live **VM 0/Cluster 0/Service 0/CustomField 0**), und darauf sitzt **TP34** (Caddyfile
+  via GC). **TP36** (Live-Daten-CustomFields + Datei-Split) ist davon **unabhängig** → parallel. Datenmodell-
+  Entscheid: **native Modelle** (konsistent zu TP44), keine eigene App. **TP44 nachgezogen:** eigene
+  Quick-Index-Zeile + Abschnitt, Seeder `nautobot/tp36-…` → `tp44-cf-estate-seed.py` umbenannt. Runbook:
+  [`docs/handoff-20260906-tp37-34-36-plan.md`](handoff-20260906-tp37-34-36-plan.md). **Kein Nautobot-Write.**
 - ✅ **TP25 Multi-Pin-Konsole (2026-09-04):** die Klick-Konsole (`docs/tp6-marker/server.py`) ist auf
   **N Clients** generalisiert und hat eine **Pin-UI** bekommen. Sie liest die Client-Liste aus
   `geraete.txt` (schreibt `tp25-walk-messung.sh`), zeigt je Client AP/Signal/Ping-Verlust aus
@@ -531,7 +540,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
 > | TP17.3 | ✅ | Shelly-Regression behoben | 2026-08-23 |
 > | TP18 | 🔜 | Garage-Objektspeicher | — |
 > | TP20.1 | 🔜 | Vaultwarden → Platform-PG | — |
-> | TP23 | ✅ | DNS-Policy (Stufe 1+2 ✅) | 2026-08-26 |
+> | TP23 | ⏳ | DNS-Policy (Stufe 1–5 ✅ 09-04) — offen nur Stufe 6 (Bypass-Sperre, in TP5) | 2026-09-04 |
 > | TP24 | 🔜 | DC-USV | — |
 > | TP25 | ⏳ | WLAN-Stabilisierung (Kern ✅) — **Fund E ✅ geschlossen 09-02: 7.24.1 war die Ursache, nicht `ft-over-ds` (4/8,6 h, 0 Ausfälle)**; **`ft=no` auf `sec-main` als Dauerzustand ✅ 09-04**; **Konsole auf N Clients + Pin-UI ✅ 09-04**; offen nur ap2 unterperformt (2 m/−80, In-situ) | 2026-09-04 |
 > | TP28 | ✅ | WLAN/CAPsMAN — dritter AP `ap3` (cAP ax) **live** | 2026-08-30 |
@@ -549,6 +558,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
 > | TP41 | ⏸️ | CF-Access-Reparatur **zurückgestellt 2026-09-01** (User): **T2/T3/T4/T5 ✅** (GitHub+Google-Login live); **Facebook abgesagt**; **Geli CF-seitig fertig** (zt-humans+geli-Policy) → offen nur noch WARP-Client auf Gelis Gerät, wartet auf User-Info | — |
 > | TP42 | ✅ | Namens-Vereinheitlichung: ein interner Suffix **`bf.emsenhuber.net`** — DHCP-domain via GC geflippt (140/140), `.16` abgebaut (`.17`=FM bleibt); Nautobot-Doku-Teil an TP37 | 2026-09-02 |
 > | TP43 | 🔜 | dw-Standort-DNS-Uplink: eigener Resolver mit site-Overrides (`420.teilzeitladen.xyz`→BF-Caddy/WG), WG-Disconnect bedacht; Geli sofort per WARP | — |
+> | TP44 | ⏳ | CF-Estate als Doku-SSoT in Nautobot — **Etappe 1 ✅ live** (`nautobot.cloud`: Account 1/ResType 6/Network 4/Service 14/Assign 3); offen Etappe 2 (CF-API→Nautobot-Sync) + IPAM-Prefixe | — |
 > | — | — | **35 archivierte TPs** in `teilprojekte-archiv.md` (inkl. TP39 ✅ 2026-09-01) | — |
 
 ### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt
@@ -2841,8 +2851,9 @@ kann in Ruhe nachziehen.
 - **Scope:** Reverse-Proxy-Hosts werden im **Nautobot-Datenmodell** gepflegt (Site, Host, Backend-Spec). **Golden Config** rendert den Caddyfile aus den Daten, Diff-Check gegen die Live-Version auf `caddy-bf1`, Compliance-Checks + Transaktionen identisch zum bestehenden Workflow für Router-Configs.
 - **Auslöser (Inventur 2026-08-27):** der Caddyfile (`bf-infra/caddy/Caddyfile`) ist heute **manuell gepflegt** — kein Drift-Check, keine Transaktionen, andere Projekte können keine Sites anlegen ohne Christoph. Lösung: **Nautobot/GC**, kein Caddy-API-Sidecar (kein zweites SSoT).
 - **Erster Anwendungsfall:** `terpene.teilzeitladen.xyz → http://10.40.20.167:8890` (Mac-mini-Backend, dort PostgREST + sync + web via lokalem Caddy `:8890`). Vor TP34: manueller Quick-Win-Caddy-Block.
-- **Abh.:** TP22 (GC-Pipeline) ✅ vorhanden · TP23 (DNS-Policy + Caddy-Voraussetzungen) ✅ Stufe 1. Hängt an **nichts**, eigene Implementierung im Runbook nach dem Quick-Win.
-- **Status:** 🔜 Stub; Konzept + Architektur-Skizze vollständig in Handoff-Datei. Implementierung in eigenem Runbook nach terpene-Caddy-Quick-Win.
+- **Abh.:** TP22 (GC-Pipeline) ✅ · TP23 (DNS/Caddy-Voraussetzungen) ✅ Stufe 1 · 🔴 **NEU 2026-09-06: TP37 Punkt 1+2** — Caddy rendert *Config aus Daten*, die Backend-Dienste müssen als `ipam.Service` in Nautobot existieren, sonst gibt es nichts zu rendern. **TP37 vor TP34.**
+- **Datenmodell (entschieden 2026-09-06):** native Modelle — Backend = `ipam.Service`, Proxy-Route = Relationship/CustomField Frontend↔Backend, GC-Job rendert den Caddyfile. Keine eigene App (konsistent zu TP44).
+- **Status:** 🔜 Stub; wartet auf TP37 P1+2. Quick-Win `terpene.teilzeitladen.xyz → 10.40.20.167:8890` als manueller Caddy-Block ist **Schritt 0** des Runbooks. Plan: [`handoff-20260906-tp37-34-36-plan.md`](handoff-20260906-tp37-34-36-plan.md).
 
 ---
 
@@ -2872,6 +2883,7 @@ kann in Ruhe nachziehen.
   3. **Archiv-Anzeige im Quick-Index** — die heute 34 Namen stehen heute in *einer* Zeile am Ende. Sichtbarkeit = „Geschichte zählt". Quick-Index-Block bekommt eine zweite Tabelle mit „abgeschlossen seit …" und Link aufs Archiv.
   4. **Migrationspfad** — kompatibel mit bestehendem Workflow (`/projektstatus`-Skill konsumieren, niemand außer mir editiert Live-Markdown). Testphase = beide Dateien parallel führen.
 - **Abgrenzung:** TP36 ist Querschnitt, nicht Kern-BF. Eigene Session, eigener Handoff. Nicht heute.
+- 🔴 **Klarstellung 2026-09-06:** **unabhängig vom TP37-Substrat** — die Live-Daten-CustomFields (Punkt 1) hängen an den **4 bestehenden `dcim.Device`**, nicht an neuen VM/Service-Objekten → TP36 kann **parallel/vorgezogen** laufen. Datenmodell: native `extras.CustomField` (Compliance-Zahl kommt aus GC selbst). ⚠️ **Namensfalle bereinigt:** das Skript `nautobot/tp36-cf-estate-seed.py` gehörte **nie** zu TP36 — es ist die TP44-CF-Estate-Befüllung und heißt seit 2026-09-06 `tp44-cf-estate-seed.py`. TP36 hat **noch kein** Skript (`gc-snapshot.py` ist zu bauen).
 - **Verzahnt mit:** TP22 (Nautobot-GC als Vorbild), TP35 (geht Hand in Hand — beide sind „SSoT + Konsolidierung"), `bf-infra/CLAUDE.md`-Lessons.
 - **Referenzen:** Lessons-Block-Eintrag „Manuell gepflegte Doku mit Live-Daten verliert gegen die Realität" · Handoff Session A 2026-08-28.
 
@@ -3168,10 +3180,10 @@ Dauerläufer am dw. Cross-Projekt (teilzeitladen.xyz). Handoff:
      „wo läuft was" steht.
   2. **Dienste abbilden** — `ipam.Service` je exponiertem Port (Caddy `:80/:443`, AdGuard `:53`,
      Nautobot `:8080`, n8n `:5678`, …). Das ist Nautobot-Kernmodell, **keine eigene App nötig**.
-  3. **CF-Connectoren als erster Anwendungsfall** — Tunnel (`bf-public`, historisch `bf-mm`/`bf-nas`/`bf-pve`)
-     als Objekt, Connector als Relation Tunnel↔Host, Ingress-Regel als Hostname→Backend-Paar.
-     Modellwahl offen: Custom Fields + Relationships auf Bestandsmodellen **oder** eine kleine eigene App.
-     🔴 **Erst Punkt 1–2 entscheiden, dann diese Frage** — umgekehrt entsteht ein Modell für einen Sonderfall.
+  3. ✅ **CF-Connectoren — ERLEDIGT via [TP44](#tp44) (Etappe 1, 2026-09-02).** Die Modellwahl ist damit
+     entschieden: **native `nautobot.cloud`-Modelle** (Tunnel/WARP = `CloudNetwork`, VPC/Hyperdrive/Worker/
+     Access-App = `CloudService`, IDs/Ports/Origins in `extra_config`), **keine eigene App**. Offen nur noch
+     TP44 Etappe 2 (CF-API→Nautobot-Sync). ⇒ **Punkt 1+2 unten sind der echte Rest von TP37.**
   4. **Drift-Check** — Skript liest CF-API (`cfd_tunnel` + `configurations`) und vergleicht gegen Nautobot,
      analog `nautobot/gc-configplan.py --refresh-compliance`. **Read-only zuerst**; ob Nautobot je nach
      Cloudflare *schreibt*, ist eine spätere, eigene Entscheidung.
@@ -3189,7 +3201,40 @@ Dauerläufer am dw. Cross-Projekt (teilzeitladen.xyz). Handoff:
   die Pipeline ist stabil und **104/104 compliant**. TP37 vergrößert die Angriffsfläche dieser Pipeline.
   Deshalb Punkt 1–2 als eigener, abnehmbarer Schritt **mit Compliance-Gegenprobe danach**, nicht als
   Nebeneffekt von Punkt 3.
-- **Status:** 🔜 angelegt 2026-08-30, Scope-Ausarbeitung in eigener Session. Kein Runbook.
+- **Status:** ⏳ **Punkt 3 (CF) ✅ via TP44; Punkt 1+2 (Substrat + Dienste) offen** — das ist die
+  fehlende Voraussetzung für TP34. Datenmodell **entschieden 2026-09-06 (native Modelle:
+  `virtualization.Cluster/VirtualMachine` + `ipam.Service`, keine App)**. Runbook liegt jetzt vor:
+  [`handoff-20260906-tp37-34-36-plan.md`](handoff-20260906-tp37-34-36-plan.md). Live-Ausgangslage:
+  VM 0 · Cluster 0 · `ipam.Service` 0 · CustomField 0 (2026-09-06 gegen die API gelesen).
+
+---
+
+<a id="tp44"></a>
+### TP44 — Cloudflare-Estate als Dokumentations-SSoT in Nautobot ▸ ⏳ **Etappe 1 ✅ live (2026-09-02), Quick-Index nachgezogen 2026-09-06**
+> **Entscheid (User, 2026-09-02):** die volle CF-Estate (Tunnel + WARP-Connector + VPC-Service +
+> Hyperdrive + Workers + alle Access-Apps) als strukturierte, abfragbare SSoT in Nautobot abbilden —
+> **etappenweise: manuell jetzt, Sync später.** Nautobot kann CF nicht steuern → „SSoT" heißt
+> **Dokumentations-SSoT; CF bleibt operativer Master.** Detail-Handoff:
+> [`handoff-20260902-cf-estate-nautobot-ssot.md`](handoff-20260902-cf-estate-nautobot-ssot.md).
+
+- **Warum eigenes TP, nicht TP36:** TP36 ist eng auf `teilprojekte.md`-Live-Daten geschnitten; gleiche
+  Idee (Nautobot als Doku-SSoT), andere Dimension. TP44 = nächste freie Nummer nach TP43.
+- **Modell (native `nautobot.cloud`, Nautobot 3.1.7 — keine eigene App):** `Manufacturer "Cloudflare"` →
+  `CloudAccount` (`393c051f…`) → `CloudResourceType ×6` → `CloudNetwork ×4` (`bf-public`/`fm`/`terpene-db`/
+  `bf-core-mesh`) + `CloudService ×14`; Service↔Tunnel über das Through-Modell
+  `cloud-service-network-assignments` (3 Rows). IDs/Ports/Hostnames/Origins je Objekt in `extra_config`.
+- **Werkzeug:** `nautobot/tp44-cf-estate-seed.py` — idempotenter Seeder (Re-Run = 26/26 „existiert"),
+  Datenstand inline (Live-CF-Inventur 2026-09-02). Token aus `docs/nas-vlan20/stacks/210-nautobot.yml`.
+- ✅ **Verifikation 2026-09-06 (live gegen die API):** CloudAccount 1 · ResourceType 6 · CloudNetwork 4 ·
+  CloudService 14 — unverändert seit 09-02.
+- 🔴 **Gotchas für Etappe 2:** `CloudService.cloud_networks` ist `read_only` (nur Through-Rows schreiben/
+  lesen) · VPC-Service-API unter `connectivity/directory/services` (PUT, voller Body) · Repo-`CF_API_TOKEN`
+  darf kein Workers-VPC → dort über den `cloudflare`-MCP-Credential.
+- **Offen (Etappe 2, eigene Session):** (1) CF-API→Nautobot-Sync (Python/n8n, analog golden-config-bot) →
+  driftfrei; (2) IPAM-Prefixe `10.40.0.0/16` + `10.101.0.0/24` anlegen, dann greifen die Prefix-Assignments
+  automatisch.
+- **Beziehung zu TP37:** TP44 hat **TP37 Punkt 3** (CF-Connectoren) vorweggenommen — dieselbe native-Modell-
+  Linie, die TP37 P1+2 (Substrat/Dienste) fortsetzt.
 
 ---