# 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"