Study focused investigation working context offline

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

@@ -0,0 +1,179 @@
+# 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.