100 lines
6.3 KiB
Markdown
100 lines
6.3 KiB
Markdown
# 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.
|