# Handoff 2026-09-06 — Plan TP37 (P1+2) → TP34, TP36 parallel

> **Sessiontyp:** „erst planen, nichts bauen" (User-Entscheid 2026-09-06). **Kein Nautobot-Write.**
> Dieses Dokument ist der verzahnte Runbook für die drei nachfolgenden Build-Sessions.
> Datenmodell-Entscheid: **native Nautobot-Modelle, keine eigene App** (konsistent zu TP44).

## 1. Ausgangslage — live gegen die API gelesen (2026-09-06)

| | Wert | Bedeutung |
|---|---|---|
| Nautobot | `http://10.40.20.30:8080`, v3.1.7 | Apps: **Golden Config 3.0.7 + Nornir** (cloud-Modelle sind Core) |
| Devices | 9 | 4 aktive MikroTik + decommissioned/Rest — in Build-Schritt 0 verifizieren |
| **VirtualMachines** | **0** | TP37 P1 offen |
| **Clusters** | **0** | TP37 P1 offen |
| **ipam.Service** | **0** | TP37 P2 offen |
| **CustomFields** | **0** | TP36 offen |
| Relationships / Tags | 0 / 0 | — |
| `cloud.*` (Account/ResType/Network/Service) | 1 / 6 / 4 / 14 | ✅ **TP44 Etappe 1** — CF-Estate steht |

**Kernbefund:** TP37 **Punkt 3 (CF-Connectoren) ist durch TP44 erledigt** (native cloud-Modelle). Echt
offen bleibt das **Substrat** (P1) und die **Dienste** (P2) — und genau darauf sitzt TP34.

## 2. Entscheidungen (User, 2026-09-06)

1. **Erst planen, nichts bauen** — diese Session schreibt nichts nach Nautobot.
2. **Native Modelle** — `virtualization.Cluster/VirtualMachine` + `ipam.Service`, **keine eigene App**.
3. **TP44-Doku aufgeräumt** — Quick-Index-Zeile + Abschnitt in `teilprojekte.md`, Seeder
   `nautobot/tp36-…` → `tp44-cf-estate-seed.py` umbenannt.

## 3. Reihenfolge / Abhängigkeit (korrigiert)

```
TP37 P3 (CF-Connectoren) ─── ✅ ERLEDIGT via TP44 ───┐
                                                     │  gleiche native-Modell-Linie
TP37 P1 (Hosts/Container → VirtualMachine)           │
        └─► TP37 P2 (Dienste → ipam.Service) ─► TP34 (Caddyfile via GC)

TP36 (CustomFields auf den 4 Devices + Datei-Split) ── ∥ unabhängig, jederzeit parallel
```

**Grund für die Unabhängigkeit von TP36:** seine Live-Daten-CustomFields hängen an den **bestehenden
`dcim.Device`**, nicht an neuen VM/Service-Objekten. TP34 dagegen kann ohne die Backend-`ipam.Service`
aus P2 nichts rendern → **TP37 vor TP34** bleibt zwingend.

---

## 4. TP37 Punkt 1 — Substrat: Hosts + Container als VMs

**Modell-Mapping (nativ):**
- `virtualization.ClusterType`: `Proxmox VE`, `Synology Docker`, `Docker Desktop`.
- `virtualization.Cluster`: `pve`, `nas-bf`, `macmini` (je einer, passender ClusterType).
  *(Die physischen Hosts als eigene `dcim.Device` sind **optional** und kommen frühestens in einer
  Etappe 2 — für den Doku-SSoT reicht der Cluster als Gruppierung. Empfehlung: Etappe 1 ohne Host-Devices.)*
- `virtualization.VirtualMachine` je Workload, mit `cluster` + `primary_ip4`:
  - **pve:** alle LXCs (u.a. `platform-pg` 105/`.20.20`, Docker-LXC 400/`.20.126`, `mcast-relay` 108,
    influxdb, MariaDB 302/`.20.23`, …).
  - **nas-bf (DS923, Portainer ep14):** Nautobot-Stack-Container, ggf. Caddy/weitere.
  - **macmini (Docker Desktop):** `n8n`/`n8n-redis`/`n8n-mcp`/`gitea-mcp` + terpene-Worker `:8890`.

**Build-Schritt 0 (read-only Inventur, BEVOR geseedet wird):** je Host die Workloads mit Name, Rolle,
primärer IP enumerieren — `pct list` + `pct config <id>` über **pve-mcp**, Portainer-API (ep14) für die
NAS, `docker ps` auf dem macmini. Ergebnis in eine **Inline-Datenstruktur** (Muster: `tp44-cf-estate-seed.py`)
→ idempotenter Seeder `nautobot/tp37-substrat-seed.py` (get-or-create, Dry-Run default, `--commit`).

## 5. TP37 Punkt 2 — Dienste als `ipam.Service`

- Je exponiertem Port ein `ipam.Service`, an die VM (bzw. später das Device) gebunden, das ihn betreibt:
  Caddy `:80/:443`, AdGuard `:53` (bf1/bf2), Nautobot `:8080`, n8n `:5678`, HA `:8123`, Portainer `:9443`,
  `pve-mcp :3000`, gitea, Vaultwarden, …
- **Quelle ohne Raten:** die Ports stehen in `CLAUDE.md` (Hardware/Tooling) **und** in den
  `extra_config.origin/port`-Feldern der TP44-`CloudService`-Objekte — gegeneinander abgleichen.
- Idempotenter Seeder `nautobot/tp37-dienste-seed.py`.

## 6. 🔴 Auflage: Compliance-Gegenprobe (aus TP37 selbst)

Nach P1+2 **muss** `python3 nautobot/gc-transaktion.py status` bzw. `gc-configplan.py --refresh-compliance`
zeigen, dass die Geräte-Compliance **unverändert 140/140** ist. VMs/Services hinzuzufügen darf die
Golden-Config-Pipeline der 4 MikroTik **nicht** berühren. P1 und P2 sind je ein **abnehmbarer** Schritt
mit dieser Gegenprobe danach — nicht als Nebeneffekt von etwas anderem.

---

## 7. TP34 — Caddyfile via Golden Config (nach P2)

- **Vorbedingung:** Backend-Dienste existieren als `ipam.Service` (P2).
- **Modell (nativ):** Proxy-Route = **Relationship** (oder CustomField) Frontend `caddy`-Service ↔ Backend-
  Service, plus den öffentlichen Hostname am Backend. GC-Job + Jinja rendert den Caddyfile, Diff gegen
  live `caddy-bf1`, neue ComplianceRule `caddyfile`.
- **Schritt 0 / Quick-Win (sobald gebaut wird):** `terpene.teilzeitladen.xyz → http://10.40.20.167:8890`
  als **manueller** Caddy-Block, damit terpene läuft, bevor die GC-Pipeline steht.
- ⚠️ **Offener Design-Punkt:** Caddy ist **kein RouterOS-Gerät** — GC an ein Nicht-Netzgerät zu deployen
  (Caddy-Reload) ist neu (die „nicht in TP37"-Grenze). Deploy-Pfad in der TP34-Build-Session entscheiden.

## 8. TP36 — Live-Daten-CustomFields + Datei-Split (parallel)

- **CustomFields auf `dcim.Device`:** `ros_version`, `compliance_pct`, `dhcp_server_count`, `mgmt_ip`,
  `dns_upstream_mode`. Compliance-Zahl kommt aus **GC selbst**, der Rest aus MikroMCP/REST.
- **Skript `nautobot/gc-snapshot.py`** (neu — existiert noch nicht): liest live, setzt die CFs, rendert
  `docs/teilprojekte-aktuell.md` als **read-only Snapshot**.
- **Datei-Split:** `teilprojekte-index.md` (nur aktive TPs, eine Zeile) · `teilprojekte-aktuell.md`
  (Live-Snapshot) · `teilprojekte-archiv.md` (unverändert). `/projektstatus` liest **Index + Archiv**.
- **Unabhängig von TP37** → kann sofort/parallel starten.

---

## 9. Empfohlene Reihenfolge der Build-Sessions

1. **TP37 P1** (Substrat) — Inventur → Seeder → Compliance-Gegenprobe.
2. **TP37 P2** (Dienste) — schließt an P1 an, gleiche Gegenprobe.
3. **TP34** — nach P2 (Quick-Win terpene als Schritt 0).
4. **TP36** — jederzeit parallel zu 1–3.

## 10. Offene Entscheidungen je Build-Session (nicht heute)

- **TP34:** Proxy-Route-Modell (Relationship vs. CustomField) + Caddy-Deploy-Pfad (GC an Nicht-Netzgerät).
- **TP37:** Hosts als eigene `dcim.Device` anlegen oder nur Cluster? (Empfehlung: Etappe 1 nur Cluster.)
- **TP36:** genaues Feld-Set + wie oft `gc-snapshot.py` läuft (Bot analog golden-config vs. on-demand).

## 11. Was diese Session geändert hat (nur Doku)

- `nautobot/tp36-cf-estate-seed.py` → **`nautobot/tp44-cf-estate-seed.py`** umbenannt (+ 4 Referenzen,
  + Docstring-Titel TP36→TP44).
- `teilprojekte.md`: Quick-Index-Zeile TP44; Ist-Stand-Bullet 2026-09-06; TP34/TP36/TP37-Abschnitte auf
  den korrigierten Stand gezogen; **neuer TP44-Abschnitt** mit Anker.
- `handoff-20260902-cf-estate-nautobot-ssot.md` + `cf-tunnel-mapping.md`: Dateiname-Referenzen + erledigte
  TODOs nachgezogen.
- **TP23-Quick-Index-Zeile** (fremde, korrekte Fremd-Änderung ✅→⏳) auf User-Okay mit übernommen.