Lista de Verificação de Correspondência de Evidências JSONL para Código Qwen Godot
Data de criação: 28 de junho de 2026
Objetivo
Gerar 50 trechos de código do Godot 3 com Qwen e verificar, da mesma forma que o teste de correspondência de evidências JSONL realizado ontem, se as avaliações “sim”/“não” são atribuídas corretamente.
Este teste não tem o objetivo de avaliar se o modelo conhece o Godot. Ele verifica, ao inserir SOURCE_CODE e JSONL juntos, se há evidências reais — strings, APIs ou padrões — dentro do JSONL que correspondam diretamente a um trecho de código.
Em outras palavras, JSONL relevantes devem ser marcados como sim e JSONL irrelevantes devem ser descartados como não.
Metodologia de Teste
Para cada trecho de código, anexe pelo menos dois tipos de JSONL e execute o teste. Como pode haver sintaxe comum entre Godot 3 e Godot 4, nem todas as funcionalidades serão tratadas como exclusivas do Godot 3.
| Tipo de JSONL | Resposta esperada | Significado |
|---|---|---|
| JSONL correto | sim |
Pelo menos um dos campos source_api, source_pattern, match_terms, required_when_seen_in_code ou before_code no JSONL corresponde exatamente ao trecho de código |
| JSONL incorreto | não |
O JSONL contém evidências que compartilham apenas APIs diferentes, nós diferentes, sistemas diferentes ou termos genéricos demais |
JSONL
Qwen direct-evidence validator prompt
SOURCE_CODE chunkA solicitação de verificação real é feita verificando se o Qwen retorna apenas sim ou não quando JSONL + prompt + chunk são enviados juntos.
Para sintaxe comum, o teste é baseado em um único chunk de código. Nesse caso, o JSONL correto contém descrições ou padrões relativos ao código/função, enquanto o JSONL incorreto contém descrições de funções ou sistemas totalmente diferentes. Os casos em que a resposta esperada é sim e os casos em que é não não diferem pelo código, mas sim se há ou não evidência direta dentro do JSONL.
Loop de Geração Repetida
O objetivo geral é testar todas as 50 funcionalidades. No entanto, hoje verificaremos manualmente apenas até 5, e depois reduziremos analisando primeiro os padrões de respostas sim/não nos resultados acumulados.
Meta de hoje: 5
Meta total: 50/50Depois de preencher 5, não aumente forçadamente o número de novos itens e primeiro observe os padrões de false positive e false negative por sintaxe comum, diferença de versão e por tabela.
Os testes criam os dados repetindo o fluxo abaixo.
1. Dê ao Qwen uma funcionalidade do Godot para testar.
2. Primeiro indique se a funcionalidade é sintaxe comum ao Godot 3/4, sintaxe específica do Godot 3 ou sintaxe específica do Godot 4.
3. Se for sintaxe comum, crie um único bloco de código.
4. Se for sintaxe comum, crie um JSONL de resposta correta para esse código/função e um JSONL de resposta incorreta para uma função totalmente diferente.
5. Se não for sintaxe comum, crie JSONLs separados para Godot 4 e para Godot 3 e teste-os.
6. Todos os JSONLs devem ser criados de acordo com as colunas da tabela de destino.
7. Insira o JSONL + bloco `SOURCE_CODE` no prompt de validação e verifique “sim”/“não”.
8. Registre se a resposta esperada coincide com a resposta real.O essencial não é a qualidade da geração de código, mas verificar se a correspondência de evidência JSONL é estável. Portanto, o JSONL correto deve resultar em sim, e o JSONL incorreto deve resultar em não.
Avisos de Sintaxe Comum
Sintaxes que permanecem iguais entre Godot 3 e Godot 4 não devem ser tratadas como teste de classificação de versão. Por exemplo, pode haver código usado em ambos os lados, como _ready(), _process(delta), atribuição de variáveis padrão, print().
Nesses casos, considere o seguinte.
| Tipo de Código | Forma de Teste | Expectativa |
|---|---|---|
| Sintaxe comum Godot 3/4 | Testar com um único chunk de código tanto para o JSONL da função quanto para um JSONL de função totalmente diferente | Apenas com base na presença direta de evidência no JSONL, deve-se decidir sim/não |
| Sintaxe específica Godot 3 | Usar o chunk de Godot 3 como referência para comparar JSONL exclusivo de Godot 3 com JSONL exclusivo de Godot 4 | Se a string/padrão real do Godot 3 estiver no JSONL, retorna sim |
| Sintaxe específica Godot 4 | Usar o chunk de Godot 4 como referência para comparar JSONL exclusivo de Godot 4 com JSONL exclusivo de Godot 3 | Se a string/padrão real do Godot 4 estiver no JSONL, retorna sim |
| Descrição de funcionalidade independente de versão | O código, seja qual for a versão, deve ter evidência direta nos conteúdos/códigos‑blocos do JSONL | Se houver apenas similaridade geral, retorna não |
Portanto, a planilha deve sempre registrar se a sintaxe é comum. Isso permite, ao revisar os resultados, distinguir se uma sintaxe comum foi julgada forçadamente como evidência de migração ou se uma sintaxe com diferença de versão foi tratada como comum.
Memorando de Redefinição de Critérios
Ao testar os itens 4 e 5, ficou evidente que é difícil emitir um julgamento definitivo. Especialmente, dependendo se o JSONL foi criado com base no Godot 3 ou no Godot 4, a resposta para o mesmo chunk de código varia, e essa variação tornou‑se objeto de análise de padrão.
Assim, por enquanto, não se decide se está “bom” ou “ruim”; registra‑se primeiro a resposta bruta, como segue.
| Categoria | Critério de Criação do JSONL | Código de Verificação | Fluxo Atual Esperado |
|---|---|---|---|
| Sintaxe comum | Baseado no Godot 3 | Código comum ou código Godot 3/4 com o mesmo significado | sim, não, sim, não, sim, não |
| Sintaxe comum | Baseado no Godot 4 | Código comum ou código Godot 3/4 com o mesmo significado | sim, não, sim, não, sim, não |
| Diferença de versão | Baseado no Godot 3 | Código Godot 3 | sim, não, sim, não, sim, não |
| Diferença de versão | Baseado no Godot 3 | Código Godot 4 | Na maioria não. Contudo, se o api_mapping ou prototype indicar explicitamente a conversão Godot 3 → 4, alguns sim podem aparecer, portanto a resposta bruta deve ser analisada separadamente |
| Diferença de versão | Baseado no Godot 4 | Código Godot 3 | Na maioria não. Contudo, se o JSONL contiver simultaneamente strings de source/target, alguns sim podem aparecer, então a resposta bruta deve ser analisada separadamente |
| Diferença de versão | Baseado no Godot 4 | Código Godot 4 | sim, não, sim, não, sim, não |
A ordem das respostas costuma ser: docs_chunks relacionado, docs_chunks não relacionado, api_mapping relacionado, api_mapping não relacionado, label_prototypes relacionado, label_prototypes não relacionado.
O item 4 também foi registrado como nas seções anteriores, mas como o teste em Godot 3 produziu um fluxo como não, não, sim, não, sim, não, ele foi excluído do julgamento definitivo. Este documento passa a servir como registro de observação que foca em “quais respostas flutuam sob quais critérios”, em vez de “quantas acertaram”.
Exemplo de Solicitação de Geração
A seguir, um exemplo de solicitação ao testar a primeira funcionalidade, a inicialização da função _ready() e a configuração do tamanho da viewport.
O formato JSONL e o propósito de cada JSONL foram detalhados em documento separado.
Por favor, forneça um chunk do Godot 3 e um chunk do Godot 4 que correspondam à inicialização da função `_ready()` e à configuração do tamanho da viewport.
Além disso, indique primeiro se esse recurso é sintaxe comum ao Godot 3 e Godot 4.
Se for sintaxe comum, indique que pode usar o mesmo código para teste.
E forneça um JSONL de resposta correta de acordo com o formato `docs_chunks` e um JSONL que não seja a resposta correta.Este exemplo é baseado em docs_chunks. Também para api_mapping e label_prototypes, crie JSONL de resposta correta e JSONL de resposta incorreta de acordo com cada formato JSONL e uso, e verifique sim/não com o mesmo prompt de validação.
A entrada de validação fica assim abaixo.
JSONL:
<linha JSONL de resposta correta ou incorreta>
PROMPT:
<prompt validador de evidência direta>
SOURCE_CODE:
<trecho de código Godot 3, trecho de código Godot 4, ou trecho de código de sintaxe comum>O prompt é enviado como se estivesse avaliando a justificativa direta ou a base de conversão entre SOURCE_CODE e JSONL, como abaixo.
Você é um avaliador de correspondência de evidências JSONL.
Determine se o JSONL abaixo contém evidências diretas de explicação ou transformação para o SOURCE_CODE abaixo.
Critérios de avaliação:
- É “sim” somente se algum dos esquemas JSONL corresponder exatamente a uma string real ou chamada de API dentro do SOURCE_CODE.
- Apenas ter palavras amplas como Godot, Godot3, Godot4, migração, 2D, física não é relevante.
- Se o JSONL tratar de outra API, outro nó ou outro sistema, a resposta é “não”.
- Não use seu conhecimento sobre Godot; use apenas as evidências textuais presentes no JSONL.
- A resposta deve ser exatamente “sim” ou “não”.Matriz de Julgamento
| Resposta esperada | Resposta real | Interpretação temporária | O que registrar |
|---|---|---|---|
sim |
sim |
corresponde à expectativa | reconhece o JSONL correto como evidência direta |
não |
não |
corresponde à expectativa | descarta o JSONL incorreto |
sim |
não |
necessidade de revisão | há evidência direta, mas foi omitido. candidato a falso negativo |
não |
sim |
necessidade de revisão | reconheceu sem evidência direta. candidato a falso positivo |
sim ou não |
outra resposta | necessidade de revisão | violação do formato de resposta. inclui explicação, JSON, resposta vazia, resposta ambígua |
Lista de Verificação de Observação
Após concluir 50 amostras de teste por tabela, verifique os itens a seguir.
| Verificação | Critério | Resultado |
|---|---|---|
| Formato da resposta | Todas as respostas exibem apenas sim ou não |
|
| Resposta JSONL relevante | Nos testes de JSONL relevantes, respostas sim aparecem de forma suficientemente estável |
|
| Resposta JSONL irrelevante | Nos testes de JSONL irrelevantes, respostas não aparecem de forma suficientemente estável |
|
| Registro de falsos positivos | Casos em que o correto é não mas foi retornado sim são registrados separadamente |
|
| Registro de falsos negativos | Casos em que o correto é sim mas foi retornado não são registrados separadamente |
|
| Filtro de termos amplos | Termos amplos como Godot, migration, 2D, physics não geram sim sozinhos |
|
| Evidência de string direta | Julgamentos sim contêm campo JSONL que corresponde ao código/string/API real |
|
| Distinção de sintaxe comum | Amostras de sintaxe comum a Godot 3/4 foram testadas com JSONL esperado sim/não baseado no mesmo trecho de código |
|
| Diferenças por tabela | As discrepâncias em docs_chunks, api_mapping, label_prototypes são registradas mostrando como variam |
|
| Reprodutibilidade | Repetir a mesma entrada não altera significativamente o julgamento | |
| Próxima decisão | Decide se este prompt e método de julgamento podem ser encaminhados para a próxima PoC |
Formato de Registro de Teste
Copie a tabela abaixo e preencha os resultados dos testes.
| ID | Função | Sintaxe comum? | Tabela | Tipo de JSONL | Resposta esperada | Resposta real | Julgamento | Campo correspondido diretamente | Observação |
|---|---|---|---|---|---|---|---|---|---|
| G03-001-A | Função _ready() inicializa e define o tamanho da viewport |
JSONL correto | sim |
||||||
| G03-001-B | Função _ready() inicializa e define o tamanho da viewport |
JSONL incorreto | não |
Registro por Tabela
docs_chunks
Verifique se a evidência descritiva da documentação oficial corresponde diretamente ao trecho de código.
| Nº | Função | Sintaxe comum? | Resultado JSONL relacionado | Resultado JSONL não relacionado | Observação |
|---|---|---|---|---|---|
| 1 | Inicialização da função _ready() e definição do tamanho da viewport |
Sintaxe comum | Observado JSONL relacionado sim |
Observado JSONL não relacionado não |
A documentação em docs_chunks que contém Node._ready, get_viewport().get_visible_rect().size, DisplayServer.window_set_size fundamenta a resposta sim; a explicação JSONL de _process(delta) foi classificada como não |
| 2 | Loop de atualização por quadro _process(delta) |
Sintaxe comum | Observado JSONL relacionado sim |
Observado JSONL não relacionado não |
A documentação em docs_chunks que contém _process(delta), position.x +=, speed * delta fundamenta a resposta sim; a explicação JSONL de Vector2.lerp foi classificada como não |
| 3 | Processamento da entrada de movimento do jogador (WASD ou setas) | Sintaxe comum | Observado JSONL relacionado sim |
Observado JSONL não relacionado não |
A documentação em docs_chunks que contém Input.is_action_pressed, Vector2.ZERO, direction.normalized(), velocity, move_and_slide() fundamenta a resposta sim; a explicação JSONL de TileMapLayer.set_cell() foi classificada como não |
| 4 | Aplicação de velocidade e aceleração ao jogador | Diferença de versão | Registros bilaterais anteriores sim foram excluídos da decisão final |
Fluxo de inspeção no Godot 3 mostrou não/não nos documentos, exigindo reavaliação |
Necessidade de redefinir critérios devido a respostas brutas não, não, sim, não, sim, não |
| 5 | Limite de velocidade máxima do jogador | Diferença de versão | Observação inicial no Godot 3. No Godot 4, respostas brutas inversas: código Godot 4 sim/sim, código Godot 3 sim/sim |
No Godot 4, todas as candidatas de documentação foram marcadas como sim |
CharacterBody2D, max_speed, velocity = input_vector * max_speed, move_and_slide(), Input.is_action_pressed aparecem literalmente; pode ser preciso restringir o escopo da funcionalidade mediante análise de padrões |
| 6 | Criação e disparo de projétil ao clicar com o mouse | Diferença de versão | As justificativas do Godot 3/4 coincidem com o código, incluídas no fluxo completo 24/24 |
Outras explicações JSONL foram descartadas conforme esperado | Diferenças entre PackedScene.instance() e instantiate(), bem como o tratamento de entrada do mouse, dividem as candidatas de documentação |
| 7 | Gerenciamento de movimento e tempo de vida (TTL) do projétil | Diferença de versão | Verificado se a justificativa em docs_chunks corresponde ao código de movimento/TTL do projétil |
Candidatas de documentação não relacionadas foram descartadas conforme esperado | Inconsistências surgem em 22/24 quando a base de mapeamento API/ rótulos de Godot 3 foi marcada como sim também para código Godot 4 |
| 8 | Lógica de IA de rastreamento do jogador pelo inimigo (Enemy) | Diferença de versão | Observado falso‑positivo: a justificativa de documentação do Godot 4 foi marcada como sim também para código Godot 3 |
Outros casos onde a documentação foi marcada como sim tanto para Godot 3 quanto para Godot 4 requerem nova revisão |
Total 21/24; docs_chunks tem tendência a ampliar a justificativa para tópicos de rastreamento/movimento e APIs semelhantes |
| 9 | Lógica de velocidade e rotação do inimigo | Diferença de versão | As justificativas de documentação para velocidade e rotação correspondem ao código conforme esperado | Candidatas não relacionadas foram descartadas conforme esperado | 24/24 aprovados. O propósito e o comportamento final são claros, permitindo distinção estável das candidatas de documentação |
| 10 | Desaparecimento do jogador ao sair da tela | Sintaxe comum | Justificativas de documentação sobre saída da tela, global_position, get_viewport_rect().size, hide() foram consolidadas como sim |
Outras candidatas de código foram consolidadas como não |
Sintaxe comum 6/6 aprovada. As justificativas de documentação e as candidatas de migração ficaram bem separadas |
| 11 | Detecção de colisão (Area2D ou PhysicsBody) | Diferença de versão | Comparação entre eventos de colisão, alvos de detecção e callbacks/relacionamento com corpos físicos nas candidatas de documentação e os trechos de código | Diferenciação de candidatas que tratam cálculo de dano ou vida após a colisão | No sample-11 verifica‑se que a justificativa de “detecção” não se mistura com a de “processamento” posterior |
| 12 | Cálculo e aplicação de dano ao colidir | Sintaxe comum | Comparação entre a justificativa de documentação que calcula o valor de dano e o aplica à vida do alvo, com o trecho de código | Diferenciação de candidatas que apenas detectam colisão, atualizam pontuação ou encerram o jogo | O sample-12 verifica se a essência da justificativa está na fórmula/aplicação de dano, não apenas na detecção |
| 13 | Lógica de redução de vida do jogador | Sintaxe comum | Comparação entre a justificativa de documentação que diminui a variável de vida do jogador, trata o hit e impõe limite inferior, com o trecho de código | Diferenciação de candidatas que diminuem vida do inimigo ou aumentam pontuação | No sample-13 é necessário distinguir se a string health se refere ao jogador ou ao inimigo |
| 14 | Quando a vida do jogador chega a 0, tratamento de Game Over | Sintaxe comum | Comparação entre a justificativa de documentação que verifica health <= 0, troca o estado para Game Over, muda/pausa a cena, e o trecho de código |
Diferenciação de candidatas que apenas diminuem vida ou removem inimigos | O sample-14 verifica se a justificativa corresponde ao estado resultante após a vida chegar a zero |
| 15 | Lógica de redução de vida do inimigo | Sintaxe comum | Comparação entre a justificativa de documentação que diminui a variável de vida do inimigo e trata o hit, com o trecho de código | Diferenciação de candidatas que diminuem vida do jogador ou acionam Game Over | No sample-15 o ponto crítico é identificar se o objeto alvo é enemy ou player |
| 16 | Quando a vida do inimigo chega a 0, remoção e adição de pontuação | Sintaxe comum | Comparação entre a justificativa de documentação que remove o inimigo (queue_free()/desativação) e aumenta a pontuação, com o trecho de código |
Diferenciação de candidatas que apenas diminuem vida ou apenas exibem pontuação | O sample-16 verifica se a justificativa cobre a ação combinada de remoção + incremento de score |
| 17 | Atualização da variável de pontuação (Score) | Sintaxe comum | Comparação entre a justificativa de documentação que incrementa/decrementa a variável de pontuação e atualiza o valor acumulado, com o trecho de código | Diferenciação de candidatas que apenas atualizam o label UI | O sample-17 separa a atualização do dado da atualização da exibição |
| 18 | Função de atualização do texto da pontuação (Label) | Sintaxe comum | Comparação entre a justificativa de documentação que usa Label.text/formatação de string para refletir a pontuação na tela, com o trecho de código |
Diferenciação de candidatas que apenas alteram a variável de pontuação | O sample-18 verifica se a justificativa está ligada à renderização UI e não apenas ao valor interno |
| 19 | Reprodução de música de fundo (BGM) e controle de volume | Sintaxe comum | Comparação entre a justificativa de documentação que trata nó de BGM, bus de volume, loop e ajuste de volume, com o trecho de código | Diferenciação de candidatas que tratam apenas efeitos sonoros pontuais | O sample-19 separa BGM contínuo de chamadas de SFX curtas |
| 20 | Função de reprodução de efeitos sonoros (SFX) | Sintaxe comum | Comparação entre a justificativa de documentação que cria/chama o player de áudio para SFX e reproduz uma única vez, com o trecho de código | Diferenciação de candidatas que tratam loop/volume de BGM | O sample-20 garante que palavras genéricas de áudio não associem indevidamente a justificativa ao BGM |
| 21 | Implementação do efeito de vibração da tela (Screen Shake) | Diferença de versão | Compare o trecho de código com a explicação sobre offset da câmera, intensidade/tempo da vibração, e uso de Tween ou offset aleatório | Diferencie de movimentação de inimigos, rastreamento da câmera, animações de UI | Verifique se sample-21 descreve diretamente o resultado da vibração da tela, mesmo que a palavra “câmera” apareça |
| 22 | Criação do sistema de partículas e correspondência de posição | Diferença de versão | Compare o trecho de código com a explicação sobre criação do nó de partícula, sincronização de posição e início da emissão | Diferencie de criação de nós genéricos, projéteis, animações | Verifique se sample-22 indica que o alvo da criação é uma partícula e se inclui fluxo de correspondência de posição e emissão |
| 23 | Função de mudança de cena (Scene Change) | Diferença de versão | Compare o trecho de código com a explicação sobre solicitação de troca de cena, chamada ao SceneTree e caminho da cena alvo | Diferencie de exibição de menu, pausa, carregamento de recursos que não envolvem troca de cena | Verifique se sample-23 realmente chama a troca de tela/cena, ou se trata apenas de carregamento ou exibição de UI |
| 24 | Carregamento e exibição da cena do menu principal | Diferença de versão | Compare o trecho de código com a explicação sobre carregar a cena do menu principal e mostrá‑la na tela | Diferencie de simples troca de cena, pausa ou pré‑carregamento de recursos | Verifique se sample-24 descreve o fluxo que realmente exibe a cena do menu, ou se trata de outra explicação de manipulação de cena |
| 25 | Alternância da funcionalidade de pausa (Pause) | Sintaxe comum | Compare o trecho de código com a explicação sobre alternar o estado de pausa, uso de get_tree().paused e mudança de pausa/reinício baseada em entrada | Diferencie de abrir menu, trocar de cena, ou indicar fim de jogo | Verifique se sample-25 altera o estado de pausa em si ou apenas mostra um UI |
| 26 | Verificação do estado de entrada do teclado (Input.is_key_pressed) | Diferença de versão | Compare o trecho de código com a explicação sobre Input.is_key_pressed, constantes de tecla e códigos de tecla | Diferencie de entrada mapeada por ação, entrada de mouse, ou lógica de movimentação | Verifique se sample-26 trata apenas da consulta do estado do teclado, separando da lógica completa de movimentação |
| 27 | Obtenção das coordenadas da posição do mouse (cursor) | Sintaxe comum | Compare o trecho de código com a explicação sobre consulta da posição do mouse na viewport/global | Diferencie de disparo ao clicar, entrada por toque, ou exibição do cursor | Verifique se sample-27 lê coordenadas sem estar ligado a um evento de clique |
| 28 | Função de geração de número aleatório | Diferença de versão | Compare o trecho de código com a explicação sobre inicialização do RNG, geração de número aleatório e definição de intervalo | Diferencie de distribuição aleatória de posições ou timer de spawn de inimigos | Verifique se sample-28 trata apenas da função de gerar número, separando seu uso da lógica de gameplay |
| 29 | Spawn de inimigos em intervalos de tempo específicos | Diferença de versão | Compare o trecho de código com a explicação sobre uso de Timer/timeout ou tempo acumulado para gerar inimigos periodicamente | Diferencie de cálculo de posição aleatória ou IA de movimentação de inimigos | Verifique se sample-29 demonstra claramente o intervalo de tempo e a chamada de spawn |
| 30 | Distribuição aleatória da posição dos inimigos spawnados | Sintaxe comum | Compare o trecho de código com a explicação sobre intervalo de coordenadas aleatórias, área de spawn e distribuição de posições | Diferencie de timer que controla a frequência de spawn | Verifique se sample-30 descreve onde os inimigos são colocados, não quando são criados |
| 31 | Transição de estado de animação do jogador (Idle, Run, Jump) | Diferença de versão | Compare o trecho de código com a explicação sobre mudar o nome da animação conforme entrada, velocidade ou estado | Diferencie de controle de velocidade ou tempo de reprodução da animação | Verifique se sample-31 separa a troca de estado da manipulação de tempo de reprodução |
| 32 | Controle do tempo de reprodução da animação | Sintaxe comum | Compare o trecho de código com a explicação sobre speed, seek, advance e controle da posição de playback | Diferencie de transição de estados Idle/Run/Jump | Verifique se sample-32 trata de ajustar velocidade/tempo, não de escolher qual animação tocar |
| 33 | Ajuste do tamanho da área de colisão | Diferença de versão | Compare o trecho de código com a explicação sobre propriedades de tamanho de CollisionShape2D/Shape2D, e atributos size/extents de RectangleShape2D | Diferencie de detecção de colisão, cálculo de dano ou sinal de Area2D | Verifique se sample-33 modifica forma/tamanho da área de colisão, não apenas detecta colisão |
| 34 | Aplicação da gravidade física (Gravity) | Diferença de versão | Compare o trecho de código com a explicação sobre acumular gravidade e delta em velocity e aplicar via função de movimento | Diferencie de força de salto, detecção de aterrissagem ou configuração de gravidade em Area | Verifique se sample-34 mostra o fluxo de acumulação da gravidade separado da lógica de salto/aterrissagem |
| 35 | Aplicação da força de salto (Jump) e detecção de aterrissagem | Diferença de versão | Compare o trecho de código com a explicação sobre is_on_floor(), velocidade de salto, condições de entrada e estado de aterrissagem | Diferencie de apenas aplicar gravidade ou apenas mudar estado de animação | Verifique se sample-35 descreve entrada de salto e verificação de chão dentro do mesmo fluxo de movimento |
| 36 | Tratamento de deslizamento ao colidir com parede (Slide) | | | | |
| 37 | Alternância da direção do jogador (Facing Left/Right) | | | | |
| 38 | Redução da contagem de munição (Ammo) | | | | |
| 39 | Transição para estado de recarregamento (Reload) quando o carregador está vazio | | | | |
| 40 | Conexão de evento de clique em botão UI | | | | |
| 41 | Alternância de abrir/fechar menu de Configurações (Settings) | | | | |
| 42 | Atualização de texto ao mudar o idioma (Language) | | | | |
| 43 | Serialização JSON de dados de salvamento (Save Game) | | | | |
| 44 | Desserialização JSON de dados carregados (Load Game) | | | | |
| 45 | Tratamento de erros ao ler/escrever arquivos | | | | |
| 46 | Verificação do estado de conexão de rede | | | | |
| 47 | Sincronização via chamada de função remota (RPC) | | | | |
| 48 | Carregamento dinâmico de recursos de cena | | | | |
| 49 | Liberação de memória e descarregamento de recursos | | | | |
| 50 | Saída de logs de depuração (print ou print_debug) | | | | |
api_mapping
Verifique se a evidência de como nomes, classes, funções e símbolos mudam do Godot 3 para o Godot 4 corresponde diretamente ao trecho de código.
| Número | Função | Sintaxe Comum | Resultado JSONL Relacionado | Resultado JSONL Irrelevante | Observação |
|---|---|---|---|---|---|
| 1 | Inicialização da função _ready() e definição do tamanho da viewport |
Sintaxe comum | Observado JSONL relacionado sim |
Observado JSONL irrelevante não |
Mapeamento que contém DisplayServer.window_set_size, Vector2i é avaliado como sim; mapeamento de AudioServer.get_bus_volume_db é avaliado como não |
| 2 | Loop de atualização por quadro _process(delta) |
Sintaxe comum | Observado JSONL relacionado sim |
Observado JSONL irrelevante não |
Mapeamento estável que contém position.x, delta, _process é avaliado como sim; mapeamento de get_node("Sprite2D") é avaliado como não |
| 3 | Processamento de entrada de movimento do jogador (WASD ou setas) | Sintaxe comum | Observado JSONL relacionado sim |
Observado JSONL irrelevante não |
Mapeamento que contém CharacterBody2D.move_and_slide, velocity, Vector2 é avaliado como sim; mapeamento de Node.connect/conexão de sinal é avaliado como não |
| 4 | Aplicação de velocidade e aceleração ao movimento do jogador | Diferença de versão | Registros bidirecionais existentes sim foram excluídos da decisão final |
Na verificação do Godot 3, o lado api_mapping varia entre sim/não |
É necessário revisar como os mapeamentos de move_and_slide, CharacterBody3D, move_toward, velocity.x, velocity.z, target_velocity reagem conforme a versão do código |
| 5 | Limitação da velocidade máxima do jogador | Diferença de versão | Observação inicial baseada no Godot 3. Resposta bruta inversa para Godot 4: código Godot 4 sim/sim, código Godot 3 não/não |
No código Godot 4, ambos os candidatos de mapeamento são sim; no código Godot 3, ambos são não |
Baseado nas diferenças de retorno de move_and_slide, velocity, limit_speed e normal de colisão. É preciso analisar padrões para dividir expectativas entre a sintaxe do Godot 4 e a do Godot 3 |
| 6 | Criação e disparo de projéteis ao clicar o mouse | Diferença de versão | Diferenças nas APIs de criação de projéteis entre Godot 3/4 e o mapeamento de entrada correspondem como esperado | Candidatos de mapeamento irrelevantes também foram descartados | Como PackedScene.instance() vs. instantiate(), a forma source/target está separada e incluída no fluxo de aprovação 24/24 |
| 7 | Gerenciamento de movimento e tempo de vida (time‑to‑live) dos projéteis | Diferença de versão | No Godot 3, o mapeamento de conversão foi identificado como sim |
O mesmo mapeamento aparece como sim também no código Godot 4, observando inconsistência |
Total 22/24; se já for código Godot 4, a conversão não se aplica, portanto a verificação de origem deve ser mais clara no prompt de validação |
| 8 | Lógica de IA de rastreamento do jogador pelo inimigo (Enemy) | Diferença de versão | O lado api_mapping não foi a causa direta da inconsistência no item 8 | Candidatos de mapeamento irrelevantes são descartados como esperado | A inconsistência total ocorre em docs_chunks. O mapeamento serve como eixo auxiliar para verificar mudanças de API da IA entre versões |
| 9 | Lógica de velocidade de movimento e rotação do inimigo | Diferença de versão | Mapeamentos de rotação/movimento correspondem corretamente ao código | Candidatos de mapeamento irrelevantes também são descartados | Aprovação 24/24. Diferenças nas APIs de velocidade e rotação são relativamente bem separadas |
| 10 | Desaparecimento do jogador ao sair da tela | Sintaxe comum | Por ser código comum, o JSONL relacionado a api_mapping não requer conversão | Candidatos de conversão irrelevantes são não |
Aprovação 6/6. Em sintaxe comum, a tabela de migração não se anexa ao fluxo |
| 11 | Detecção de colisão (Area2D ou PhysicsBody) | Diferença de versão | Verificar se a API de detecção de colisão Area2D/PhysicsBody ou mudança de conexão de sinal é necessária no código atual | Diferenciar do mapeamento de aplicação de dano ou tratamento de vida | sample-11 avalia se a própria API de detecção e o fluxo subsequente precisam de mapeamento |
| 12 | Cálculo e aplicação de dano ao colidir | Sintaxe comum | Verificar se há mudanças de API por versão no modo de aplicação de dano que realmente existam no código | Diferenciar do mapeamento que descreve apenas o sinal de detecção de colisão | sample-12 separa se o mapeamento é necessário por mudança ou se é apenas lógica de jogo |
| 13 | Lógica de redução de vida do jogador | Sintaxe comum | Verificar se a redução de vida do jogador requer justificativa de mudança de API entre versões | Diferenciar de candidatos de mapeamento de vida do inimigo/pontuação/fim de jogo | sample-13 observa que, sendo principalmente lógica de jogo, pode estar sendo excessivamente marcada como migração |
| 14 | Tratamento de Game Over quando a vida do jogador chega a 0 | Sintaxe comum | Verificar se a troca de cena, pausa ou mudanças na API da árvore ocorrem no código | Diferenciar de candidatos de mapeamento que tratam apenas da redução de vida | sample-14 confirma se a API de transição de estado é a base do mapeamento |
| 15 | Lógica de redução de vida do inimigo | Sintaxe comum | Verificar se há necessidade real de justificativa de mudança de API Godot 3→4 para a redução de vida do inimigo | Diferenciar de mapeamentos de vida do jogador ou pontuação | sample-15 indica que, se o objeto alvo for diferente, o candidato de mapeamento deve resultar em não |
| 16 | Remoção do inimigo ao chegar a 0 de vida e adição de pontuação | Sintaxe comum | Verificar se as APIs de remoção, atualização de pontuação e manipulação da árvore de cenas estão presentes no código | Diferenciar de mapeamentos simples de dano ou atualização de Label | sample-16 separa qual parte (remoção ou pontuação) serve como justificativa de mapeamento |
| 17 | Atualização da variável de pontuação (Score) | Sintaxe comum | Verificar se a atualização da variável de pontuação realmente depende de mudança de API | Diferenciar de mapeamentos de atualização de UI ou salvamento/carregamento | sample-17 garante que operações simples de variável não sejam superavaliadas como motivo de migração |
| 18 | Função de atualização do texto da pontuação (Label) | Sintaxe comum | Verificar se a forma de acessar o texto do Label ou a referência ao nó mudou no código | Diferenciar de mapeamentos que calculam o valor da pontuação | sample-18 checa se expressões como Label.text são comuns ou se há alterações entre versões |
| 19 | Reprodução de música de fundo (BGM) e controle de volume | Sintaxe comum | Verificar se há necessidade direta de mudança nas APIs de AudioServer, AudioStreamPlayer ou volume do bus no código | Diferenciar de mapeamentos de reprodução única de SFX | sample-19 impede que termos genéricos de áudio acionem mapeamento indevido |
| 20 | Função de reprodução de efeitos sonoros (SFX) | Sintaxe comum | Verificar se a API de reprodução de SFX ou a forma de criar o nó mudou no código | Diferenciar de mapeamentos de loop/volume de BGM | sample-20 separa a justificativa de migração mesmo que SFX e BGM pertençam ao mesmo subsistema de áudio |
| 21 | Implementação do efeito de tremor de tela (Screen Shake) | Diferença de versão | Verificar se há mudanças nas APIs de Tween, Camera2D, offset ou shake aleatório entre versões | Diferenciar de mapeamentos de rastreamento de câmera ou movimento geral | sample-21 valida se candidatos relacionados à câmera são realmente a base para a migração do efeito de tremor |
| 22 | Criação de sistema de partículas e correspondência de posição | Diferença de versão | Verificar se as mudanças relacionadas a Particles2D/GPUParticles2D, emitting, position/global_position estão diretamente no código | Diferenciar do mapeamento de criação de projéteis ou nós genéricos | sample-22 separa as mudanças da API exclusiva de sistemas de partículas da lógica de criação geral |
| 23 | Função de mudança de cena (Scene Change) | Diferença de versão | Verificar se as mudanças das séries change_scene, change_scene_to_file, change_scene_to_packed estão diretamente no código atual | Diferenciar do mapeamento de load()/preload() simples ou exibição do menu principal | sample-23 verifica se as chamadas de mudança de cena do Godot 3 e as substitutas do Godot 4 são aplicadas conforme a versão do código |
| 24 | Carregamento e exibição da cena do menu principal | Diferença de versão | Verificar se as mudanças relacionadas ao carregamento de cena, instanciação e exibição da cena do menu são necessárias no código atual | Diferenciar do mapeamento de mudança de cena genérica ou preload de recursos | sample-24 verifica se o objetivo de exibir o menu principal não se mistura com as mudanças da API de cena |
| 25 | Alternar função de pausa (Pause) do jogo | Sintaxe comum | Verificar se as mudanças de pause mode/process mode e pause da árvore são realmente necessárias no código atual | Diferenciar do mapeamento de UI de menu ou game over | sample-25 verifica se o código comum de toggle de pausa não recebe mapeamentos de migração excessivos |
| 26 | Verificar estado de entrada do teclado (Input.is_key_pressed) | Diferença de versão | Verificar se as mudanças de constantes de tecla, scancode/keycode e Input.is_key_pressed correspondem diretamente ao código | Diferenciar do mapeamento de ação de movimento ou entrada de mouse | sample-26 separa as mudanças da API de consulta de estado de tecla da lógica de gameplay que usa entrada |
| 27 | Obter coordenadas da posição do mouse (cursor) | Sintaxe comum | Verificar se a API de leitura da posição do mouse requer mudanças específicas por versão | Diferenciar do mapeamento de criação de projéteis ao clicar ou entrada de toque | sample-27 garante que o código de leitura de coordenadas não recebe justificativas de conversão desnecessárias |
| 28 | Função de geração de número aleatório | Diferença de versão | Verificar se randomize, RandomNumberGenerator, função range têm mudanças que aparecem diretamente no código | Diferenciar do mapeamento de posição aleatória de spawn ou timer de spawn | sample-28 separa as mudanças da própria API de números aleatórios do propósito de uso dos valores |
| 29 | Spawn de inimigos em intervalos regulares | Diferença de versão | Verificar se sinais de Timer, conexão de timeout, e mudanças nas séries yield/await estão diretamente no código | Diferenciar da distribuição aleatória de posição dos inimigos ou mapeamento de IA de movimento | sample-29 analisa a estrutura de execução periódica junto com a lógica de criação de alvos |
| 30 | Distribuição aleatória da posição dos inimigos spawnados | Sintaxe comum | Verificar se random range, tamanho da viewport, cálculo da área de spawn exigem mudanças reais de API | Diferenciar do mapeamento de spawn baseado em timer | sample-30 garante que o código que só calcula posição não recebe mapeamento de periodicidade de spawn |
| 31 | Transição de estado da animação do jogador (Idle, Run, Jump) | Diferença de versão | Verificar se as mudanças em AnimatedSprite/AnimatedSprite2D, transição de estado do AnimationPlayer correspondem ao código | Diferenciar do mapeamento de controle de velocidade/seek/tempo | sample-31 separa mudanças de nomes de nós de animação dos padrões de transição de estado |
| 32 | Controle do tempo de reprodução da animação | Sintaxe comum | Verificar se mudanças em playback speed, seek, posição atual são necessárias no código atual | Diferenciar do mapeamento de seleção de estado Idle/Run/Jump | sample-32 separa a API de ajuste de tempo de reprodução da API de transição de estado |
| 33 | Ajuste do tamanho da área de colisão | Diferença de versão | Verificar se mudanças em CollisionShape2D, RectangleShape2D, tamanho/extensões da forma são diretamente necessárias no código | Diferenciar do mapeamento de sinal de colisão, camada física, dano | sample-33 verifica se a mudança é sobre a API de ajuste de tamanho da forma, não sobre a lógica de detecção de colisão |
| 34 | Aplicação de gravidade física (Gravity) | Diferença de versão | Verificar se mudanças em CharacterBody2D/KinematicBody2D, velocity, move_and_slide são diretamente necessárias no código | Diferenciar do mapeamento de impulso de salto, verificação de chão, gravidade de Area2D | sample-34 confirma se a gravidade é acumulada no frame físico e refletida no movimento |
| 35 | Aplicação de força de salto (Jump) e detecção de aterrissagem | Diferença de versão | Verificar se is_on_floor(), velocidade de salto, ação de Input, move_and_slide correspondem ao código | Diferenciar do movimento apenas por gravidade, estado de animação, colisão com parede | sample-35 verifica se as condições de início de salto e a detecção de aterrissagem requerem o mapeamento conjunto |
| 36 | Tratamento de deslizamento (Slide) ao colidir com parede | | | | |
| 37 | Inversão da direção do jogador (Facing Left/Right) | | | | |
| 38 | Redução da contagem de munição (Ammo) | | | | |
| 39 | Transição para estado de recarregamento (Reload) quando o carregador está vazio | | | | |
| 40 | Conexão de evento de clique em botão UI | | | | |
| 41 | Alternar abertura/fechamento do menu de Configurações (Settings) | | | | |
| 42 | Atualizar texto ao mudar o idioma (Language) | | | | |
| 43 | Serialização JSON de dados de salvamento (Save Game) | | | | |
| 44 | Desserialização JSON de dados carregados (Load Game) | | | | |
| 45 | Tratamento de erros de leitura/escrita de arquivos | | | | |
| 46 | Verificação do estado de conexão de rede | | | | |
| 47 | Sincronização via chamada de função remota (RPC) | | | | |
| 48 | Carregamento dinâmico de recursos de cena | | | | |
| 49 | Liberação de memória e descarregamento de recursos | | | | |
| 50 | Saída de logs de depuração (print ou print_debug) | | | | |
label_prototypes
Verifique se a evidência do exemplo, que não é apenas uma mudança de nome simples, mas altera completamente o modo de uso da função, a composição dos argumentos e o padrão de chamada, corresponde diretamente ao trecho de código.
| Número | Função | Tipo de Sintaxe Comum? | Resultado JSONL Relacionado | Resultado JSONL Irrelevante | Observação |
|---|---|---|---|---|---|
| 1 | Inicialização da função _ready() e definição do tamanho da viewport |
Sintaxe comum | Observado JSONL relacionado sim |
Observado JSONL irrelevante não |
O protótipo DisplayServer.window_set_size(Vector2i(1920, 1080)) é sim; o protótipo AudioStreamPlayer3D é avaliado como não |
| 2 | Loop de atualização por quadro _process(delta) |
Sintaxe comum | Observado JSONL relacionado sim |
Observado JSONL irrelevante não |
O protótipo func _process(delta) e position.x += move_speed * delta é sim; o protótipo _input(event)/event.is_action_pressed é não |
| 3 | Processamento de entrada de movimento do jogador (WASD ou setas) | Sintaxe comum | Observado JSONL relacionado sim |
Observado JSONL irrelevante não |
O protótipo Input.is_action_pressed, velocity = direction * move_speed, move_and_slide() é sim; o protótipo @onready/acesso ao caminho do nó é não |
| 4 | Aplicação de velocidade e aceleração do jogador | Diferença de versão | Registros bidirecionais sim foram excluídos da decisão final |
Na inspeção do Godot 3, a coluna label_prototypes ficou sim/não |
Necessário revisar se os protótipos por eixo move_toward(velocity.x/velocity.z), move_and_slide(), CharacterBody3D são evidência exclusiva de versão ou evidência de string comum |
| 5 | Limitação da velocidade máxima do jogador | Diferença de versão | Observação inicial baseada no Godot 3. Resposta bruta inversa no Godot 4: código Godot 4 sim/não, código Godot 3 sim/não |
O protótipo Tween foi descartado como não em ambos os lados |
CharacterBody2D, move_and_slide(), velocity aparecem em ambos os códigos, portanto o protótipo relacionado foi marcado como sim em ambos. É preciso separar evidência exclusiva de versão de evidência de string comum |
| 6 | Criação e disparo de projétil ao clicar o mouse | Diferença de versão | O padrão de chamada de criação/disparo de projétil corresponde ao código | Candidatos de protótipo irrelevantes também foram descartados | Incluído no fluxo de aprovação 24/24. O processamento de entrada e o padrão de criação de projétil estão bem separados |
| 7 | Gerenciamento de movimento e tempo de vida (time‑to‑live) do projétil | Diferença de versão | No Godot 3, o protótipo de conversão foi marcado como sim |
O mesmo protótipo aparece como sim no código Godot 4, indicando inconsistência |
Total 22/24; casos em que o código Godot 4 já convertido recebe o protótipo “necessita conversão” são incorretos |
| 8 | Lógica de IA de rastreamento do jogador pelo inimigo (Enemy) | Diferença de versão | A coluna label_prototypes não foi a causa direta da inconsistência no item 8 | Candidatos de protótipo irrelevantes foram descartados como esperado | A inconsistência total ocorreu em docs_chunks. O protótipo registra como eixo auxiliar se houve mudança no modo de uso da IA de rastreamento |
| 9 | Lógica de velocidade e rotação do inimigo | Diferença de versão | O padrão de chamada de movimento/rotação corresponde ao código | Candidatos de protótipo irrelevantes foram descartados como esperado | Aprovação 24/24. Cálculo de velocidade e aplicação de rotação estão relativamente bem separados |
| 10 | Desaparecimento do jogador ao sair da tela | Sintaxe comum | Por ser código comum, os JSONL de label_prototypes não requerem conversão | Candidatos de conversão irrelevantes também são não |
Aprovação 6/6. Em sintaxe comum, o fluxo não exige a anexação de protótipo |
| 11 | Detecção de colisão (Area2D ou PhysicsBody) | Diferença de versão | Verificar se o uso de sinal/callback de detecção de colisão corresponde ao padrão antes da mudança no código atual | Diferenciar do protótipo de aplicação de dano após colisão | sample-11 separa o padrão de evento de detecção e o padrão de tratamento de gameplay subsequente |
| 12 | Cálculo e aplicação de dano ao colidir | Sintaxe comum | Verificar se o padrão de chamada que aplica dano a partir da colisão está presente diretamente no código atual | Diferenciar do protótipo de simples detecção de colisão ou tratamento de vida = 0 | sample-12 verifica se a composição de argumentos, objeto alvo e ordem de aplicação de dano são evidência de protótipo |
| 13 | Lógica de redução de vida do jogador | Sintaxe comum | Verificar se o padrão de dano/ redução de vida do jogador está presente diretamente no código atual | Diferenciar do protótipo de redução de vida do inimigo | sample-13 testa se, apesar de pertencer à mesma família health, há diferença entre alvo player/enemy |
| 14 | Tratamento de Game Over quando a vida do jogador chega a 0 | Sintaxe comum | Verificar se o padrão de chamada de game over após vida = 0 está presente diretamente no código atual | Diferenciar do protótipo de simples redução de vida ou remoção de inimigo | sample-14 verifica se o protótipo descreve a transição de estado/ troca de cena após a condição |
| 15 | Lógica de redução de vida do inimigo | Sintaxe comum | Verificar se o padrão de dano/ redução de vida do inimigo está presente diretamente no código atual | Diferenciar do protótipo de dano ao player | sample-15 observa se falsos positivos surgem quando nomes de variáveis de estado e objetos alvo são amplamente semelhantes |
| 16 | Remoção do inimigo e adição de pontuação quando a vida chega a 0 | Sintaxe comum | Verificar se o padrão que combina remoção do inimigo e aumento de score está presente diretamente no código atual | Diferenciar do protótipo de simples atualização de score ou remoção isolada | sample-16 checa se o protótipo que agrupa múltiplas ações corresponde à ordem real no SOURCE_CODE |
| 17 | Atualização da variável de pontuação (Score) | Sintaxe comum | Verificar se o padrão de atualização da variável score está presente diretamente no código atual | Diferenciar do protótipo que apenas reflete o texto do Label | sample-17 separa a atualização de dados internos da atualização da exibição UI |
| 18 | Função de atualização do texto do Label de pontuação | Sintaxe comum | Verificar se o padrão de atualização do texto do Label está presente diretamente no código atual | Diferenciar do protótipo que apenas altera a variável score | sample-18 verifica se o protótipo se refere à exibição na tela, não apenas à mudança de valor |
| 19 | Reprodução de música de fundo (BGM) e controle de volume | Sintaxe comum | Verificar se o padrão de reprodução/controle de volume do BGM está presente diretamente no código atual | Diferenciar do protótipo de reprodução única de SFX | sample-19 foca no propósito de reprodução contínua e ajuste de volume, não apenas em termos genéricos de áudio |
| 20 | Função de reprodução de efeitos sonoros (SFX) | Sintaxe comum | Verificar se o padrão de chamada/reprodução de SFX está presente diretamente no código atual | Diferenciar do protótipo de loop de BGM ou controle de volume de bus | sample-20 separa o fluxo de reprodução curta de efeitos do gerenciamento de música de fundo |
| 21 | Implementação do efeito de tremor de tela (Screen Shake) | Diferença de versão | Verificar se o padrão de aplicação de intensidade/tempo/offset de tremor está presente diretamente no código atual | Diferenciar do protótipo de rastreamento de câmera ou Tween genérico | sample-21 confirma se, mesmo com Camera2D/Tween presentes, o efeito final é realmente um shake |
| 22 | Criação do sistema de partículas e alinhamento de posição | Diferença de versão | Verificar se o padrão de criação de partículas, alinhamento de posição e início de emissão está presente diretamente no código atual | Diferenciar do protótipo de criação de projéteis ou nós genéricos | sample-22 verifica se o protótipo cobre a sincronização de posição e o início da emissão |
| 23 | Função de mudança de cena (Scene Change) | Diferença de versão | Verificar se o padrão de chamada que recebe o caminho da cena e a converte para SceneTree está presente diretamente no código atual | Distinguindo de protótipos de carregamento simples de recursos, abertura de menu, pausa | sample-23 verifica se o protótipo descreve o caminho de entrada da mudança de cena, o alvo da chamada e o resultado da transição |
| 24 | Carregamento e exibição da cena do menu principal | Diferença de versão | Verificar se o padrão de chamada que carrega e exibe a cena do menu está presente diretamente no código atual | Distinguindo de protótipos de carregamento simples de recursos, mudança de cena, menu de pausa | sample-24 verifica se o protótipo descreve o resultado “exibir o menu principal” |
| 25 | Alternar a funcionalidade de pausa (Pause) | Sintaxe comum | Verificar se o padrão que inverte o estado de pausa e agrupa o tratamento de UI/entrada está presente diretamente no código atual | Distinguindo de protótipos de abertura de menu de configurações ou game over | sample-25 verifica se a mudança da flag de pausa e a exibição na tela devem ser vistas como um mesmo fluxo |
| 26 | Verificar estado de entrada do teclado (Input.is_key_pressed) | Diferença de versão | Verificar se o padrão que faz polling direto do estado das teclas está presente no código atual | Distinguindo de protótipos de força de ação, vetor de movimento, entrada de mouse | sample-26 registra a consulta de entrada separada da ação executada com essa entrada |
| 27 | Obter coordenadas da posição do mouse (cursor) | Sintaxe comum | Verificar se o padrão que lê as coordenadas do cursor e as usa em variáveis ou cálculos de posição está presente diretamente no código atual | Distinguindo de protótipos de evento de clique do mouse ou criação de projéteis | sample-27 verifica se a própria consulta da posição do mouse é o ponto central |
| 28 | Função de geração de número aleatório | Diferença de versão | Verificar se o padrão de chamada que gera números aleatórios/com intervalo está presente diretamente no código atual | Distinguindo de protótipos de distribuição de posição de spawn, tabela de drop, timer spawn | sample-28 separa a chamada da API random do local onde o resultado aleatório é usado |
| 29 | Spawn de inimigos em intervalos de tempo específicos | Diferença de versão | Verificar se o padrão que chama a função de spawn a cada intervalo de tempo está presente diretamente no código atual | Distinguindo de protótipos de cálculo de posição aleatória ou IA de rastreamento de inimigos | sample-29 verifica se as condições de tempo, timer e ordem de chamada do spawn estão corretas |
| 30 | Distribuição aleatória da posição dos inimigos spawnados | Sintaxe comum | Verificar se o padrão que posiciona inimigos gerados dentro de um intervalo aleatório está presente diretamente no código atual | Distinguindo de protótipos de loop de spawn que cria a cada intervalo de tempo | sample-30 separa a distribuição/cálculo de coordenadas do ciclo de criação |
| 31 | Transição de estado de animação do jogador (Idle, Run, Jump) | Diferença de versão | Verificar se o padrão que altera o nome da animação com base em valores de estado ou velocidade está presente diretamente no código atual | Distinguindo de protótipos de controle de velocidade de reprodução, seek, controle de frame/tempo | sample-31 verifica se o ponto central é qual estado está sendo transicionado |
| 32 | Controle do tempo de reprodução da animação | Sintaxe comum | Verificar se o padrão que controla velocidade de reprodução, seek e posição atual de reprodução está presente diretamente no código atual | Distinguindo de protótipos de transição de estado Idle/Run/Jump | sample-32 verifica se o ponto central é o controle do tempo de reprodução, não a escolha da animação |
| 33 | Ajuste do tamanho da área de colisão | Diferença de versão | Verificar se o padrão que lê ou altera o valor de tamanho da forma de colisão está presente diretamente no código atual | Distinguindo de protótipos de tratamento de evento de colisão ou aplicação de dano | sample-33 separa se a mudança do tamanho da forma ou o tratamento do resultado da colisão é o ponto central |
| 34 | Aplicação de gravidade física (Gravity) | Diferença de versão | Verificar se o padrão que acumula gravidade baseada em delta na velocidade e reflete isso na chamada de movimento está presente diretamente no código atual | Distinguindo de protótipos de entrada de salto, verificação de aterrissagem, spawn/timer | sample-34 verifica se a acumulação de gravidade dentro do loop de movimento físico é o ponto central |
| 35 | Aplicação de força de salto (Jump) e detecção de aterrissagem | Diferença de versão | Verificar se o padrão que aplica força de salto quando está no chão e depois verifica se aterrissou está presente diretamente no código atual | Distinguindo de protótipos que só acumulam gravidade no movimento ou que só mudam estado de animação | sample-35 verifica se condição de salto, mudança de velocidade vertical e verificação de piso são agrupadas em um único fluxo |
| 36 | Tratamento de deslizamento ao colidir com parede (Slide) | | | | |
| 37 | Troca de direção do jogador (Facing Left/Right) | | | | |
| 38 | Redução da contagem de munição (Ammo) | | | | |
| 39 | Transição para estado de recarregamento (Reload) quando o carregador está vazio | | | | |
| 40 | Conexão de evento de clique em botão UI | | | | |
| 41 | Alternar abertura/fechamento do menu de Configurações (Settings) | | | | |
| 42 | Atualizar texto ao mudar o idioma (Language) | | | | |
| 43 | Serialização JSON de dados de salvamento (Save Game) | | | | |
| 44 | Desserialização JSON de dados de carregamento (Load Game) | | | | |
| 45 | Tratamento de erros de leitura/escrita de arquivos | | | | |
| 46 | Verificação do estado de conexão de rede | | | | |
| 47 | Sincronização via chamada de função remota (RPC) | | | | |
| 48 | Carregamento dinâmico de recursos de cena | | | | |
| 49 | Liberação de memória e descarregamento de recursos | | | | |
| 50 | Saída de log de depuração (print ou print_debug) | | | | |
Registro adicional de 6 de julho de 2026
Do item 6 ao 10 já foram refletidos no fluxo de melhorias em 3 de julho de 2026, deixando observações detalhadas. Portanto, neste documento não deixamos os itens 6‑10 em branco; adaptamos o conteúdo das observações existentes nas tabelas docs_chunks, api_mapping e label_prototypes para cada um deles.
Em 6 de julho de 2026, com base em http://localhost:8520/#item=sample-22, foram adicionados os registros do item 11 ao 22. Essa seção descreve, para cada item, qual candidato de evidência corresponde ao JSONL, e quais candidatos devem ser descartados como código diferente, transformação diferente ou padrão diferente.
Registro adicional de 8 de julho de 2026
Em 8 de julho de 2026, com base em http://localhost:8520/#item=sample-32, foram adicionados os registros do item 23 ao 32. Essa seção também é vista mais como uma planilha de observação — indicando como docs_chunks, api_mapping e label_prototypes explicam ou rejeitam o mesmo trecho de código sob diferentes perspectivas — do que como uma tabela de decisão final.
Registro adicional de 13 de julho de 2026
Em 13 de julho de 2026, com base em http://localhost:8520/#item=sample-35, foram registrados os itens 33 ao 35. Essa seção trata de áreas onde tamanho de colisão, gravidade, pulo/aterrissagem e outros movimentos físicos interagem, exigindo análise conjunta do propósito do código e do local de aplicação, em vez de apenas sobreposição de strings.
Observação reversa do item 5
O item 5 entrou na meta de quantidade de hoje, mas ao inspecioná‑lo retroativamente como JSONL para Godot 4, o resultado não se reduziu a pares limpos de “sim/não”. Assim, não se decide a confirmação agora e ele será analisado na próxima fase como alvo de análise de padrão.
A ordem de respostas é docs_chunks #1, docs_chunks #2, api_mapping #1, api_mapping #2, label_prototypes #1, label_prototypes #2.
| Código de inspeção | Ordem de resposta | Observação |
|---|---|---|
| Código Godot 4 | sim, sim, sim, sim, sim, não |
Como há muitas strings que coincidem diretamente com o código — como limit_speed, velocity, move_and_slide(), Input.is_action_pressed — as candidatas em docs/api são amplamente marcadas como sim |
| Código Godot 3 | sim, sim, não, não, sim, não |
As candidatas em docs e o protótipo CharacterBody2D são marcados como sim, mas as candidatas em api_mapping para Godot 4 são marcadas como não |
Esse resultado deve ser visto não como um erro do modelo, mas como um sinal de que os campos match_terms, required_when_seen_in_code e content dentro do JSONL podem estar muito amplos. Em especial, strings comuns como move_and_slide() e Input.is_action_pressed são evidências diretas, mas podem ser amplas demais para justificar limites de velocidade ou diferenças de versão.
Registro de casos de inconsistência
Falso Positivo
Casos em que a resposta correta seria não, mas foi retornado sim.
| ID | Função | Sintaxe comum? | Tabela | Resumo do JSONL incorreto | Resposta Qwen | Motivo da revisão |
|---|---|---|---|---|---|---|
Falso Negativo
Casos em que a resposta correta seria sim, mas foi retornado não.
| ID | Função | Sintaxe comum? | Tabela | Resumo do JSONL correto | Resposta Qwen | Motivo da revisão |
|---|---|---|---|---|---|---|
Violação de formato de resposta
Casos em que, em vez de sim ou não, foram dadas explicações, JSON, respostas vazias ou múltiplas frases.
| ID | Função | Sintaxe comum? | Tabela | Resposta esperada | Resposta real | Observação |
|---|---|---|---|---|---|---|
Resumo das observações
Durante os testes, preencha os números e respostas brutas abaixo. Aqui não se decide a confirmação, apenas se observa como as respostas variam segundo os critérios.
| Item | docs_chunks | api_mapping | label_prototypes | Total |
|---|---|---|---|---|
| Observações de hoje | Registros adicionais 23‑32 | Registros adicionais 23‑32 | Registros adicionais 23‑32 | Registros adicionais 23‑32 (base 08‑07‑2026) |
| Observações totais | 32/50 registros de teste | 32/50 registros de teste | 32/50 registros de teste | 32/50 registros de teste |
| Número de trechos de código testados | 32/50 | 32/50 | 32/50 | 32/50 |
| Amostras de sintaxe comum | Cálculo acumulado pendente | Cálculo acumulado pendente | Cálculo acumulado pendente | Necessário agregar após registro de rótulos até o item 32 |
| Amostras de diferença de versão | Cálculo acumulado pendente | Cálculo acumulado pendente | Cálculo acumulado pendente | Necessário agregar após registro de rótulos até o item 32 |
| Concordância com respostas esperadas (primeira fase) | 5 | 5 | 5 | 15 |
| Discordância com respostas esperadas (primeira fase) | 0 | 0 | 0 | 0 |
| Resposta bruta reversa do item 5 (Godot 4) | Godot 4 sim/sim, Godot 3 sim/sim |
Godot 4 sim/sim, Godot 3 não/não |
Godot 4 sim/não, Godot 3 sim/não |
Necessária análise de padrão |
| Violação de formato de resposta | 0 | 0 | 0 | 0 |
| Necessita revisão | 2 | 2 | 2 | Necessária redefinição para itens 4/5 |
| Julgamento atual | Decisão final suspensa | Decisão final suspensa | Decisão final suspensa | Necessária análise de padrão posterior, incluindo registros adicionais 23‑32 |