6.3 KiB
Gemeinsame Planung v2: Quellen, Teilkorrekturen und Abhängigkeiten
Neue Revisionen mit trial run --planning-mode joint verwenden case_plan_v2.
Der Kontext speichert joint_generation.version=2. Bereits eingefrorene v1-Kontexte
und Requests bleiben unverändert und über den bisherigen Pfad wiederaufnehmbar.
Der getrennte Modus, Investigation-Loop, Tools, Budgets und Diagnose bleiben unverändert.
docs/architecture.md wurde nicht geändert. Syntaxreparaturen sind ein separater Ausbau.
Quellenklassen und ausdrückliche Testerannahmen
Die dynamischen Interpretationsverträge beschränken source_ids je Aussagekategorie auf tatsächlich vorhandene IDs der zulässigen Quellentypen. Dies gilt im Prompt und in der fachlichen Annahme, nicht nur im Transport. Leere Quellmengen erlauben nur leere entsprechende Aussagearrays. Testerannahmen sind in v2 ausschließlich aus explizit typisierten tester_assumption-Quellen zugelassen. Kommentare/Beobachtungen werden nicht allein durch ihre Verfügbarkeit zu Annahmen. Ohne solche Quellen bleibt tester_assumptions leer. Die LLM darf eigene Schlussfolgerungen nicht dem Tester zuschreiben.
Explizite Voraussetzungen
Jeder v2-Wire-Vorschlag enthält premises mit kind=grounded oder unverified, knappem Text, source_ids und interpretation_paths. Grounded benötigt mindestens einen Verweis und darf keine ungelesenen Referenzen als gelesenen Beleg ausgeben. Referenzen müssen im Kontext und in den eigenen deklarierten Vorschlagsreferenzen existieren. Hypothesen bleiben spekulativ; eine Voraussetzung ist keine Bestätigung des Mechanismus. Die vollständigen Voraussetzungen und Reviews bleiben im unveränderlichen Originalcall. Die kanonischen Vorschläge behalten den bisherigen Vertrag und erhalten nach Prüfung nur deterministisch aufgelöste I-IDs. Übernahme/Replays prüfen den Original-Wire-Vertrag erneut.
Lokale Beanstandungen und begrenzte Patches
Ablehnungen speichern validation_issues mit Aussage-/Feldpfad, Fehlerkategorien und Quell-/Schemahinweisen. Korrigierbare Stellen werden aus der tatsächlichen Antwort ermittelt: Quellenklassen, unbekannte Quellen, Schemafehler, Entity-Provenienz, fehlende Erwartungs-Vollständigkeit und Lookup-Ungewissheit. Unbekannte/globale Fehler und zu viele Stellen erhalten keinen frei geratenen Patchbereich.
case_plan_statement_repair_v2 verlangt nur Patches für genau die beanstandeten Stellen. Ein Patch ersetzt eine ganze Aussage bzw. ein nötiges oberes Feld. Null darf eine beanstandete Arrayaussage entfernen; Löschungen werden absteigend angewandt, damit sich Indizes nicht während der Zusammensetzung verschieben. Andere Stellen können nicht überschrieben werden. Ein fehlender oder zusätzlicher Pfad wird abgelehnt. Es gibt keine stille Entfernung unzulässiger Quellen oder Testerbehauptungen.
Der Request enthält beanstandete Aussagen, nötige verfügbare Quellen, die vorhandenen Hypothesen samt Voraussetzungen und deren deklarierten Interpretationsaussagen. Er enthält keinen weiteren vollständigen Case. Kontextkomprimierung/Konsolidierung bleiben aktiv. Source-Call und Hash binden die unveränderte Ausgangsantwort außerhalb der Komprimierung. Danach wird die vollständig zusammengesetzte Interpretation geprüft. Ist keine sichere Lokalisierung möglich, bleibt der bisherige begrenzte Ersatzpfad verfügbar.
Individuelle Hypothesenprüfung
Der Korrekturaufruf muss jede Hypothese auf direkte UND implizite Abhängigkeit von korrigierten Aussagen prüfen, auch ohne direkten Verweis auf diese Stellen. Er meldet:
- retain: begründet unabhängig, keine neue Vorschlagsfassung.
- replace: gezielt ein Ersatzvorschlag im vollständigen v2-Vertrag.
- uncertain: keine ungeprüfte Übernahme.
Der Controller lässt retain nur zu, wenn zusätzlich ALLE deklarierten Inputs exakt unverändert sind. Bei Löschungen wird der Inhalt am Pointer verglichen, nicht nur dessen Fortbestehen. Geänderte direkte Grundlagen erfordern Ersatz oder weitere Prüfung. Der Controller kann versteckte Bedeutungsabhängigkeiten nicht beweisen; die semantische Review bleibt eine fehlbare LLM-Bewertung. Fehlende Referenzen allein gelten niemals als Nachweis von Unabhängigkeit. Alle zusammengesetzten Vorschläge durchlaufen erneut Quellen-, Fokus-, Diversitäts-, Count- und Registry-Prüfungen.
Auch ein fehlender oder falsch geformter Review-Block verwirft einen gültigen Interpretationspatch nicht. Seine Hypothesen werden dann nicht ungeprüft übernommen.
Ist die Interpretation gültig, aber ein Kandidat noch unklar, bleibt die Interpretation angenommen. Explizit geprüfte unabhängige Vorschläge werden in joint_retained des kanonischen Hypothesenkontexts festgehalten. Folgeaufrufe dürfen nur die anderen Positionen neu bearbeiten. Position/Anzahl und erhaltene Objekte sind durch Schema-const/prefixItems UND phasenseitige Gleichheitsprüfung gesperrt. Die volle Registry wird erst nach gültigem Gesamtergebnis veröffentlicht. Fehlt eine auswertbare Review, wird keine Unabhängigkeit unterstellt; dann bleibt der konservative Ersatzpfad nötig.
Persistenz und Grenzen
Original, Patch und Reviews bleiben getrennte echte Calls mit echten Usage-Werten. Es gibt keine künstlichen LLM-Runden oder doppelte Kostenbuchung. Die Interpretation wird deterministisch aus Original und zulässigen Patches rekonstruiert. Beim Wiederlesen werden Quellenhash, Requesthash, Identität, Phase, Konfiguration, erlaubte Pfade und Zusammensetzung geprüft. Die Kette ist begrenzt; direkte Selbstreferenzen und zu tiefe Ketten werden abgelehnt. Gespeicherte Reparaturcalls werden nach einem Abbruch wiederbenutzt.
Der bestehende Korrekturversuchszähler begrenzt weiterhin Modellversuche. Transport-Retries bleiben getrennt. Ein formaler Validierungserfolg beweist weiterhin nicht die Wahrheit jedes Freitextsatzes. Die Begrenzung dieser Unsicherheit ist ausdrücklich Teil der Policy.
Offline-Prüfung
Die Tests decken Quellen-Enums, fehlende Annahmenquellen, Voraussetzungscitations, gezielte Patches, direkte Abhängigkeiten, explizite Ersatzvorschläge, unklare Reviews, Sperren erhaltener Vorschläge, falsch geformte Modellfelder, Abbruch/Wiederaufnahme und Import in einen neuen Workspace ab. Ein Fall des unveränderten kuratierten Fehlerkorpus prüft die Lokalisierung der tatsächlich beobachteten Fehler. Kein bezahlter API-Test wurde ausgeführt; Kosten und semantische Qualität sind im nächsten Realtest zu messen.