SSoT: Status-Marker aus den TP-Headern entfernt, Sync-Werkzeug auf Anlege-Richtung festgelegt

Die `### TPnn`-Header trugen weiterhin Status-Anspruche (▸ ✅ FERTIG …, ▸ ⏳ CUTOVER …),
obwohl Index/Status seit dem TP36-Cutover in Gitea liegt. Das war eine dritte Statusquelle,
die den Labels nachlief — Header-Marker datierten teils Wochen vor dem Issue-Update.

- 75 Header (32 aktiv + 43 Archiv) auf `### TPnn · Gitea #N — <Titel> — <Caveat>` umgestellt.
  Caveats, Warnungen, Querverweise und Archiv-Links bleiben erhalten, nur der Status faellt weg.
  Status-Marker im Fliesstext (Messchronik, Unterpunkte) bleiben — sie beschreiben Historie.
- TP47 fehlte als Gitea-Issue komplett (nur in der Datei seit 808d3a1) -> als #74 angelegt.
- bin/gitea-tp-sync.py schrieb in die falsche Richtung: der Abgleich leitete den Zielzustand
  aus dem Datei-Marker ab (fest ✅) und haette #24 (TP34, bewusst status:dropped) auf status:done
  gezogen. Jetzt werden nur noch FEHLENDE Archiv-Issues angelegt, bestehende nie angefasst.
- CLAUDE.md: Header-Form + Werkzeug-Richtung festgehalten.
- Announcement 2026-10-03 für die naechste Session.

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

docs/handoff-20260928-core-wghub-ping-fix.md

@@ -0,0 +1,52 @@
+# Handoff 2026-09-28 — Core erreicht FM/DW-Spoke-Netze nicht aus eigener Kraft
+
+## Kontext / Auslöser
+Christoph konnte von Notebook + macmini immer `10.101.0.254` (FM-Standort-GW) pingen, eine
+überforderte Vorgänger-Session hatte behauptet, der Core „komme dort nicht hin". Befund
+sollte jetzt geprüft und ausgeräumt werden.
+
+## Befund (alles live verifiziert 2026-09-28, crs326-core)
+| Quelle | → 10.101.0.254 (FM-GW) | → 10.101.0.10 (FM-Host) |
+|---|---|---|
+| macmini (VLAN20, gw 10.40.20.1) | ✅ 0 % Loss | ✅ 0 % Loss |
+| Notebook (VLAN10, gw 10.40.10.1) | ✅ 0 % Loss | ✅ 0 % Loss |
+| **Core default** (`/ping` ohne src) | ❌ **100 % Loss** | ❌ **100 % Loss** |
+| **Core mit `src-address=10.40.10.1`** | ✅ **0 % Loss** (ttl 64) | ✅ **0 % Loss** (ttl 63) |
+
+## Root Cause
+`wg-hub` (TP10 Multi-Site VPN Hub) hat **keine IP-Adresse** — weder live
+(`/ip address print where interface="wg-hub"` → leer) noch im GC-Template
+(`mikrotik_routeros.j2:379`, nur listen-port/mtu/name/private-key).
+
+FM-seitig erlaubt die FritzBox als AllowedIPs Richtung Hub `10.40.0.0/16`
+(`routeros/fritzbox-wg-lanlan-klickanleitung.md`). Weitergeleiteter Client-Traffic
+(Quell-IP 10.40.x) liegt in diesem Raum → läuft. **Core-eigener** Traffic ohne
+explizite Quell-IP: RouterOS wählt mangels IP auf wg-hub eine Quell-IP **außerhalb**
+von 10.40.0.0/16 (vermutlich WAN `90.146.33.177`) → FM routet die Antwort nicht zurück
+→ Timeout. Der Tunnel selbst ist up (FM-Peer last-handshake ~1m45s, rx 140.8 GiB).
+
+## SSoT / Governance
+Die Core-Config liegt im GC-Template `nautobot/mikrotik_routeros.j2`. Dort existieren:
+- `:375` `/ip route add ... dst-address=10.101.0.0/24 gateway=wg-hub comment="TP10: FM spoke"`
+- `:376` `/ip route add ... dst-address=10.95.10.0/24 gateway=wg-hub comment="TP10: DW spoke"`
+- `:379-381` wg-hub Interface + fm/dw Peers (Privkey redacted)
+
+Ein Fix gehört **ins Template**, nicht als Direkt-Write aufs Gerät (GC-Compliance-Regel).
+Deploy via `nautobot/gc-configplan.py` / GC-Job „Backup → Intended → Compliance".
+
+## Fix-Optionen (noch nicht entschieden)
+1. **`preferred-source` auf die zwei TP10-Routen** (Zeile 375/376, z. B. `10.40.10.1`).
+   Kein FM-Eingriff nötig (FM erlaubt 10.40.0.0/16 bereits). Minimal-invasiv. **Empfohlen.**
+2. wg-hub eine IP geben (z. B. dedizierte Adresse aus 10.40.0.0/16) — mehr Risiko, IP-Raum-
+   Eingriff, FM-Abgleich nötig.
+3. FM-seitig AllowedIPs um die Core-WAN-IP erweitern — FritzBox-WG-Config eingeschränkt, nicht sauber.
+
+## Offene Entscheidungen
+- Welche `preferred-source`-IP? (10.40.10.1 = MAIN-SVI ist naheliegend.)
+- TP10 ist im Archiv „KERN DURCH, offen nur DDNS-Updater". Neuer Befund → TP10-Issue
+  `reopen` + Prosa zurück nach `teilprojekte.md`, oder als eigenes kleines TP? (Christoph-Entscheid.)
+- Fix jetzt ausführen oder nur dokumentieren?
+
+## Aufwandsschätzung (Core-Ping-Fix)
+Klein. 2 Zeilen Template-Edit + ein GC-Deploy-Zyklus (~30–60 min inkl. Backup/Intended/Compliance)
++ Ping-Verifikation. Kein Hardware-/FM-Eingriff bei Option 1.