# Upgrade: vereinfachte GLPI-KB-Auto-Reply-Freigabe Die ITIL-basierte Artikelfreigabe wurde entfernt. Vor dem Start sollte die `.env` angepasst werden: ```env # Nur GLPI-Knowledge-Base-Kategorie-IDs GLPI_KB_AUTO_REPLY_CATEGORY_IDS=4,7 # Unkategorisierte Artikel nur über konkrete KnowbaseItem-IDs GLPI_KB_AUTO_REPLY_ALLOW_UNCATEGORIZED=true GLPI_KB_AUTO_REPLY_UNCATEGORIZED_ARTICLE_IDS=1,5 # Veraltet und wirkungslos GLPI_KB_AUTO_REPLY_ITIL_CATEGORY_IDS= ``` Ein alter `data/glpi-kb-cache.json` wird wegen der geänderten Sicherheitsregel nicht geladen. Der Agent synchronisiert die GLPI-KB neu und schreibt danach einen Cache mit aktueller Policy-Version und einem Hash der relevanten Freigabekonfiguration. Ändert sich später die Allowlist, wird ein Cache mit der alten Freigabe ebenfalls nicht verwendet. Die Diagnose trennt jetzt: - `Artikel darf für Auto-Reply verwendet werden`: Grundfreigabe über KB-Kategorie oder Artikel-ID. - `Artikel passt zur effektiven Ticketkategorie`: optionale fachliche Prüfung über ein vorhandenes GLPI-Mapping. Details stehen in `HOTFIX-GLPI-KB-SIMPLE-AUTO-REPLY.md`. ## Hotfix für fehlende Prioritätsläufe Das vorherige Quellarchiv konnte durch ein zu breites Paket-Ausschlussmuster die Verzeichnisse `cmd/agent` und `internal/agent` verlieren. In diesem Fall enthielten neue Laufdatensätze keine `analyses` und keine Prioritätsfelder. Dieses Paket enthält den vollständigen Quellstand. Bitte den Agenten vollständig ersetzen und neu bauen beziehungsweise eines der neuen Programme aus `dist/` verwenden. Historische Läufe werden nicht rückwirkend ergänzt; erst ein neuer Ticketlauf zeigt die Prioritätsdiagnose. Weitere Einzelheiten stehen in `HOTFIX-PRIORITAET.md`. # Upgrade-Hinweise ## Upgrade: eigenständige Analyseläufe, Priorisierung und Eskalation Diese Version erweitert den Audit-Datensatz abwärtskompatibel um `trigger` und `analyses`. Alte Zeilen in `data/runs.jsonl` bleiben lesbar; neue Läufe enthalten zusätzlich eigenständige Analyseobjekte. Beim ersten Start wird keine manuelle Datenmigration benötigt. Aus vorhandenen Auditzeilen wird zusätzlich `DATA_DIR/state-index.json` aufgebaut; diese Datei hält die letzte verarbeitete Version je Ticket und ausgeführte Eskalationsschlüssel unabhängig von der Diagnose-Aufbewahrung fest. Sehr große Auditdateien werden nach einem erfolgreichen Append automatisch auf die konfiguriert vorgehaltenen Läufe kompaktiert. Vor dem Upgrade sollte trotzdem eine Sicherung von `DATA_DIR` erstellt werden. Empfohlener erster Start: ```env DRY_RUN=true PRIORITY_ENABLED=true AUTO_PRIORITY=false ESCALATION_ENABLED=false AUTO_ESCALATION=false ``` Damit entstehen separate Prioritätsanalysen, aber keine neuen GLPI-Schreiboperationen. Nach der Auswertung im Diagnose-Cockpit kann die zeitgesteuerte Eskalation ebenfalls im Shadow Mode aktiviert werden: ```env ESCALATION_ENABLED=true AUTO_ESCALATION=false ESCALATION_SCAN_INTERVAL=15m ESCALATION_MIN_AGE=4h GLPI_ESCALATION_FILTER=status.id==1 ``` Vor `AUTO_PRIORITY=true` oder `AUTO_ESCALATION=true` sind die Rechte und API-Felder jeder freigegebenen Aktion zu prüfen. Live-Aktionen benötigen zusätzlich `DRY_RUN=false`. Zuweisungen, private Followups, Webhooks und der installationsspezifische Major-Incident-Linkadapter sollten einzeln im Shadow Mode getestet werden. Automatische Herabstufungen sind nicht implementiert. Details stehen in `ESCALATION.md`. Neue Variablen: - `PRIORITY_ENABLED`, `AUTO_PRIORITY`, `PRIORITY_CONFIDENCE`, `PRIORITY_MAX_INCREASE`, `PRIORITY_ALLOWED_REASON_CODES` - `ESCALATION_ENABLED`, `AUTO_ESCALATION`, `ESCALATION_SCAN_INTERVAL`, `ESCALATION_MIN_AGE`, `ESCALATION_MIN_INACTIVITY`, `ESCALATION_ANALYSIS_TIMEOUT`, `ESCALATION_CONFIDENCE`, `ESCALATION_MAX_LEVEL`, `ESCALATION_SLA_RISK_WINDOW` - `ESCALATION_SERVICE_OWNER_MIN_LEVEL`, `ESCALATION_MANAGER_REVIEW_MIN_LEVEL`, `ESCALATION_MAJOR_INCIDENT_MIN_RELEVANCE` - `ESCALATION_ALLOWED_REASON_CODES`, `ESCALATION_ALLOWED_ACTIONS` sowie die `ESCALATION_*_GROUP_ID`-/`*_USER_ID`-Ziele - `ESCALATION_ADD_PRIVATE_FOLLOWUP`, die fünf `ESCALATION_*_NOTE`-Templates und die optionalen `ESCALATION_WEBHOOK_*`-Werte - `GLPI_ESCALATION_GROUP_PATCH_FIELD`, `GLPI_ESCALATION_USER_PATCH_FIELD`, `GLPI_ESCALATION_ITIL_LINK_PATH`, `GLPI_ESCALATION_ITIL_LINK_BODY`, `GLPI_ESCALATION_FILTER`, `GLPI_ESCALATION_LIMIT` ## Vordefinierte Uptime-Kuma-Statusantworten Optional kann nach der Kategorieanalyse und vor der normalen KB-Antwortauswahl eine separate Uptime-Kuma-Zuordnung aktiviert werden. Die KI erzeugt dabei keinen Benutzertext. Sie liefert ausschließlich `matched`, `candidate_id`, `confidence` und eine interne Begründung. ```env CONTEXT_STATUS_REPLY_ENABLED=true CONTEXT_STATUS_REPLY_MIN_RELEVANCE=0.50 CONTEXT_STATUS_REPLY_MIN_AI_CONFIDENCE=0.80 CONTEXT_STATUS_REPLY_MIN_FINAL_SCORE=0.45 CONTEXT_INCIDENT_REPLY_TEXT=Zu Ihrer Meldung liegt derzeit wahrscheinlich eine zentrale Störung bei {{service_name}} vor. CONTEXT_MAINTENANCE_REPLY_TEXT=Für {{service_name}} läuft derzeit eine Wartung. ``` Go berechnet `final_score = relevance × ai_confidence`. Nur wenn alle drei Schwellwerte erreicht werden, wird der passende Betreibertext deterministisch gerendert und als Followup verwendet. Die normale KB-Antwortanalyse wird dann übersprungen. Ohne Aktivierung bleibt das bisherige Verhalten unverändert. Verfügbare Platzhalter sind `{{service_name}}`, `{{status}}`, `{{status_page}}`, `{{message}}`, `{{incident_title}}`, `{{incident_content}}` und `{{last_heartbeat}}`. ## Zweistufige Kategorie- und Antwortanalyse Die bisherige kombinierte Ollama-Entscheidung wurde in zwei echte, aufeinander folgende Analysen getrennt: 1. Die Kategorieanalyse erhält nur GLPI-Kategorien und Quellen aus `KNOWLEDGE_CATEGORY_SOURCES`. Antwortfelder werden entfernt. 2. Die normalen Antwort-KBs werden anschließend anhand der wirksamen Kategorie neu gerankt. Nur die ausgewählten Kandidaten gehen an einen zweiten Ollama-Aufruf für die Antwortauswahl. Die Diagnose unter `/diagnostics` zeigt beide Kandidatenlisten, beide KI-Begründungen, Laufstatus/Dauer und die Kategorie, auf der die Antwortauswahl beruht. Alte `runs.jsonl`-Einträge bleiben lesbar und werden als historischer gemeinsamer Lauf gekennzeichnet. Scheitert nur die zweite Ollama-Stufe, bleibt eine gültige Kategorieentscheidung erhalten; die Antwort wird fail-closed deaktiviert. Bei vorhandenem Followup, `AUTO_REPLY=false` oder fehlenden Antwortkandidaten wird die zweite Stufe gar nicht aufgerufen. ## Kategorisierung ohne auswählbare Antwort Wenn ein Ticket bereits ein Followup besitzt, `AUTO_REPLY=false` gesetzt ist oder kein Antwort-Knowledge-Kandidat verfügbar ist, wird ausschließlich die erste Kategorie-Stufe ausgeführt. Die zweite Antwort-Stufe wird mit einem expliziten Skip-Grund im Audit ausgelassen und kann die Kategorisierung nicht mehr mit einem Reply-Fehler abbrechen. ## Getrennte Sources für Kategorisierung und Antworten Knowledge-Quellen können jetzt getrennt nach Verwendungszweck freigegeben werden: ```env # Normale Suche und mögliche Antwortkandidaten KNOWLEDGE_ALLOWED_SOURCES=internal-kb,glpi-kb,runbook # Ausschließlich Klassifikationswissen KNOWLEDGE_CATEGORY_SOURCES=internal-category # Teilmenge der normalen Quellen für automatische Antworten KNOWLEDGE_AUTO_REPLY_SOURCES=internal-kb,glpi-kb ``` Der Index lädt die Vereinigung aus `KNOWLEDGE_ALLOWED_SOURCES` und `KNOWLEDGE_CATEGORY_SOURCES`. Einträge, deren Source nur in `KNOWLEDGE_CATEGORY_SOURCES` steht, werden ausschließlich als Hinweise für die Kategorieentscheidung verwendet. Ihre Antwortfelder werden nicht an Ollama übergeben, und ihre IDs können nicht als Antwort-Knowledge ausgewählt werden. Ohne gesetztes `KNOWLEDGE_CATEGORY_SOURCES` bleibt das bisherige Verhalten bestehen: Dann werden automatisch die Werte aus `KNOWLEDGE_ALLOWED_SOURCES` verwendet. Für die mitgelieferten `internal-category`-Dateien sollte die neue Variable ausdrücklich auf `internal-category` gesetzt werden. ## Neue/empfohlene Variablen ```env OLLAMA_NUM_PREDICT=768 OLLAMA_JSON_RETRIES=1 LEARNING_ENABLED=true LEARNING_MAX_EXAMPLES=500 LEARNING_EXAMPLES_PER_CATEGORY=5 # Nur bei authentifiziertem Dashboard aktivieren: KNOWLEDGE_WEB_EDIT_ENABLED=true ``` `KNOWLEDGE_DIR` bleibt statisch/read-only. Im Dashboard erzeugte Artikel werden automatisch unter `DATA_DIR/knowledge-managed/` gespeichert. Bestätigte Kategorie-Lernbeispiele liegen in `DATA_DIR/category-learning.json`. ## Gitea-Registry / Linux Das Image weiterhin in Gitea bauen. Auf dem Zielsystem ist kein lokaler Build erforderlich: ```bash export AGENT_IMAGE=gitea.example.de/organisation/glpi-ai-agent:latest mkdir -p data knowledge sudo chown 65532:65532 data docker compose -f docker-compose.registry.yml up -d --pull always ``` Der statische Ordner `./knowledge` bleibt read-only. Da Web-KB und Lernspeicher unter `./data` liegen, müssen nur die Daten für UID/GID `65532:65532` beschreibbar sein. ## Sicherer Start Für die ersten Lernläufe empfohlen: ```env DRY_RUN=true AUTO_CATEGORY=true AUTO_REPLY=false CATEGORY_CONFIDENCE=0.90 ``` Im Dashboard anschließend Entscheidungen bestätigen/korrigieren. Erst nach genügend beobachteten Tickets Schwellwerte oder Schreibrechte anpassen. ## GLPI Knowledge Base Connector Für den neuen read-only GLPI-KB-Sync ergänzen Sie bei Bedarf: ```env KNOWLEDGE_ALLOWED_SOURCES=internal-kb,glpi-kb GLPI_KB_ENABLED=true GLPI_KB_PATH=auto GLPI_KB_SYNC_INTERVAL=10m GLPI_KB_LIMIT=500 GLPI_KB_SOURCE=glpi-kb GLPI_KB_AUTO_REPLY=false GLPI_KB_AUTO_REPLY_CATEGORY_IDS= ``` Der sichere Start ist `GLPI_KB_AUTO_REPLY=false`. Erst nachdem die importierten Artikel im Dashboard geprüft wurden, sollte `glpi-kb` optional in `KNOWLEDGE_AUTO_REPLY_SOURCES` aufgenommen und eine explizite Whitelist von GLPI-Knowledge-Base-Kategorie-IDs gesetzt werden. ## Hybrid Knowledge Scoring Diese Version ersetzt den einzelnen Dokument-Cosine-Score durch ein Hybrid-Scoring mit Body-Chunks, Titel, Keywords und Kategorie-/Lernsignalen. Der bestehende `data/embeddings.json` Cache wird bei Bedarf automatisch im neuen Format aufgebaut; ein manuelles Löschen ist nicht erforderlich. Für bestehende `.env`-Dateien werden folgende Werte empfohlen: ```env KNOWLEDGE_MIN_SCORE=0.70 KNOWLEDGE_WEIGHT_SEMANTIC=0.50 KNOWLEDGE_WEIGHT_TITLE=0.25 KNOWLEDGE_WEIGHT_KEYWORDS=0.15 KNOWLEDGE_WEIGHT_CATEGORY=0.10 KNOWLEDGE_CHUNK_WORDS=160 KNOWLEDGE_CHUNK_OVERLAP_WORDS=30 KNOWLEDGE_MAX_CHUNKS_PER_DOC=24 ``` Der neue Hybrid-Score ist nicht direkt mit alten Cosine-Scores vergleichbar. Nach dem Upgrade zunächst im Dry-Run beobachten und den Mindestscore anhand realer Tickets kalibrieren. ## Dashboard / Knowledge-Editor v2 Das Dashboard wurde grundlegend überarbeitet. Es zeigt jetzt: - eine Betriebsübersicht mit GLPI-/Ollama-/GLPI-KB-Gesundheit, - die effektiven, nicht geheimen ENV-Werte gruppiert nach Agent, Ollama, RAG, GLPI-KB und Kontextquellen, - eine Detailansicht je Verarbeitung mit KI- und Policy-Entscheidung, - die Top-Knowledge-Kandidaten inklusive Hybrid-, Semantik-, Titel-, Keyword- und Kategorie/Lernscore, - die tatsächlich verwendeten Ticket-/KB-Chunks, - kompakte Details zu Changes, Major Incidents, Uptime-Kuma-Störungen und Benutzergeräten, - Filter für Verarbeitungen, Knowledge Base und Lernbeispiele. ### Geänderte Knowledge-API Der Webeditor verwendet jetzt explizite CRUD-Semantik: - `GET /api/knowledge/{id}` lädt einen Artikel frisch vom Server. - `POST /api/knowledge` legt einen neuen Web-Artikel an und liefert bei einer bereits existierenden ID `409 Conflict`. - `PUT /api/knowledge/{id}` aktualisiert ausschließlich einen bestehenden, Web-verwalteten Artikel. - Die ID eines Artikels kann beim Bearbeiten nicht geändert werden. - `DELETE /api/knowledge/{id}` löscht weiterhin nur Web-verwaltete Artikel. Statische Git-/Datei-Artikel und synchronisierte GLPI-KB-Artikel bleiben read-only. Neue Läufe speichern zusätzlich die Top-Knowledge-Kandidaten und kompakte Kontextdetails im Audit. Ältere `runs.jsonl`-Einträge bleiben kompatibel; dort sind diese neuen Detailfelder naturgemäß leer. ## Rich-Text-Antworten aus der GLPI Knowledge Base Synchronisierte GLPI-KB-Artikel behalten ab dieser Version zwei getrennte Darstellungen: - `text` / `answer`: bereinigter Plaintext für RAG, Ranking und LLM-Kontext. - `answer_html`: originales GLPI-Rich-Text-Markup ausschließlich für die spätere Ticketantwort. Dadurch bleiben bei Auto-Replies unter anderem Überschriften, Fett/Kursiv, Listen, Tabellen und Links erhalten. Das Rich-Text-Markup wird nicht an Ollama gesendet und beeinflusst keine Embeddings. Anrede und Signatur werden HTML-sicher um den KB-Inhalt ergänzt. Es sind keine neuen ENV-Variablen erforderlich. Nach dem Upgrade führt der initiale GLPI-KB-Sync automatisch dazu, dass `answer_html` im lokalen GLPI-KB-Cache ergänzt wird. ## Dynamisches Knowledge Top-K Für Installationen mit vielen Knowledge-Artikeln wird die Kandidatenauswahl ab dieser Version dynamisch begrenzt. Empfohlene Werte: ```env KNOWLEDGE_TOP_K=6 KNOWLEDGE_AUDIT_TOP_K=10 KNOWLEDGE_CANDIDATE_MAX_GAP=0.20 KNOWLEDGE_RETRIEVAL_FLOOR=0.30 ``` `KNOWLEDGE_TOP_K` ist die maximale Anzahl von Artikeln im Ollama-Prompt. Artikel werden nur übergeben, wenn sie mindestens den Retrieval-Floor erreichen und nicht mehr als `KNOWLEDGE_CANDIDATE_MAX_GAP` unter dem besten Treffer liegen. `KNOWLEDGE_AUDIT_TOP_K` steuert separat, wie viele Treffer für Dashboard/Audit aufbewahrt werden. Bestehende `.env`-Dateien sollten die drei neuen/angepassten Werte explizit ergänzen. ## Shared KB category compatibility Local knowledge JSON files may now use external string labels in `categories`. Recommended migration settings: ```env KNOWLEDGE_CATEGORY_MODE=unscoped KNOWLEDGE_CATEGORY_MAP_FILE=/app/data/knowledge-category-map.json KNOWLEDGE_IGNORE_GLOBS= ``` Unmapped labels no longer crash startup in `unscoped` mode. Such documents remain searchable but their `auto_reply` is disabled until all external labels are mapped. Use `skip` to ignore those documents or `strict` to retain fail-fast behavior. ## Große lokale Knowledge Bases (vNext) Lokale Knowledge-Verzeichnisse werden beim Prozessstart nicht mehr synchron vor dem HTTP-Server indexiert. Das WebUI startet zuerst; Scan, JSON-Validierung, Cache-Prüfung und Embeddings laufen anschließend im Hintergrund. Währenddessen gilt: - `/healthz` bleibt erreichbar. - `/readyz` liefert HTTP 503, bis GLPI, Ollama und die lokale Knowledge Base bereit sind. - Ticket-Polling und Worker starten erst nach erfolgreicher Knowledge-Initialisierung. - `/api/status` und das Dashboard zeigen Phase, Datei-/Dokumentfortschritt, Cache-Treffer, offene Embeddings und Fehler. - Bei einem fehlerhaften KB-Dokument bleibt das WebUI erreichbar und zeigt den Initialisierungsfehler an. Die Embedding-Erzeugung verarbeitet große Korpora dokumentweise in Batches. Nach dem ersten vollständigen Aufbau wird ein atomarer persistenter Snapshot geschrieben; spätere Starts verwenden diesen Snapshot und führen nur Delta-Scans aus. ## Persistenter inkrementeller Knowledge-Index Für große lokale KB-Bestände sollte die bestehende `.env` ergänzt werden: ```env KNOWLEDGE_INDEX_MODE=incremental KNOWLEDGE_EMBED_BATCH_SIZE=64 KNOWLEDGE_INDEX_SCAN_INTERVAL=5m ``` Der neue Snapshot liegt unter `DATA_DIR/knowledge-index/snapshot.gob`. Bei Docker muss `DATA_DIR` deshalb dauerhaft gemountet und für UID/GID `65532:65532` beschreibbar bleiben. `docker compose down -v` bzw. das Löschen des Host-Verzeichnisses entfernt auch den persistenten Index. Beim ersten Start dieser Version existiert noch kein Snapshot. Der Agent kann vorhandene gültige Vektoren aus dem bisherigen `DATA_DIR/embeddings.json` übernehmen und schreibt nach erfolgreichem Aufbau den neuen Snapshot. Danach wird `embeddings.json` für die lokale KB nicht mehr als primärer Index benötigt. Normaler Neustart in `incremental`: 1. Snapshot laden. 2. Knowledge sofort als `ready` markieren. 3. Ticketverarbeitung starten. 4. Quelldateien im Hintergrund per Größe/`mtime` vergleichen. 5. Nur geänderte Dateien lesen/hashen/parsen und nur geänderte Retrieval-Texte neu embedden. 6. Geänderten Snapshot atomar ersetzen. `KNOWLEDGE_INDEX_MODE=rebuild` erzwingt einen vollständigen Quellen-Scan. `readonly` verwendet ausschließlich den vorhandenen Snapshot und führt keine lokalen Delta-Scans aus. ## KI-Kennzeichnung Automatische Antworten tragen standardmaessig den TrustedNet-Kennzeichnungsblock am Anfang. Zum expliziten Aktivieren/Deaktivieren: `AI_CONTENT_LABEL_ENABLED=true|false`. ## Diagnose-Cockpit Nach dem Upgrade ist keine neue ENV-Variable erforderlich. Das neue Interface ist unter `/diagnostics` erreichbar und verwendet dieselbe Web-Authentifizierung wie das normale Dashboard. Neue Ticketläufe speichern strukturierte `category_checks`, `reply_checks` und `execution_checks` in `runs.jsonl`. Alte Laufdatensätze bleiben kompatibel, enthalten diese historischen Checks naturgemäß jedoch nicht rückwirkend. ## Kategorie-Mapping-Editor Das bestehende `KNOWLEDGE_CATEGORY_MAP_FILE` kann jetzt über das authentifizierte Webinterface unter `/category-mappings` gepflegt werden. Voraussetzungen: - `KNOWLEDGE_CATEGORY_MAP_FILE` zeigt auf eine für den Agenten beschreibbare Datei, empfohlen unter `DATA_DIR`, z. B. `/app/data/knowledge-category-map.json`. - `KNOWLEDGE_WEB_EDIT_ENABLED=true`. - Das Webinterface ist in Produktion authentifiziert (`WEB_ALLOW_ANONYMOUS=false`). Der Editor zeigt alle String-/Fremdkategorien der lokalen indexierten KB-Dateien, ihre Verwendungshäufigkeit und die aktuell aus GLPI gelesenen ITIL-Kategorien. Eine Fremdkategorie kann mehreren GLPI-Kategorien zugeordnet werden. Verwaiste Mappings bleiben sichtbar und können bewusst entfernt werden. Beim Speichern wird die Mapping-Datei atomar ersetzt. Anschließend werden die lokalen KB-Dateien hinsichtlich Kategoriezuordnung und Policy neu bewertet. Vorhandene Embeddings werden wiederverwendet, weil Kategorie-Mappings den an das Embedding-Modell gesendeten Text nicht verändern. ## Prioritäts-Hotfix: neutrale Enthaltungsgründe Nach diesem Update werden doppelte KI-Reason-Codes normalisiert. Eine unveränderte Prioritätsempfehlung mit `insufficient_information` erscheint nicht mehr als `priority_reason_not_allowed`, sondern als `priority_no_change_insufficient_information`. Es ist keine neue ENV-Variable erforderlich. Historische Läufe bleiben unverändert; die neue Semantik gilt für neu ausgeführte Prioritätsanalysen. ## Upgrade auf Prioritäts-Prompt `priority-v3` Es sind keine neuen Pflichtvariablen erforderlich. `OLLAMA_JSON_RETRIES=1` wird empfohlen, damit eine inkonsistente erste Modellausgabe einmal mit dem konkreten Validierungsfehler erneut angefordert werden kann. Nach dem Neustart gelten nur neue Ticketläufe als `priority-v3`. Historische Auditdaten werden nicht verändert. ## Emergency-Hotfix priority-v4 `priority-v3` konnte bei semantisch widersprüchlichen Modellantworten einen Wiederholungsaufruf erzeugen. Mit nur einem parallelen Ollama-Aufruf konnte dies die gesamte Ticketpipeline bis zum allgemeinen Ollama-Timeout verzögern. Neu: ```env PRIORITY_ANALYSIS_TIMEOUT=45s ``` Der Prioritätslauf ist nun strikt fail-open. Semantische Widersprüche werden deterministisch normalisiert und führen nicht mehr zu einem weiteren Modellaufruf. Beim Austausch des Releases `data/`, `knowledge/` und lokale Umgebungsdateien beibehalten. ## Upgrade auf mehrere Ollama-Nodes Die bisherige Einzelnode-Konfiguration bleibt kompatibel: ```env OLLAMA_URL=http://localhost:11434 OLLAMA_URLS= ``` Für einen Pool ergänzen Sie mindestens: ```env OLLAMA_URLS=http://10.20.30.21:11434,http://10.20.30.22:11434,http://10.20.30.23:11434 OLLAMA_NODE_NAMES=lenovo-01,lenovo-02,lenovo-03 OLLAMA_ROUTING_MODE=least_inflight OLLAMA_NODE_MAX_INFLIGHT=1 OLLAMA_FAILOVER_ENABLED=true OLLAMA_FAILOVER_ATTEMPTS=0 OLLAMA_REQUIRE_SAME_MODEL_DIGEST=true OLLAMA_REQUIRE_EMBEDDING_MODEL=true ``` Vor dem ersten Start müssen `OLLAMA_MODEL` und – bei aktivem RAG – `OLLAMA_EMBEDDING_MODEL` auf jedem Node vorhanden sein. Bei aktivierter Digest-Pflicht führt bereits ein abweichender Modellstand dazu, dass der Pool keine Requests annimmt. Das Dashboard zeigt pro Node Erreichbarkeit, Kompatibilität, Digest, Auslastung, Fehler und Laufzeit. Bestehende `runs.jsonl`-Einträge bleiben lesbar. Nur neue `AnalysisRun`-Datensätze enthalten den Bereich `provider` mit Node-Auswahl und Failover-Versuchen. `state-index.json` muss beim Upgrade erhalten bleiben.