# 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.