5.7 KiB
Fokussierter Untersuchungsschritt v17
Neue Projekt-Untersuchungskontexte verwenden investigation_project_v17. Die Änderung betrifft nur die Hypothesenuntersuchung. Gespeicherte v16- und ältere Anfragen behalten ihre bisherige Darstellung; Architektur, Caseinterpretation, Hypothesengenerierung und finale Diagnose bleiben unverändert.
Ein konkreter nächster Entscheidungsauftrag
Der reguläre Prompt trägt die Aufgabe advance_selected_question. investigation_step.question kommt aus dem letzten Modell-Arbeitsstand, ersatzweise aus der ersten ungelösten Frage, zuletzt aus dem ausgewählten Mechanismus. Die Quelle wird angegeben. Eine exakt bereits als gelöst markierte Frage wird nicht aus einem veralteten Arbeitsstand wieder als Leitfrage übernommen. Die Reihenfolge ist deterministisch, keine zusätzliche semantische Auswahl durch eine zweite LLM.
Der Auftrag verlangt: Bedeutung des aktuellen Resultats für diese Frage bewerten, Grenzen/Unsicherheit behalten, Befunde fortschreiben und genau eine unterscheidende nächste Aktion oder begründeten Abschluss wählen. Keine wiederholte Neuerzeugung des gesamten Falls oder eines breiten Untersuchungsplans. Materiale Gegenbelege dürfen und sollen die Richtung ändern. Alle bisherigen Aktionen bleiben verfügbar; der Leitfrage wird keine höhere Autorität als neuer Evidenz gegeben.
Mechanische Vorprüfung
preflight bezieht sich über previous_id und capture_index auf die bereits gespeicherte rohe Antwort; Zeilen, Filter und Herkunft werden nicht nochmals kopiert. returned_records zählt zurückgegebene Ergebnisobjekte, nicht automatisch passende Datenbankzeilen. Insbesondere bedeutet eine Count-Antwort mit matched_rows=0 ein Ergebnisobjekt und null Treffer, nicht eine leere Antwort.
- Vollständige DB-Zeilenabfragen: nur bei expliziter complete_filtered_rows-Abdeckung, truncated=false, Offset 0 und ohne Folgeseite complete_for_exact_query.
- Vollständige lexikalische Suchen: zusätzlich explizit keine übersprungenen Dateien und complete_selected_text_search. Das beweist keine semantischen Beziehungen oder Ausführung.
- Schema und Anzahl: schema_only bzw. count_only; keine erfundene Vollständigkeit von Welt-/Laufzeitdaten.
- Fehlende, widersprüchliche oder unbekannte Metadaten, Ausschnitte und spätere Seiten: partial_or_unknown. Null zurückgegebene Objekte beweisen dort keine Abwesenheit.
schema_captures verweist auf bereits erfasste Schemas, auch anderer Hypothesen. Vor einer erneuten Beschaffung sollen vorhandene Spaltenkataloge oder lokales Recall genutzt werden. same_query_and_origin_ids kennzeichnet beim aktuellen Resultat exakte frühere Abfragen mit exakt gleicher Herkunft. Andere Filter, Projektionen, Offsets, Snapshots oder JSON-Skalartypen werden nicht gleichgesetzt; unbekannte Herkunft wird nicht als Gleichheit ausgegeben. Diese Hinweise ersetzen keine fachliche Beweiswürdigung und erlauben keine Zitate ungelesener Belege. Sie sperren keine gerechtfertigte neue Abfrage.
Kanonischer Kontext, Originalresultate, Gegenbefunde, offene Fragen und Budgetabrechnung bleiben erhalten. Die Vorprüfung führt keine Queries aus und ändert weder Confidence noch Rewards. Es gibt keinen automatischen Schluss von fehlenden statischen Zeilen auf fehlende dynamische Pfade.
Frühabschluss und Cache
Die enge Frühabschluss-Bewertung verwendet unverändert investigation_review_v16.txt und denselben JSON-Auftrag. Die neue reguläre Aufgabenrahmung wird dort nicht angehängt. Der separat konfigurierte niedrige Denkmodus gilt weiterhin; normale Schritte behalten den bisherigen Denkmodus. Cache und Replay unterstützen die neue Version. Veränderliche Leitfrage/Vorprüfung liegen außerhalb des stabilen Fallpräfixes.
Kostenbewertung
Diese Maßnahme reduziert die zu lösende Denkaufgabe, nicht unmittelbar die Eingabezeichen. Die zusätzlichen mechanischen Hinweise kosten etwas Input. Offline-Größen derselben gespeicherten Bug20-Kontexte stehen in investigation-v17-framing-20261018.json. Sie sind keine Messung tatsächlicher Tokens oder eingesparter Denkarbeit. Der nächste Live-Test muss Denktokens, Aufrufzahl, Laufzeit und Lösungsqualität gemeinsam prüfen. Keine zusätzlichen LLM-Zusammenfassungen, kein niedrigeres allgemeines Denkniveau, keine kostenpflichtigen Testaufrufe während der Implementierung.
Präzise Korrekturhinweise für Werkzeugargumente
Verschachtelte oneOf-/anyOf-Fehler werden anhand der vorhandenen kind- und operation-Diskriminatoren bis zur passenden Variante verfolgt, einschließlich enum-basierter Queryarten. Dafür werden die bereits gegen das vollständige Schema aufgelösten Unterfehler verwendet; isoliertes erneutes Validieren einer Variante verliert sonst Root-Definitionen und Pfadinformationen.
Beispiel: Eine source.search-Anfrage ohne path_prefix erhält validation_path=/next/arguments, validation_fields=[path_prefix] und den Hinweis, dass path_prefix="" eine Suche ab Repository-Wurzel bezeichnet. Andere fehlende Pflichtfelder, etwa value in einem DB-Filter, werden entsprechend an ihrer tatsächlichen Position genannt. Typfehler werden von fehlenden Feldern unterschieden. Unbekannte oder mehrdeutige Diskriminatoren bleiben ein allgemeiner Formfehler, statt Felder einer geratenen Variante zu verlangen.
Es werden weiterhin nur erlaubte Feldnamen, Fehlerkategorien und begrenzte Schema-Pfade ausgegeben, keine Anfragewerte oder Rohantworten. Die Hinweise gelangen über den normalen Checkpoint in den nächsten Korrekturprompt. Keine automatische Ergänzung von Werkzeugargumenten, kein höheres Wiederholungslimit, keine zusätzliche LLM-Abfrage. Die beiden abgelehnten Antworten des ersten v17-Bug20-Laufs wurden lokal erneut geprüft; beide benennen nun das fehlende path_prefix korrekt.