# wowdiag-worker v0.4 – BugAnalysis-Übergabe Erweiterung des vorgelegten v0.3-Workers. Die ursprüngliche Queue-Claim-Logik und DB-Struktur bleiben erhalten. Keine Änderung der aktiven `config.toml`, kein Dienststart und keine Datenbankmigration durch diese Dateien. Nach erfolgreicher wowdiag-/wowsrc-Erzeugung wird ein Versandauftrag dauerhaft in einer separaten lokalen SQLite-Outbox gespeichert. `diagnostic_runs.completed` bedeutet weiterhin **Erfassung abgeschlossen**, nicht Analyse abgeschlossen oder API-Zustellung bestätigt. Die Versandquittung ist über `--handoff-status` sichtbar. Die API übernimmt den Fall anschließend in ihren eigenen Analyseworker. ## Einrichtung 1. Bestehende `wowdiag_worker.py` sichern und die v0.4-Datei sowie `buganalysis_handoff.py` nebeneinander installieren. Python 3.11 und PyMySQL bleiben die Voraussetzungen; der HTTP-Client benötigt keine neue Bibliothek. 2. Den Abschnitt aus `buganalysis.config.example.toml` in die vorhandene Worker-Konfiguration übernehmen. Tatsächliche URL und Projektzuordnung setzen. Der URL muss die Serverwurzel sein; HTTPS ist für entfernte Server erforderlich. 3. Einen Integrationsschlüssel in BugAnalysis für das Projekt erzeugen und im Dienst-Environment als `VBA_INTAKE_TOKEN` hinterlegen. Unter Linux eine geschützte systemd-EnvironmentFile verwenden; den Schlüssel nicht in Skriptargumente, Repository oder Worker-Logs schreiben. Bestehende Unit um EnvironmentFile ergänzen und anschließend kontrolliert neu starten. 4. SQLite-Outbox und Diagnosearchive bis zur bestätigten Zustellung erhalten. Das Outbox-Verzeichnis muss für den Worker schreibbar sein und einen lokalen Datenträger mit SQLite-Dateisperren verwenden. Die Datei nicht zwischen unabhängigen Installationen teilen. Ohne aktivierten `[buganalysis]`-Abschnitt bleibt der bisherige Ablauf erhalten. Das Flag bedeutet ausschließlich Erfassung plus Übergabe; der Worker löst keine Modellanfrage selbst aus. Ein laufender BugAnalysis-Worker kann nach Annahme allerdings sofort eine kostenpflichtige Analyse beginnen. ## Wiederholungen und Status ```sh python3 wowdiag_worker.py --config config.toml --handoff-status python3 wowdiag_worker.py --config config.toml --retry-handoffs ``` Diese beiden Befehle führen keine Erfassung aus. Der normale Dauerdienst sendet fällige Aufträge vor dem nächsten Capture; `--once` versucht sie auch danach. Netzwerkfehler, Serverausfälle, temporäre Ablehnungen und fehlende/ungültige Zugangsdaten bleiben `pending`. Nach Behebung werden dieselben Inhalte mit demselben Idempotenzschlüssel versandt. Auch eine verlorene Erfolgsantwort legt dadurch keinen zweiten Fall an. Es werden keine HTTP-Redirects verfolgt. Unveränderliche Metadaten, Ziel-URL, Archivpfade und Inhaltsprüfwerte stehen in der Outbox; Zugangsdaten stehen dort nicht. Archivänderung oder endgültiger HTTP- Konflikt wird `attention` und benötigt Betreiberprüfung. Ein Lease verhindert gleichzeitigen regulären Versand durch mehrere Worker-Prozesse. Ein Prozessabbruch lässt den Auftrag nach Ablauf des Lease erneut versuchen. Es gibt keine automatische Neuerzeugung von Archiven oder ein Zurücksetzen der ursprünglichen Queue-Claims. Bereits vor dem Update abgeschlossene Erfassungen werden nicht automatisch nachträglich eingesendet. Ein erneuter neuer Auftrag für dieselbe Bug-ID wird von BugAnalysis bewusst abgewiesen, wenn der Fall bereits existiert. Rückgaben nach einem Patch erfolgen über den separaten `case_return`-Vertrag und nicht durch automatisches Umdeuten neuer Captures. Der Übergabeumschlag nennt die Bug-ID und den Erfassungs-Commit. Die wirklichen Testerbeobachtungen, Titel und Beziehungen liest der BugAnalysis-Importer direkt aus den unveränderten Archiven. Der Worker erfindet keine Beobachtungen und gibt den Erfassungsstand nicht als Stand der ursprünglichen Fehlermeldung aus. ## Lokale Prüfung im BugAnalysis-Checkout `python -m pytest tests/profiles/vcore/test_capture_handoff.py` prüft den Versand gegen die echte lokale Intake-API mit synthetischen Archiven. Kein echter Server, keine Cloud- Anfrage, keine Änderung der Diagnose-Queue. Ein Server-Feldtest mit einem neuen Bug und Dienstneustart steht nach der Konfiguration noch aus.