# Handoff 2026-09-02 — CF-Estate als SSoT in Nautobot (TP44, Etappe 1)

> Scope: die Cloudflare-Infrastruktur (Tunnel + App-Ebene) als strukturierte, abfragbare SSoT in
> Nautobot abbilden. Etappe 1 = **manuelle Erstbefüllung** über die nativen `nautobot.cloud`-Modelle.
> Ausgelöst aus der DB-Pfad-Session (siehe `cf-tunnel-mapping.md` §17).

## Entscheidung (User, 2026-09-02)

- **SSoT-Modus:** Etappen — *manuell jetzt, Sync später*. `cf-tunnel-mapping.md` wird zum Snapshot/Zeiger.
- **Scope Etappe 1:** *volle CF-Estate* (Tunnel + WARP-Connector + VPC-Service + Hyperdrive + Workers +
  alle Access-Apps).
- **Grundsatz:** Nautobot kann CF **nicht steuern** → „SSoT" = **Dokumentations**-SSoT. CF bleibt
  operativer Master.

## Warum ein eigenes TP (TP44), nicht TP36

TP36 ist in `teilprojekte.md` eng auf *`teilprojekte.md`-Live-Daten + Datei-Aufteilung* geschnitten.
Dieselbe Idee (Nautobot als Doku-SSoT), aber andere Dimension → **TP44** (nächste freie Nummer nach TP43).
Quick-Index-Zeile + TP-Abschnitt in `teilprojekte.md` sind **noch offen** (die Datei trug bei dieser
Session fremde, ungestagte Änderungen — bewusst nicht mit angefasst, um den Commit sauber zu halten).

## Modell (Nautobot 3.1.7, App `nautobot.cloud`)

```
Manufacturer "Cloudflare"
  └─ CloudAccount "Cloudflare" (account_number = 393c051f3accf51881d6c98fc5b66c36)
       ├─ CloudResourceType ×6
       │    cloudflared Tunnel · WARP Connector        → cloud.cloudnetwork
       │    VPC Service · Hyperdrive · Worker · Access Application → cloud.cloudservice
       ├─ CloudNetwork ×4   bf-public · fm.emsenhuber.net · terpene-db · bf-core-mesh
       └─ CloudService ×14  VPC terpene-db · Hyperdrive terpene(ro)+terpene-rw ·
                            Worker terpene+blaueblueten-n8n · 9× Access-App
```

- **IDs/Ports/Hostnames/Origins** liegen je Objekt in `extra_config` (JSON).
- **Service↔Tunnel-Verknüpfung** über das Through-Modell `cloud-service-network-assignments` (3 Rows):
  `terpene-db↔terpene-db`, `*.emsenhuber.net↔bf-public`, `hass, vw, gitea↔bf-public`.
- **Prefix-Routen** (`10.40.0.0/16` bf-core-mesh, `10.101.0.0/24` fm) sind **nicht** als
  `cloud-network-prefix-assignments` gesetzt, weil die Prefixe nicht in IPAM existieren → in
  `extra_config.route` belassen (best-effort im Seeder, greift automatisch, sobald die Prefixe in IPAM sind).

## Werkzeug

`nautobot/tp44-cf-estate-seed.py` — **idempotenter** Seeder (get-or-create), Datenstand als Inline-Struktur.
Token aus `docs/nas-vlan20/stacks/210-nautobot.yml` (gitignored). Aufruf: Dry-Run default,
`--commit` schreibt. Re-Run = 26/26 „existiert".
*(Datei am 2026-09-06 von `tp36-…` auf `tp44-cf-estate-seed.py` umbenannt — Präfix jetzt korrekt.)*

## Gotchas (für Etappe 2 / Folgesessions)

- 🔴 **`CloudService.cloud_networks` ist im Serializer `read_only` und bleibt bei GET leer** — die
  Verknüpfung wird **ausschließlich** über `cloud-service-network-assignments` geschrieben UND gelesen.
  Nicht am leeren Convenience-Feld verzweifeln; die Through-Rows sind die Wahrheit.
- VPC-Service-API liegt unter `connectivity/directory/services` (Update = **PUT**, voller Body), nicht `/vpc/`.
- Der Repo-`CF_API_TOKEN` darf `cfd_tunnel`, aber **nicht** Workers-VPC (`connectivity/directory`) — dort
  über den `cloudflare`-MCP-Credential gehen.

## Offen (Etappe 2, eigene Session)

1. **CF-API→Nautobot-Sync** (Python/n8n): Inline-Daten im Seeder durch Live-Pull ersetzen, periodisch
   (analog golden-config-bot). Dann ist Nautobot driftfrei.
2. ✅ **TP44 in `teilprojekte.md`** eingetragen (Quick-Index + Abschnitt + Ist-Stand) — 2026-09-06.
3. IPAM-Prefixe `10.40.0.0/16` + `10.101.0.0/24` anlegen → dann greifen die Prefix-Assignments automatisch.
4. ✅ Seeder-Datei nach `tp44-cf-estate-seed.py` umbenannt — 2026-09-06.

## Verifikation (2026-09-02)

Counts: CloudAccount 1 · ResourceType 6 · CloudNetwork 4 · CloudService 14 · Service-Network-Assignments 3.
Idempotenz-Gegenprobe grün.