119 lines
6.5 KiB
Markdown
119 lines
6.5 KiB
Markdown
# 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.
|
|
|
|
```powershell
|
|
.\.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:
|
|
|
|
```powershell
|
|
.\.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:
|
|
|
|
```powershell
|
|
.\.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:
|
|
|
|
```powershell
|
|
.\.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](early-correction-v1.md): 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.
|
|
|
|
```powershell
|
|
.\.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.
|