handoff: pre-opencode-migration, backups done, plan open, mid-action correction received

docs/handoff-20260828-pre-opencode-migration.md

@@ -0,0 +1,199 @@
+# Handoff 2026-08-28 — Pre-OpenCode-Migration: Backups ✅, Plan offen, abgebrochen
+
+> **Bezug:** Inventur 2026-08-27 (`handoff-20260827-inventur-und-architektur.md`) → MCP-Cleanup 2026-08-28 (`handoff-20260828-mcp-cleanup-und-shelly-tote.md`). Diese Datei: **was bisher wirklich passiert ist** im Plan „Globale MCP-SSoT + 3-Schicht-CLAUDE.md + Backup-Guard", und wo der Plan offen liegt.
+
+## TL;DR
+
+- **Backups durchgeführt** für alle 12 Projekte + die 4 globalen Configs.
+- **Plan in dieser Session erarbeitet, nicht umgesetzt** — Christoph hat nach dem ersten „go" korrigiert (Ollama läuft auf 2 Hosts lokal, uwe-job-bewerbung doch dabei, Backup-Guard braucht aktive-Tage-Definition). Vor dem zweiten „go" hat er **gestoppt** und um Handover gebeten.
+- **Stand der Welt**: keine globalen Configs verändert, keine Repos verändert, keine CLAUDE.md verändert. Nur die Backup-Files sind neu (in `~/dev/.pre-opencode-migration-backups/`).
+
+## Was tatsächlich gemacht wurde
+
+### Backups (Schicht 1)
+
+**Pfad:** `~/dev/.pre-opencode-migration-backups/20260828-150335/` (chmod 700, Inhalte chmod 600).
+
+| Projekt | Größe | Files | Verfahren | gzip-validiert |
+|---|---|---|---|---|
+| bf-infra | 24M | 4061 | `git ls-files` + `ls-files --others --ignored` → tar | ✅ |
+| bf-network-r6 | 13M | 736 | dto | ✅ |
+| bf-network-r6.opencode | 13M | 736 | dto | ✅ |
+| blaueblueten-n8n | 89M | 2348 | dto | ✅ |
+| ha-xstate | 24M | 7331 | dto | ✅ |
+| valamar | 53M | 98 | dto | ✅ |
+| migration-audit | 421K | 72 | dto | ✅ |
+| poulios-recherche | 398K | 143 | dto | ✅ |
+| chinalichterkette | 252B | 3 | tar (kein Git) | ✅ |
+| dachterrasse | 368B | 4 | dto | ✅ |
+| ha | 310B | 4 | dto | ✅ |
+| uwe-job-bewerbung | 590M | (nicht validiert) | dto, **Schreibvorgang wurde durch Christoph abgebrochen, danach Größe stabil** | ⚠️ **nicht abschließend geprüft** |
+
+**Globale Configs** (im selben Verzeichnis, chmod 600):
+- `opencode.jsonc` (3155 B)
+- `claude.json` (70031 B)
+- `exports.zsh` (2606 B)
+- `credentials.env` (10020 B)
+
+**🔴 Achtung — uwe-job-bewerbung.tar.gz**: der Backup-Schreibvorgang lief zum Zeitpunkt von Christophs „stopp" noch (Timeout 5 min, er hat manuell abgebrochen). Die Datei ist **590 MB groß und seit 15:14 unverändert** — das ist plausibel vollständig (das Quellverzeichnis ist 4.5G, und bei gzip-Level 1 ist ein Kompressionsfaktor von ~7x normal für PDFs/Bilder), aber **`gunzip -t` wurde nicht ausgeführt**. Vor einem eventuellen Rollback oder Löschen muss die Datei validiert werden. Sie ist im Backup-Verzeichnis; der Source ist unverändert.
+
+### md5-Snapshot der globalen Configs (vor dem ersten go, alle unverändert)
+
+```
+~/.config/opencode/opencode.jsonc   7efbb854bf91d68d7f308277ef574fac
+~/.claude.json                      98f946abb6a0061c6a559ff11c1c9c75
+~/.secrets/exports.zsh              147d1e398e8f70204fa80e466cbb85f5
+~/.secrets/credentials.env          01185a9af00bb87bc4d6e5c5bc53f2f0
+```
+
+### Repo-Snapshots (alle unverändert)
+
+```
+bf-infra           HEAD 7e81ce6a   (untracked: docs/tp31-schritt5-runbook.md, routeros/cloudflared-bf-public-config.yml, routeros/cloudflared/)
+bf-network-r6      HEAD de5429de
+bf-network-r6.opencode HEAD de5429de
+blaueblueten-n8n   HEAD bf8d2b29   (modified: blaueblueten_terpene.n8n.json, cannaleo_core.py, cannaleo_mcp.py — VOR der Session, nicht durch sie)
+ha-xstate          HEAD c78ed80a
+```
+
+## Der Plan, der offen liegt
+
+### Was du (Christoph) in der Antwort geklärt hast
+
+1. **Ollama läuft auf 2 Hosts lokal** (`localhost:11434` jeweils) — `10.40.20.167:11434` ist nur **einer** davon (Mac mini). Der zweite Host ist noch zu identifizieren. **Konsequenz:** `OLLAMA_HOST` darf **nicht** hart auf eine IP zeigen, sondern muss **pro Host** gesetzt werden. Default in der globalen Config = `http://localhost:11434`.
+2. **uwe-job-bewerbung ist doch ein Projekt** — ich hatte es im ersten Anlauf ausgeschlossen („4.5G Medien, separat gesichert"). Christoph sagt nein, der Guard macht es erträglich. Backup ist im Verzeichnis, aber nicht validiert (s.o.).
+3. **Backup-Guard: 3 Tage aktive Arbeit**, nicht 3 Tage Standzeit. Definition „aktiv" noch zu präzisieren — mein Vorschlag: `git log --since=<guard-date>` mit Schwelle **5 Commits ODER 1000 LOC diff** (großzügig, damit „ein kleiner Commit" nicht zählt, aber „drei Commits an einem Tag" auch nicht).
+4. **Übergabe-Mechanik**: Christoph hat zwei Mal „go" gesagt, ich habe dazwischen angefangen — beim zweiten Mal kam die Korrektur mit Stopp. Frage am Ende dieses Handoffs.
+
+### Sechs Schichten, die ich umsetzen wollte
+
+**Schicht 1 — Backups ✅** (fertig, siehe oben)
+
+**Schicht 2 — Globale Konfiguration** (`~/.config/opencode/opencode.jsonc` + `~/.claude.json`)
+- `~/.claude.json` bleibt parallel, **Sync** über `~/.bin/sync-mcps.sh` (gitignored, chmod 700).
+- Credentials in `claude.json` durch `{env:...}` ersetzen, wo technisch möglich. Wo nicht: `// TODO: credential in env migrieren` + Inventur-Eintrag in `bf-infra/docs/mcp-leak-inventur.md`.
+- `ollama`-MCP-Block: `OLLAMA_HOST` als Default `http://localhost:11434` in der Config (kein hartcodierter `10.40.20.167`).
+
+**Schicht 3 — Globale CLAUDE.md** (`~/.claude/CLAUDE.md`)
+Konsolidierung der **generischen** Verhaltensregeln aus `bf-infra/CLAUDE.md`:
+- Bestandsaufnahme vor Plan
+- Eine Fragenrunde, nicht Mikrorunden
+- Master-Frage früh stellen
+- Drift zuerst, Lösungen später
+- MCP-Lifecycle (aktiv melden, Host vor Edit verifizieren, tote MCPs ins Projekt-Repo)
+- Backup-Guard-Regel (siehe Schicht 5)
+
+NICHT in die globale: projektspezifische Gotchas (SSID-Datapath-Falle, Drucker-SNMP, mDNS-Relay, etc.).
+
+**Schicht 4 — 3-Schicht-CLAUDE.md in den Projekten**
+- `CLAUDE.md` (Git, öffentlich) — was die Welt über das Repo wissen muss.
+- `CLAUDE.local.md` (gitignored) — projektspezifische Interna (Credentials, lokale IPs, tote Backups).
+- `~/.claude/CLAUDE.md` (global) — Verhaltensregeln.
+
+Voll ausgearbeitet für 3 Projekte: `bf-infra`, `blaueblueten-n8n`, `ha-xstate`. Für die anderen (valamar, uwe-job-bewerbung, migration-audit, poulios-recherche, chinalichterkette, dachterrasse, ha): **nur die 3-Schicht-Trennung + Verweis auf globale CLAUDE.md**, kein Inhalt (zu wenig Kontext).
+
+**Schicht 5 — Backup-Guard** (`~/dev/.bin/backup-guard.sh`, chmod 700)
+```bash
+# Pro Projekt:
+# 1. Hat Backup? Nein → anbieten, Backup anlegen, .guard schreiben
+# 2. Hat .guard? Nein → anbieten, Backup + .guard anlegen
+# 3. .guard da, <3 Tage aktiv → grün (nichts tun)
+# 4. .guard da, ≥3 Tage aktiv → einmalig fragen, dann .guard updaten
+```
+„Aktiv"-Definition: `git log --since="<guard-date>" --oneline | wc -l` ≥ **5 Commits** ODER `git diff --shortstat <guard-date> HEAD | awk '{sum+=$4+$6} END {print sum}'` ≥ **1000 Zeilen**.
+
+Bei Löschung: Backup weg + `.guard` weg.
+Bei „nein, behalten": `.guard` mit `last_denied=<datum>`, in 7 Tagen wieder fragen.
+Bei „verschieben": Backup in `.archive/`, `.guard` mit `archived=<pfad>`.
+
+**Schicht 6 — Sync-Helper**
+`~/.bin/sync-mcps.sh`:
+```bash
+#!/bin/bash
+# Diff opencode.jsonc vs claude.json mcpServers — Exit 1 bei Drift
+diff <(jq '.mcpServers | keys' ~/.config/opencode/opencode.jsonc) \
+     <(jq '.mcpServers | keys' ~/.claude.json) && echo OK
+```
+
+### Was ich noch brauche, bevor es weitergeht
+
+**Zweiter Ollama-Host.** Christoph hat gesagt „genau 2 Hosts". Einer ist der Mac mini (`.167`), der andere? Hypothesen, sortiert nach Wahrscheinlichkeit:
+- (a) MacBook selbst (`localhost` = 127.0.0.1, schon heute Default für lokale Ollama-Setups)
+- (b) Ein LXC/Container auf pve
+- (c) NAS
+
+Ich **frage nicht zweimal** — wenn du beim nächsten „go" den zweiten Host nicht nennst, **gehe ich davon aus: (a) MacBook**, und die globale Config setzt `OLLAMA_HOST` per Default auf `http://localhost:11434` mit einem Kommentar „falls Mac mini aus dem BF-LAN gewünscht: `export OLLAMA_HOST=http://10.40.20.167:11434` in der Shell".
+
+## Lehre für die nächste Session (Christoph-Direktive)
+
+**„Stopp während der Arbeit" ist ein valides Signal.** Die richtige Reaktion darauf ist nicht „weitermachen und am Ende korrigieren", sondern **„mid-action-Checkpoint schreiben, dann warten"**. Mein Fehler in dieser Session: ich habe nach dem ersten „go" **zu schnell** mit dem tar-Befehl angefangen, ohne die zweite Antwort abzuwarten, obwohl ich sie noch nicht gesehen hatte. (Die lag wahrscheinlich noch in der Queue.)
+
+**Konkret:** bei einem „go" mit großem Scope (mehrere Schichten, mehrere Dateien) sollte ich **einen Mid-Action-Checkpoint** setzen:
+- Backup ja/nein (falls noch nicht da)
+- Plan-Summary (welche Schichten, in welcher Reihenfolge)
+- **expliziter Satz:** „Wenn du jetzt anders entscheidst, ist das hier der Punkt, an dem ich aufhöre."
+
+## Lehre für die Übergabe-Mechanik (deine Frage)
+
+Du hast gefragt, **wie du Handoffs am besten an mich übergibst**. Aus dieser Session:
+
+### Was bei diesem „go" schiefging
+
+Du hast einen mehrschichtigen Plan in **einer** Nachricht formuliert:
+- MCP-SSoT + Credentials
+- CLAUDE.md-Schichten
+- Backup-Guard mit Time-Bomb
+- Anpassungen an andere Sessions
+
+Das ist **kein** einzelner Auftrag — das sind 5-6 voneinander unabhängige Entscheidungen, die jeweils eigene Recherche-/Backup-Schritte brauchen. Mein Bauchgefühl hätte sein müssen: **erst die Entscheidungsfragen klären, dann den Plan schreiben, dann das „go" einholen**.
+
+### Was besser wäre
+
+**Muster, das in dieser Session gefehlt hat:**
+
+1. **Wenn du einen komplexen Plan hast**, der mehrere voneinander unabhängige Entscheidungen enthält:
+   - Formuliere die Entscheidungsfragen **einzeln** (A, B, C, …)
+   - Warte auf meine **Antwort pro Frage**, bevor du „go" sagst
+   - Das „go" sollte sich auf **einen** klar umrissenen Schritt beziehen, nicht auf das ganze Bündel
+
+2. **Wenn du mitten in der Arbeit korrigierst**:
+   - Schreib **was** du ändern willst und **warum** (die Korrektur war klar, das war nicht das Problem)
+   - **Lass mich die Mid-Action-Notiz schreiben**, bevor ich weiter ändere (Backup-Status, was bereits angefasst, was noch nicht)
+   - Du kannst dann entweder „weiter so" oder „rollback + neu" sagen
+
+3. **Wenn du unsicher bist, ob ein Schritt autonom laufen soll**:
+   - Schreib **„Plan-Modus: nicht ausführen, nur Vorschlag"** explizit dazu
+   - Ich liefere dann einen Plan-Output (was würde ich tun, in welcher Reihenfolge), kein Tool-Call
+   - Erst nach deinem „Plan steht, los" geht's los
+
+### Was ich vorschlage für die Übergabe ab jetzt
+
+**Format-Vorlage für „go"-Nachrichten an mich:**
+
+```
+[Aktion]: [konkreter Schritt, ein Satz]
+Scope: [welche Dateien/Repos/Systeme sind betroffen]
+Stop-Bedingung: [was soll ich auf jeden Fall NICHT anfassen]
+Erwarteter Checkpoint: [was melde ich zurück, wenn fertig]
+Falls etwas schiefgeht: [rollback oder fragen]
+```
+
+Zum Beispiel:
+```
+[Aktion]: uwe-job-bewerbung.tar.gz validieren (gunzip -t)
+Scope: nur die eine Datei in ~/dev/.pre-opencode-migration-backups/20260828-150335/
+Stop-Bedingung: keine andere Datei anfassen
+Erwarteter Checkpoint: "OK" oder konkrete Fehlermeldung
+Falls etwas schiefgeht: fragen, nicht löschen
+```
+
+### Was du anders machen könntest
+
+**Nicht** einen ganzen Plan als „go" formulieren. Lieber **einen Schritt nach dem anderen**. Du hast die richtige Intuition („du weißt ja von dir wie ich antworten würde") — die funktioniert am besten, wenn der Plan klein ist.
+
+## Stand
+
+- 2026-08-28, nach Christophs Stopp
+- Backup-Verzeichnis steht, Inhalt noch nicht abschließend validiert (uwe-job-bewerbung.tar.gz offen)
+- Keine globalen Configs verändert, keine Repos verändert
+- Plan für 6 Schichten offen — nächste Session setzt nach deinem „Plan-Modus: Vorschlag zuerst, dann go"