feat: Container-Recherche-Phase im /docker-compose Skill

Vor der Generierung wird für jedes Image die aktuelle Doku via Context7,
Docker Hub und GitHub-Releases konsultiert: Pflicht-Env-Vars der aktuellen
Major-Version, Breaking Changes, deprecated Variablen, Default-Ports und
Volume-Pfade. Ergebnis landet als Header-Kommentar in der Compose-Datei.

Bei kritischen Stacks (DBs, Auth) wird die Major-Version gepinnt statt
:latest, um unkontrollierte Major-Upgrades zu vermeiden.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

CLAUDE.md

@@ -104,7 +104,7 @@ Kurzbefehl für den gesamten Ablauf: `/story`
 | `/workflow-review` | `skills/workflow-review/SKILL.md` | Opus reviewt alle Skills/Konfig → Umsetzungsplan für Sonnet |
 | `/implement` | `skills/implement/SKILL.md` | Implementierung direkt aus bestehendem Plan (überspringt Research/Planung) |
 | `/project-review` | `skills/project-review/SKILL.md` | Domänenunabhängiges Review für Nicht-Software-Dokumente (Bau, Hardware, Analysen) |
-| `/docker-compose` | `skills/docker-compose/SKILL.md` | Erstellt/aktualisiert eine docker-compose.yaml nach Hausregeln (4 Zielhosts: automation/controller/webserver/localhost, Port-Belegungs-Check, 5 MB Logging, TZ Berlin, Bind-Mounts, .env-Secrets, VPN-Binding für Webserver) |
+| `/docker-compose` | `skills/docker-compose/SKILL.md` | Erstellt/aktualisiert eine docker-compose.yaml nach Hausregeln (4 Zielhosts: automation/controller/webserver/localhost, Container-Doku-Recherche, Port-Belegungs-Check, 5 MB Logging, TZ Berlin, Bind-Mounts, .env-Secrets, VPN-Binding für Webserver) |
 
 ## Agenten
 

skills/docker-compose/SKILL.md

@@ -32,6 +32,67 @@ Bei `webserver` zusätzlich:
 
 Standardregel: **alle Ports an `10.7.0.1` binden**, nur explizit öffentliche (HTTP/HTTPS für reverse-proxy) bleiben ohne Bind-IP.
 
+## Phase 0.5: Container-Recherche (Pflicht vor Generierung)
+
+Für **jedes** Image im Stack die aktuelle Dokumentation konsultieren, bevor die Compose-Datei geschrieben wird. Ziel: korrekte aktuelle Konfiguration, bekannte Breaking Changes berücksichtigen, deprecated Variablen vermeiden.
+
+### Quellen (in dieser Reihenfolge)
+
+1. **Context7** (bevorzugt für offizielle Images):
+   ```
+   mcp__plugin_context7_context7__resolve-library-id  → Library-ID finden
+   mcp__plugin_context7_context7__query-docs           → gezielte Frage stellen
+   ```
+2. **Offizielle Docker-Hub-Seite** via `WebFetch`:
+   ```
+   https://hub.docker.com/_/<image>           # Official Images
+   https://hub.docker.com/r/<vendor>/<image>  # Community Images
+   ```
+3. **GitHub-Releases / CHANGELOG** via `WebFetch` — für Breaking Changes der aktuellen Major-Version.
+4. **WebSearch** als Fallback, wenn die obigen Quellen leer bleiben.
+
+### Was muss konkret geprüft werden?
+
+Pro Image diese Punkte abklären:
+
+- **Aktuelle Major-Version** (`:latest` zeigt auf welche?)
+- **Breaking Changes** seit der vorherigen Major-Version (z.B. PostgreSQL-Daten-Migration zwischen Major-Versionen, Keycloak `start-dev` vs `start --optimized`, MySQL→MariaDB-Replacements)
+- **Pflicht-Env-Vars** der aktuellen Version (z.B. Auth-Defaults wurden in vielen Images entfernt — `POSTGRES_PASSWORD` ist Pflicht, kein Standard mehr)
+- **Deprecated Env-Vars** — alte Namen vermeiden
+- **Default-Ports** und ob sie sich geändert haben
+- **Volume-Pfade** des Images — wo erwartet das Image persistente Daten?
+- **Health-Check-Kommando** — was empfiehlt der Maintainer?
+- **User/UID-Verhalten** — läuft das Image als Root, gibt es ein `PUID/PGID`-Pattern, oder `user:`-Override möglich?
+
+### Output dieser Phase
+
+Bevor weitergegangen wird, dem User eine **Zusammenfassung pro Image** zeigen:
+
+```
+postgres:latest → aktuell 17.x
+  Breaking: pg_dump-Format zwischen Major-Versionen inkompatibel — Major-Upgrade
+            erfordert pg_dumpall/restore (siehe Release-Notes)
+  Pflicht: POSTGRES_PASSWORD
+  Empfohlen: POSTGRES_DB, POSTGRES_USER, Healthcheck pg_isready
+  Volume: /var/lib/postgresql/data
+```
+
+Bei Major-Sprung gegenüber einem bestehenden Stack: User explizit warnen und Migrationsschritt vorschlagen, bevor `:latest` gepinnt bleibt.
+
+### Im Compose-Header dokumentieren
+
+Header-Kommentar in der `docker-compose.yaml`:
+
+```yaml
+# Stack: <name>
+# Recherchiert: <YYYY-MM-DD>
+# Images:
+#   postgres:latest    → 17.x  (Breaking: Major-Upgrade braucht pg_dumpall)
+#   <image>:latest     → x.y   (Hinweise/Breaking)
+```
+
+So bleibt nachvollziehbar, gegen welchen Wissensstand der Stack designed wurde.
+
 ## Phase 1.5: Port-Belegungs-Analyse (Pflicht vor Generierung)
 
 Bevor irgendein Port in die `docker-compose.yaml` geschrieben wird, **beide** Prüfungen auf dem Zielhost ausführen:
@@ -139,9 +200,9 @@ Diese Regeln gelten für jeden generierten Stack:
 
 ### Image-Versionen
 
-- **`:latest`** ist der Default (User-Wunsch: immer neueste Version).
+- **`:latest`** ist der Default (User-Wunsch: immer neueste Version) — aber nur, wenn die in Phase 0.5 dokumentierte Major-Version mit der Stack-Konfiguration kompatibel ist.
-- Bei `:latest` + Watchtower-Enable=`true` → automatische Updates.
+- Bei `:latest` + Watchtower-Enable=`true` → automatische Updates. Bei Datenbanken nur, wenn das Image rolling-kompatibel ist (oft nicht — siehe PostgreSQL-Hinweis aus Phase 0.5).
-- Bei kritischen Stacks (Datenbanken, Auth) kann ein gepinnter Tag sinnvoll sein — explizit beim User nachfragen.
+- Bei kritischen Stacks (Datenbanken, Auth) Major-Version pinnen (z.B. `postgres:17`) und Major-Upgrades bewusst durchführen.
 
 ### Security-Hardening (für exposed Services empfohlen)