VianoBugAnalysis/docs/investigation-working-brief-v1.md

Investigation: versionierter Arbeitsstand und schlankere Verwaltungsdaten

Neue projektgestützte Investigation-Kontexte verwenden investigation_project_v13. Caseinterpretation und Hypothesengenerierung ändern sich nicht. Alle Recherchepayloads, auch ältere und fremder Hypothesen, bleiben vollständig vorhanden. Es gibt keine neue Recall-Schleife und keinen zusätzlichen LLM-Aufruf zum Zusammenfassen.

Arbeitsstand

Die ohnehin stattfindende Investigation-Antwort liefert zusätzlich update.working_brief:

{
  "format_version": 1,
  "findings": [
    {
      "id": "B0001",
      "direction": "against",
      "text": "Der vermutete fehlende Callback ist implementiert.",
      "scope": "Untersuchter Source-Commit; Ausführung im Deployment nicht belegt.",
      "evidence_refs": ["E000001"]
    }
  ],
  "uncertainties": ["Stimmt die ausgelieferte Version mit dem Source-Stand überein?"],
  "next_question": "Wie verhält sich der belegte Dispatch im betroffenen Stand?",
  "changes": []
}

Das Beispiel beschreibt das Format, keine vorgegebene Bugursache. Der Arbeitsstand ist eine Modellbewertung, keine unabhängige Beobachtung. Befunde sind ausdrücklich als support, against oder neutral markiert und tragen Reichweite und echte Beleg-IDs. Kompatible Symptome sind nicht schon Belege für einen konkreten Defekt. Das Modell wählt den nächsten Prüfschritt selbst anhand dieses Erkenntnisstands.

Der Controller prüft vor Budgetabrechnung/Toolausführung:

• Schema und Größen: maximal 16 Befunde, je 300 Zeichen Text/200 Zeichen Scope, je maximal 8 Beleg-IDs; maximal 6 Unsicherheiten mit je 240 Zeichen und eine nächste Prüffrage mit maximal 300 Zeichen. Die kurze Aktionsnotiz ist auf 400 Zeichen begrenzt.
• Eindeutige Befund-IDs innerhalb der jeweiligen Hypothese und bekannte Belege. Alle aktuellen Befundbelege müssen auch in update.evidence_refs stehen.
• Stabile IDs für unveränderte Befunde. Jede Änderung oder Entfernung eines bisherigen Befunds braucht genau einen changes-Eintrag mit Begründung und bestehenden Belegen. Keine erfundenen Änderungen unbekannter Befunde.
• Die Vereinigungsmengen der Pro-/Contra-Belege stimmen exakt mit causal_review.support und .against überein. Die bestehende kausale Confidence-Kalibrierung gilt unverändert.

Das prüft die Struktur und nachvollziehbare Änderung, nicht die semantische Wahrheit einer Modellbehauptung. Das Modell kann Befunde mit expliziter Begründung korrigieren oder zusammenführen. Vollständige Rohbelege und alte Bewertungen bleiben erhalten; die unabhängige finale Diagnose bleibt zuständig.

Persistenz und Wiederaufnahme

Jede erfolgreich ausgeführte Entscheidung erzeugt ein neues Artefakt: analysis/investigation/NNNN/briefs/Hx-NNNN.json. Es enthält Identität, Hypothese, Sequenz, Elternreferenz, LLM-Call-Referenz und Arbeitsstand. Der Hypothesenzustand hält Referenz und SHA-256. Beides wird mit dem Investigation-Checkpoint atomar veröffentlicht. Ein unterbrochener bereits validierter Schritt verwendet dieselbe gespeicherte Antwort erneut; er benötigt keinen zweiten Modellaufruf. Die Artefakte bleiben bei Pakettransport verfügbar.

Die Fallrekonstruktion erkennt ausschließlich checkpointgebundene Arbeitsstände als generierte Analyseartefakte. Sonst würden neue Brief-Dateien fälschlich den ursprünglichen Inputfingerabdruck ändern. Unbekannte Dateien werden weiterhin berücksichtigt und unverändert erhalten. Dies ändert keine fachliche Caseinterpretation oder Hypothesengenerierung.

Alte gespeicherte Kontexte/Antworten behalten ihre bisherigen Promptverträge. Ein neu beginnender Schritt nutzt v13. Solange eine Hypothese noch keinen Arbeitsstand hat, bleiben ihre bisherigen eigenen Notizen im Prompt, damit der erste Arbeitsstand aus allen Belegen rekonstruiert werden kann. Erst danach ersetzt er diese Notizhistorie. Er wird nicht aus Confidence-Werten erfunden.

Modelldarstellung und Cache

• Ausgewählte Hypothese: Vorschlag, Confidence, Fragen/Status, Arbeitsstand.
• Andere Hypothesen: kurzer Vorschlag, Confidence und Disposition.
• Budget: nur das ausgewählte Konto, einschließlich offener Aktionen; globale Konten und Scheduling verwaltet der Controller.
• Evidenz: sämtliche Inhalte und IDs; interne Speicherpfade/Hashes, Paket-/Recordformatfelder, Novelty-Werte und Requestspeicherverweise entfallen. Abfragen, Ergebnisabdeckung, Snapshot-/Quellprovenienz und gemeinsame Tabellen bleiben erhalten. Die kanonische Akte bleibt vollständig.
• Bestehender stabiler Fallcache bleibt aktiv. Der Arbeitsstand ist veränderlich und liegt im Live-Teil. Neue Befunde ändern den statischen Fallpräfix nicht.
• Die Untersuchungshistorie ist weiter im Paket vorhanden, nur ihre wiederholte Modelldarstellung wird reduziert. Es findet keine Paketbereinigung statt.

Offline-Messung

Alle 17 erhaltenen historischen v11-Kontexte wurden mit dem tatsächlichen neuen v13-Prompt/Schema als Migrationsfall neu dargestellt. Ohne erfundene Arbeitszusammenfassungen und mit vollständig beibehaltener eigener Alt-Notizhistorie sinkt der summierte Live-Transport von 645.032 auf 485.572 UTF-8-Bytes (24,72 %). Hinweise auf doppelte Evidenz (duplicate_of) bleiben erhalten, damit sie nicht als unabhängige Bestätigung gezählt wird. Daten: measurements/investigation-v13-migration-20261016.json. Reproduktion: python scripts/study_investigation_context.py <paket> --production-v13 --output <messung.json> (offline).

Der statische Präfix wächst durch neue Instruktionen und Schema; dieses Wachstum ist in der Messdatei enthalten. Die neue Antwort benötigt ebenfalls Tokens für den Arbeitsstand. Die Offline-Zahlen sind deshalb kein Versprechen von 24,72 % weniger Gesamttokens oder Kosten. Wie gut und knapp der kumulative Arbeitsstand im Live-Betrieb funktioniert, muss der nächste vom Nutzer gestartete Test zeigen.