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.