diff --git a/CLAUDE.md b/CLAUDE.md
index 4e2148c..5a81bfb 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -122,7 +122,9 @@ GW je VLAN = `.1` (crs326-core L3) · Mgmt VLAN99: core `.99.1`, branch `.99.2`,
   🔴 **Ein GC-Recovery von null erzeugt einen Core, in den Nautobot nicht mehr per SSH kommt** — die
   Pipeline wäre tot. Gleiche Lücke wie die DHCP-Reservierungen. **Merkregel: was auf dem Gerät existiert,
   aber nicht im Template, ist eine Recovery-Lücke, auch wenn Compliance 140/140 grün meldet** — die Zahl
-  prüft nur, was gerendert wird. Ablösung durch Komodo (native MCP) geplant.
+  prüft nur, was gerendert wird. Systematisch erfasst in **[TP48](docs/teilprojekte.md#tp48)** (Gitea #75),
+  der auch prüft, ob Ansible Nautobot als SSoT ablösen kann. ⚠️ **Nicht Komodo** — es verwaltet Container,
+  nicht RouterOS-Config (frühere Notiz hier war eine Kategorie-Verwechslung).
 
 ---
 
diff --git a/docs/teilprojekte-archiv.md b/docs/teilprojekte-archiv.md
index af0659c..3b5839f 100644
--- a/docs/teilprojekte-archiv.md
+++ b/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>
diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md
index 9f7b710..5dcf806 100644
--- a/docs/teilprojekte.md
+++ b/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.