idea_world_labDEV JOURNAL
Dienstag, 30. Juni 2026

30. Juni 2026

  • Da es Weltmeisterschaftssaison ist und ich wegen des Anschauens der WM nicht richtig schlafen konnte, habe ich nicht viel arbeiten können

  • Die Markdown → JSONL‑Umwandlung von localhost:8501 ist derzeit bis etwa 655 Einträge fortgeschritten

  • Heute habe ich mich darauf konzentriert, ein einfaches Validierungs‑Test‑Debug‑Tool zu erstellen und zu verfeinern, anstatt große Sammlungen/Lernvorgänge durchzuführen

  • Ich habe die Strategie für das Validierungs‑Test‑Debug‑Tool festgelegt und das separate Web‑Tool Qwen Validation Debugger implementiert

    • Der Ausführungspfad ist tools/qwen-validation-debugger
    • Der lokale Ausführungsbefehl lautet npm run validation-debug:debug
    • Die Standardadresse ist http://127.0.0.1:8520/

  • Am 28. Juni habe ich mit dem Qwen‑Chatbot Godot‑Code‑Chunks und JSONL selbst erstellt und die „Ja/Nein“-Validierung manuell durchgeführt

    • Dieses Verfahren hat die Machbarkeit gezeigt, aber je mehr Einträge hinzukamen, desto mehr Kopieren/Einfügen und Ergebnisvergleiche wurden nötig
    • Insbesondere mussten die drei Tabellen docs_chunks, api_mapping und label_prototypes vollständig getestet werden; bei gemeinsamer Syntax sind 6 Slots nötig, bei Versionsunterscheidung 12 Slots, was die manuelle Verwaltung stark verkompliziert

  • Das Tool lädt als Beispiel 50 Godot‑Testeinträge, und für jeden Eintrag lässt es Qwen zuerst kennzeichnen, ob es sich um gemeinsame Syntax oder um eine Trennung zwischen Godot 3/4 handelt

    • Bei gemeinsamer Syntax wird ein gemeinsamer Code erzeugt
    • Bei Versionsunterschieden werden jeweils ein Godot 3‑Code und ein Godot 4‑Code erzeugt
    • Anschließend werden die JSONL‑Slots pro Tabelle automatisch zusammengestellt

  • Ich habe erneut bestätigt, dass man docs_chunks, api_mapping und label_prototypes nicht einfach zu einem einzigen „Ja/Nein“ zusammenfassen kann

    • docs_chunks dient als Beleg für Code‑Erklärungen, daher ist „Ja“ korrekt, wenn der Code exakt übereinstimmt
    • api_mapping und label_prototypes sind Belege für Migrations‑Quellen; häufig ist „Nein“ richtig, wenn bereits Code für Godot 4 oder gemeinsame Syntax angewendet wurde
    • Deshalb wurden die Slot‑Bezeichnungen in Erklärungs‑Beleg, Irrelevante‑Erklärung, Umwandlung‑erforderlich, Bereits‑angewendet, Gemeinsam/Unnötig, Irrelevante‑Umwandlung unterteilt

  • Der größte Unterschied, den ich beim Erstellen des Tools festgestellt habe, ist die Trennung von JSONL‑Erzeugungs‑Basiscode und Validierungs‑Zielcode

  • Anfangs war die Struktur so, dass JSONL, die mit Godot 3‑Code erstellt wurden, nur mit Godot 3‑Code validiert wurden und JSONL, die mit Godot 4‑Code erstellt wurden, nur mit Godot 4‑Code validiert wurden

    • In der Praxis muss jedoch geprüft werden, ob bei Anbringung von Godot 3‑JSONL an Godot 4‑Code ebenfalls „Nein“ ausgegeben wird
    • Deshalb wurden für jeden Slot separate Schaltflächen „Godot 3‑Code‑Validierung“ und „Godot 4‑Code‑Validierung“ eingeführt und die Ergebnisse jeweils gespeichert

  • Nachdem das Tool erstellt wurde, hat sich die Entwicklungseffizienz deutlich verändert

    • Früher musste man Qwen jedes Mal den Code und das JSONL anfordern, das Ergebnis wieder in den Prompt einfügen, validieren und die erwartete Antwort im Kopf vergleichen
    • Jetzt erfolgen Auswahl des Elements, Labeling, Code‑Generierung, JSONL‑Erstellung, Godot 3/4‑Kreuzvalidierung sowie die Ansicht von Roh‑Prompt/Response auf einem einzigen Bildschirm
    • Statt einfach nur schnell viel zu produzieren, ist es jetzt am wichtigsten, dass man nicht mehr verwirrt ist, nach welchen Kriterien etwas erzeugt und in welchem Code es validiert wurde
    • Beim Wiederholen von 50 Test‑Items reduziert sich der zu merkende Zustand für den Menschen, sodass Fehlermuster schneller erkannt werden können

  • Mit diesem Tool kann man direkt auf dem Bildschirm sehen, welchen Prompt man sendet, in welcher Reihenfolge die Batch‑Erstellung/Validierung von JSONL aufgerufen wird und wie Validierungs‑ und Anforderungs‑Prompts zusammengesetzt sind

    • Die erwartete Antwort ist je nach Labeling und Slot‑Charakteristik festgelegt, sodass die „Ja“/„Nein“‑Kriterien nicht verwirrend sind
    • Da das Ergebnis sofort pro Slot angezeigt wird, lässt sich schnell erkennen, welche Code‑ und JSONL‑Kombination fehlschlug
    • Auch wenn ein Fehler durch den Prompt verursacht wurde, bleibt der verwendete Prompt auf dem Bildschirm, sodass nachträgliche Anpassungen leicht möglich sind

  • Da das Tool nun weitgehend fertig ist, plane ich, das Tempo etwas zu drosseln und statt die Menge zu erhöhen, die Validierungskriterien schrittweise zu verfeinern

  • Dokumentation: Qwen Validation Debugger Strategie und Implementierungsprotokoll

  • Rückblick: docs/retrospectives/2026-06-30.md