TP10: Mesh-DDNS-Updater gebaut, Handoff für Finalisierung

Skript `tp10-ddns-bf4` auf crs326-core angelegt (MIT, Basis bajodel/mikrotik-cloudflare-dns):
- WAN-IP aus DHCP-Lease (client1/vlan100), NICHT von Echo-Diensten
- check-certificate=yes, Public-IPv4-Guard, Idempotenz, Token als globale Variable

CF_DNS_API_TOKEN (eng gescoped: Zone→DNS:Edit nur emsenhuber.net/bf4) liegt
in ~/.secrets/credentials.env und ist als cfDdnsToken auf Core gesetzt.

Offen: Global-Scope-Problem (Variable im Skript nicht sichtbar) — Handlauf 1+2,
Scheduler, Positiv-Test, TP10 #49 schließen stehen aus.
Handoff-Dokumentation in docs/handoff-20261003-tp10-ddns-finalisierung.md.

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

docs/handoff-20261003-tp10-ddns-finalisierung.md

@@ -0,0 +1,103 @@
+# Handoff 2026-10-03 — TP10: Mesh-DDNS für bf4.emsenhuber.net — Finalisierung
+
+## Kontext / Auslöser
+TP10 (Multi-Site VPN) war im Archiv als „KERN DURCH" mit offenem DDNS-Updater für `bf4.emsenhuber.net`.
+Der A-Record wurde manuell gepflegt; bei Liwest-IP-Wechsel würden beide WG-Tunnel (fm/dw) sterben.
+
+Neuer Befund 2026-10-03: CF_DNS_API_TOKEN lag bereits in `~/.secrets/credentials.env` — DNS-Schreiben
+funktioniert, Token kann *keine* Tokens anlegen (eng gescoped: `Zone → DNS:Edit` nur `emsenhuber.net`).
+
+## Stand (alles live auf crs326-core)
+
+| Objekt | Status |
+|---|---|
+| **Skript** `tp10-ddns-bf4` | angelegt, `invalid=false` — liest WAN-IP aus DHCP-Lease `client1` (`vlan100`), Public-IPv4-Guard, `check-certificate=yes`, Idempotenz über globale Variable `CFWanIP4Cur` |
+| **Globale Variable** `cfDdnsToken` | auf Core gesetzt (`len=53`), persistiert in `/system script environment` |
+| **CF_DNS_API_TOKEN** | liegt in `~/.secrets/credentials.env` → `CF_DNS_API_TOKEN` — Scope: `Zone → DNS:Edit` nur `emsenhuber.net` (Record `bf4`, ID `dba9d9ec3b261fdb314c0f83e4e62f0d`) |
+| **Handlauf 1 (Idempotenz-Beweis)** | **PENDING** — Skript-Variable `cfDdnsToken` ist im Skript-Kontext nicht sichtbar (`:global` im Skript vs. `/system script environment`) |
+
+## Offener Kernpunkt: Global-Variable im Skript nicht sichtbar
+
+- `/system script environment print` → `cfDdnsToken` vorhanden (`count=1`, `len=53`)
+- CLI-Test: `:global cfDdnsToken; :put [:len $cfDdnsToken]` → `53` ✅
+- **ABER** im Skript (`:global cfDdnsToken; :if ([:typeof $cfDdnsToken] = "nothing")`) → `nothing`
+- **Ursache:** RouterOS-Global-Scope-Differenz zwischen CLI-Interaktion und Skript-Ausführung
+- **Workaround noch nicht angewendet** (Probe-Skript `tp10-ddns-probe` angelegt, `:log`-Ausgabe nicht bestätigt)
+
+## Abhängigkeiten (NEU: envs auf Geräten)
+
+| Gerät | Variable | Ort | Rotation bei Änderung |
+|---|---|---|---|
+| **crs326-core** | `cfDdnsToken` (53 Zeichen, `CF_DNS_API_TOKEN`) | `/system script environment` — **nicht** im Skripttext | Token-Wechsel: Wert in `/system script environment` aktualisieren, Skript unverändert |
+
+**Wichtig:** Das Token liegt **nicht** im Git, nicht im Skript, nicht in Nautobot — nur in:
+1. `~/.secrets/credentials.env` → `CF_DNS_API_TOKEN` (SSoT)
+2. `crs326-core` → `/system script environment cfDdnsToken` (Live)
+3. `mcp/cloudflare/.env` → `CF_DNS_API_TOKEN` (MCP-Bereitstellung)
+
+Bei Token-Rotation: alle drei Orte synchron ändern.
+
+## Was noch fehlt (Restmetern)
+
+1. **Global-Scope-Fix** — Skript muss die Variable lesen können.
+   - Option A: Skript per `run_command` statt als benanntes Skript ausführen (CLI-Scope)
+   - Option B: Variable per `:global cfDdnsToken` *im Skript* **vor** der Prüfung setzen (Dummy, dann überschreiben)
+   - Option C: Skript via `run_command` als Inline-Befehl ausführen (CLI-Scope)
+
+2. **Handlauf 1 (Idempotenz):** Skript einmal laufen lassen → `CFWanIP4Cur` wird gesetzt → Log `⚠ aktualisiert`
+3. **Handlauf 2 (Idempotenz-Beweis):** Skript nochmal → Log `⚠ unverändert`
+4. **Scheduler anlegen** — DHCP-Client-Trigger `client1` + stündlicher Scheduler als Netz
+5. **Positiv-Test** — A-Record kurz auf falsche IP setzen, Scheduler-Lauf abwarten, `dig bf4.emsenhuber.net` prüfen
+6. **TP10 #49 schließen** — Issue: beide Close-Bedingungen abhaken (DDNS-Updater steht, GC-konform), Label `status:done`
+7. **Handoff löschen** — diese Datei gehört ins Archiv, kein Handoff mehr nötig
+
+## Nächste Schritte (für die nächste Session)
+
+```bash
+# 1. Probe: CLI-Scope Test (läuft das Skript inline?)
+/tool fetch ... (wie im Skript, aber inline auf CLI)
+
+# 2. Falls Global-Scope im Skript unrettbar:
+#    - Skript als Scheduler-Aufruf inline bauen (DHCP-Client script=tp10-ddns-bf4)
+#    - ODER: Skript die Variable selbst setzen lassen (Dummy → überschreiben)
+
+# 3. Handlauf 1+2, Scheduler, Positiv-Test, TP10 schließen
+```
+
+## Wichtige Dateien
+
+| Datei | Zweck |
+|---|---|
+| `routeros/tp10-ddns-cf-updater.rsc` | Skript-Quelle (MIT, Copyright bajodel 2025) |
+| `routeros/tp10-ddns-cf-updater.rsc` (lokal) | importiert als `tp10-ddns-bf4` |
+| `docs/teilprojekte.md` → `### TP10` | Prosa mit Befund, Close-Bedingung |
+| `docs/teilprojekte-archiv.md` → `### TP10` | Zeiger: `♻️ REOPENED 2026-10-03` |
+| `~/.secrets/credentials.env` | `CF_DNS_API_TOKEN` (SSoT) |
+| `mcp/cloudflare/.env` | `CF_DNS_API_TOKEN` (MCP) |
+
+## Sicherheit / Governance
+
+- Token `CF_DNS_API_TOKEN` ist **eng gescoped**: `Zone → DNS:Edit` nur `emsenhuber.net`, Record `bf4`
+- **Kein** `Account → Account API Tokens:Edit` — Token kann keine neuen Tokens anlegen
+- Token liegt **nicht** im Git, nicht im Skript, nicht in Nautobot
+- Rotation: drei Orte (`credentials.env`, Core `script environment`, `mcp/cloudflare/.env`)
+
+## Bekannte offene Punkte
+
+- **Recovery-Lücke:** GC-Template rendert kein `/system script` / `/system scheduler` — Recovery von null hätte den Updater nicht. Im TP10-Issue als offener Punkt vermerkt, Entscheidung vertagt.
+- **WAN-IP-Quelle:** DHCP-Lease (korrekt), **nicht** Echo-Dienste — Liwest ist Quelle, kein Cloudflare im Pfad.
+- **Mesh-IP-Falle widerlegt:** Core holt via `api.ipify.org` korrekt `90.146.33.177` (WAN), nicht Mesh-IP `100.96.0.6`.
+
+## Nächste Session: genau das
+
+1. Global-Scope-Problem lösen (10 Min)
+2. Handlauf 1+2 (5 Min)
+3. Scheduler (DHCP-Trigger + stündlich) + Positiv-Test (15 Min)
+4. TP10 #49 `status:done` + Prosa finalisieren (5 Min)
+5. Handoff löschen, pushen
+
+**Geschätzte Restzeit: ~45 Min**
+
+---
+
+*Erstellt 2026-10-03 — Session-Handoff für Finalisierung TP10 DDNS*