# Session-Briefing 2026-08-28 — Neue Session ab hier

> **Lies diese Datei + die zwei Handoffs in dieser Reihenfolge**, dann bist du auf Stand.

## Was du als Erstes liest (in dieser Reihenfolge)

1. **`docs/handoff-20260828-pre-opencode-migration.md`** — Status-Quo, Backups, Lessons, Übergabe-Mechanik
2. **`docs/session-20260828-decisions.md`** — Warum, F1–F5 mit Begründung, MCP-Status-Toleranzen, Auth-Sanierung
3. **`docs/teilprojekte.md` → TP35** — Scope, Abgrenzung, Verweise

## TL;DR (3 Zeilen)

Wir wollten MCP-Konfiguration (heute verteilt über `~/.config/opencode/opencode.jsonc` + `~/.claude.json`, kein Schema global/projekt/user) in eine saubere Schichtung bringen. TP35 ist angelegt, Ausarbeitung läuft hier. Backups: 12/12 valid in `~/dev/.pre-opencode-migration-backups/20260828-150335/`.

## Was du als Erstes tust

1. `opencode mcp list` — bei n8n-mcp ggf. `failed` (Cold-Start-Race + Accept-Header-Strike, beides tolerierbar; Sidebar ist Wahrheit)
2. `git log --oneline -5` in `~/dev/bf-infra` — bestätige, dass du auf `5797364` stehst
3. Wenn etwas unklar: **erst `grep` auf den Quick-Index in `teilprojekte.md`** bevor du „neuer TP" sagst — Lehre aus der gestrigen Session (TP16.3 existierte bereits, war als „Vorab-Notiz" doppelt formuliert worden)

## Übergabe-Mechanik (gilt ab sofort)

```
[Aktion]:      ein Satz, was konkret passieren soll
Scope:         welche Dateien/Repos/Systeme
Stop-Bedingung: was ich NICHT anfassen darf
Checkpoint:    was ich zurückmelde, wenn fertig
Bei Fehler:    rollback oder fragen
```

Nicht das ganze Bündel als „go" formulieren. Eine Entscheidung pro „go", oder explizit „Plan-Modus: Vorschlag zuerst".

## Mid-Action-Checkpoint (gilt ab sofort)

Bei komplexen Plänen (mehrere Schichten, mehrere Dateien) **vor** dem ersten Tool-Aufruf einen Checkpoint setzen:

> „Backups ✅, jetzt fange ich Schicht 2 an: globale Config. Wenn du jetzt anders entscheidst, ist das hier der Punkt zum Stoppen."

Das ist die Lehre aus 2026-08-28 (zweimal „go" gegeben, beim zweiten Mal korrigiert — wäre vorher gekommen, wäre es einmal „go" geblieben).

## Commit-Hinweis-Regel (gilt ab sofort)

Wenn ich denke, dass ein Commit ein guter Zeitpunkt ist und Christoph es übersieht: aktiv darauf hinweisen mit „Wäre jetzt ein guter Commit-Zeitpunkt — soll ich?". Nicht „einfach committen". Christoph bestätigt oder verwirft.

## Was offen ist

- TP35-Schicht 6 zuerst (`/projektstatus`-Skill globalisieren — alle Projekte sollen dasselbe Skill verwenden)
- Pro Projekt eigener Handover-Post (Reihenfolge: bf-infra, blaueblueten-n8n, ha-xstate, valamar, uwe-job-bewerbung, dann die Kleinen)
- Globale CLAUDE.md (5 Lessons + Single Point of Contact für Infrastruktur)
- Backup-Guard (`~/dev/.bin/backup-guard.sh`, Pre-Commit-Hook, „3 Tage aktiv"-Definition)
- Auth-Sanierung in **TP16.3** (existiert bereits, technische Notiz dort eingepflegt, NICHT als neuer TP)