VianoBugAnalysis/docs/first-llm-trial.md

Erster LLM-Test

Der einmalige Testtreiber verbindet vorhandene Komponenten. Er ist kein Daemon: genau ein Fall, begrenzte Dispatches, keine Hintergrund-Wiederholungen, keine automatische Wiederaufnahme blockierter Fälle. Architektur und Projektcode bleiben unverändert. Die bekannte Fehlerlösung gehört nicht in Eingaben oder Prompts.

Vorbereitung in PowerShell

Alle Befehle aus dem Repository-Hauptverzeichnis ausführen, nicht aus config/. Python 3.11+ und die installierte Projektumgebung werden vorausgesetzt. Die lokale Datei config/llm.local.toml muss existieren; API-Schlüssel kommen ausschließlich aus den darin benannten Umgebungsvariablen. Das Programm muss aus der PowerShell mit diesen Variablen gestartet werden. Es lädt keine .env automatisch.

.\.venv\Scripts\python.exe -m viano_bug_analysis.trial check

CONFIG_READY bestätigt gültige Konfiguration und vorhandene Schlüssel aller aktivierten, zulässigen Anbieter. Es prüft keine Erreichbarkeit, Modellfreigabe, Abrechnung oder JSON-Kompatibilität. Es sendet keine Netzwerkanfrage und gibt keine Schlüssel aus. Ohne API-Key erscheint LLM_CREDENTIALS.

Import des Beispielpaars ohne LLM:

.\.venv\Scripts\python.exe -m viano_bug_analysis.trial prepare --workspace service-data --wowdiag "C:/Users/User/Desktop/Cata Bug fixes/BUG-000020-20261008-130429.tar.gz" --wowsrc "C:/Users/User/Desktop/Cata Bug fixes/WOWSRC-BUG-000020-20261008-130446.tar.gz" --case-id BUG-000020 --package-id trial-BUG-000020

Die Ausgabe PREPARED nennt den vollständigen package-Pfad in service-data/inbox/. IDs werden explizit vergeben; Dateinamen liefern keine Identität. Ohne --package-id entsteht eine UUID. Identische erneute Vorbereitung überschreibt keine vorhandene Datei. service-data/ und config/*.local.toml sind durch Git ausgeschlossen. Originalarchive bleiben unverändert.

Echte Verarbeitung

Nur dieser Schritt kann kostenpflichtige LLM-Aufrufe auslösen und bei cloud_allowed zusammengestellte Falldaten an Cloud-Dienste senden:

.\.venv\Scripts\python.exe -m viano_bug_analysis.trial run --workspace service-data --package "VOLLSTAENDIGER_PACKAGE_PFAD_AUS_PREPARED"

Der erste Lauf validiert die Inbox-Datei, sichert den Original-ZIP im Cache und übernimmt ihn in die verwalteten Generationen. Nach bestätigter Aufnahme wird die Inbox-Datei quittiert. Andere Inbox-Dateien werden nicht verarbeitet. Phase und Dispatchnummer erscheinen auf stderr; das finale JSON auf stdout enthält Identität, Zustand, Generation, Routing und ggf. Export-/Retry-Pfad.

Für den ersten Verbindungstest --max-dispatches 2 ergänzen: Bei einem frischen Paket wird der Case deterministisch gebaut und anschließend die Interpretation angefragt. Bei Erfolg endet dieser kurze Lauf mit YIELDED. Anschließend mit den stabilen IDs weiterarbeiten. Bereits bestätigte Schritte werden wiederverwendet.

Nach Aufnahme mit der stabilen Identität fortsetzen:

.\.venv\Scripts\python.exe -m viano_bug_analysis.trial run --workspace service-data --case-id BUG-000020 --package-id trial-BUG-000020

Ein Prozess führt standardmäßig höchstens 100 Dispatches aus. Das ist eine konfigurierbare Testlaufgrenze (--max-dispatches), kein neues Hypothesenbudget und keine Geldgrenze. Investigation macht einen kontrollierten Schritt pro Dispatch. Die bestehenden Hypothesenbudgets und Iterationsgrenzen gelten weiter. Bei YIELDED setzt derselbe Resume-Befehl die Analyse fort.

RETRY_PENDING/DEFERRED beendet den Lauf sofort mit dem frühesten nächsten Zeitpunkt. Nach diesem Zeitpunkt denselben Resume-Befehl ausführen. Kein Sleep oder automatischer Neustart: zehn Provider-Runden benötigen wiederholte fällige Dispatches. BLOCKED bleibt blockiert, auch wenn eine Frist vergeht. Externe Testanfragen erhalten ihre Reservierungen; die spätere bestätigte Feedback- Integration ist für deren Wiederaufnahme zuständig.

Interpretation/Hypothesen mit ungültiger Antwort verwenden die begrenzte Korrekturschleife: standardmäßig drei ungültige Antworten pro Phase/Revision, einschließlich vorheriger Fehlversuche. Neue Antworten erhalten Validierungsfeedback. --attempt-id setzt diese Grenze nicht zurück. Nach Ausschöpfung erfolgt früher Review ohne Diagnose/Coding-Auftrag. Die späteren Phasen behalten ihre bestehenden Grenzen. Keine automatische neue Analysis Revision oder Budgetzurücksetzung findet statt.

Optionale Konfigurationspfade: --analysis-config, --budget-config, --investigation-config, --diagnosis-config, --change-request-config, --telemetry-config, --llm-config, --correction-config. Ohne Pfade gelten die bestehenden Defaults. Bereits eingefrorene Policies nicht zwischen Resume-Läufen ändern; dieselben Optionen erneut angeben. Der gesamte Gateway-Konfigurationsfingerprint ist Teil der Operation; Änderungen können kontrolliert als Konflikt abgelehnt werden.

Ergebnis und Diagnose

• OUTPUT_READY: validiertes ZIP mit Diagnose und Coding-Auftrag in outbox/.
• REVIEW: validiertes ZIP mit Untersuchungsbericht in review/; kein Coding-Auftrag.
• BLOCKED: langlebiger verwalteter Fall; Grund und Budgets bleiben erhalten.
• YIELDED, RETRY_PENDING, DEFERRED, REJECTED: kontrollierter Zwischenstand.
• ERROR/QUARANTINED: Fehlercode und ggf. Quarantäne-Diagnose prüfen.

Exitcodes: 0 für erfolgreiche Vorbereitung/Prüfung/lokale Ausgabe, 3 für einen Zwischen-/Wartezustand, 2 für Fehler, 130 für Abbruch mit Ctrl+C. Ein Review ist ein erfolgreiches kontrolliertes Analyseergebnis, kein bewiesener Fix.

.\.venv\Scripts\python.exe -m viano_bug_analysis.telemetry status --workspace service-data
.\.venv\Scripts\python.exe -m viano_bug_analysis.telemetry errors --workspace service-data
.\.venv\Scripts\python.exe -m viano_bug_analysis.telemetry events --workspace service-data

Logs, Status und Prometheus-Text liegen in service-data/runtime/telemetry/. STOPPED nach einem beendeten Testlauf ist normal. Stack-Diagnosen enthalten keine freien Exceptiontexte, Prompts oder Schlüssel. Der Treiber bleibt bei kontrollierten Fehlern ohne rohe Tracebacks. Fallartefakte enthalten hingegen die fachlichen LLM-Anfragen/-Antworten und sind entsprechend vertraulich.

Vergleiche anschließend Diagnose, Evidenz und ggf. Änderungsauftrag mit der bekannten Fehlerlösung. Ein Live-Test beweist die Modellqualität noch nicht; insbesondere fehlende Sollinformationen oder nicht angeschlossene externe Research-/Tester-Dienste können zu Wartezuständen oder Review führen.