Files
VianoBugAnalysis/docs/bootstrap-schema-diagnostics.md
T

3.2 KiB

Schemafehler bei Bootstrap v21

Der Gateway validiert weiterhin gegen das vollständige lokale Ausgabeschema. Bootstrap v21 war jedoch nicht für die detaillierte, bereinigte Schemafehlerdiagnostik freigeschaltet. Deshalb enthielten fehlgeschlagene Aufrufe teilweise nur validation_keyword: type, ohne die betroffene Stelle.

Jetzt werden auch für diesen Prompt validation_path, bekannte validation_fields und das konkrete Validierungskeyword erfasst. Bei verschachtelten Aktionsalternativen wird die zum vorhandenen Diskriminator passende Schemaalternative verwendet. Unbekannte Feldnamen werden maskiert; Antwortwerte und rohe Fehlermeldungen werden nicht in die Diagnose übernommen. Die bekannten Werkzeugfelder profile und entity_refs sind für sichere Feldpfade freigegeben.

Der Controller speichert diese Diagnose append-only mit dem fehlgeschlagenen Aufruf. Für Bootstrap-Aufrufe bekommen Typ- und Enumfehler einen gezielten Korrekturhinweis am gemeldeten Pfad. Das Schema wird nicht gelockert und die Antwort nicht automatisch umgeschrieben. Ein technischer Fehlversuch löst keinen Rechercheauftrag aus. Die vorhandene Begrenzung ungültiger Antworten bleibt wirksam.

Lokale Tests prüfen Typfehler, fehlende Pflichtfelder, zusätzliche Felder, Datenschutz und den Weg vom Gateway über das Paket bis zur Wiederaufnahme und erfolgreichen Korrektur mit einem simulierten Anbieter. Es werden keine kostenpflichtigen Anfragen ausgeführt. Historisch nicht gespeicherte Fehlerpfade lassen sich damit nicht nachträglich rekonstruieren.

Präzisierung nach dem Source-/Schema-Test

Der folgende echte Test zeigte dreimal denselben Typfehler an /update/working_brief/findings/0. Die zuvor erfolgreichen Bootstrap-Antworten enthielten leere Beleglisten. Ein Erfolg dieser Antworten prüfte daher nicht die Struktur ausgefüllter Belegobjekte. Der Transport prüft weiterhin nur die äußere Form nativ; das vollständige lokale Schema bleibt maßgeblich.

Typfehler enthalten jetzt zusätzlich expected_types und actual_type, ausschließlich aus den sieben JSON-Schematypen. Boolesche Werte werden nicht als Integer gemeldet. Es werden weder Antwortwerte noch Python-Klassennamen übertragen. Diese Angaben bleiben im Fehlerprotokoll und im wiederaufnehmbaren Korrekturkontext erhalten.

Bei einem fehlerhaften Belegelement mit erwartetem Typ object erhält nur der Korrekturaufruf ein kurzes englisches Objektbeispiel mit den benötigten Feldern. Die Beispielwerte sind ausdrücklich illustrativ: IDs, Text und Geltungsbereich müssen aus den tatsächlich sichtbaren Belegen stammen. Komprimierte Datensätze, Tupel und Zeichenketten sind keine zulässigen Belegobjekte; bestehende Erkenntnisse dürfen nicht zum Umgehen der Prüfung gelöscht werden. Der Controller konvertiert keine Modellantwort automatisch und startet keine zusätzliche Recherche.

Unveränderte Erstaufrufe und historische Korrekturkontexte ohne diese neuen Typangaben erhalten keinen zusätzlichen Prompttext. Frühere Prompts bleiben so reproduzierbar. Die lokal simulierte Paketwiederaufnahme prüft denselben Fehlerpfad wie der echte Lauf und anschließend einen korrigierten Aufruf. Dies ersetzt keinen Erfolgsnachweis mit dem echten Modell.