VianoBugAnalysis/docs/investigation-startup-batch-v1.md

Schlanke Startrunde mit gemeinsamer Bewertung

Neue Fälle können mit --investigation-config config/investigation.startup-batch.toml gestartet werden. Diese Konfiguration aktiviert startup_batch_review = true bei lean_loop = true und lean_protocol = 2. Bisherige Konfigurationen und eingefrorene Fallzustände werden nicht migriert. Ein geänderter expliziter Konfigurationsstand wird bei bestehenden Fällen wie bisher kontrolliert abgelehnt.

Ablauf und Grenzen

1. Der Controller wählt die vorhandenen Hypothesen in numerischer Reihenfolge. Jede erhält eine schlanke investigation_startup_v1-Anfrage für genau einen zulässigen Rechercheauftrag. Keine Confidence-Bewertung, kein Arbeitsstand, keine Abschluss-/Wechselentscheidung. Bereits terminale Konten werden übersprungen.
2. Jeder Auftrag wird vor Ausführung vollständig technisch geprüft. Reservierung, Kostenbelastung, Resultat und Provenienz werden sofort dauerhaft gespeichert. Das Ergebnis wartet auf die semantische Bewertung; es gibt noch keinen Reward.
3. Alle erfassten Ergebnisse der Startrunde sind für die folgenden Hypothesen lesbar. Es erfolgt weder eine zusätzliche LLM-Zusammenfassung noch eine Kürzung der Payloads.
4. Nach der Startrunde bewertet investigation_startup_review_v1 alle ausstehenden Hypothesen gemeinsam. Fallkontext und Ergebnisse stehen einmal im Prompt; identische Bewertungsverträge ebenfalls nur einmal. Findings, Confidence, Gegenbelege, offene Fragen und Informationswert werden pro Hypothese geprüft.
5. Gültige Einzelbewertungen werden mit echten LLM-Quellenverweisen übernommen; fehlerhafte Geschwister werden nicht mit übernommen. Nur diese verbleibenden Blöcke werden erneut angefordert. Sichere bestehende Formnormalisierung greift auch auf die einzelnen Blöcke. Unbekannte Evidenz oder unzulässige Scores bleiben ungültig. Eine begrenzte Anzahl fehlerhafter Runden führt zu BLOCKED.
6. Nach der vollständigen Bewertung setzt der bisherige Confidence-Scheduler fort. Die weitere schlanke Schleife, Frühabschlussprüfung und finale Diagnose bleiben inhaltlich unverändert. Die Startrunde ist auf die vorhandene Hypothesenmenge ausgelegt und nicht auf exakt drei Einträge fest verdrahtet.

Persistenz und Wiederaufnahme

Die versionierte Policy und startup im Investigation-State halten Reihenfolge, Fortschritt, eingefrorene Bewertungskontexte, Anfragen, akzeptierte Einzelbewertungen und deren Bindung an die tatsächlichen LLM-Antworten fest. Die Bewertungsanfragen werden vor Aufruf gespeichert und bei Wiederaufnahme rekonstruiert/geprüft. Budgetsettlements sind idempotent; bei einem Abbruch nach der Abrechnung wird die bereits gespeicherte Antwort erneut projiziert, statt erneut angefragt/vergütet.

Neue Kontexte, Anfragen und Arbeitsstände werden durch bestätigte Checkpoints als Analyseartefakte ausgewiesen. Sie verändern nicht nachträglich den Case-Inputhash. Ein importiertes Paket trägt die benötigten Zustände und Antwortprovenienz mit sich. Beide Prompttypen unterstützen die bestehende verlustfreie Cache-Aufteilung.

Erprobung

Die lokalen Tests prüfen automatische Reihenfolge, gemeinsame Evidenzsicht, ausstehende und abschließende Budgetabrechnung, getrennte Blockvalidierung, Korrektur nur fehlerhafter Blöcke, Import/Wiederaufnahme, Abbruch nach Settlement, verbotene Aktionen, Wiederholungsgrenzen, terminale Konten, Cache-Aufteilung, variable Hypothesenmengen und den anschließenden Confidence-Scheduler. Kostenpflichtige API-Tests erfolgen durch den Nutzer. Eine wirtschaftliche Einsparung ist erst durch den Vergleich der gesamten Startrunde inklusive Bewertung und Korrekturen nachweisbar; kleinere Einzelprompts allein reichen dafür nicht aus.