bf-infra/docs/handoff-20260828-mcp-cleanup-und-shelly-tote.md

Handoff 2026-08-28 — MCP-Cleanup + shelly-mcp-Tote + nächste Schritte

Bezug: docs/handoff-20260827-inventur-und-architektur.md (Master-Plan, Asymmetrie, TP34) + Inventur-Handoff bleibt der Einstieg für Master-Fragen. Diese Datei ist der konkrete nächste Schritt aus der Session 2026-08-28.

TL;DR

• MCP-Cleanup durchgeführt: cannaleo + terpene-pg aus ~/.claude.json UND ~/.config/opencode/opencode.jsonc entfernt (Backup ~/.claude.json.bak-pre-mcp-cleanup, ~/.opencode/opencode.jsonc.bak-pre-n8n-mcp).
• n8n-mcp repariert: URL war https://n8n-mcp.emsenhuber.net/ (kein /mcp am Ende) → jetzt https://n8n-mcp.emsenhuber.net/mcp. Bearer über headers.Authorization aus {env:N8N_MCP_BEARER}. ✅ live verifiziert.
• shelly-mcp ist tot (war in Inventur-Handoff nicht aufgefallen): läuft auf keinem Host, kein lokaler Prozess, kein Container auf NAS/pve. Config jetzt http://127.0.0.1:3030/mcp mit enabled=false.
• CLAUDE.md erweitert: 3 neue Lessons-for-Sessions-Regeln (MCP-Lifecycle: aktiv melden, Host vor Edit verifizieren, tote MCPs ins Projekt-Repo).
• Commit: 046f103 (lokal + remote synchron in admin/bf-infra).

Drift-Befunde der MCP-Cleanup-Session

#	Befund	Einschätzung „richtig"
M1	cannaleo + terpene-pg waren in ~/.claude.json UND ~/.config/opencode/opencode.jsonc doppelt	Beide aus globalen Configs entfernt, in terpene-Repo dokumentiert
M2	n8n-mcp URL war ohne /mcp	Korrigiert auf https://n8n-mcp.emsenhuber.net/mcp
M3	shelly-mcp zeigt auf 127.0.0.1:3030, aber kein Prozess dort	enabled=false, Deploy-Folgepunkt angemerkt
M4	ollama mcp list zeigte Hänger nach Zeile 1 (war Race-Condition beim Initial-Connect)	Nicht in Config, sondern Cold-Start; mit etwas Wartezeit vollständig (10 Server alle ✅ oder disabled)

Was ich konkret geändert habe

1. ~/.claude.json

• Entfernt: cannaleo, terpene-pg
• Backup: ~/.claude.json.bak-pre-mcp-cleanup

2. ~/.config/opencode/opencode.jsonc

• Entfernt: cannaleo, terpene-pg
• Korrigiert: n8n-mcp.url → https://n8n-mcp.emsenhuber.net/mcp (mit /mcp)
• Markiert: shelly-mcp.enabled → false (kein Host)
• Kommentar: shelly-mcp-Deploy als TODO angemerkt
• Backup: ~/.opencode/opencode.jsonc.bak-pre-n8n-mcp (vor n8n-mcp-Edit)

3. ~/dev/bf-infra/CLAUDE.md

• Ist-Stand-Block: shelly-mcp-Tote hinzugefügt
• Lessons-for-Sessions: 3 neue Regeln
  • MCP-Änderung = aktiv melden (Christoph-Direktive 2026-08-27)
  • Host vor Edit verifizieren (Live-Read: nc/ps/curl)
  • Tote MCPs → ins Projekt-Repo, nicht global
• Checkliste um Punkt 5 erweitert: „MCP-Änderung? Vorher Live-Check"

5. Neue Datei in terpene-Repo

• ~/dev/blaueblueten-n8n/docs/mcp-rueckantwort-2026-08-27.md — dokumentiert für terpene-Phase, was war und welche Optionen (A = Repo-Pattern, B = weglassen) bestehen

Live-Verifizierung (2026-08-28)

n8n-mcp: ✅ connected, Bearer akzeptiert, serverInfo: n8n-documentation-mcp 2.57.1
10 MCP-Server total: 9 connected + 1 disabled (shelly-mcp)
URL-Test: curl POST /mcp mit Bearer → 200, initialize-Response

Was du noch zu tun hast

Reihenfolge (du wolltest „erst bf-network-r6 archiv, dann 1")

1. bf-network-r6 im Gitea auf read-only + Archiv-Header (deine Aktion):

• https://gitea.emsenhuber.net/admin/bf-network-r6/settings
• Archived anhaken ✓
• Read-only anhaken ✓
• Description: „Archiv — siehe admin/bf-infra für aktive Entwicklung"

2. terpene-Caddyfile-Block (~/dev/bf-infra/caddy/Caddyfile):

terpene.teilzeitladen.xyz {
    reverse_proxy http://10.40.20.167:8890
}

• Mac mini (.167) lebt (live ping 527 µs avg, Port 8890 offen)
• Commit-Kommentar: „Quick-Win für terpene-Backfill — nicht das Pattern, TP34 ist die saubere Lösung"

3. STATUS.md Z.47 in ~/dev/blaueblueten-n8n/STATUS.md korrigieren:

• Realität: kein Tunnel hat terpene.teilzeitladen.xyz als Ingress, Worker läuft nur über CF-Workers-Custom-Domain 420.teilzeitladen.xyz
• Streichen oder umformulieren

4. ~/.claude.json n8n-mcp-Eintrag nachziehen (du wolltest „n8n-mcp auch korrekt in beide Configs"):

• Aktuell nur in ~/.config/opencode/opencode.jsonc, nicht in ~/.claude.json
• Block dort identisch:

  "n8n-mcp": {
    "type": "http",
    "url": "https://n8n-mcp.emsenhuber.net/mcp",
    "headers": {
      "Authorization": "Bearer 47a34f5589388d37d8b7503abac07b930df264c469ef0674aaeeea9b71dde847"
    }
  }
  

5. gitea-mcp „Server not initialized" untersuchen:

• Diese Session: MCP-Aufruf gab Streamable HTTP error: ... "Bad Request: Server not initialized"
• Mögliche Ursache: Container-Restart noch nicht durch, oder Backend-Init fehlt
• Erste Adress-Tests: https://gitea-mcp.emsenhuber.net/mcp antwortet mit 405 (Method not Allowed, nicht Init-Fehler) → MCP-Backend läuft, aber die SSE-Initialisierung klemmt
• Aktion: Portainer/Komodo-Container-Logs prüfen, ggf. manueller Restart

6. shelly-mcp deployen (eigener Punkt, nicht zeitkritisch):

• Skript: ~/dev/bf-infra/mcp/shelly/server.py
• Wo deployen? Optionen:
  • Container auf Mac mini (10.40.20.167) — passt zum Caddyfile-Pattern
  • Container auf NAS (10.40.20.10) — wo auch Portainer läuft
  • pve-LXC (10.40.20.126 oder neu) — zentral
• Sobald deployed, Config auf neue IP + enabled=true

Lessons Learned (an nächste Session)

• ~/.claude.json ≠ ~/.config/opencode/opencode.jsonc: zwei separate Werkzeugkästen, müssen manuell synchron gehalten werden
• MCP-Geistereinträge sind häufiger als gedacht — regelmäßiger Audit (alle 2-4 Wochen) auf tote Hosts sinnvoll
• opencode mcp list zeigt Initialisierungs-Status, nicht dauerhaften Connect — bei Hänger: kurz warten, dann erneut prüfen

Stand

• 2026-08-28, gegen Ende der MCP-Cleanup-Session
• Christoph + Hubert/minimax-m3
• Commits lokal + remote: 046f103 (HEAD)
• 256 Commits in admin/bf-infra