VianoBugAnalysis/docs/investigation-working-context-study-20261016.md

Schlanker Investigation-Arbeitskontext: Offline-Studie

Gegenstand

Untersucht wurden alle 17 gespeicherten Investigation-Kontexte des neuesten erhaltenen Bug-17-Pakets (g148, historischer Prompt v11). Die bestehenden Promptbuilder wurden zum Rekonstruieren verwendet, ohne Provideraufruf. Caseinterpretation, Hypothesengenerierung, produktive Prompts, Controller und Paketverträge sind unverändert. Das Werkzeug ist eine Offline-Designstudie, kein bereits ausführbares neues Promptprotokoll.

Werkzeug: scripts/study_investigation_context.py <paket> --output <messung.json>. Messdaten: measurements/investigation-context-study-20261016.json. Stand: nach Commit 500ae27. Kostenbaseline unverändert 7,40 EUR; keine API-Nutzung.

Was die Investigation gegenwärtig tatsächlich bekommt

analysis/investigator.py::_context stellt eine vollständige Archivdarstellung zusammen. analysis/investigation_prompt.py::build_prompt erzeugt daraus eine kompaktere Modelldarstellung über full_history_view und block_view. Der produktive Nachfolger v12 ergänzt die kausale Bewertung, verwendet aber weiterhin dieselbe vollständige Historienstrategie.

Die Nachricht enthält:

1. Systeminstruktionen: Beweismaßstab, Confidence, nächste Aktion, Toolnutzung, Grenzen der Interpretation, Referenzkodierung und Verhalten beim Frühabschluss.
2. Statische Fallinformationen: aufbereitete Quellen, Identitäten, Interpretation, Tool-/Budgetregeln und Schemas. Diese liegen bei geeigneter Gemini-Konfiguration im stabilen Fallcache und müssen nicht erneut voll berechnet werden.
3. Veränderliche Arbeitsdaten: ausgewählte Hypothese, andere Hypothesen, Fragen und Notizhistorien, Budgetkonten, alle Rechercheergebnisse und deren Metadaten. Das vorherige Ergebnis ist bereits als Beleg referenziert.
4. Das Antwortschema. Die Antwort bewertet das vorige Ergebnis, aktualisiert die ausgewählte Hypothese und wählt genau eine nächste Aktion. Nicht jeder Dispatch ist ein einzelner API-Aufruf.

Es fehlt ein eigener, verlässlich gepflegter kurzer Erkenntnisstand. Alte assessment-Notizen sind vielfach Arbeitsprotokolle mit nächstem Suchschritt, keine kumulative Pro-/Contra-Zusammenfassung. Eine Confidence supported verwandelt solche Notizen nicht in belastbare Evidenz.

Zwei gemessene Varianten

Bytewerte messen exakt serialisierte UTF-8-Daten, keine Provider-Tokens. Der gleiche ursprüngliche Systemtext und das gleiche Schema bleiben für diesen Datenvergleich stehen. Vor einem Live-Einsatz müssten die Instruktionen an den neuen Vertrag angepasst werden, insbesondere Aussagen über vollständige Notizen.

Variante, 17 Kontexte	Nachrichteninhalt gesamt	Live-Transport	Veränderung Live
Bisherige v11-Darstellung	1.400.843 B	645.032 B	—
Verwaltungsdaten/Notizhistorie verkürzt, alle Recherchepayloads behalten	1.233.456 B	459.777 B	−28,72 %
Zusätzlich nur jüngstes Rechercheergebnis behalten, ausdrücklich unsicher	1.110.549 B	313.571 B	−51,39 %

Der stabile Präfix bleibt in allen Varianten inhaltlich gleich; seine summierte Transportdarstellung beträgt 987.326 B. Die Live-/Präfixmessung enthält andere Transporthüllen als die Nachrichteninhaltmessung; die Spalten nicht addieren.

Variante A: pragmatische Verringerung ohne Entfernen von Recherchepayloads

• Andere Hypothesen: kurze Vorschläge, Confidence und Disposition; keine Notizen, Fragen, Laufzähler oder internen Zustandszeiger.
• Ausgewählte Hypothese: Vorschlag bleibt, alle Fragen bleiben, Historiennotizen werden durch die letzte Arbeitsnotiz und gegebenenfalls den letzten expliziten kausalen Review ersetzt. Offene Fragen erscheinen zusätzlich im Arbeitsbrief. Das ist bewusst konservativ, noch nicht auf jedes doppelte Feld optimiert.
• Budget: ausgewähltes Konto; fremde Konten und globale Buchhaltung bleiben beim Controller. Dessen Scheduling wird nicht an das Modell verlagert.
• Evidenz: alle Beleg-IDs und Inhalte bleiben vollständig enthalten, auch aus anderen Hypothesen. Interne Record-/Contentpfade, Hashes, Format-/Paketfelder, bereits berechnete Novelty und interne Request-/Resultspeicherverweise werden aus der Modelldarstellung entfernt. Query-/Result-Inhalte, Abfrageumfang, Herkunft und gemeinsame Quell-/Metadatentabellen bleiben unverändert.
• Unbekannte Felder in erhaltenen Evidenz-Records bleiben erhalten.

Für den letzten Aufruf mit 15 Belegen sinkt der Live-Transport von 63.206 B auf 43.766 B. Der Vergleich prüft für jeden Beleg, dass sein Inhalt unverändert bleibt, und dass Quell-/Result-/Metadatentabellen unverändert bleiben.

Diese Variante ist nicht insgesamt verlustfrei: alte Modellnotizen und die Detailzustände anderer Hypothesen fehlen. Eine vergessene Zwischenfolgerung ist weiterhin möglich, solange es keinen gepflegten kumulativen Erkenntnisstand gibt. Die Offline-Messung belegt keine gleichbleibende Analysequalität.

Variante B: nur frisches Ergebnis ist kein tragfähiger Arbeitskontext

Im letzten Aufruf fehlen dann die Inhalte von E000001 bis E000014; nur E000015 bleibt vollständig. Diese älteren Belege enthalten gerade die entscheidenden Informationen zu Quest-ID, QuestAccept, Core-Dispatch und AI-Erzeugung. Alle gemeinsamen Tabellen bleiben im Größenexperiment konservativ vorhanden; das ist also keine maximal mögliche Verkleinerung. Trotzdem verliert die LLM den expliziten Zusammenhang der ausgelassenen Belege mit Abfrage und Ergebnis.

Diese Variante nicht aktivieren. Sie illustriert die Größenordnung, wiederholt aber ohne zuverlässiges Arbeitsgedächtnis das Problem der früheren Recall-Lösung. Die Größenmessung ist kein Grund, alte Gegenbelege aus der Untersuchung zu drängen.

Die vorgeschlagene Pro-/Contra-Darstellung

Die Idee des Nutzers ist sinnvoll. Die kurze Darstellung sollte einen versionsgebundenen Erkenntnisstand der Hypothese bilden. Sie ersetzt nicht die Existenz und Prüfbarbeit der Belege. Paketpfade braucht sie nicht; kurze interne Beleg-IDs sollte das Modell weiterhin bekommen, um Aussagen prüfen, zuordnen und zitieren zu können. Eine menschenlesbare Ansicht darf die IDs ausblenden. Modellschlüsse werden ausdrücklich nicht zu unabhängigen Fakten.

So könnte H1 als lesbares Beispiel aussehen (redaktionell erstellte Illustration, nicht automatisch aus Confidence berechnet und nicht an eine LLM geschickt):

Vermutung: Die Questannahme startet den Escort nicht, weil der passende Callback fehlt oder eine veraltete Quest-ID geprüft wird.

Anlass: Der Tester beobachtet nach der Annahme keinen Bewegungsbeginn. Das ist mit der Vermutung vereinbar, belegt aber diesen speziellen Defekt nicht.

Bisher dafür: Kein konkret nachgewiesener Callback-/ID-Defekt.

Bisher dagegen: Die gespeicherten Codebefunde zeigen eine Behandlung der Quest-ID 26050, einen QuestAccept-Override mit StartEvent-Aufruf, einen AI-Dispatch im Core und die passende AI-Erzeugung.

Unsicherheit: Statischer Sourcecode belegt noch keine tatsächliche Ausführung im betroffenen Deployment. Das ist eine Lücke, kein positiver Beleg für einen fehlenden Callback.

Nächste Entscheidung: Das neue Ergebnis zu den Dispatch-Bedingungen bewerten. Stützt es keinen Defekt des behaupteten Mechanismus, die Hypothese abschwächen oder verwerfen, statt sie still auf eine andere Ursache umzudeuten.

Das ist keine vorweggenommene endgültige Diagnose und keine generelle Anweisung, bei jedem künftigen Bug denselben Codepfad zu untersuchen. Die Inhalte sind fallspezifisch. Das Programm darf nicht bereits vorgeben, dass H1 falsch sein muss.

Der aktuelle v12-Review enthält bereits support, against, effect und reason. Er ist ein guter Anschluss, aber noch kein vollständiger strukturierter kumulativer Arbeitsbrief: Die IDs haben keine einzeln zugeordnete Kurzbegründung, und alte v11-Läufe haben diese Struktur gar nicht. Das Offline-Werkzeug markiert fehlende Pro-/Contra-Daten deshalb als not_recorded_in_this_legacy_run, statt sie zu erfinden oder alte Arbeitsnotizen als Beweis auszugeben.

Konkreter nächster Implementierungsentwurf

1. In der ohnehin erfolgenden Investigation-Antwort einen knappen kumulativen Arbeitsbrief aktualisieren: stützende Befunde, Gegenbefunde, Unsicherheiten, aktuell zu prüfende Frage. Je Befund kurze Begründung, Geltungsbereich und echte Beleg-IDs; keine weitere Zusammenfassungs-LLM.
2. Diesen Brief als versioniertes Artefakt an die Akte anhängen. Der Controller prüft Referenzen/Struktur, bewahrt Gegenbelege und verifiziert ausdrücklich entfernte/ersetzte Befunde strukturell. Semantische Wahrheit kann er damit nicht automatisch beweisen. Die finale Diagnose bleibt eine Gegenprüfung.
3. Zuerst Variante A mit diesem Arbeitsbrief produktionsreif machen. Das neue Ergebnis, sämtliche bisherigen Recherchepayloads und ihre Reichweite bleiben zunächst verfügbar. So prüfen wir Briefqualität und Verwaltungsreduktion, ohne zugleich Belege zu verbergen.
4. Erst anschließend gezielte Belegauswahl erwägen: frisch/unbewertet, im Brief referenziert, für die offene Frage relevant und Gegenbelege über Hypothesen- grenzen hinweg. Nicht nur nach Alter oder sammelnder Hypothese filtern. Für zusätzlich benötigte Belege braucht es eine zuverlässige lokale Wiederbereitstellung, getrennt von kostenpflichtigen Außenweltabfragen.
5. Das Modell entscheidet über den nächsten sinnvollen Suchschritt anhand von Frage und Befundlage. Ein kurzer Aufgabenrahmen sagt, welche Entscheidung zu treffen ist; er schreibt keine vermeintlich richtige Ursache oder konkrete Suche im Voraus fest. Erlaubte Tools/Parameter und vollständiges frisches Ergebnis bleiben Bestandteil des Vertrags.

Caseinterpretation und Hypothesengenerierung bleiben von diesem Entwurf ausdrücklich ausgenommen. Keine Änderung der Systemgrenzen oder der Architekturdatei.

Prüfung und Grenzen

• Offline-Neudarstellung aller 17 historischen Kontexte abgeschlossen.
• Assertions prüfen unveränderte Evidenzinhalte und gemeinsame Tabellen.
• Vier gezielte Tests: keine erfundene Pro-/Contra-Bilanz, Erhalt eines vorhandenen kausalen Reviews, Erhalt fremder Gegenbelege/Scope ohne Mutation des Originals, explizite Kennzeichnung fehlender Belege in der unsicheren Variante.
• Kein Tokenizer-/Provider-Benchmark, keine behauptete Euro-Ersparnis und kein bestandener Qualitätstest. Neue Instruktionen und ein Arbeitsbrief können zusätzliche Ausgabetokens benötigen; entscheidend ist der Gesamtaufwand.