4.1 KiB
Begrenzte Diagnose und ehrliche Unsicherheit
Neue Abschlussanfragen verwenden diagnosis_v8 beziehungsweise
diagnosis_early_v8; neue Übergaben change_request_v9.
Die Diagnose trennt in den vorhandenen Feldern beobachtete Ergebnisse von
kausalen Ableitungen. remaining_uncertainty enthält offene Annahmen,
decision_basis.scope_limits den tatsächlich untersuchten Geltungsbereich.
Ein Quellenverweis belegt nicht automatisch alle Aussagen über die Quelle.
Fehlende Fundstellen in einem Ausschnitt beweisen keine globale Nichtausführung;
eine vorhandene Methode beweist umgekehrt keinen tatsächlich erfolgten Aufruf.
Die Anleitung gilt projektunabhängig und enthält keine bekannten Buglösungen.
Ein plausibler, evidenzgestützter und begrenzter Änderungsversuch bleibt mit Restunsicherheit zulässig. Weder ein lückenloser Negativbeweis noch der Ausschluss aller alternativen Ausführungspfade wird gefordert. Die bestehenden Prüfungen für unbekannte Belege, fehlende Gegenprüfung und ausdrücklich ungelöste materielle Widersprüche bleiben erhalten. Es gibt keinen zusätzlichen LLM-Aufruf und keine neue pauschale Abschlusssperre. Das Programm erkennt nicht deterministisch alle inhaltlichen Widersprüche in Freitext; dies bleibt Aufgabe der Diagnose-LLM.
Die Auftragserstellung soll offene Annahmen nicht zu gesicherten Fakten erklären.
Ihre bestehenden validation_requirements sollen beobachtbare Ergebnisse nennen,
die die Erklärung nach einer Änderung stützen oder infrage stellen, und relevantes
unverändertes Verhalten berücksichtigen. Ein erfolgreicher Build allein bestätigt
keine Verhaltensursache. Die externe Pipeline implementiert und testet; BugAnalysis
wartet darauf nicht und erzwingt keine Rückgabe.
Verlustfreie Übergabe der Einschränkungen
Neue Übergabekontexte speichern uncertainty_handoff_version=1. Der Controller
kopiert remaining_uncertainty und decision_basis.scope_limits aus der akzeptierten
Diagnose unverändert nach change_request.json.diagnostic_caveats. Dieser Block
steht auch in der menschenlesbaren Coding-Zusammenfassung. Er wird nicht von der
Auftrags-LLM erzeugt und verändert weder Assignment noch Status oder Human-Auftrag.
Es werden keine zusätzlichen LLM-Ausgabefelder verlangt. Bestehende Dokumente ohne
den Kontextmarker bleiben bytegleich rekonstruierbar; abgeschlossene Artefakte
werden nicht nachträglich ergänzt. Die Replay-Prüfung vergleicht neue Dokumente
weiterhin vollständig mit ihrer deterministisch rekonstruierten Fassung.
Abgrenzung und Nachweis
Server-/Erfassungs-/Repository-Versionserfassung bleibt ein gesonderter Ausbau.
Die Investigation, deren Budgets, Zeichenlimits und der Lifecycle ändern sich nicht.
docs/architecture.md bleibt unverändert. Alle Prüfungen erfolgen lokal mit
Fixture-Adaptern; die tatsächliche Wirkung der Promptänderung muss ein späterer
LLM-Test zeigen. Die bereits abgeschlossene Bug17-Akte g228 bleibt unverändert
und besteht weiterhin die vollständige Ausgabevalidierung ohne Modellaufruf.
Die Abschlussphasen-Testvorbereitung verwendet jetzt die begrenzte Startbewertung mit einer Untersuchungsiteration pro Hypothese. Die frühere unbegrenzte Vorbereitung scheiterte bereits im unveränderten HEAD am 20.000-Zeichen-Limit, bevor eine finale Diagnose aufgerufen wurde. Das Produktionslimit wird für Tests nicht gelockert.
Validierung am 20.10.2026: 97 Tests im abschließenden Regressionslauf bestanden
(317,63 Sekunden), dazu der anschließend separat geprüfte zusätzliche Test gegen
modellseitiges Setzen des Controller-Blocks. Insgesamt 98 unterschiedliche lokale
Tests bestanden. Die acht gezielten Tests in tests/test_qualified_handoff.py
bestanden ebenfalls vollständig (sieben davon im Regressionslauf enthalten).
Geprüft wurden unveränderte Modell-Ausgabeverträge, normale und frühe Diagnose,
weiterhin zulässige Restunsicherheit, verlustfreie Übernahme ohne gemeinsame
mutierbare Listen, alte Kontexte ohne den neuen Block, ready/template/none,
Budgeterhaltung, Wiederaufnahme, Korrekturversuche und portable Ausgabevalidierung.
git diff --check ohne Befund. Keine kostenpflichtigen API-Aufrufe.