Schlüssel-Proxy, Server-Anforderungen und gitleaks-Regel für API-Werk

- tools/ki-proxy: setzt API-Schlüssel aus der Windows-Anmeldeinformationsverwaltung ein,
  nur im Speicher, ohne Header-Protokoll; Tests gegen Platzhalter-Server
- docs/server-anforderungen.md für den ITM-Entwickler
- .gitleaks.toml erkennt zki_/zodl_/zocr_-Schlüssel
- CLAUDE.md, Plan, Tech-Stack: Schlüssel nie in .env, in der App verschlüsselt in der DB

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

tools/ki-proxy/README.md

@@ -0,0 +1,65 @@
+# Schlüssel-Proxy für die KI-API (nur Entwicklung)
+
+Der Proxy setzt die API-Schlüssel von ITM in Anfragen an `https://api-werk.de` ein. Claude Code,
+Tests und die App in Sail rufen den Proxy ohne Schlüssel auf und sehen ihn nie. Die Schlüssel
+liegen in der Windows-Anmeldeinformationsverwaltung. Der Proxy liest sie beim Start und hält sie
+nur im Arbeitsspeicher; er protokolliert Methode, Pfad, Status und Dauer, aber keine Header.
+
+In Staging und Produktion gibt es keinen Proxy: Dort stehen die Schlüssel verschlüsselt in der
+Datenbank (Verwaltung → Einstellungen).
+
+## Einmalig: Schlüssel in den Windows-Tresor eintragen
+
+Systemsteuerung → Anmeldeinformationsverwaltung → Windows-Anmeldeinformationen →
+„Generische Anmeldeinformationen hinzufügen“:
+
+| Internet- oder Netzwerkadresse | Benutzername | Kennwort |
+|---|---|---|
+| `ki-bauin/itm-ki` | `api` | KI-Schlüssel (`zki_…`) |
+| `ki-bauin/dataloader` | `api` | OpenDataLoader-Schlüssel (`zodl_…`) |
+| `ki-bauin/ocr` | `api` | OCR-Schlüssel (`zocr_…`) |
+
+Schlüssel nie in ein Terminal, eine Datei oder den Chat mit Claude kopieren.
+
+## Starten (nur du, in einem eigenen Terminal)
+
+```bash
+cd ~/code/ki-bauin
+python3 tools/ki-proxy/ki_proxy.py --check   # zeigt nur „gefunden“ / „FEHLT“, keine Werte
+python3 tools/ki-proxy/ki_proxy.py           # läuft, bis Strg+C
+```
+
+Nach dem Ändern eines Schlüssels den Proxy neu starten. Claude Code startet den Proxy nie selbst;
+ein Hook in `~/.claude/settings.json` sperrt das zusätzlich.
+
+## Adressen
+
+| Von | Adresse |
+|---|---|
+| WSL (Claude Code, Skripte) | `http://127.0.0.1:8787` |
+| App in Sail (Container) | `http://host.docker.internal:8787` |
+
+Pfade wie bei api-werk.de: `/v1/ki/…`, `/v1/dataloader/…`, `/v1/ocr/…`. Andere Pfade lehnt der
+Proxy ab. Über die Netzwerkkarte der WSL und aus dem LAN ist er nicht erreichbar.
+
+```bash
+curl -s http://127.0.0.1:8787/v1/ki/models
+```
+
+## Was der Proxy schützt und was nicht
+
+- **Geschützt:** Der Schlüssel steht in keiner Datei, keiner Umgebungsvariablen und keinem
+  Startbefehl. Den Speicher des Proxys können andere Prozesse nicht lesen (`ptrace_scope=1`).
+  Ein Hook sperrt für Claude Code Windows-Programme (`powershell.exe`, `cmdkey.exe` usw.), das
+  Auslesen fremder Prozesse und das Starten des Proxys.
+- **Nicht geschützt:** Das ist ein Schutz vor Versehen, kein Schutz vor Absicht. Jeder Prozess
+  auf deinem Rechner kann den Proxy aufrufen, solange er läuft. Und der Proxy schützt die
+  Schlüssel, nicht die Daten: Echte Kundendaten gehen trotzdem nicht an Claude.
+
+## Tests
+
+```bash
+python3 -m unittest discover -s tools/ki-proxy
+```
+
+Die Tests laufen gegen einen Platzhalter-Server, ohne Tresor und ohne Netz.