7.6 KiB
Untersuchung verworfener Antworten – 2026-10-19
Offline-Untersuchung von BUG20 joint-planning (Generation 97) und shared-recovery
(Generation 100). Originale und Programmcode unverändert; keine API-Anfragen,
keine Recherchetools/SQL ausgeführt, keine Kandidaten in einen Case übernommen.
index.json enthält Call-Referenzen und Hashes; die Call-Dateien enthalten Usage zur Nachvollziehbarkeit.
1. Gemeinsame Interpretation: zwei beanstandete Stellen
observed_behavior/2
Aussage: Reproduktion bestätige, dass Wolpertinger am Testort in Dun Morogh nicht
spawnen. Quellen: F0001 und O0003. F0001 ist ein strukturierter Reproduktionsfakt
result = reproduced, O0003 die Beobachtung „Wolpertinger spawnen tatsächlich nicht“.
Die Quelle F0001 ist in dieser Ausgabekategorie nicht zugelassen. Die Aussage hat
jedoch bereits eine passende Beobachtungsquelle. Das ist wesentlich näher an einer
redundanten, falsch einsortierten Quellenangabe als an erfundener Beobachtung.
Ein Fact-Kind allein rechtfertigt weder das Verwerfen der Aussage noch das automatische
Entfernen der Quelle: Aussage, Provenienz und verbleibende Belege müssen erhalten bleiben.
Die Ortsangabe muss im Gesamtkontext bewertet werden; O0003 nennt allein keinen Ort.
tester_assumptions/0
Die Antwort schreibt dem Tester die Annahme zu, die Brille sei die alleinige Sichtbarkeitsvoraussetzung. O0002 sagt lediglich, dass trotz getragener notwendiger Brille keine Wolpertinger erscheinen und der Horde-Fall funktioniere. Eine explizite Behauptung „alleinige Voraussetzung“ steht dort nicht. Das ist eine semantische Überinterpretation, nicht nur eine falsch etikettierte Quellen-ID. Die Kategorie ist zusätzlich formal nur für tester_assumption/tester_comment zugelassen, nicht observation. Diese Passage darf nicht durch bloßes Umetikettieren zu einer Beobachtung werden.
Offline-Gegenprobe
Nur im Arbeitsspeicher F0001 aus observed_behavior/2 entfernt und den unbelegten Testerannahmen-Eintrag entfernt: Die bestehende vollständige Interpretationsvalidierung besteht danach. Dies ist eine menschlich gewählte Gegenprobe, keine automatisch bewiesene Reparaturregel oder semantische Vollfreigabe der Antwort.
Die drei ursprünglichen Hypothesen verweisen ausschließlich auf unveränderte Stellen: H1 observed_behavior/1; H2 zusätzlich confirmed_technical_facts/7; H3 zusätzlich confirmed_technical_facts/6. Keine deklarierten Verweise betreffen die beiden beanstandeten Stellen. Nach der Gegenprobe lassen sich alle Pointer erneut auflösen und alle drei Vorschläge bestehen die vorhandene Hypothesenvalidierung. Das rechtfertigt die Prüfung einer abhängigkeitssensitiven Wiederverwertung statt pauschaler Neugenerierung. Deklarierte Referenzen beweisen aber nicht, dass jede implizite inhaltliche Abhängigkeit ausgeschlossen ist.
Weitere qualitative Schwächen trotz formal gültiger Gegenprobe
- Eine Untersuchungsrichtung bezeichnet 32907 als Netz und 32906 als gefangenes Item, obwohl die Entity-Einträge selbst ihre Namen/Funktion ausdrücklich als ungeprüft ausweisen. Die zitierten Questfelder belegen die numerischen Relationen, nicht diese Namens-/Funktionszuordnung. Das ist eine interne Inkonsistenz.
- H2 nennt für unit_flags 512 eine symbolische Bedeutung, die im bereitgestellten Case-Kontext nicht belegt ist. Sie vermischt Nicht-Auswählbarkeit und Unsichtbarkeit. Der allgemeine Sichtbarkeitsverdacht ist sinnvoll; die technische Zuordnung ist so keine bestätigte Grundlage. Ein Item-Erzeugungsspell ist zudem kein Nachweis einer bereits verifizierten Detektionsaura.
- H3 formuliert die vermutete Quest-/Phasenabhängigkeit stellenweise zu sehr als gegebenen Mechanismus. Als ausdrücklich zu prüfende Alternative ist sie zulässig.
Die bestehenden Validatoren prüfen Struktur, Quellenklassen und Referenzen, können aber nicht die Wahrheit oder vollständige Ableitbarkeit jedes Freitextsatzes beweisen.
2. Syntaxfehler der Auftragsproduktion im gemeinsamen Lauf
Eine Human-Dev-Objektklammer endet nach expected_results mit ] statt }.
Eine einzige Ersetzung dieser schließenden Klammer macht die gesamte Antwort
parsebar. Danach besteht sie unverändert die bestehende vollständige
Change-Request-Validierung einschließlich des archivierten Kontexts.
Das ist der klarste Kandidat für eine lokale, durch String-/Containerzustand
abgesicherte Klammerkorrektur. Aktuell wird eine falsche schließende Klammer
noch nicht vom allgemeinen Normalisierer ersetzt.
3. Zwei beschädigte Hypothesenantworten im vorigen Lauf
Erster Versuch endet nach dem dritten vollständigen Vorschlag mit }缸.
Probeweise ausschließlich das terminale Fremdzeichen durch ]} ersetzt:
parsebar, und vollständige bestehende Hypothesenvalidierung bestanden.
Der Inhalt der drei Vorschläge bleibt bei dieser Gegenprobe unverändert.
Aktuell ist das bewusst ausgeschlossen: Es müssten fehlende Endklammern ergänzt
werden, was auch eine abgeschnittene Antwort verdecken könnte. STOP/complete,
vollständige Vorschläge, Stackzustand und genau eine zulässige Reparatur wären
notwendige Zulassungskriterien; keine freie Ergänzung beliebiger Fragmente.
Zweiter Versuch endet mit } syndromes]}. Probeweise nur das unquotierte Wort
zwischen vollständigem Vorschlag und vorhandenen Endklammern entfernt:
parsebar, vollständige bestehende Hypothesenvalidierung bestanden.
Alle Strings, Werte, Vorschläge und vorhandenen Klammern bleiben dabei erhalten.
Dies spricht für eine eng begrenzte Prüfung von Fremdtext außerhalb von Strings
an Containergrenzen. Es rechtfertigt kein pauschales Entfernen unbekannter Wörter
oder ein Übernehmen beliebig aus Text herausgeschnittener JSON-Teilobjekte.
4. Ungültiger Untersuchungsauftrag im vorigen Lauf
Filter: ["!#flatten", "name", "contains", "Glodrak"]. Das Tool erwartet Filterobjekte mit column/operator/value. Für diese Liste samt Marker ist kein Eingabeformat definiert. Ein Mensch kann eine Namenssuche vermuten; die vorhandene Software hat aber keinen Vertrag, der diese Interpretation garantiert. Nicht stillschweigend ausführen. Zusätzlich erklärt dieselbe Antwort statische Horde-Spawns zu einem Gegenbeweis gegen dynamisches Spawning allgemein. Das folgt daraus nicht. Es ist somit kein rein kosmetischer Fehler, bei dem alle Zustandsänderungen ungeprüft erhalten bleiben sollten. Ein gezielter Korrekturauftrag müsste die Filterstruktur und die gekoppelte Evidenz-/Confidence-Bewertung berücksichtigen.
Bewertung und Reihenfolge
- Beim gemeinsamen Modus bleiben: Quellenkategorien eindeutig rahmen, falsche Annahmenzuschreibungen gezielt korrigieren und unveränderte Hypothesen nach erklärter Abhängigkeitsprüfung erneut validieren. Änderungen an Quellen nicht allein anhand des ID-Präfixes vornehmen. Typ/Provenienz kommt aus dem Kontext.
- Den eindeutigeren Klammerfehler lokal abfangen, mit Protokoll der exakten Änderung, unveränderten Literalen, begrenzter Kandidatenzahl und voller anschließender Prüfung.
- Terminale Fremdtokens/fehlende Abschlussklammern getrennt behandeln. Diese sind engere, ausdrücklich zu spezifizierende Ausnahmen zur bisherigen Sicherheitsregel.
- Den Filterlistenfall nicht mit einer pauschalen Formatheuristik retten.
Kein automatischer Reparaturalgorithmus wurde in dieser Untersuchung implementiert. Eine formal gerettete Antwort ist noch kein Nachweis einwandfreier Analysequalität. Wirtschaftlich relevant sind die vermiedenen Folgeaufrufe: Die ursprüngliche Antwort wurde bereits bezahlt; ihre Offline-Reparatur macht diese Tokens nicht rückwirkend kostenlos.