bf-infra/docs/handoff-20260906-tp37-34-36-plan.md

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.