VianoBugAnalysis/docs/response-format-recovery.md

Begrenzte Formatrettung in der Hypothesenuntersuchung

Die versionierte Untersuchungspolicy response_recovery_version = 1 aktiviert zwei Mechanismen. Das schlanke Testprofil aktiviert diese Version ausdrücklich; der Standardwert 0 und alte gespeicherte Policies behalten das bisherige Verhalten. Andere Analysephasen werden nicht umgestellt. docs/architecture.md bleibt unverändert: Es wird weiterhin ausschließlich eine vollständig validierte Antwort atomar verarbeitet, niemals ein herausgelöster gültiger Rechercheauftrag neben ungültigen Zustandsänderungen.

Deterministische Normalisierung

Die Anfrage trägt den Schema-Marker x-viano-response-recovery: 1. Nur markierte Investigation-Aufrufe erhalten die folgenden Regeln:

• Ein einzelner äußerer Markdown-Codeblock ohne Sprachangabe oder mit json wird entfernt. Zusätzliche Prosa und beliebige JSON-Syntaxfehler werden nicht repariert. Doppelte Schlüssel bleiben ungültig.
• Ein einmal JSON-kodiertes Objekt wird streng dekodiert: als gesamte Antwort oder an bekannten Objektstellen wie next.arguments und einem Belegobjekt. Freie Texte werden nicht in fachliche Objekte umgedeutet.
• Primitive DB-Filter ["id","eq",1] oder ["column","id","operator","eq","value",1] werden bei eindeutig gültigem Spaltennamen und bekanntem Operator zu [{"column":"id","operator":"eq","value":1}] normalisiert. Die Werte bleiben unverändert; Tabellen, Spalten, Operatoren und Grenzen werden danach weiterhin durch den vollständigen Werkzeugvertrag geprüft.

Originaldarstellung, normalisierte Antwort und angewandte Regeln werden im append-only LLM-Aufruf gespeichert. Rohtexte befinden sich ausschließlich im Paket-Audit, nicht in Fehlerdiagnosen oder Logs. Erst nach vollständiger Schema-, Beleg-, Budget- und Toolprüfung wird eine Aktion ausgeführt. Ein kurzer Hinweis auf die Normalisierung wird im nächsten regulären Aufruf mitgegeben, ohne einen zusätzlichen Korrekturaufruf zu erzeugen.

Kleiner LLM-Reparaturaufruf

Verbleibende, ausdrücklich zugelassene Container-Typfehler können einen investigation_format_repair_v1-Aufruf erzeugen. Er enthält die bereits generierte Antwort, den Fehlerpfad, den betroffenen Schemaausschnitt und wenige Bindungsdaten (Hypothese, vorheriges Ergebnis und sichtbare E-IDs). Er enthält keine erneute Fallinterpretation, Codehistorie, Rohbelege oder allgemeinen Rechercheanweisungen.

Die LLM gibt ausschließlich replacement für genau diesen Strukturpfad zurück. Das Programm setzt die Antwort selbst zusammen. Alle skalaren Werte müssen samt Typ und Häufigkeit erhalten bleiben; vorhandene benannte skalare Zuordnungen dürfen nicht verschwinden. Bei erkennbaren Filtertripeln bleiben außerdem die Positionen von Spalte, Operator und Wert verbindlich; ein Tausch gleichartiger Strings zwischen Spalte und Wert wird abgelehnt. Außerhalb des Pfads bleibt die Antwort exakt gleich. Die vollständige rekonstruierte Antwort wird anschließend erneut gegen den ursprünglichen fachlichen Vertrag geprüft. Quelle, Hash, Patch und rekonstruierte Antwort bleiben über Checkpoints auch nach Paketwiederaufnahme nachvollziehbar.

Erfundene Belege, unbekannte Aktionen, Confidence-Änderungen und nicht eindeutig strukturbezogene Fehler werden damit nicht legitimiert. Ein bloßer Prosasatz anstelle eines Belegobjekts lässt sich beispielsweise nicht ohne erfundene ID-/Rollen-/Referenzangaben vervollständigen und erhält keine solche Reparatur. Ein Änderungsvorschlag mit anderen Abfragewerten wird abgelehnt. Bestehende Invalid-Response-Limits gelten auch für Reparaturversuche. Transportfehler behalten die vorhandenen Failover-/Retry-Regeln. Nicht unterstützte Fehler bleiben im bisherigen kontrollierten Ablehnungspfad.

Grenzen und Aktivierung

Die Formatrettung ist auf 65.536 UTF-8-Bytes Antwort-/Reparaturdaten sowie 16 Normalisierungen begrenzt. Das sind Sicherheitsgrenzen dieses versionierten Mechanismus, keine Grenzen des Case-Paketformats. Größere Antworten werden nicht für einen Reparaturaufruf dupliziert. Zu große oder nicht reparierbare Antworten werden nicht abgeschnitten oder teilweise ausgeführt.

Neue Untersuchungen müssen die Policy initialisieren. Eine laufende Untersuchung wird nicht still auf eine andere Policy umgestellt. Historische Kontexte ohne Marker, Audit oder Reparaturdescriptor ergeben unveränderte Prompts.

Lokale Tests decken Originalerhaltung, einmalige Ausführung, Hinweise ohne Extraaufruf, Wiederaufnahme und die Ablehnung geänderter Abfragewerte sowie unbekannter Aktionen/Belege ab. Ein gezielter Reparaturprompt bleibt im geprüften Fixture bei 2.199 statt 10.353 Zeichen des normalen Untersuchungsaufrufs. Das ist keine allgemeine Kosten- oder Qualitätsgarantie; bezahlte Tests erfolgen separat.

Zulassung und Ablehnungs-Audit nach dem ersten echten Lauf

Der erste echte Lauf normalisierte einen name/contains/Wolpertinger-Filter erfolgreich. Ein weiterer Filter enthielt dagegen ["LogTitle","like","%Wolpertinger%"]. Das ist nicht rein strukturell: like gehört nicht zum Werkzeugvertrag. Die damalige Reparatur zielte zusätzlich fälschlich auf den einzelnen String filters[0]. Ein vollständiges Objekt mit Spalte, Operator und Wert kann daraus nicht werterhaltend erzeugt werden.

Die Zulassung berücksichtigt jetzt die vollständige Filtereinheit und löst den zugehörigen Schemaausschnitt über die passende Aktions-/Query-Alternative auf. Ein Fehlerpfad innerhalb einer flachen Liste wird, soweit überhaupt reparierbar, auf deren vollständigen Filterbereich angehoben. Skalare Ziele, unvollständige Filter, fehlende Werte und unbekannte Operatoren erhalten keinen Format-Reparaturaufruf. Es wird weder SQL LIKE in contains übersetzt noch werden Prozentzeichen entfernt. Stattdessen bekommt der normale Ablehnungspfad einen kurzen, ausdrücklichen Operator-Vertragshinweis. Eine neue fachliche Entscheidung bleibt Sache der LLM.

Vor der Zulassung wird mit den bereits vorhandenen Filterwerten eine rein strukturelle Prüffassung gebildet. Sie muss die gesamte ursprüngliche Ausgabestruktur erfüllen und die Erhaltungsregeln einhalten. Weitere unveränderte Strukturfehler verhindern so ebenfalls einen aussichtslosen Reparaturaufruf. Diese Prüffassung wird nicht ausgeführt; eine tatsächliche Modellreparatur muss später nochmals alle Kontrollen einschließlich fachlicher Beleg- und Budgetprüfung bestehen. Alte gespeicherte Reparaturpläne werden vor einem erneuten Anbieteraufruf ebenfalls auf ungeeignete Zieltypen und Operatoren geprüft, ohne ihre historischen Prompts umzuschreiben.

Abgelehnte Reparaturantworten stehen separat in outcome.rejected_repair, mit Version, Ablehnungsgrund und SHA-256 über die kanonische JSON-Darstellung des gespeicherten Inhalts. Ein geparster Vorschlag wird als patch, kaputtes JSON als original_text gespeichert. Die Grenze liegt bei höchstens 65.536 UTF-8-Bytes und zusätzlich innerhalb des konfigurierten Response-Limits. Größere Vorschläge werden nicht gekürzt oder teilweise übernommen. HTTP-Fehlerkörper und Header werden dadurch nicht aufbewahrt. Logs und bereinigte Diagnosen enthalten weiterhin keinen Antworttext. Das Aufrufprotokoll erlaubt die zusätzlichen sicheren JSON-Parserdiagnosen, damit deren Speicherung selbst nicht mit INPUT_SCHEMA scheitert.