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

  • Zu Beginn war die Struktur so, dass JSONL, die mit Godot 3‑Code erstellt wurden, nur mit Godot 3‑Code geprüft wurden und JSONL, die mit Godot 4‑Code erstellt wurden, nur mit Godot 4‑Code geprüft wurden

    • In der Praxis muss jedoch überprü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 die Auswahl des Items, das Labeln, die Code‑Erstellung, die JSONL‑Erstellung, die Godot 3/4‑Kreuzvalidierung sowie die Ansicht von Roh‑Prompt/Response auf einem einzigen Bildschirm
    • Statt nur schnell und 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, welche Prompt‑Anfragen gesendet werden, in welcher Reihenfolge die JSONL‑Massen‑Erstellung/Validierung aufgerufen wird und wie die Validierungs‑ und Anfrage‑Prompts selbst aufgebaut sind

    • Die erwartete Antwort wird je nach Label und Slot‑Charakteristik festgelegt, sodass die „Ja“/„Nein“‑Kriterien nicht verwirrend sind
    • Da die Antwort sofort pro Slot angezeigt wird, lässt sich viel schneller erkennen, welche Code‑ und JSONL‑Kombinationen fehlschlagen
    • Auch wenn ein Fall wegen des Prompts fehlschlägt, 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