5.3 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.
Nativer verschachtelter Vertrag v22
Neue Untersuchungen verwenden bei aktiviertem Bootstrap-Framing standardmäßig
bootstrap_framing_version = 2, gespeichert in der Untersuchungspolicy. Der daraus
gebildete Kontext trägt denselben Versionsmarker; der Aufruf heißt
investigation_bootstrap_v22. Die Konfiguration im schlanken Testprofil setzt
diese Version ausdrücklich.
Für Gemini im Modus json_object erhält responseJsonSchema jetzt auch die
verschachtelten Typen und Pflichtfelder von assessment und update, insbesondere
working_brief.findings.items. Jedes Belegelement muss ein Objekt mit id,
direction, text, scope und evidence_refs sein. Referenzen müssen als Liste
von Strings vorliegen. Auch retired und next_step behalten ihre Struktur.
Die Projektion wird aus dem lokalen Ausgabeschema erzeugt; sie enthält keine
zusätzliche fachliche Zusammenfassung und verändert das Schema nicht.
Der native Vertrag ist bewusst eine Strukturprüfung, ohne die komplexen
Werkzeugalternativen von next. Wertebereiche, ID-Muster, zulässige Aktionen,
Provenienz und fachliche Belegprüfung bleiben Aufgaben der vollständigen lokalen
Validierung. Das vollständige Schema bleibt im Cachepräfix enthalten. Explizites
Caching, Cache-Messung und sichere Fehlerdiagnosen unterstützen v22.
Version 1 und alte Policies ohne Versionsfeld behalten v21 und dessen äußeren Vertrag. Gespeicherte Kontexte werden nicht migriert. Eine explizite abweichende Policy wird abgelehnt. Für den nächsten Test muss daher ein Checkpoint vor der Initialisierung der Untersuchung oder ein neues Eingabepaket verwendet werden; der zuvor vorbereitete H3-Checkpoint würde weiterhin v21 nutzen.
Lokale Transporttests prüfen den tatsächlich gesendeten Vertrag, nicht nur den Prompt: String-, Array-, Null-, Zahlen- und Bool-Einträge als Belege werden abgelehnt; ausgefüllte Objektbelege sind zulässig. Weitere Prüfungen decken verschachtelte Feldtypen, Cache-Erzeugung/-Wiederverwendung sowie Paketwiederaufnahme mit beiden Versionen ab. Ob der Anbieter den neuen Vertrag im echten API-Aufruf akzeptiert und zuverlässig befolgt, muss weiterhin im Nutzer-Test geprüft werden.