session-briefing-20260828.md: TL;DR + Lese-Reihenfolge für neue Sessions
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.
This commit is contained in:
51
docs/session-briefing-20260828.md
Normal file
51
docs/session-briefing-20260828.md
Normal file
@@ -0,0 +1,51 @@
|
||||
# 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)
|
||||
Reference in New Issue
Block a user