VianoBugAnalysis/docs/joint-case-planning.md

Gemeinsame Interpretation und Hypothesengenerierung

Diese Seite dokumentiert das erhaltene v1-Protokoll. Neue gemeinsame Revisionen verwenden v2 mit Quellenbeschränkungen und gezielten Abhängigkeitsprüfungen.

Modus und Grenze

trial run --planning-mode joint aktiviert für eine neue, noch nicht interpretierte Analysis Revision einen gemeinsamen Aufruf. Standard bleibt separate als Vergleich. Der Modus wird samt Hypothesenpolicy und vorherigen Generationen im unveränderlichen Interpretationskontext gespeichert. Beim Wiederaufnehmen bleibt dieser Kontext maßgeblich, auch ohne erneute Angabe des Schalters. Ein bereits eingefrorener getrennter Kontext wird nicht rückwirkend umgestellt.

case_plan_v1 ist ein neuer englischer Prompt für einmaliges Fallverständnis: Beobachtungen, Erwartungs-/Beschreibungsprovenienz, Identitäten und Wissenslücken werden eingeordnet; daraus werden unterschiedliche ungetestete Mechanismen abgeleitet. Er verkettet nicht die bisherigen Systemprompts und überträgt den Fall nur einmal. Die bestehende deterministische Kontextselektion und JSON-Konsolidierung bleiben aktiv. Die Namensauflösung davor und die Hypothesenuntersuchung danach bleiben eigenständig. docs/architecture.md wird nicht verändert; die fachlichen Phasengrenzen bleiben erhalten.

Antwort und unabhängige Annahme

Der echte Modellaufruf liefert:

{
  "interpretation": {"...": "bestehender Interpretationsvertrag"},
  "hypotheses": {"hypotheses": ["Vorschläge mit interpretation_paths"]}
}

Die vollständigen Kindverträge stehen einmal im Prompt. Der Transportvertrag erlaubt unabhängig fehlerhafte/fehlende Kindblöcke. Ein gültiger Interpretationsblock geht deshalb nicht durch eine ungültige Hypothese verloren. Jeder Block wird separat mit dem bisherigen Schema und den fachlichen Provenienz-/Identitäts-/Diversitätsregeln geprüft. Hypothesen verwenden zunächst exakte JSON-Pointer zu ganzen Aussagen der Interpretation, z.B. /interpretation/observed_behavior/0. Erst nach Annahme der Interpretation bildet der Controller diese auf die deterministischen I-IDs des kanonischen Hypothesenkontexts ab. Unbekannte Pointer werden abgelehnt. Das Modell erfindet keine internen I-IDs.

Die Interpretation wird mit dem bisherigen Complete-Checkpoint gespeichert. Danach kann der Hypothesenbuilder ohne weiteren API-Aufruf den zweiten Block übernehmen und die bestehende Registry mit gleichen Startbudgets erzeugen. Beide fachlichen Artefakte referenzieren denselben echten Call. Es entstehen keine künstlichen LLM-Runden; Usage ist aus den llm/operations/*/round-*.json-Datensätzen einmalig zu summieren, nicht aus den wiederholten Metadaten der fachlichen Artefakte.

Fehler und Wiederaufnahme

• Gemeinsame lokale JSON-Korrektur und begrenztes Capture greifen weiterhin im Gateway.
• Jeder Kindblock kann zusätzlich unabhängig durch dieselben konservativen Objekt-/Array-Normalisierungsregeln geprüft werden. Der unveränderte Originalcall bleibt erhalten; die Projektion wird beim Lesen deterministisch erneut berechnet.
• Gültige Interpretation, ungültige Hypothesen: Interpretation bleibt unverändert; nur der Hypothesenblock wird über den bestehenden, begrenzten Korrekturpfad ersetzt. Der Folgeprompt enthält die akzeptierte Interpretation als Kontext, verlangt aber ausschließlich Hypothesen. Er erzeugt keine zweite Interpretation.
• Ungültige Interpretation: case_plan_interpretation_repair_v1 verlangt ausschließlich eine korrigierte Interpretation, mit deren Quellenkontext und konkretem Fehlerhinweis. Die Hypothesen des ursprünglichen Calls werden vorsichtshalber verworfen, weil ihre Abhängigkeit von der fehlerhaften Interpretation nicht sicher auszuschließen ist. Nach Annahme erzeugt der normale Hypothesenpfad neue Vorschläge.
• Nicht parsebare oder unvollständige Gesamtausgaben bleiben kontrolliert abgelehnt. Es werden keine fehlenden Fakten oder Endklammern ergänzt.
• Die bestehenden Retry-, Failover-, Fall-Locks, erwarteten Generationen und Maximalversuche bleiben verbindlich. Nach Abbruch zwischen den zwei fachlichen Complete-Checkpoints wird der gespeicherte Call verwendet, nicht neu generiert.
• Replay prüft Originalrequest, Hash, Identität, Phase, akzeptierte Interpretation und die exakte Pointerprojektion. Eine nachträglich geänderte Interpretation kann keine alten Hypothesen legitimieren.

--stop-after interpretation bleibt ein fachlicher Haltepunkt: Der gemeinsame Call hat Hypothesen bereits geliefert, veröffentlicht sie aber erst beim späteren Builder- Dispatch nach eigener Prüfung. Die Dispatchanzahl muss dadurch nicht um eins sinken; die Zahl tatsächlich kostenpflichtiger Aufrufe sinkt im gültigen Fall um eins.

Messung und zurückgestellte Arbeit

Offline mit dem gespeicherten BUG-20-Kontext des shared-recovery-Laufs: 37.999 Nachrichtzeichen für den neuen gemeinsamen Prompt gegenüber 41.419 für die Interpretation plus 42.287 für die erfolgreiche Hypothesengenerierung (83.706 zusammen). Das ist eine Zeichenmessung ohne neue API-Anfrage, kein Nachweis für eine bestimmte Token-/Kostenersparnis oder unveränderte semantische Qualität. Der Realtest muss Gesamteingabe, sichtbare Ausgabe, Denktokens, Korrekturen, Laufzeit und Qualität vergleichen.

Nach Umsetzung und Erprobung dieses Modus bleiben ausdrücklich zurückgestellt: Untersuchung der gespeicherten beschädigten Originalantworten auf sichere Reparierbarkeit; Vereinfachung ausführlicher Untersuchungsstarts und deterministische Ableitung unnötiger Zustandsangaben; weitere gezielte Senkung von Denk- und Korrekturkosten.