Add lean hypothesis startup round with joint evidence review

docs/investigation-startup-batch-v1.md

@@ -0,0 +1,57 @@
+# 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.