88 lines
5.3 KiB
Markdown
88 lines
5.3 KiB
Markdown
# 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.
|