Propósito do documento

Qwen Validation Debugger é uma ferramenta que testa todo o fluxo com dados sintéticos antes que o Retriever de produção e o validador estejam concluídos.

Um teste será criado para um tema, contendo código para Godot 3 e código para Godot 4, e serão gerados arquivos JSONL que correspondem e que não correspondem ao código. Em seguida, o mesmo JSONL será inserido em cada versão do código para verificar se a decisão final resulta em “sim” ou “não” corretamente.

O esquema de resposta e os tipos de julgamento permanecem inalterados.

Escopo da gramática: common, separate
Tabela JSONL: docs_chunks, api_mapping, label_prototypes
Slots: positive, negative
Decisão final: sim, não

Não foram criados campos de valor de julgamento terceiro, pontuação ou motivo adicional.

Fluxo geral

TEST_ITEM
  -> classificação comum / separada
  -> salvar resultados da classificação
  -> gerar código da versão alvo
  -> verificar parser real do motor Godot
  -> verificar código sim/não do Qwen
  -> gerar JSONL apenas com códigos aprovados
  -> verificar JSON Schema existente
  -> verificar evidência direta com o código atual
  -> validação cruzada entre JSONL e código

O item separate cria primeiro o código do Godot 3. O código do Godot 4 recebe esse código do Godot 3 como REFERENCE_GODOT3_CODE e gera um código correspondente que mantém a mesma funcionalidade e fluxo de execução.

Separação de classificação e entrada de geração de código

A resposta de classificação mantém os cinco campos existentes.

{
  "syntax_scope": "common 또는 separate",
  "label": "짧은 한국어 라벨",
  "reason": "분류 근거",
  "godot3_focus": "Godot 3 코드 생성 포인트",
  "godot4_focus": "Godot 4 코드 생성 포인트"
}

reason, godot3_focus, godot4_focus são mantidos na exibição da tela e no registro, mas não são passados para o prompt de geração de código. Isso impede que, mesmo que a fase de classificação explique uma sintaxe de versão incorreta, essa frase sirva como base factual para a próxima geração de código.

A geração de código usa apenas as seguintes entradas:

Itens de teste
common ou separate
Versão alvo da geração
Código Godot 3 que passou primeiro ao gerar separate Godot 4
Código rejeitado imediatamente anterior e diagnóstico de verificação ao tentar novamente

Contrato de Código Composto

O código gerado deve ser um único arquivo GDScript que o motor possa analisar, não uma string que pareça um fragmento de código.

A primeira linha de execução deve ser a declaração extends.
Use a classe que realmente possui a API de teste.
Funções comuns não devem ser aninhadas dentro de outras funções.
Use a API de ação real do item de teste.
Não simule a ação alvo com pass, comentários ou chamadas locais.
Não misture sintaxe exclusiva de versões opostas em comentários ou código.
O código Godot 4 deve manter as funcionalidades, entradas, alvos e resultados do código Godot 3 que passou primeiro.

Para itens cuja sintaxe varia claramente entre versões, como RPC, forneça o contrato de sintaxe oficial no prompt. Isso não é uma lógica de substituição posterior das palavras geradas. Não modifique arbitrariamente a string de código gerada; insira-a diretamente no analisador do motor.

Verificação Real do Motor Godot

O Qwen conseguiu fazer com que seu próprio código fosse aprovado mesmo contendo sintaxe errada. Nos testes reais, houve casos em que o código Godot 3 continha @rpc de Godot 4 e o verificador Qwen ainda respondeu “sim”.

Atualmente, o motor real é executado imediatamente após a geração do código.

Godot 3: --no-window --check-only --script  
Godot 4: --headless --check-only --script  
common: Verificação em ambos Godot 3 e Godot 4

Os arquivos executáveis podem ser especificados como GODOT3_BIN e GODOT4_BIN. A instalação padrão local deve ser colocada no diretório de dados do usuário fora do repositório. O código a ser verificado deve ser criado apenas em arquivos temporários e removido após a verificação. Nos logs de diagnóstico, os caminhos temporários e o caminho da pasta home do usuário são removidos.

A geração e a verificação de código são realizadas no máximo três vezes. Se falhar, altere a seed para que a mesma resposta não seja repetida e inclua o código anterior e o diagnóstico real do motor no próximo prompt de geração.

Manter o esquema JSONL

Os campos de nível superior permanecem os mesmos das três definições de tabela existentes.

docs_chunks

chunk_id, doc_version, source_url, source_file, source_sha256,
doc_type, symbol, section_path, heading, content, code_blocks,
language_tags, godot_version_tags, api_symbols, token_count, metadata

api_mapping

mapping_id, source_api, target_api, change_type, godot_from,
godot_to, confidence, evidence_chunk_ids, match_terms, notes,
negative_patterns

label_prototypes

prototype_id, label, task_type, input_pattern, expected_finding,
recommended_action, evidence_mapping_ids, evidence_chunk_ids,
severity, validator_rules

validator_rules também usa apenas os quatro campos existentes.

{
  "required_when_seen_in_code": [],
  "before_code": "",
  "after_code": "",
  "reject_when_seen_in_code": []
}

Após receber a resposta, verifique o JSON Schema existente quanto a campos obrigatórios, tipo, enum e se há campos adicionais. Se o modelo usar confidence como número ou section_path como string, rejeite e gere novamente até três vezes.

geração de positive e negative

O JSONL positivo usa evidências diretas do código sintetizado atual.

docs_chunks: descreve diretamente o objetivo, o alvo, o fluxo de entrada e o resultado do código.
api_mapping: o source_api do Godot 3 e o target_api do Godot 4 devem estar presentes no código correspondente.
label_prototypes: a evidência before deve estar no código do Godot 3, e a evidência after no código do Godot 4.
Em negative_patterns e reject_when_seen_in_code do positivo, use arrays vazios.

Para gerar JSONL negativo, não forneça o código atual nem o item atual. Selecione dinamicamente um item de amostra após o item atual como NEGATIVE_TEST_ITEM e crie o JSONL usando apenas esse outro item. Após a geração, o servidor compara diretamente com o código atual; se houver sobreposição de evidência source/before, rejeita.

Esse processo não faz substituição palavra‑por‑palavra de nomes de API ou frases. Usa apenas a escolha da ordem de amostra e a comparação de strings dos resultados reais.

ordem de validação

A validação segue esta sequência:

Se o resultado ficar determinado pela estrutura de slots de versão, julgue não sem chamar o modelo.
Se, antes da migração, não houver nenhuma evidência direta no código atual, julgue não.
Só se as duas condições acima não forem satisfeitas, o Qwen compara significado e modo de uso.

O gate determinístico não cria novo estado. O valor de retorno continua sendo sim ou não, como antes.

JSONL	alvo da validação	resposta esperada
`docs_chunks` positive da mesma versão	código de geração	sim
`docs_chunks` positive de versão diferente	código cruzado	não
`docs_chunks` negative	qualquer código	não
migração `3 -> 4` positive	código Godot 3	sim
migração `3 -> 4` positive	código Godot 4	não
migração `3 -> 4` negative	qualquer código	não

robustez das requisições de API

Desative a saída de thinking.
Solicite respostas JSON Schema contendo apenas os campos existentes para classificação, código e JSONL.
O julgamento final aceita apenas sim ou não via grammar.
Alterne a seed ao recriar código e JSONL.
Em caso de HTTP 429, 502, 503, 504, desconexão ou timeout, tente novamente até três vezes.

A chave de API é incluída na requisição apenas a partir do valor atualmente digitado na memória do navegador. Não a registre em repositórios, documentos, logs ou commits.

resultados do teste em 15 de julho de 2026

27 testes de contrato unitário foram aprovados.

Na inspeção real do motor Godot, observou‑se:

O código remote func do Godot 3 passou pelo parser do Godot 3.
Inserir @rpc em código Godot 3 foi rejeitado com “Unexpected '@'”.
O código @rpc do Godot 4 passou pelo parser do Godot 4.

Resultados da execução do teste Qwen no RunPod:

E2E inicial: 5/12 aprovados. Detectou‑se código sintetizado de Godot 3 incorreto e julgamentos de alta correlação inadequados.
Após aplicar inspeção de motor e contrato de geração: 10/12 aprovados.
Após aplicar itens negativos dinâmicos e gate de string direta: 4/4 aprovados para negative de migração.
Os 2 casos restantes foram positivos de migração que o modelo tentou aplicar ao Godot 4, ignorando a cláusula de slot. Essa condição foi movida para um gate de versão determinístico e os testes unitários passaram.
Um novo teste completo foi iniciado, mas o serviço RunPod retornou HTTP 502 nas rotas /v1/models e nas requisições de geração, interrompendo o processo. Não foi rejeição de código ou JSONL, mas falta de resposta do serviço remoto.

Quando o serviço remoto voltar a responder, será necessário reexecutar os 12 casos E2E do início.