TP48 (Gitea #75) angelegt: Recovery-Luecke + Ansible-Abloese-Evaluation

Anlass aus TP10-Abschluss: DDNS-Updater lebt als /system script auf dem Core, in keinem
Template — Recovery von null haette ihn nicht. Systematische Klasse, nicht Einzelfund.

- Gitea #75: TP48 mit status:todo + thema:nautobot-doku angelegt
- docs/teilprojekte.md: Prosa-Abschnitt TP48 (Inventur + Evaluationsfragen)
- Live gemessener Kernbefund: Nautobot ist heute nur TEILWEISE SSoT — datengetrieben sind
  nur Device-Felder, interfaces/IPs und zwei ConfigContexts; 7 VLAN-Defs, 37 bridge-port-
  und 19 bridge-vlan-Zeilen, Core-Firewall, NAT/Mangle/Queue/Routen stehen LITERAL im Jinja.
  Der Abloese-Vergleich lautet damit 'Ansible vs. Jinja-im-Repo', nicht 'vs. Nautobot-SSoT'.
- Nebenbefund dokumentiert (nicht angefasst): WG-Hub-Privkey im Klartext im Recovery-Skript
  tp21-wan-wg-restore auf dem Core
- Korrektur: 'Abloesung durch Komodo' (CLAUDE.md + Archiv) war eine Kategorie-Verwechslung —
  Komodo verwaltet Container, nicht RouterOS-Config; es kann diese Luecke nicht schliessen

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

docs/teilprojekte-archiv.md

@@ -781,8 +781,11 @@ Quell-IP ohnehin im erlaubten Raum. Die Datei wurde gelöscht; die Erkenntnis st
 
 ### ⚠️ Offener Restpunkt (bewusst, eigener TP)
 **Recovery-Lücke:** das GC-Template rendert **kein `/system script` / `/system scheduler`**.
-Ein Recovery von null hätte den DDNS-Updater nicht. Entscheidung vertagt (Ablösung durch Komodo
-geplant) — nicht Teil von TP10.
+Ein Recovery von null hätte den DDNS-Updater nicht. Nicht Teil von TP10 —
+**übernommen von [TP48](teilprojekte.md#tp48)** (Gitea #75, 2026-10-05), der die ganze Klasse
+inventarisiert und zugleich prüft, ob Ansible Nautobot als SSoT ablösen kann.
+*(Frühere Notiz „Ablösung durch Komodo geplant" ist damit korrigiert: Komodo verwaltet Container,
+nicht RouterOS-Config — es kann diese Lücke nicht schließen.)*
 
 
 <a id="tp14"></a>

docs/teilprojekte.md

@@ -2321,6 +2321,61 @@ eigenes Modell braucht.
 
 ---
 
+<a id="tp48"></a>
+### TP48  ·  Gitea #75 — Recovery-Lücke: Nicht-GC-Objekte + Evaluation Ansible als Nautobot-Ablösung
+
+> **Anlass:** beim Abschluss von **TP10** (2026-10-05) fiel auf, dass der DDNS-Updater als
+> `/system script` + DHCP-Trigger auf `crs326-core` lebt und in **keinem** Template steht — ein
+> Recovery von null hätte ihn nicht. Das ist eine **Klasse**, kein Einzelfund. Christophs Frage
+> daraus: *„wäre ansible in der lage, nautobot vollständig als ssot abzulösen. 1 tool für
+> doku/deployment und nicht mehrere … keine indiv-anpassungen falls einfach vermeidbar."*
+
+#### Teil 1 — Die Lücke (live geprüft 2026-10-05, `crs326-core`)
+
+| Objekt | In einem Template? |
+|---|---|
+| `tp10-ddns-bf4`, DHCP-Client `client1` `script=` | ❌ |
+| `/system script environment cfDdnsToken` (**Secret**) | ❌ und darf nie (Secret-Gebot) |
+| 8 Alt-Skripte aus TP21.1 (`tp21-dhcp-restore`, `tp21-wan-wg-restore`, …) | ❌ |
+| `/system scheduler` | — (keiner vorhanden) |
+
+🔴 **Nebenbefund:** `tp21-wan-wg-restore` trägt den **WG-Hub-Privkey im Klartext** im Skript-Körper.
+Das Skript liegt **nicht im Git** (nur auf dem Gerät), es ist also ein undokumentierter Recovery-Pfad
+mit einem Secret darin. **Aufnehmen, nicht sofort anfassen** (Christoph 2026-10-05).
+
+**Warum unsichtbar:** GC prüft **29 ComplianceFeatures** — **keines** deckt `system script`,
+`system scheduler` oder `script environment`. Die Compliance-Zahl prüft nur, **was gerendert wird**;
+was nicht gerendert wird, ist per Definition nicht „drift".
+
+#### Teil 2 — Die Evaluation
+
+🔴 **Der Befund, der die Fragestellung verschiebt:** Nautobot ist **heute schon nur teilweise SSoT.**
+Live gezählt im Template: **datengetrieben** sind nur Device-Felder, `interfaces.all()`,
+`ip_addresses.all()` und zwei ConfigContexts (`dhcp_leases`, `firewall_filter`). **Literal im Jinja**
+stehen: 7 VLAN-Definitionen, 37 `bridge-port`- und 19 `bridge-vlan`-Zeilen, die Core-Firewall,
+NAT/Mangle/Queue/Routen. Der Ablöse-Vergleich lautet also nicht „Ansible vs. Nautobot-SSoT", sondern
+„Ansible vs. **Jinja-im-Repo + Gitea + ein paar Nautobot-Felder**".
+
+| Rolle | Träger heute | Ansible-Äquivalent |
+|---|---|---|
+| TP-Index/Status | **Gitea** (seit TP36 — nicht Nautobot) | ❌ bleibt Gitea |
+| Live-Gerätedaten (Compliance) | Nautobot DCIM + GC | ⚠️ Facts + `--check` |
+| Soll-Config | GC-Templates (Jinja) | ✅ Templates/Inventar |
+| Ist-Config | GC-Backup | ⚠️ `netcommon` backup |
+| Doku/Inventar (133 Interfaces, 38 IPs, 54 Leases) | Nautobot DB | ❓ offen — Ansible hat keine DB |
+
+**Offene Punkte:** (1) was leistet Nautobot *unersetzlich* (Compliance-Historie, ConfigPlan-Audit,
+GitRepository-Sync, Secret-Maskierung)? (2) Kann Ansible Inventar+Soll+Drift aus *einer* Git-Quelle
+bedienen? (3) Migrationskosten: 29 Features + 7 `config_replace`-Regeln nachbauen? (4) **Wo bleibt
+Doku**, wenn Ansible nur deployt? (5) Werden die heutigen Sonderfälle (Literal-Blöcke wegen bewusster
+Schiefstände wie `ether2` in VLAN1) mit Ansible sauberer oder chaotischer?
+
+**Abgrenzung:** nicht TP21/TP22 (bauen GC auf), nicht TP46 (CF-SSoT). Berührt die Governance-Regel
+„Config nur über Nautobot" — bei Trägerwechsel neu zu fassen. Verwandt: TP30 (der WG-Privkey ist ein
+Rotations-Kandidat). **Ergebnis = Empfehlung mit Zahlen, keine Migration.**
+
+---
+
 ## Abgeschlossene Teilprojekte ▸ [`teilprojekte-archiv.md`](teilprojekte-archiv.md)
 
 **34 abgeschlossene TPs** liegen dort im Volltext, unverändert und mit eigenem Inhaltsverzeichnis.