feat(deploy): Image-Promotion, deploy.env, Health-Check-Fix und Anleitungen

- Deploy-Scripts: Image-Promotion statt Rebuild (docker tag + up -d),
  deploy.env fuer Server-Konfiguration, -p fuer Projekt-Namen,
  Health-Check mit Host-Header und /xhr/health-check
- docker-compose.prod.yaml: name-Feld entfernt (Projekt-Name per -p)
- deploy.env.example als Vorlage hinzugefuegt
- .vibe/skills/client-build/SKILL.md aus Git-Index entfernt (gitignore)
- Deployment-Anleitung: Zugangsdaten, deploy.env, Image-Promotion,
  prod ohne eigenes Repo, git-clone-Hinweis, Log-Befehle mit -p
- Deploy-lokal-testen.md: neue Anleitung fuer lokales Testen

Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>

Dokumentationen/Deployment-Anleitung.md

@@ -58,6 +58,23 @@ Folgende Software muss installiert sein:
 Docker Compose muss als Plugin installiert sein (Befehl: `docker compose`,
 nicht `docker-compose`).
 
+### Git-Zugangsdaten konfigurieren
+
+Das `git clone` und `git fetch` in den Deploy-Scripts nutzen die
+Git-Credentials, die auf dem Deploy-Server konfiguriert sind. Die
+Zugangsdaten stehen nicht in den Scripts oder Konfigurationsdateien.
+
+Drei Moeglichkeiten:
+
+| Methode | Einrichtung | Wo hinterlegt |
+|---|---|---|
+| SSH-Key | `git clone git@git.everdc.eu:.../kbcrm` (SSH-URL verwenden) | `~/.ssh/id_rsa` auf dem Deploy-Server |
+| Git-Credential-Store | `git config --global credential.helper store` | `~/.git-credentials` auf dem Deploy-Server |
+| Deploy-Token (Gitea) | Token in Remote-URL: `https://token:secret@git.everdc.eu/...` | In der `origin`-URL des geklonten Repos |
+
+Empfohlen: SSH-Key oder Deploy-Token. Der Credential-Store speichert
+Passwoerter im Klartext und sollte nur fuer Test-Umgebungen verwendet werden.
+
 ---
 
 ## 3. Verzeichnisstruktur auf dem Deploy-Server
@@ -67,14 +84,14 @@ Es werden zwei Umgebungen (test-prod und prod) parallel betrieben:
 ```
 /opt/kbcrm/
 ├── test-prod/
-│   ├── repo/              ← git clone des Repos
+│   ├── repo/              ← git clone des Repos (einziges Repo auf dem Server)
 │   └── .env              ← test-prod Umgebung (eigene Ports, eigene DB)
 ├── prod/
-│   ├── repo/
-│   └── .env              ← prod Umgebung
+│   └── .env              ← prod Umgebung (kein eigenes Repo — Images per docker tag)
 └── scripts/
     ├── deploy-kbcrm-test.sh   ← aus dem Repo (scripts/)
-    └── deploy-kbcrm-prod.sh   ← aus dem Repo (scripts/)
+    ├── deploy-kbcrm-prod.sh   ← aus dem Repo (scripts/)
+    └── deploy.env             ← Server-spezifische Konfiguration (nicht im Repo)
 ```
 
 Die SQLite-Datenbanken liegen ausserhalb des Repos in einem bind-mount
@@ -89,11 +106,16 @@ Die SQLite-Datenbanken liegen ausserhalb des Repos in einem bind-mount
 ```bash
 sudo mkdir -p /opt/kbcrm/test-prod /opt/kbcrm/prod
 
-# Test-Prod Repository
+# Repository klonen (nur einmal — prod nutzt die Images aus test-prod)
+# WICHTIG: git clone wird nur beim ersten Mal ausgefuehrt. Wenn das Verzeichnis
+# bereits existiert (z.B. .env wurde bereits abgelegt), schlaegt clone fehl.
+# Weitere Updates werden durch das deploy-kbcrm-test.sh Script via
+# git fetch + git reset --hard durchgefuehrt — kein manueller clone mehr.
 sudo git clone https://git.everdc.eu/chmln-app-dev/kbcrm /opt/kbcrm/test-prod/repo
 
-# Prod Repository
-sudo git clone https://git.everdc.eu/chmln-app-dev/kbcrm /opt/kbcrm/prod/repo
+# Falls das Verzeichnis bereits existiert und aktualisiert werden soll:
+# cd /opt/kbcrm/test-prod/repo && git fetch origin main && git reset --hard origin/main
+# Oder einfach: /opt/kbcrm/scripts/deploy-kbcrm-test.sh
 ```
 
 ### 4.2. `.env`-Dateien anlegen
@@ -104,8 +126,8 @@ Kopieren Sie die Vorlage aus dem Repo und passen Sie die Werte an:
 # Test-Prod
 cp /opt/kbcrm/test-prod/repo/env-sample /opt/kbcrm/test-prod/.env
 
-# Prod
-cp /opt/kbcrm/prod/repo/env-sample /opt/kbcrm/prod/.env
+# Prod (Vorlage aus test-prod-Repo)
+cp /opt/kbcrm/test-prod/repo/env-sample /opt/kbcrm/prod/.env
 ```
 
 ### 4.3. `.env` fuer Test-Prod anpassen
@@ -194,12 +216,44 @@ zentralen Ort:
 ```bash
 sudo mkdir -p /opt/kbcrm/scripts
 sudo cp /opt/kbcrm/test-prod/repo/scripts/deploy-kbcrm-test.sh /opt/kbcrm/scripts/
-sudo cp /opt/kbcrm/prod/repo/scripts/deploy-kbcrm-prod.sh /opt/kbcrm/scripts/
+sudo cp /opt/kbcrm/test-prod/repo/scripts/deploy-kbcrm-prod.sh /opt/kbcrm/scripts/
 sudo chmod +x /opt/kbcrm/scripts/*.sh
 ```
 
-Passen Sie die Pfad-Variablen am Anfang der Scripts an, falls Ihre
-Verzeichnisstruktur abweicht.
+### 4.8. `deploy.env` anlegen (Server-spezifische Konfiguration)
+
+Die Deploy-Scripts laden ihre Server-spezifische Konfiguration (Pfade, Ports,
+Projekt-Namen) aus einer Datei `deploy.env`, die im gleichen Verzeichnis wie
+die Scripts liegen muss. Diese Datei ist **nicht Teil des Repos** und wird
+nicht per `git pull` ueberschrieben.
+
+Kopieren Sie die Vorlage und passen Sie die Werte an:
+
+```bash
+cp /opt/kbcrm/test-prod/repo/scripts/deploy.env.example /opt/kbcrm/scripts/deploy.env
+vi /opt/kbcrm/scripts/deploy.env
+```
+
+Inhalt der `deploy.env`:
+
+```bash
+# --- Test-Prod Umgebung (fuer deploy-kbcrm-test.sh) ---
+DEPLOY_REPO_DIR=/opt/kbcrm/test-prod/repo
+DEPLOY_ENV_FILE=/opt/kbcrm/test-prod/.env
+DEPLOY_PROJECT_NAME=kbptest
+DEPLOY_HEALTH_PORT=8443
+
+# --- Prod Umgebung (fuer deploy-kbcrm-prod.sh) ---
+DEPLOY_PROD_COMPOSE_FILE=/opt/kbcrm/test-prod/repo/docker-compose.prod.yaml
+DEPLOY_PROD_ENV_FILE=/opt/kbcrm/prod/.env
+DEPLOY_PROD_PROJECT_NAME=kbpprod
+DEPLOY_PROD_TEST_PROJECT_NAME=kbptest
+DEPLOY_PROD_HEALTH_PORT=443
+```
+
+Wenn `deploy.env` fehlt, verwenden die Scripts ihre eingebauten Defaults
+(die den obigen Werten entsprechen). Die `deploy.env` ist nur noetig, wenn
+Ihre Verzeichnisstruktur oder Ports abweichen.
 
 ---
 
@@ -291,7 +345,7 @@ Das Script fuehrt folgende Schritte aus:
    Build und Python mit Anwendungscode)
 3. Health-Check
 
-### 6.2. Manuelle Promotion nach Prod
+### 6.2. Manuelle Promotion nach Prod (Image-Promotion)
 
 Nach Verifikation auf dem Test-Server:
 
@@ -299,8 +353,22 @@ Nach Verifikation auf dem Test-Server:
 /opt/kbcrm/scripts/deploy-kbcrm-prod.sh
 ```
 
-Das Script fragt eine Bestaetigung ("yes/no") und fuehrt dann den gleichen
-Ablauf aus wie das Test-Script, jedoch mit der Prod-`.env`.
+Das Script fragt eine Bestaetigung ("yes/no") und uebernimmt dann die
+getesteten Images aus test-prod per `docker tag` — kein Rebuild, kein git pull.
+Prod startet mit exakt dem Stand, der in test-prod verifiziert wurde. Nur
+die `.env` unterscheidet sich (Ports, Zertifikate, DB-Pfad, OIDC).
+
+Ablauf:
+1. Sicherheitsabfrage ("yes/no")
+2. `docker tag` — Images von `kbptest-*` nach `kbpprod-*` kopieren
+3. `docker compose up -d` — Container starten (ohne `--build`)
+4. Health-Check
+
+**Wichtig:** Das Prod-Script fuehrt kein `git pull` aus. Eine Aenderung an
+der `docker-compose.prod.yaml` zwischen test-prod und Promotion wuerde
+bedeuten, dass prod mit einer anderen Konfiguration startet als verifiziert.
+Bei Aenderungen an der Compose-Datei muss erst ein neues test-prod-Deploy
+durchgefuehrt werden.
 
 ### 6.3. Alternative: Git-Tag-basierte Promotion
 
@@ -334,34 +402,34 @@ done
 
 ```bash
 # Test-Prod
-docker compose --env-file /opt/kbcrm/test-prod/.env \
+docker compose -p kbptest --env-file /opt/kbcrm/test-prod/.env \
     -f /opt/kbcrm/test-prod/repo/docker-compose.prod.yaml logs
 
 # Prod
-docker compose --env-file /opt/kbcrm/prod/.env \
-    -f /opt/kbcrm/prod/repo/docker-compose.prod.yaml logs
+docker compose -p kbpprod --env-file /opt/kbcrm/prod/.env \
+    -f /opt/kbcrm/test-prod/repo/docker-compose.prod.yaml logs
 
 # Nur Python-Container
-docker compose --env-file /opt/kbcrm/prod/.env \
-    -f /opt/kbcrm/prod/repo/docker-compose.prod.yaml logs pythonapp
+docker compose -p kbpprod --env-file /opt/kbcrm/prod/.env \
+    -f /opt/kbcrm/test-prod/repo/docker-compose.prod.yaml logs pythonapp
 
 # Nur NGINX-Container
-docker compose --env-file /opt/kbcrm/prod/.env \
-    -f /opt/kbcrm/prod/repo/docker-compose.prod.yaml logs nginx-proxy
+docker compose -p kbpprod --env-file /opt/kbcrm/prod/.env \
+    -f /opt/kbcrm/test-prod/repo/docker-compose.prod.yaml logs nginx-proxy
 ```
 
 ### Container-Status pruefen
 
 ```bash
-docker compose --env-file /opt/kbcrm/prod/.env \
-    -f /opt/kbcrm/prod/repo/docker-compose.prod.yaml ps
+docker compose -p kbpprod --env-file /opt/kbcrm/prod/.env \
+    -f /opt/kbcrm/test-prod/repo/docker-compose.prod.yaml ps
 ```
 
 ### Manuell in den Container wechseln
 
 ```bash
-docker compose --env-file /opt/kbcrm/prod/.env \
-    -f /opt/kbcrm/prod/repo/docker-compose.prod.yaml exec pythonapp bash
+docker compose -p kbpprod --env-file /opt/kbcrm/prod/.env \
+    -f /opt/kbcrm/test-prod/repo/docker-compose.prod.yaml exec pythonapp bash
 ```
 
 ### Rollback
@@ -370,10 +438,10 @@ Bei Problemen kann auf einen frueheren Stand zurueckgekehrt werden:
 
 ```bash
 # Auf dem Deploy-Server:
-cd /opt/kbcrm/prod/repo
+cd /opt/kbcrm/test-prod/repo
 git log --oneline -10          # frueheren Commit finden
 git checkout <commit-hash>
-docker compose --env-file /opt/kbcrm/prod/.env \
+docker compose -p kbpprod --env-file /opt/kbcrm/prod/.env \
     -f docker-compose.prod.yaml up -d --build
 ```
 
@@ -425,6 +493,7 @@ docker image prune -f
 - [ ] Datenbank-Verzeichnisse erstellt (`PYTHON_DB_DIR`)
 - [ ] SSL-Zertifikate abgelegt (`NGINX_CERTS`)
 - [ ] Deploy-Scripts kopiert und ausfuehrbar gemacht
+- [ ] `deploy.env` angelegt und angepasst (Pfade, Ports, Projekt-Namen)
 - [ ] Git-Hook oder Webhook eingerichtet (fuer automatisches Test-Deploy)
 - [ ] Erster manueller Deploy-Test: `deploy-kbcrm-test.sh`
 - [ ] Health-Check erfolgreich: `curl -k https://localhost:8443/health-check`