Bugfix

README.md

@@ -31,6 +31,35 @@ Produktionsorientierter, bewusst **policy-gesteuerter** Ticket-Agent für GLPI 1
 
 Beim Start lädt der Agent `/api.php/doc.json` und prüft, ob die erwarteten Kernrouten vorhanden sind. Dadurch schlägt ein API-Mismatch früh und sichtbar fehl. Die mitgelieferten Tests laufen gegen HTTP-Mocks; eine echte GLPI-Instanz konnte in dieser Build-Umgebung nicht angebunden werden, daher ist der Shadow-Mode auf deiner Installation vor Live-Schreibzugriff zwingend.
 
+## Start nativ unter Windows / PowerShell
+
+Für einen nativen Windows-Start **nicht** die Docker-Pfade `/app/data`, `/app/knowledge` oder den Docker-Hostnamen `ollama` verwenden. Die mitgelieferte `.env.example` enthält deshalb jetzt native, plattformneutrale Defaults:
+
+```env
+DATA_DIR=./data
+KNOWLEDGE_DIR=./knowledge
+OLLAMA_URL=http://localhost:11434
+```
+
+Einmalig:
+
+```powershell
+Copy-Item .env.example .env
+# Danach .env mit den echten GLPI-Zugangsdaten bearbeiten.
+ollama pull qwen3:8b
+ollama pull embeddinggemma
+```
+
+Start:
+
+```powershell
+.\run.ps1
+```
+
+`run.ps1` lädt `.env`, startet immer aus dem Projektverzeichnis und erkennt zur Migration auch alte Docker-Werte. Beispielsweise wird ein vorhandenes `KNOWLEDGE_DIR=/app/knowledge` beim nativen Windows-Start auf `<Projekt>\knowledge` umgesetzt und mit einer Warnung ausgegeben. Das Datenverzeichnis wird bei Bedarf erstellt; ein fehlendes Knowledge-Verzeichnis führt zu einer verständlichen Fehlermeldung statt zu einem Panic.
+
+Docker Compose überschreibt diese drei nativen Werte im Container weiterhin explizit mit `/app/data`, `/app/knowledge` und `http://ollama:11434`.
+
 ## Start mit Docker Compose
 
 ```bash
@@ -44,7 +73,7 @@ docker compose exec ollama ollama pull embeddinggemma
 docker compose up -d --build agent
 ```
 
-Dashboard: `http://127.0.0.1:7080/`
+Dashboard: `http://127.0.0.1:8080/`
 
 Vor dem ersten Live-Betrieb unbedingt mehrere Tage/Wochen im Shadow Mode lassen:
 
@@ -264,3 +293,30 @@ make test
 make vet
 make build
 ```
+
+
+## Docker troubleshooting: `/app/data` permission denied and slow Ollama
+
+The Compose stack contains a one-shot `agent-data-init` service. It prepares the named `agent-data` volume for the non-root agent user before the agent starts. The agent also probes `runs.jsonl` at startup and exits immediately with a clear error if the volume is not writable.
+
+For local LLMs, the default request budget is intentionally longer than a typical HTTP API call:
+
+```env
+OLLAMA_TIMEOUT=10m
+OLLAMA_NUM_PREDICT=256
+OLLAMA_KEEP_ALIVE=10m
+OLLAMA_THINK=false
+OLLAMA_MAX_CONCURRENT=1
+```
+
+`OLLAMA_NUM_PREDICT` limits the maximum generated tokens for the small structured decision. `OLLAMA_KEEP_ALIVE` asks Ollama to keep the analysis model loaded between tickets. `OLLAMA_THINK=false` disables optional model thinking for this deterministic classification task. `OLLAMA_MAX_CONCURRENT=1` serializes local Ollama inference even when multiple ticket workers are active, so queued requests do not consume their HTTP timeout while waiting for the model. On very slow CPU-only hosts, use a smaller local model and/or increase `OLLAMA_TIMEOUT`.
+
+After upgrading an existing Compose deployment, recreate the stack so the init service runs:
+
+```bash
+docker compose down
+docker compose build --no-cache agent agent-data-init
+docker compose up -d
+```
+
+You do **not** need to delete `agent-data`; the init service fixes ownership on the existing named volume.