Reject impossible format repairs and retain rejected proposals

docs/response-format-recovery.md

@@ -77,3 +77,41 @@ 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.