- Wireshark-Analyse (hms-mqtt-publisher PR #110, HMS-800W-2T): Poll <30 s
resettet den Countdown, Cloud-Updates fallen aus; nach 4-5 min startet
die DTU eine neue TCP-Session -- und dabei (Log-Beweis 09-14) eine
vollstaendige WiFi-Disassoziation inkl. DHCP-Churn. Zyklus-Abstaende
decken sich aufs Minutenkomma. Fund F damit neu interpretiert.
- Ursache: hmsmqtt 30500 ms (Grenzzone). Hebel = Poll-Rate, nicht
DNS-Hoheit: Christoph hat 45000 ms gesetzt (09-14 abends).
- Verifikation ab 09-15 frueh (Log-Lauf ohne 4-5-min-Zyklen = Fund-F-
Abschlussbeweis); Fallback: DTU-Firmware klaeren (ha-hoymiles-wifi#134).
- Issue #17, Kommentar #228.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Recherche 09-14 abends: HMS-XXXXW-2T (W = eingebaute DTU, protobuf-
Protokoll) wird von AhoyDTU/OpenDTU nicht unterstuetzt (lumapu/ahoy#1189
seit 09-2023 offen; Christophs eigene AhoyDTU inkompatibel). Lokale Tools
(hmsmqtt, dtuGateway, ha-hoymiles-wifi) nehmen die DTU nicht von der Luft.
Einziger Airtime-Heibel bleibt DNS-Hoheit ueber die Cloud -- von Christoph
bewusst zurueckgestellt (Cloud-Aufzeichnungen bis hmsmqtt + WLAN stabil).
Korrektur auch als Issue-17-Kommentar #227; Messplan #225 bleibt gueltig.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- DTU geht mit der Sonne an/ab (09-14: 07:09-19:35) -- nachts unbetelligt,
20:37-Verlust passierte ohne sie. Tagsueber ~5:05-Zyklus auf ch11 bei -53.
- Messplan (Issue #17, Kommentar #225): Referenz-Client auf ch11 pinnen,
30-60 min Ping, Korrelation gegen die 5:05-Taktmarken.
- Hebel falls messbar: OpenDTU/AhoyDTU-Dongle statt Cloud-DTU (5-Min-Takt
ist S-Miles-Telemetrie per Design, kein Ethernet an der DTU-WLite,
Pin auf anderen AP kontraindiziert).
- 20:37-Nachtrag zur Abnahme: Totalverlust eigener Klasse (-89-Roam +
iOS-Aufgeben, identisch 19:01 mit ft=no) -- keine ft=yes-Regression.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Live-Beleg 2026-09-14 20:33-20:34, Terrasse: nur roamed-to-Events, keine
disconnected-Zeile mehr im Fenster (davor 20:29/20:31 noch zwei volle
Trennungen). Hebel (1) damit komplett abgenommen; offen bleibt nur noch
der Deckungsfix Variante 3.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- CLAUDE.md: 09-04-Entscheid (ft=no) mit Ruecknahme 09-14 konsistent gemacht —
Weg, Plan-ID, Compliance-Stand und CAP-Abnahme vermerkt, damit keine
Folgesession einen ft=no-Zustand liest, der nicht mehr existiert.
- teilprojekte.md TP25: Hebel (1) auf DURCH gesetzt (Sequenz, Plan b1135f3e,
Asserts, Polling-Timeout-Folgenlosigkeit), offene Abnahme = Terrassen-Anruf.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Go Christoph 2026-09-14 nach Terrasse-In-situ-Session: mit ft=no ist jeder
Roam eine Voll-Reassoziation -- darin starben 2 Anrufe.
- Known-Good-Stand vor Hebel-2: Fund-E-Abschlussmessung 09-02 lief auf
ft=yes/ft-over-ds=yes + 7.24.1 ruhig (4 reauth/8,6 h, 0 Ausfaelle).
- Template [6c]-Kommentar auf Stand 09-14 gebracht: signal-range-Boden
geprueft und gescheitert (kein band-Property, cap-wifiN-Rejoin-Falle).
- Commands-File docs/transaktionen/TP25-ft-yes-secmain.commands.rsc fuer
den GC-Deploy via gc-manual-plan.py (Dry-Run gelesen).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Handoff 2026-09-14: iPhone-Flapping auf der Terrasse = 5-GHz-Zellkante
(-76..-81) plus client-getriebene Band-Wechsel in der Uberlappungszone
-70..-77; vor ap2 (1-2 m) -49..-51 dBm, >2 min stabil => HW-Verdacht
(23:02-Befund 2 m/-80) in situ widerlegt, kein Tausch begruendet.
- Hebel "Access-List-Band-Boden < -76 auf 5G" nicht sauber ausdrueckbar:
kein band-Property, Interface-Scoping bricht am cap-wifiN-Rejoin,
SSID-/MAC-Scope trae fen 2,4 GHz mit (Lockout-Risiko). Nicht umgesetzt.
- TP30: Posten #9 vorgemerkt -- GITEA_ACCESS_TOKEN am 09-14 ueber einen
Fehlerpfad (URL-Konstruktion -> ValueError-Traceback) ins Transkript
geraten; sechster Vorfall der Leak-Familie, neue Unterklasse.
- Gitea: TP25-Issue #17 Kommentar 217, TP30-Issue #20 Kommentar 218.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
5/6 Schichten durch; Schicht-3-pro-Projekt-Rollout laut Abgrenzung eigene
Sessions; On-Network-mikromcp-Smoketest als Merkposten → TP30 #20.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Diagnose: die GC-Backups standen seit 2026-09-04, weil NIE ein Scheduler
existierte — Backup/Intended/Compliance liefen nur manuell aus Sessions. Die
"2×/Tag per SSH"-Annahme (CLAUDE.md Bot-Master-Zeile + gc-snapshot.py-Docstring)
war nie real; beide korrigiert.
Fix: Nautobot-Job "Execute All Golden Configuration Jobs - Multiple Device"
enabled + ScheduledJob "GC Backup+Compliance – taeglich" (platform=RouterOS,
täglich 03:30 UTC, Backup→Intended→Compliance). Sofort-Lauf SUCCESS, alle 5
Geräte backup/compliance auf 2026-09-12 10:35, frischer bf-golden-config-Commit.
Announcement-Eintrag ergänzt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
exports.zsh um die 3 von opencode bereits referenzierten, aber fehlenden
MCP_MIKROMCP_{ROUTER_AP3,CRS326_CORE,CRS326_BRANCH}_PASS ergänzt (25 Vars,
gui-env-sync 25/25 in launchd-Env). claude.json hält noch 7 Klartext-Secrets;
DRY-RUN bestätigt alle Ziel-Vars MATCH. Flip läuft bei BEENDETER App über
~/dev/.bin/schicht2-claude-json-migrate.py --apply-claude (nicht aus laufender
Session — Claude Code schreibt State in die Datei). Announcement-Eintrag ergänzt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Schicht 4 (Announcement): docs/announcements.md angelegt (Format
## YYYY-MM-DD — Titel + Betrifft/Aktion, neueste oben) + globaler Skill /news
(liegt in ~/.claude/skills/news/ UND ~/.config/opencode/skills/news/, cp kein
Symlink). /news zeigt Einträge seit dem letzten Lauf (Seen-State ~/.news-seen/).
Erste Einträge: SSoT-Cutover + TP36-Live.
Schicht 5 (Backup-Guard): abgenommen — Guard + pre-commit-Hook live verdrahtet,
hat beim TP36-Live-Commit real gegriffen. Grenze dokumentiert (check prüft nur
Existenz der Guard-Datei, nicht deren Alter).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Christoph on-site: Upstream 10.40.20.36 + .37, DNS-Rebind-Schutz-Ausnahme
bf.emsenhuber.net, Fallback-Haken "öffentliche NS bei Unreachbarkeit der
primären" gesetzt (existiert auf diesem FRITZ!OS-Stand) → Ideal-Variante,
.37-Redundanz bleibt, BF-down fällt auf public. Gitea #32 closed (status:done).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dw-FritzBox kann per DHCP nur eine DNS-IP ausliefern → "mehrere NS an die
Clients" scheidet aus. Neue Richtung: Clients → 10.95.10.1 (FB), die FB
forwardet an Upstream 10.40.20.36 + .37 (beide BF, Voll-Resolver).
- Zwingend: DNS-Rebind-Schutz-Ausnahme bf.emsenhuber.net (sonst filtert die FB
die Privat-IP-Antworten 10.40.x als Rebind weg).
- BF-down-Fallback: FRITZ!OS-"öffentliche NS bei Unreachbarkeit"-Setting, sonst
public im Alternativ-Slot (kostet .37, dann strikt-primär verifizieren).
- Sauberer als DHCP-Multi: FB ist einziger Client-Resolver, .36 löst
intern+public → public nie "zuerst" gefragt, kein NXDOMAIN-Leak.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Auslöser: portainer.bf.emsenhuber.net vom dw-Standort (WG-Tunnel up) nicht
auflösbar — dw-FritzBox kennt die interne Zone bf.emsenhuber.net nicht.
- Gitea #32 reopened (status:todo, thema:firewall-dns), Prosa aus dem Archiv
zurück nach teilprojekte.md (Archiv = ♻️-Zeiger).
- fm-Einwand live entkräftet (dig @.36): bf-Namen → 10.40.0.0/16 (über WG
erreichbar), fm-Namen → Cloudflare-Anycast, nie 10.101.x.
- Entscheidung: FritzBox verteilt per DHCP die DNS-Liste .36/.37/9.9.9.9;
.37-Redundanz bleibt, FB entlastet. NXDOMAIN-Failover-Haken + zwei
On-site-Verifikationen dokumentiert. Umsetzung = eigene On-site-Session.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- TP41 abgeschlossen: Gelis WARP via Android eingerichtet (letzter Blocker weg)
- TP43 verworfen: 420 = public CF-Worker, kein BF-Split-Horizon nötig; keine Altlasten
- TP42-Prosa nachgezogen (war closed in Gitea, Prosa stand noch in teilprojekte.md)
- Status-SSoT-Änderungen in Gitea gesetzt (#30 done, #32 dropped, #31 title-Fix)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Volltext TP44 (✅ DURCH) nach teilprojekte-archiv.md (Anker #tp44 + TOC-Zeile),
aus teilprojekte.md entfernt, Control-Plane-Themenzeile + gebrochenen intra-file
Link auf teilprojekte-archiv.md#tp44 gefixt. Gitea #33 war bereits closed/status:done.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Die Zeile "Repo-CF_API_TOKEN darf kein Workers-VPC" war falsch (live: liest
14/14). Handoff als Snapshot belassen, aber Korrektur-Hinweis ergänzt. Damit
ist die letzte Wiederholung der stale Gotcha markiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
10.40.0.0/16 (container, Route bf-core-mesh) + 10.101.0.0/24 (network,
Route fm) in Nautobot IPAM angelegt; Seeder-Re-Run hat die zwei
cloud-network-prefix-assignments eingehängt (count=2, idempotent).
Gitea #33 kommentiert, bleibt WIP (Teil B CF-Sync offen).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Doku-Drift behoben: §10-15 beschrieben das 3-Tunnel-HA bf-mm/bf-nas/bf-pve,
das seit dem TP16.3-Cutover (2026-08-27) nicht mehr existiert und eine
Folgesession zu halluzinierten Tunneln/FQDNs verleitet hatte. Neuer §0 mit
dem live gegen die CF-API gemessenen Ist-Stand (bf-public/fm/terpene-db +
warp_connector bf-core-mesh, WARP-Routen); §10-16 in <details> ARCHIV
gekapselt (Inhalt unverändert), §17 (terpene-db, aktuell) bleibt sichtbar;
§14 Mesh-live-Notiz. Deckt sich mit dem Nautobot-Seed (TP44).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- teilprojekte.md: Quick-Index-Tabelle + "Ist-Stand (Kurz)"-Block entfernt (-493 Z.),
Kopf zeigt aufs Gitea-Board (Labels status:*/thema:*); Governance/Genehmigte Ausnahmen
unter eigenem Header behalten; TP36 reframed (Nautobot->Gitea, Scope = Index/Status,
Nautobot nur noch Live-Geraetedaten). Alle 33 ### TPnn-Prosa-Abschnitte intakt.
- gitea-tp-sync.py: an das neue SSoT-Modell angepasst - aktive TPs sind SSoT direkt in
Gitea, das Tool gleicht nur noch das Archiv ab und fasst offene Issues nie an. Dry-Run 0/0.
- CLAUDE.md: Pflichtlektuere #1 = Gitea-Board (Status) + Prosa-Datei (Detail); neue Sektion
"SSoT & Branch-Konvention"; TP-Management-Sektion nachgezogen.
/projektstatus-Skill (beide globalen Kopien ~/.claude + ~/.config/opencode) auf die
Gitea-API umgestellt (Modus A Board / Modus B Markdown-Fallback) - liegt ausserhalb des Repos.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- docs/tp23-stufe6-bypass-sperre-runbook.md: separate Vor-Ort-Session; AGH-SPOF-Warnung
(nicht aus der Ferne / nicht waehrend Abwesenheit), log-only-Vorstufe -> Drop mit Auto-Revert,
Exempt/JIT-Bau, DoH-443-Grenze, Rollback + Abnahme
- teilprojekte.md: TP23-Zeiger auf den Runbook + Vor-Ort-Gate
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
TP25-kanalplan-ap1-live.json state open->committed (Nachzug aus dem
gc-transaktion commit). Dazu die zwei In-situ-Messrunden vom 09-04:
tp25-runde-1er (Walk iphone/s22) und tp25-runde-dauerping (Dauerping
ipad/iphone/macbook/s22) als Rohdaten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ap3 trug auf wifi1/wifi2 einen Werks-Inline security.ft=yes (Bring-up-Skript
tp28-ap3-phase2-cap.rsc unset !ft-over-ds, aber nicht !ft; Abnahme zaehlt nur
benannte security-Objekte -> Inline-Wert unsichtbar). Gemischtes FT-ESS =
Strong-Signal-Abbrueche (-43/-45 dBm) NUR auf ap3 bei 3/3 Strichen. Live per
!security.ft geradegezogen (uniform ft=no), Bring-up-Quelle korrigiert.
Kanalplan committed: Template auf DFS-Frequenzlisten (ch-5g-ap1=5260,5280,
ch-5g-ap2=5300,5320) + ap1-Provisioning-Zeilen (radio-mac ...E5/...E6) wieder
aufgenommen. Push nach bf-golden-config + GitRepo-Sync + refresh-compliance ->
140/140, 0 Drifts; Transaktion TP25-kanalplan-ap1-live committed.
Doku: Ist-Stand, Fund-E-Block, CLAUDE.md Punkt 5 (Merkregel: nach jeder
sec-main-FT-Aenderung jeden CAP einzeln auf security.ft pruefen).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hebel 2 (ft=no) doch gezogen: sec-main von ft=yes ft-over-ds=yes auf
ft=no ft-over-ds=no. Template (nautobot/mikrotik_routeros.j2) + Push nach
bf-golden-config + Nautobot-Sync; wifi-security damit gruen (Live stand
schon auf ft=no, das Template war der Drift).
Doku nachgezogen (CLAUDE.md Punkt 5, teilprojekte.md Ist-Stand/Quick-Index/
Fund-E-Block): Soll ft=yes ft-over-ds=yes -> ft=no ft-over-ds=no, 802.11r aus.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Die Konsole (docs/tp6-marker/server.py) war beim Multi-Pin-Umbau nicht
mitgezogen worden: hartkodiert auf 2 Clients, pinnte ueber die alte
Gegen-AP-Automatik. Jetzt:
- Client-Liste aus geraete.txt (schreibt tp25-walk-messung.sh), Fallback
auf die zwei alten MACs fuer Alt-Laeufe.
- Kein eigenes SSH mehr: je Client letzte Zeile von sampler-<name>.csv
(AP/Signal) + Ping-Verlust aus walk-ping-<name>.csv.
- N Client-Karten; Alarm, wenn ein gepinnter Client nirgends haengt.
- Pin-UI: je Client AP/Band waehlen, set/off/verify via tp25-pin-multi.sh
(POST /pinmulti). Alte 2-Client-Automatik (entscheide/pin_setzen/auto)
entfernt; tp25-pin-s22.sh liefert nur noch die map.
- tp25-runde.sh loest beim Aufraeumen den Multi-Pin statt des S22-Pins.
Doku: Ist-Stand-Block + Quick-Index + Messwerkzeug-Bullets nachgezogen,
neuer Handoff 2026-09-04.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Fuer die gepinnte Pro-AP-Abdeckungsmessung: pinnt mehrere Clients gleichzeitig
band-genau auf je einen AP (je Sonde alle cap-wifiN AUSSER dem Ziel per
access-list reject, eigener Tag TP25-PINM-<name>), iPhone bleibt frei. Loest
AP+Band -> cap-wifiN live aus der Karte (reuse tp25-pin-s22.sh map), cacht nie.
Modi set/verify/off/map. 3.2-safe (keine assoziativen Arrays, macOS /bin/bash).
access-list steht unter keiner ComplianceRule -> kein Nautobot-Drift; off raeumt
vollstaendig auf.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- tp25-walk-messung.sh: halber Refactor geschlossen — Rumpf schleift ueber die
PH_*-Arrays (pro Geraet ein Sampler + ein Core-Ping, sampler-<name>.csv /
walk-ping-<name>.csv), PID-Arrays im Cleanup, Archiv-/Echo-Block generisch.
Lief vorher unter set -u gar nicht (unbound $PHONE_MAC).
- tp25-gehweg-auswertung.py: liest N benannte Geraete per glob; altes 2-Rollen-
Schema (sampler.csv/walk-ping.csv/walk-ping-iphone.csv/beide-telefone.csv) bleibt
als Legacy-Fallback erhalten. Beide Pfade getestet.
- tp25-pin-s22.sh: karte() repariert — channel.frequency ist seit dem DFS-Kanalplan
(2026-09-03, Frequenz-Listen) ein Array; der alte Skalar-Vergleich blankte map,
wodurch ap-map.txt leer blieb. Fix nimmt bei :typeof=array das erste Element.
Live-Smoke (4 Geraete) gruen: alle erreichbar, sauberes Cleanup, korrekte AP-Map.
Naechster Schritt: In-situ-Walk (nur Zahlen, Commit/Rollback des Kanalplans separat).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Uebergabeprompt fuer die Messsession: Aufstellorte begehen, entscheiden
ob Zielzustand (Template + Commit) oder Nachjustieren. Enthaelt Messplan,
Rollback- und Commit-Weg, sowie die relevanten CLAUDE.md-Gotchas
(scan/registration-table nur am Manager, cap-wifiN wandert, DFS-CAC).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sideboard-Test fuer ap1 (TP28) plus Umsetzung des TP25-Kanalplans
in einem Zug am Manager (crs326-core):
L2 (TEST-ether3-trunk-ap1-sideboard-2, bridge-vlan, committed):
- ether3 zum AP-Trunk fuer ap1 hinzugefuegt (analog ether15/ether21)
- Template mikrotik_routeros.j2 nachgezogen: ether3 in allen VLAN-Zeilen
WLAN (TP25-kanalplan-ap1-live, wifi-channel, OFFEN bis 2026-09-10):
- ch-5g-ap1: 5180 -> Frequenz-Liste 5260,5280 (DFS Band B, ch52/56)
- ch-5g-ap2: 5220 -> Frequenz-Liste 5300,5320 (DFS Band B, ch60/64)
- Neue Provisioning-Regeln fuer ap1 (radio-mac E5=5G, E6=2G), analog ap2/ap3
- remote-cap provision fuer ap1 und ap2
Live-Ergebnis (35 Clients an der Registration-Table, vorher 30):
- ap1: 5260/5280 + 2412 (ch1), 9/9 Interfaces up
- ap2: 5300/5320 + 2462 (ch11), 9/9 up
- ap3: 5180 + 2437 (ch6), unveraendert
- Keine 5-GHz-Kollisionen mehr, 2,4-GHz sauber auf ch1/6/11
Follow-up in naechster Session: In-situ-Messungen an den Aufstellorten;
bei ok Template auf Frequenz-Listen + ap1-Provisioning-Regeln erweitern
und die offene Akte committen. Snapshot fuer Rollback liegt bereit.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
(A) DHCP-Search-Domain der 7 Netze emsenhuber.net -> bf.emsenhuber.net ueber
die GC-Pipeline (kein Direkt-Write): Template Z.133 gehoben, per
push-gc-template.py ins bf-golden-config-Repo (7a4068c4), GitRepo-Sync,
neuer manueller Job tp42-dhcp-domain in gc-configplan.py (set [find], weil
add das existierende Netz doppeln wuerde), Deploy an crs326-core.
Live 7/7 = bf.emsenhuber.net, Compliance 140/140 keine Drifts.
Nebenbefund: Remote-GC-Template hing dem lokalen hinterher (noch *.bf.lan +
router.lan) -> mit an den Live-Stand angeglichen.
Loest den Kernkonflikt: DHCP verteilte bare emsenhuber.net, Records leben
unter bf.emsenhuber.net -> bare macmini loest jetzt beim Lease-Renew.
(B) .16 (adguard_bf1) abgebaut: lag im mit FM geteilten Portainer-Stack 195
zusammen mit adguard_fm2 (.17, Standort FM). Statt Stack-Delete die compose
auf nur .17 getrimmt + redeployt (Prune). .16 weg, .17 laeuft (kurzer Blip).
Nautobot-Soll (Scope 4) an TP37 gekoppelt, separat.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gegen die Geraete gemessen: .bf.lan ist ueberall weg, DHCP-domain auf
emsenhuber.net vereinheitlicht, Core-Static + Caddyfile konsistent auf
.bf.emsenhuber.net (deckt sich mit GC-Template). Drift hat ~80% erledigt.
Kernkonflikt: DHCP verteilt bare emsenhuber.net, Records leben unter
bf.emsenhuber.net -> bare macmini loest nicht. Entscheidung (User):
Zielschema = bf.emsenhuber.net (wenig-Arbeit-Weg); .16 (adguard_bf1)
abbauen, .17 (=FM) bleibt.
Netto-Rest = 2 Infra-Eingriffe: DHCP-domain ->bf.emsenhuber.net ueber die
GC-Pipeline (Template Z.133 + push-gc-template.py + Deploy) und .16-Teardown.
Kein Core-Objekt haengt an .16 (Firewall/NAT/DNS/Addr-List live geprueft).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Kern von TP31 (Caddy als Host->Origin-SoT, cloudflared 6->1 Knoten) lief
über den Piloten TP16.3 durch: bf-public 12 conns, vier öffentliche Namen
über Caddy (https://10.40.20.40:443), Alttunnel bf-nas/bf-pve/bf-mm weg.
cf-sync.py:107 akzeptierte nur http://<caddy>; der Flip legte die Namen auf
https://...:443 -> Abnahme-Tool meldete vier Fehlalarme. Fix: auch https://
als "zeigt auf Caddy". Drift-Check jetzt grün (nur ds-bf als bewusst intern).
Schritt-6-Teil "MCP-Clients auf FQDN" durch TP35 Schicht 1 umgekehrt (LAN-IP),
damit gegenstandslos. Quick-Index/TP-Abschnitt/Ist-Stand-Block nachgezogen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Kein eigenständiger claude-mcp-Token mehr: in TP41 T4 (2026-09-01) zu
zt-svc umbenannt+rotiert, mcp/cloudflare/.env trägt jetzt
CF_ACCESS_CLIENT_ID/_SECRET. Quick-Index (🔜→✅), TP-Abschnitt und
Ist-Stand-Block nachgezogen; alte ".env leer"-Notiz als überholt erhalten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
terpene-db-Tunnel (b83b68f0) war seit TP16.3 §6 versehentlich mit
terpene-cloudflared entfernt → VPC-Service zeigte auf toten Tunnel →
Worker 503. Mesh von CF abgelehnt (5101, kein cloudflared-Tunnel).
Neuer cfd_tunnel terpene-db (f2d2fc8a) + Connector auf LXC 400 (VLAN20),
VPC-Service umgehängt. Kein Firewall-Loch.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
