CLAUDE.md behauptete "lokal, kein Gitea-Remote (Working-Copy). Verloren bei
Festplattencrash." Live geprueft 2026-08-30:
origin = https://gitea.emsenhuber.net/admin/bf-infra.git
origin/main = b917691 (Handoff 2026-08-28)
Das Remote existiert also seit spaetestens 2026-08-28. Die Aussage war bei
der Inventur am 08-27 richtig und ist seither ueberholt -- nicht falsch
erhoben, sondern nicht mitgezogen.
Anlass: eine Session hat die Zeile uebernommen und "lokaler Master ohne
Gitea-Remote" behauptet, statt `git remote -v` zu tippen. Genau der Fall aus
dem Lessons-Block "Kommentar in Code != Verhalten". Merkregel deshalb an der
korrigierten Zeile verankert.
CLAUDE.md: Zeile direkt korrigiert (lebende Anweisungsdatei).
Handoff 2026-08-27: Originalzeile bewusst erhalten, Korrekturvermerk
darunter -- historische Fassungen werden hier nicht umgeschrieben.
Die Backup-Luecke bleibt real, hat aber eine andere Ursache als notiert:
nicht fehlende Struktur, sondern ungepushte Commits (am 08-30 waren es vier).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Public-Strang eingedampft. Entfernt aus Ingress UND DNS:
pve, portainer, pve-mcp, ha-mcp, ds-bf, ccu, iobroker, z2m25, pbs
sowie die drei CF-Access-SSH-Ziele 82unkpb5 / 3k23uow7 / j44d6tua.
Ingress-Bilanz: bf-mm 6->4, bf-nas 6->3, bf-pve 9->2, Catch-all je letzte.
pbs + SSH standen nicht in der Kandidatenliste -- User-Entscheid 2026-08-30
"beide mesh-only".
Abnahme beidseitig gemessen:
- intern traegt weiter: AdGuard loest alle neun Namen auf 10.40.20.40,
Caddy antwortet HTTPS 200 (pve 0,08s / portainer 0,03s / pbs 0,03s)
- oeffentlich weg: NXDOMAIN gegen 1.1.1.1
- Public-Strang unberuehrt: vw/hass/n8n/gitea weiterhin HTTP 200
Nachweis ist das Zuruecklesen der Ingress-Config, nicht die Frontend-Antwort
(Access antwortet vor dem Tunnel -- TP16.3-Regel).
Bewusst NICHT geschnitten: gitea-mcp + n8n-mcp. Die TP16.3-Vorpruefung
schlaegt an -- gitea-mcp.emsenhuber.net steht in 9 Dateien (8 fremde
Projekte + bf-infra/opencode.jsonc), ~/.claude.json nutzt zusaetzlich
n8n-mcp. TP35 Schicht 1 ist nur global vollzogen, nicht auf Projekt-Ebene.
Erst migrieren, dann schneiden -> Follow-up F1.
Blocker fuer den Abbau der drei Alt-Tunnel: bf-public hat 0 Connectoren.
Er gehoert laut Entscheid auf ap1/ap2, dort fehlen aber container-Paket
UND device-mode container=yes (physische Bestaetigung am Geraet, fetch=no).
Vor-Ort-Session noetig -> Follow-up F2. Bis dahin stehen bf-mm/bf-nas/bf-pve
mit sechs Containern (LXC400, macmini, NAS -- alle lokalisiert).
Doku an allen drei Stellen nachgezogen: Quick-Index, TP16.3-Abschnitt,
Ist-Stand-Block. TP37 (CF-Connectoren in Nautobot) als Vorschlag
eingetragen, Okay steht aus.
Rollback: docs/cf-backup/*-20260830-vor-tp16.3-schnitt.json
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christophs Kontext explodiert am Sessionende. Handoff bündelt:
- CF-Token-Audit-Befund: CF_DNS_API_TOKEN ungültig (Code 1000 'Invalid API Token'),
Christophs Verdacht 'falscher Token extrahiert' bestätigt.
- Globale MCP-Migration FQDN → IP für gitea-mcp + n8n-mcp; cloudflare bleibt
extern (User-Direktive explizit). WARP-Pfad statt Bearer-Header wenn der
Connector intern ohne Token lebt.
- terpene W5: n8n-mcp in blaueblueten-n8n/.mcp.json (User-Zustimmung).
- Domain-Korrektur: 420.teilzeitladen.xyz ist die echte terpene-Domain
(NICHT terpene.teilzeitladen.xyz) — User-Direktive, gilt für alle.
- W1/W6 bleiben User-blocked, W7 wartet auf TP31-Schritt 5/6.
Dringend beim Nachfolger: CF-Token-Validität zuerst klären, dann erst
MCP-Migration. STATUS.md im terpene-Repo ist auf die falsche Domain
korrigieren.
Container crashte beim ersten Deploy mit 'No module named mcp.server.fastmcp':
PyPI hat mcp 2.x als aktuellste Version, FastMCP wurde dort zu MCPServer
umbenannt. Repo-Code (server.py) nutzt noch v1-API.
Fix: requirements.txt 'mcp[cli]>=1.0,<2' — hält den Server auf v1-kompatibel.
Deploy-Ergebnis:
- Container shelly-mcp auf DS923, IP 10.40.20.180 (macvlan vlan20)
- Health /health: 200, psk_configured:true, iot_ssid=dirtyvader-iot
- StreamableHTTP /mcp: serverInfo 'shelly-mcp 1.29.1'
- Live-Sweep 10.40.30.180-250: 23 Shellys erreichbar
TP30 Posten #3 (Shelly-Gerätepasswort) hochgestuft: SHELLY_DEVICE_PW ist im
Zuge dieses Deploys erneut in ein Sitzungstranskript geraten (sed-Pattern
'SHELLY_DEVICE_PW=.*' hat den Wert nicht maskiert, weil der Replacement-
String zu wenig greedy war — neuer Lessons-Block-Eintrag). Reihenfolge:
erst Werkzeug-Härtung (Stream-Filter statt cat+sed), dann Posten #3
rotieren. CLAUDE.md hat den Lessons-Eintrag, TP30 Posten #3 hat die
Hochstufungs-Begründung.
Portainer-Server (pve LXC 400): 2.40.0 → 2.42.0 via Image-Swap mit Volume-Erhalt.
Pre-Upgrade-Snapshot: docker commit :2.40.0-preupgrade-20260828 (Rollback 7 d
verfügbar) + Settings/Stacks/Endpoints-JSON-Dump (40 KB, 31 Stacks, 4 Endpoints).
Instance-ID + API-Token nach Bump identisch — kein Re-Auth, kein Settings-Verlust.
portainer-mcp: offizielles PyPI-Paket mcp-portainer~=2.42.0 (193 Tools), nur
in bf-infra/opencode.jsonc, via uvx-stdio. Tool-Gate: get_guidance() einmal pro
Session zwingend vor erstem Read. Andere Projekte unberührt.
Korrekturen ggü. Handoff 2026-08-28 README:
- mcp-portainer PyPI bis 2.42.6, Docker-Hub portainer/portainer-ce nur bis 2.42.0
(unterschiedliche Versionierungspfade).
- mcp/portainer/README.md ist auf 2.42.6 formuliert und sollte nachgezogen werden.
Bestand: mcp/INVENTORY.md portainer-mcp ⛔→🟢 + Header MCP-WARP-Direktive ergänzt.
.mcp.json (war getrackt aus Commit 3426366) entfernt: opencode nutzt opencode.jsonc,
nicht .mcp.json — Claude-Code-Konvention hier irrelevant.
Befund 2026-08-28 nach Skill-Verifikation in opencode:
- Der 'Nächster Schritt (2026-08-26)'-Absatz war zwei Tage veraltet
(drei Sessions waren parallel offen)
- Manuelle Doku mit Live-Daten verliert gegen die Realitaet, sobald
die Datei lang wird (1940 Zeilen, drei Stellen pro Edit)
Reaktion:
1. 'Nächster Schritt' umgeschrieben: drei Folge-Sessions A/B/C aus
dem gestrigen Handoff, klar als 'parallel' markiert. A ist erledigt
(TP35 Schicht 6), B+C offen.
2. TP36 als Folge-TP neu angelegt: SSoT via Nautobot fuer
teilprojekte-Live-Daten + Datei-Aufteilung (Index / Snapshot /
Archiv). Eigene Session, nicht heute.
3. CLAUDE.md: zwei Lessons-Eintraege:
a) opencode-TUI: fuehrendes Leerzeichen vor /command manchmal
noetig (Beobachtung, kein Skill-Bug)
b) Manuell gepflegte Doku verliert gegen Realitaet, Merkregel:
drei Stellen pro Edit mitlesen (Quick-Index, TP-Abschnitt,
Ist-Stand); strukturelle Antwort = TP36
Lessons-Block hat jetzt 7 Eintaege (Stand 2026-08-28).
- CLAUDE.md: zwei Lessons-Eintraege (opencode-Default-Pfad kopieren,
nicht symlinken; Kommentar in Code != Verhalten)
- teilprojekte.md: TP35 Quick-Index auf 'Schicht 6 erledigt, Rest offen',
Schicht-6-Befund im TP-Block, Ist-Stand auf 2026-08-28 mit MCP-Bestand-
Korrektur
- handoff-20260828-session-a-projektstatus.md: Session-A-Bericht mit
Drift, Befund, Entscheid, Lehren fuer Session B
Skill selbst liegt in ~/.config/opencode/skills/projektstatus/SKILL.md
(cp aus ~/.claude/skills/projektstatus/, byte-identisch) - opencode
scannt diesen Default-Pfad, kein skills.paths-Eintrag in der JSONC
noetig.
Vorbereitetes Runbook für TP31.5 (cloudflared-Container auf hAPs statt
TUN-Device-Workaround, da WARP-Connector auf ROS nicht möglich). Inhalt:
- Image-Build (RouterOS 7.x container, 70 MB Budget je AP)
- Pro AP: veth, interface-list-Mitgliedschaft, container-env
- CNAME-Flip von CF-Tunnel auf ap1/ap2 (DNS-Propagation, Rollback)
- Voraussetzungen: WAN-Healthcheck, Tunnel-Secret aus credentials.json
(siehe routeros/cloudflared/.gitignore im Folge-Commit)
Status: vorbereitet, nicht ausgeführt. Stand 2026-08-27.
Eine Seite, die eine frische Session in 30 Sekunden auf Stand bringt:
TL;DR, Lese-Reihenfolge (Handoff → Anker → TP35), sofort-tun-Liste,
Übergabe-Mechanik, Mid-Action-Checkpoint, Commit-Hinweis-Regel, Was-offen.
Löst das 'Bahnhof'-Problem, das Christoph beim Session-Neustart
beobachtet hat.
TP16.3 existiert seit 2026-08-17 (Quick-Index Z. 194, Body Z. 401,
Runbook tp16.3-nautobot-mesh-only-runbook.md) und deckt 'alle Tools
über Caddy oder CF + Caddy (extern)' + Auth-Sanierung bereits ab.
Mein Fehler: ich habe im Index nicht nachgeschaut und einen Vorab-Punkt
formuliert, der TP16.3 doppelt. Anwender hat das in dieser Session
explizit markiert ('das darf dir kein 2. mal passieren').
Fix:
- Session-Anker: Vorab-Notiz entfernt, ersetzt durch Verweis auf TP16.3.
- TP16.3-Body: technische Notiz 'n8n-mcp Accept-Header-Strike +
Auth-Sanierung' eingepflegt (SSE-Header-Konsequenz für künftiges
Caddy-Fronting, Reihenfolge TP16.3 → TP35 Schicht 2).
Lehre: vor jeder Aussage 'gibt's noch nicht' oder 'neuer TP nötig':
erst grep auf den Quick-Index in teilprojekte.md.
n8n-mcp-Accept-Header-Strike wird mit dem noch kommenden CF-Tunnel-Punkt
gelöst, nicht heute. Bearer-Authentifizierung soll einmal sauber per
Caddy/CF-Access zentralisiert werden — TP35-Schicht-2 Endform hängt davon.
Inhalt: nur Doku, keine Migration, kein neuer TP, keine Config-Änderung.
Diagnose: n8n-mcp verlangt 'Accept: application/json, text/event-stream'
(StreamableHTTP-Modus). opencode mcp list schickt nur 'application/json',
kriegt 406, wertet als failed. Echter Tool-Aufruf nutzt richtigen Header,
deshalb Sidebar grün. Bearer-Token + Server sind gesund (200 OK mit
richtigem Accept-Header, serverInfo: n8n-documentation-mcp 2.57.1).
Konsequenz: 'failed' in mcp list ist nicht 'kaputt' sondern 'Probing-Header
zu strikt'. Sidebar-Status bleibt Wahrheit.
- Neue Handoff-Datei für den konkreten nächsten Schritt (im Gegensatz zur
Inventur-Handoff, die den Master-Plan zeigt).
- Dokumentiert: cannaleo/terpene-pg entfernt, n8n-mcp repariert,
shelly-mcp-Tote entdeckt, CLAUDE.md-Erweiterung.
- Liste der offenen Aktionen für die nächste Session: bf-network-r6
archivieren, terpene-Caddyfile-Block, STATUS.md Z.47 korrigieren,
n8n-mcp auch in ~/.claude.json, gitea-mcp-Init-Problem.
Die Datei war bereits im Working Tree, aber ohne klaren Zweck -- jetzt
umbenannt auf .snapshot.yaml und mit Marker-Kommentar versehen, der sagt:
- das ist KEINE Transaktions-Akte (kein .json)
- das ist auch KEIN Vor-Zustand zum heutigen nas.emsenhuber.net-Edit
- das ist die AGH-Komplett-Config mit bereits angewandtem Standortsuffix
(*.bf.emsenhuber.net), die beim Bau des AGH-Paars (110/111) in der
naechsten Session als Soll-Zustand gilt.
upstream_dns ist auf /bf.emsenhuber.net/ bedingt (Suffix-Form), 26 von
30 Rewrites haben .bf.-Suffix, 4 Public (vw/hass/n8n/gitea) bleiben ohne
Suffix.
Baut auf handoff-20260825 auf (AdGuard-Paar + Split-Horizon) und ergaenzt
den Auftrag um den heute eingefuehrten Standortsuffix-Sweep: alle BF-Hosts
in AGH heissen kuenftig <host>.bf.emsenhuber.net statt ohne Suffix.
nas.emsenhuber.net ist seit 1d569fa weg (Commit direkt vorher).
`nas.emsenhuber.net` war nur als AGH-Rewrite auf 10.40.20.10 vorhanden,
zeigte aber nirgends hin: kein CF-CNAME, kein Caddyfile-Eintrag (der
hatte von Anfang an ds-bf.emsenhuber.net fuer Synology DSM).
Mit dem TP23-Stufe-2-Cutover wandert die DNS-Aufloesung in ein
AdGuard-Paar und der Rewrite-Satz wird neu aufgebaut. Die Regel
ist ab jetzt: Hosts, die es an mehreren Standorten gibt, heissen
immer `<host>.<site>.emsenhuber.net` — kein gemeinsamer Name
ohne Suffix.
Andere namensgleiche Hosts (macmini/mfc/tv/docker/platform-pg/
core/ap1/ap2/branch) bleiben vorerst ohne Suffix in AGH und werden
einzeln in der TP23-Stufe-2-Session bewertet.
- adguard/AdGuardHome.yaml: AGH-Wizard-Setup (27 Rewrites ohne .bf, DoH zum CF-Gateway, conditional emsenhuber.net).
- nautobot/mikrotik_routeros.j2: DHCP dns-server=10.40.20.36,.37, domain=emsenhuber.net.
- docs/transaktionen/TP23-agh-firewall.commands.rsc: TP5-E2 LAN->AGH dns auf .16/.17 ersetzt durch .36/.37.
- docs/transaktionen/TP23-agh-dhcp-cutover.commands.rsc: DHCP-Cutover (dns-server + domain in einem Deploy).
Compliance 104/104, 0 Drifts. Core bleibt als Rückfallebene unangetastet.
[KEIN go fuer den Rest: Persistenz (CLAUDE.md/memory), Host.Naming (.host.emsenhuber.net),
add-dns-entries-Suffix, conditional-Upstream, lease-time-Transaktion, TP31-defer — alles im Plan,
Wartet auf separates go des Users.]
