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.