Lista de verificación de prueba de coincidencia de evidencia JSONL para código Qwen Godot
Fecha de creación: 28 de junio de 2026
Propósito
Generar 50 fragmentos de código de Godot 3 con Qwen y comprobar, de la misma manera que la prueba de coincidencia de evidencia JSONL realizada ayer, que la valoración sí/ no se asigna correctamente.
Esta prueba no busca determinar si el modelo conoce Godot. Se trata de evaluar, al proporcionar simultáneamente SOURCE_CODE y JSONL, si dentro del JSONL existe una evidencia (cadena/API/patrón) que coincida directamente con el fragmento de código real.
En otras palabras, los JSONL relevantes deben marcarse como sí, y los que no tengan relación deben descartarse con no.
Método de prueba
Para cada fragmento de código se adjuntan al menos dos tipos de JSONL. No obstante, dado que Godot 3 y Godot 4 comparten algunas sintaxis comunes, no se trata todo como sintaxis exclusiva de Godot 3.
| Tipo de JSONL | Respuesta esperada | Significado |
|---|---|---|
| JSONL correcto | sí |
Al menos uno de los campos source_api, source_pattern, match_terms, required_when_seen_in_code, before_code del JSONL coincide directamente con el fragmento de código |
| JSONL incorrecto | no |
El JSONL contiene evidencia que solo comparte una API distinta, nodo distinto, sistema distinto o palabras genéricas amplias |
Cada prueba se considera con el siguiente conjunto de entradas.
JSONL
Qwen direct-evidence validator prompt
SOURCE_CODE chunkLa solicitud de verificación real es un método que consiste en comprobar si Qwen devuelve solo sí o no cuando se envían juntos JSONL + prompt + chunk.
En el caso de sintaxis común, se prueba basándose en un único fragmento de código. En ese momento, el JSONL correcto es un JSONL que contiene una descripción o patrón del código/función correspondiente, y el JSONL incorrecto es un JSONL que contiene una descripción de una función o sistema completamente diferente. Los casos en los que la respuesta esperada es sí y los casos en los que es no no se diferencian por el código, sino por si hay o no evidencia directa dentro del JSONL.
Bucle de generación repetida
El objetivo total es probar las 50 funciones completas. Sin embargo, hoy solo se verificarán manualmente hasta 5, y luego se reducirá analizando primero el patrón de respuestas sí/no en los resultados acumulados.
Objetivo de hoy: 5
Objetivo total: 50/50Después de completar los 5, no se incrementa forzadamente el número de nuevos ítems, y primero se observan las tendencias de falsos positivos y falsos negativos por sintaxis común/diferencias de versión/por tabla.
Las pruebas generan datos repitiendo el flujo a continuación.
1. Proporcione a Qwen una función de Godot para probar.
2. Primero indique si la función es una sintaxis común de Godot 3/4, una sintaxis específica de Godot 3 o una sintaxis específica de Godot 4.
3. Si es sintaxis común, cree un único bloque de código.
4. Si es sintaxis común, genere un JSONL correcto para ese código/función y un JSONL incorrecto para una función totalmente diferente.
5. Si no es sintaxis común, cree JSONL separados para Godot 4 y para Godot 3 y realice la prueba.
6. Todos los JSONL deben ajustarse a las columnas de la tabla de destino.
7. Inserte el JSONL + el bloque SOURCE_CODE en el prompt de validación y verifique “sí”/“no”.
8. Registre si la respuesta esperada coincide con la respuesta real.El núcleo no es la calidad de generación de código, sino verificar si la coincidencia de evidencia JSONL es estable. Por lo tanto, el JSONL correcto debe producir sí y el JSONL incorrecto debe producir no.
Precauciones de sintaxis común
Las sintaxis que se mantienen iguales en Godot 3 y Godot 4 no deben considerarse pruebas de clasificación por versión. Por ejemplo, pueden existir códigos que se usan en ambos lados como _ready(), _process(delta), asignaciones de variables básicas, print().
En esos casos se procede de la siguiente manera.
| Tipo de código | Método de prueba | Expectativa |
|---|---|---|
| Sintaxis común Godot 3/4 | Probar con un solo fragmento de código tanto contra el JSONL de esa función como contra un JSONL de una función totalmente diferente | Sólo con la evidencia directa del JSONL debe decidirse sí/no |
| Sintaxis específica de Godot 3 | Usar el fragmento de Godot 3 como referencia y comparar JSONL exclusivo de Godot 3 con JSONL exclusivo de Godot 4 | Si la cadena/patrón real de Godot 3 está en el JSONL, se devuelve sí |
| Sintaxis específica de Godot 4 | Usar el fragmento de Godot 4 como referencia y comparar JSONL exclusivo de Godot 4 con JSONL exclusivo de Godot 3 | Si la cadena/patrón real de Godot 4 está en el JSONL, se devuelve sí |
| Descripción de funcionalidad independiente de la versión | El código, sea de cualquier versión, debe tener evidencia directa en el contenido/code_blocks del JSONL | Si solo hay una similitud amplia, se devuelve no |
Por lo tanto, la tabla de registro debe indicar siempre si la sintaxis es común. Así, al revisar los resultados más tarde, se podrá distinguir si una sintaxis común se juzgó forzadamente como evidencia de migración o si una sintaxis con diferencia de versión se trató como común.
Nota de redefinición de criterios
Al probar los ítems 4 y 5 se observó que es difícil emitir un juicio definitivo. En especial, dependiendo de si el JSONL se creó bajo la premisa de Godot 3 o de Godot 4, la respuesta al mismo fragmento de código varía, y esa diferencia misma se convierte en objeto de análisis de patrones.
Así que, por ahora, no se determina si es “bueno” o “malo”, sino que se registra primero la respuesta cruda, como sigue.
| Categoría | Criterio de generación del JSONL | Código de prueba | Flujo esperado actual |
|---|---|---|---|
| Sintaxis común | Basado en Godot 3 | Código común o código de Godot 3/4 con el mismo significado | sí, no, sí, no, sí, no |
| Sintaxis común | Basado en Godot 4 | Código común o código de Godot 3/4 con el mismo significado | sí, no, sí, no, sí, no |
| Diferencia de versión | Basado en Godot 3 | Código de Godot 3 | sí, no, sí, no, sí, no |
| Diferencia de versión | Basado en Godot 3 | Código de Godot 4 | Mayormente no. Sin embargo, si api_mapping o prototype contiene evidencia explícita de conversión de Godot 3 a 4, pueden aparecer algunos sí, por lo que se revisa la respuesta cruda por separado |
| Diferencia de versión | Basado en Godot 4 | Código de Godot 3 | Mayormente no. Sin embargo, si el JSONL incluye simultáneamente cadenas de origen y destino, pueden aparecer algunos sí, por lo que se revisa la respuesta cruda por separado |
| Diferencia de versión | Basado en Godot 4 | Código de Godot 4 | sí, no, sí, no, sí, no |
El orden de respuestas se considera, por defecto, relacionado a docs_chunks, no relacionado a docs_chunks, relacionado a api_mapping, no relacionado a api_mapping, relacionado a label_prototypes, no relacionado a label_prototypes.
El ítem 4 también se registró antes como una entrada estructurada, pero dado que en la inspección de Godot 3 apareció una secuencia como no, no, sí, no, sí, no, se excluye de los juicios definitivos. Este documento servirá, a partir de ahora, como registro de observación que muestra “qué respuestas fluctúan bajo qué criterios”, más que “cuántas fueron correctas”.
Ejemplo de solicitud de generación
A continuación se muestra un ejemplo de solicitud al probar la primera función, la inicialización de _ready() y la configuración del tamaño del viewport.
El formato JSONL y el propósito de cada JSONL se describen en un documento separado.
Proporcióname un fragmento de Godot 3 y uno de Godot 4 que inicialicen la función `_ready()` y configuren el tamaño del viewport.
Además, indica primero si esta funcionalidad es una sintaxis común entre Godot 3 y Godot 4.
Si es sintaxis común, indica que se puede probar con el mismo código.
Y proporciona un JSONL de respuesta correcto según el formato `docs_chunks` JSONL y un JSONL que no sea una respuesta correcta.Este ejemplo se basa en docs_chunks. api_mapping y label_prototypes también se crean de la misma manera los JSONL correctos y los JSONL incorrectos según el formato y uso de cada JSONL, y se verifica sí/no con el mismo prompt de validación.
La entrada de validación queda como sigue.
JSONL:
<Una línea JSONL de respuesta correcta o incorrecta>
PROMPT:
<prompt validador de evidencia directa>
SOURCE_CODE:
<fragmento de código Godot 3, fragmento de código Godot 4, o fragmento de código de sintaxis común>El prompt se envía como si estuviera evaluando la evidencia directa de explicación o la base de transformación entre SOURCE_CODE y JSONL.
Eres un evaluador de coincidencia de evidencia JSONL.
Determina si el JSONL a continuación contiene evidencia directa de descripción o transformación para el SOURCE_CODE a continuación.
Criterios de evaluación:
- Sólo es “sí” si alguna de las esquemas JSONL coincide exactamente con una cadena real o llamada a API dentro del SOURCE_CODE.
- Simplemente coincidir en palabras amplias como Godot, Godot3, Godot4, migration, 2D, physics no es relevante.
- Si el JSONL trata sobre otra API, otro nodo o otro sistema, es “no”.
- No uses tu conocimiento de Godot; utiliza solo la evidencia textual presente en el JSONL.
- La respuesta debe ser únicamente “sí” o “no”.Matriz de juicio
| Respuesta esperada | Respuesta real | Interpretación provisional | Contenido a registrar |
|---|---|---|---|
sí |
sí |
Coincide con lo esperado | Se reconoce como JSONL correcto basado en evidencia directa |
no |
no |
Coincide con lo esperado | Se descarta JSONL incorrecto |
sí |
no |
Necesita revisión | Se omitió a pesar de haber evidencia directa. Candidato a falso negativo |
no |
sí |
Necesita revisión | Se aceptó sin evidencia directa. Candidato a falso positivo |
sí o no |
otra respuesta | Necesita revisión | Violación del formato de respuesta. Incluye explicación, JSON, respuesta vacía, respuesta ambigua |
Lista de verificación de observación
Después de completar 50 pruebas de muestra por tabla, se verifica lo siguiente.
| Verificación | Criterio | Resultado |
|---|---|---|
| Formato de respuesta | Todas las respuestas solo contienen sí o no |
|
| Respuesta JSONL relacionada | En la prueba de JSONL relacionado, la respuesta sí aparece de forma suficientemente estable |
|
| Respuesta JSONL no relacionada | En la prueba de JSONL no relacionado, la respuesta no aparece de forma suficientemente estable |
|
| Registro de falsos positivos | Se registran por separado los casos en que la respuesta correcta era no pero se obtuvo sí |
|
| Registro de falsos negativos | Se registran por separado los casos en que la respuesta correcta era sí pero se obtuvo no |
|
| Filtro de palabras amplias | Palabras amplias como Godot, migration, 2D, physics no generan sí por sí solas |
|
| Evidencia de cadena directa | La determinación sí incluye un campo JSONL que coincide con la cadena de código/API/patrón real |
|
| Distinción de sintaxis común | Las muestras de sintaxis común de Godot 3/4 se probaron con JSONL esperado sí/no basados en el mismo fragmento de código |
|
| Diferencias por tabla | Se registra cómo varían los desacuerdos en docs_chunks, api_mapping, label_prototypes |
|
| Reproducibilidad | Al volver a introducir la misma entrada, la determinación no varía significativamente | |
| Próxima decisión | Se decide si este prompt y método de juicio pueden pasar al siguiente PoC |
Formato de registro de pruebas
Copie la tabla a continuación y complete los resultados de la prueba.
| ID | Función | ¿Sintaxis común? | Tabla | Tipo de JSONL | Respuesta esperada | Respuesta real | Juicio | Campo coincidente directo | Comentario |
|---|---|---|---|---|---|---|---|---|---|
| G03-001-A | Función _ready() inicializa y establece el tamaño del viewport |
JSONL correcto | sí |
||||||
| G03-001-B | Función _ready() inicializa y establece el tamaño del viewport |
JSONL incorrecto | no |
Registro por tabla
docs_chunks
Se verifica si la evidencia descriptiva de la documentación oficial coincide directamente con el fragmento de código.
| número | función | ¿es sintaxis común? | resultado JSONL relacionado | resultado JSONL no relacionado | nota |
|---|---|---|---|---|---|
| 1 | Inicialización de la función _ready() y configuración del tamaño del viewport |
sintaxis común | Observación JSONL relacionada sí |
Observación JSONL no relacionada no |
La evidencia en docs_chunks que incluye Node._ready, get_viewport().get_visible_rect().size, DisplayServer.window_set_size está marcada como sí; la explicación de _process(delta) en JSONL se juzga como no |
| 2 | Bucle de actualización por fotograma _process(delta) |
sintaxis común | Observación JSONL relacionada sí |
Observación JSONL no relacionada no |
La evidencia en docs_chunks que incluye _process(delta), position.x +=, speed * delta está marcada como sí; la explicación de Vector2.lerp en JSONL se juzga como no |
| 3 | Procesamiento de la entrada de movimiento del jugador (WASD o teclas de flecha) | sintaxis común | Observación JSONL relacionada sí |
Observación JSONL no relacionada no |
La evidencia en docs_chunks que incluye Input.is_action_pressed, Vector2.ZERO, direction.normalized(), velocity, move_and_slide() está marcada como sí; la explicación de TileMapLayer.set_cell() en JSONL se juzga como no |
| 4 | Aplicación de velocidad y aceleración al movimiento del jugador | diferencia de versión | El registro bidireccional anterior sí se excluye del juicio definitivo |
En la inspección de Godot 3, la documentación mostró no/no, por lo que se requiere revisión |
Necesidad de redefinir criterios debido a respuestas crudas no, no, sí, no, sí, no |
| 5 | Límite de velocidad máxima del jugador | diferencia de versión | Observación inicial basada en Godot 3; respuesta inversa basada en Godot 4: código Godot 4 sí/sí, código Godot 3 sí/sí |
En la revisión inversa de Godot 4, todas las candidatas de documentación aparecen como sí |
CharacterBody2D, max_speed, velocity = input_vector * max_speed, move_and_slide(), Input.is_action_pressed aparecen directamente en texto; se necesita análisis de patrones para delimitar el alcance funcional |
| 6 | Creación y disparo de proyectil al hacer clic con el ratón | diferencia de versión | La justificación en Godot 3/4 coincide con el código y pasa el flujo completo 24/24 |
Otras explicaciones de código JSONL se descartan según lo esperado | La diferencia entre PackedScene.instance() y instantiate(), y el manejo de la entrada del ratón, se separa según el código, lo que genera divergencias en las candidatas de documentación |
| 7 | Gestión del movimiento y vida útil (time‑to‑live) del proyectil | diferencia de versión | Se verifica que la evidencia en docs_chunks coincide con el código de movimiento/TTL del proyectil |
Las candidatas de documentación no relacionadas se descartan según lo esperado | De los 22/24 totales, la discrepancia surge donde la base de conversión api_mapping/label_prototypes de Godot 3 se marca como sí también en el código de Godot 4 |
| 8 | Lógica de IA de seguimiento del jugador por parte del enemigo (Enemy) | diferencia de versión | Se observó un falso positivo: la candidata de documentación de Godot 4 también se marca como sí en el código de Godot 3 |
Otros casos donde la candidata de código se marca como sí tanto en Godot 3 como 4 requieren revisión |
Total 21/24; docs_chunks a veces abarca de forma amplia temas de seguimiento/movimiento o pistas de API similares como evidencia directa |
| 9 | Lógica de velocidad de movimiento y rotación del enemigo | Diferencia de versión | La documentación de velocidad de movimiento y rotación coincide con el código según lo esperado | La documentación no relacionada también se descarta según lo esperado | 24/24 aprobado. El propósito y el comportamiento final de movimiento/rotación son relativamente claros, por lo que la documentación candidata se decide de forma estable |
| 10 | El jugador desaparece al salir de la pantalla | Sintaxis común | La salida de la pantalla, global_position, get_viewport_rect().size, la explicación de hide() se resume como Sí | Otras explicaciones de código se resumen como No | Sintaxis común 6/6 aprobada. La evidencia de la documentación y las candidatas de migración están bien separadas |
| 11 | Detección de colisión (Area2D o PhysicsBody) | Diferencia de versión | Se compara la documentación que describe eventos de colisión, objetivos de detección y la relación de callbacks/physics body con el fragmento de código | Se diferencia de las candidatas que explican la lógica posterior a la colisión, como cálculo de daño o manejo de salud | En sample-11 se verifica que la evidencia de “detección” de colisión no se mezcle con la evidencia de “procesamiento” posterior |
| 12 | Cálculo y aplicación de daño al colisionar | Sintaxis común | Se compara la documentación que explica el cálculo del daño y su aplicación a la salud del objetivo con el fragmento de código | Se diferencia de las candidatas que solo describen detección simple, actualización de puntuación o fin de juego | sample-12 verifica que el flujo de cálculo/aplicación de daño sea el núcleo de la evidencia documental, más que la colisión en sí |
| 13 | Lógica de reducción de salud del jugador | Sintaxis común | Se compara la documentación que describe la disminución de la variable de salud del jugador, el manejo del golpe y el límite inferior con el fragmento de código | Se diferencia de las candidatas que tratan la reducción de salud del enemigo o el aumento de puntuación | sample-13 debe distinguir si la cadena health se refiere al jugador o al enemigo |
| 14 | Cuando la salud del jugador llega a 0, manejo de fin de juego | Sintaxis común | Se compara la documentación que muestra health <= 0, la transición al estado de fin de juego y el flujo de cambio/pausa de escena con el fragmento de código | Se diferencia de las candidatas que solo describen reducción de salud o eliminación del enemigo | sample-14 verifica que, tras alcanzar 0, el estado resultante coincida con la evidencia documental |
| 15 | Lógica de reducción de salud del enemigo | Sintaxis común | Se compara la documentación que describe la disminución de la variable de salud del enemigo y el manejo del golpe con el fragmento de código | Se diferencia de las candidatas que tratan la reducción de salud del jugador o el fin de juego | sample-15 debe determinar si el objeto objetivo es enemy o player, lo cual es clave para la evaluación de la evidencia |
| 16 | Cuando la salud del enemigo llega a 0, eliminación y aumento de puntuación | Sintaxis común | Se compara la documentación que explica la eliminación del enemigo, queue_free()/desactivación y el aumento de puntuación con el fragmento de código | Se diferencia de las candidatas que solo describen reducción de salud o visualización de puntuación | sample-16 verifica que la acción final incluya tanto la eliminación como el incremento de puntuación |
| 17 | Actualización de la variable de puntuación (Score) | Sintaxis común | Se compara la documentación que muestra el incremento/disminución de la variable de puntuación y la actualización del valor acumulado con el fragmento de código | Se diferencia de las candidatas que solo actualizan la visualización del Label o el renderizado UI | sample-17 separa la actualización del dato de la actualización visual en pantalla |
| 18 | Función de actualización del texto de puntuación (Label) | Sintaxis común | Se compara la documentación que refleja la puntuación en pantalla mediante Label.text/formateo de cadena con el fragmento de código | Se diferencia de las candidatas que solo actualizan la variable de puntuación | sample-18 verifica que la evidencia se centre en la reflexión del UI, no solo en el valor de la variable |
| 19 | Reproducción de música de fondo (BGM) y ajuste de volumen | Sintaxis común | Se compara la documentación que describe el nodo de reproducción de BGM, el bus de volumen y el ajuste de bucle/volumen con el fragmento de código | Se diferencia de las candidatas que solo reproducen efectos de sonido puntuales | sample-19 separa la verificación de BGM continuo de la llamada a SFX breves |
| 20 | Función de reproducción de efectos de sonido (SFX) | Sintaxis común | Crear/llamar al reproductor de efectos de sonido, comparar la explicación de reproducción única con el fragmento de código | Distinción de candidatos de bucle/ajuste de volumen de música de fondo | sample-20 verifica que solo con palabras comunes relacionadas con Audio no se añada evidencia de BGM |
| 21 | Implementación del efecto de sacudida de pantalla (Screen Shake) | Diferencia de versión | Comparar con el fragmento de código la justificación que describe el desplazamiento de cámara, la intensidad/tiempo de sacudida, Tween o desplazamiento aleatorio | Distinguir de candidatos como movimiento de enemigos, seguimiento de cámara, animación UI | sample-21 verifica si, aunque la palabra “cámara” sea la misma, describe directamente el resultado de la sacudida de pantalla |
| 22 | Creación del sistema de partículas y coincidencia de posición | Diferencia de versión | Comparar con el fragmento de código la justificación que describe la creación del nodo de partícula, la sincronización de posición y el inicio de emisión | Distinguir de candidatos como creación de nodos genéricos, generación de proyectiles, animación | sample-22 verifica si el objetivo creado es una partícula y si incluye la lógica de coincidencia de posición y emisión |
| 23 | Función de cambio de escena (Scene Change) | Diferencia de versión | Comparar con el fragmento de código la justificación que describe la solicitud de cambio de escena, la llamada a SceneTree y la ruta de la escena objetivo | Distinguir de candidatos que solo muestran menús, pausa o carga de recursos sin cambiar de escena | sample-23 separa si la llamada realmente cambia la pantalla/escena o solo describe una carga o visualización de UI |
| 24 | Carga y visualización de la escena del menú principal | Diferencia de versión | Comparar con el fragmento de código la justificación que describe la carga y visualización de la escena del menú principal | Distinguir de candidatos como simple cambio de escena, pausa o precarga de recursos | sample-24 separa si el flujo muestra realmente la escena del menú o solo explica otro tipo de manejo de escenas |
| 25 | Alternar la función de pausa del juego (Pause) | Sintaxis común | Comparar con el fragmento de código la justificación que describe el toggle del estado de pausa, get_tree().paused y la explicación de pausa/reanudación según la entrada | Distinguir de candidatos como apertura de menú, cambio de escena, fin del juego | sample-25 verifica si cambia el estado de pausa o solo muestra una UI |
| 26 | Verificar el estado de entrada del teclado (Input.is_key_pressed) | Diferencia de versión | Comparar con el fragmento de código la justificación que describe Input.is_key_pressed y la comprobación de constantes/códigos de teclas | Distinguir de candidatos como entrada de mapa de acciones, entrada de ratón, lógica de movimiento | sample-26 separa la consulta del estado del teclado de la lógica completa de movimiento |
| 27 | Obtener coordenadas de la posición del ratón (cursor) | Sintaxis común | Comparar con el fragmento de código la justificación que describe la consulta de la posición del ratón en viewport/global | Distinguir de candidatos como disparo con clic, entrada táctil, visualización del cursor | sample-27 verifica si el código lee coordenadas y no solo maneja un evento de clic |
| 28 | Función de generación de número aleatorio | Diferencia de versión | Comparar con el fragmento de código la justificación que describe la inicialización del RNG, generación de número aleatorio y rango especificado | Distinguir de candidatos como distribución aleatoria de posición o temporizador de aparición de enemigos | sample-28 separa la función de generación de número de la lógica de juego que lo utiliza |
| 29 | Aparición de enemigos (Spawn) a intervalos de tiempo específicos | Diferencia de versión | Comparar con el fragmento de código la justificación que describe la generación periódica de enemigos basada en Timer/timeout o tiempo acumulado | Distinguir de candidatos como cálculo de posición aleatoria o IA de movimiento de enemigos | sample-29 verifica si el intervalo de tiempo y la llamada a spawn están directamente justificadas |
| 30 | Distribución aleatoria de la posición de los enemigos generados | Sintaxis común | Comparar con el fragmento de código la justificación que describe el rango de coordenadas aleatorias, área de spawn y distribución de posición | Distinguir de candidatos como temporizador que genera en intervalos fijos | sample-30 verifica si explica dónde se colocan los enemigos, no cuándo se generan |
| 31 | Cambio de estado de animación del jugador (Idle, Run, Jump) | Diferencia de versión | Comparar con el fragmento de código la justificación que describe el cambio del nombre de la animación según entrada, velocidad y estado | Distinguir de candidatos que solo controlan velocidad o tiempo de reproducción de la animación | sample-31 separa el cambio de estado de la gestión del tiempo de reproducción |
| 32 | Control del tiempo de reproducción de la animación | Sintaxis común | Comparar con el fragmento de código la justificación que describe control de velocidad, seek, advance y posición de reproducción | Distinguir de candidatos que cambian entre estados Idle/Run/Jump | sample-32 verifica si se controla el tiempo/velocidad de reproducción y no solo la selección de animación |
| 33 | Ajuste del tamaño del área de colisión | Diferencia de versión | Comparar con el fragmento de código la justificación que describe las propiedades de tamaño de CollisionShape2D/Shape2D y la serie size/extents de RectangleShape2D | Distinguir de candidatos como detección de colisión, procesamiento de daño, señal Area2D | sample-33 verifica si el código modifica la forma/tamaño del área de colisión y no solo detecta colisiones |
| 34 | Aplicación de gravedad física (Gravity) | Diferencia de versión | Comparar con el fragmento de código la justificación que describe la acumulación de gravedad y delta en la velocidad y su aplicación mediante la función de movimiento | Distinguir de candidatos como fuerza de salto, detección de aterrizaje, configuración de gravedad en Area | sample-34 separa el flujo de acumulación de gravedad de la lógica de salto/aterrizaje |
| 35 | Aplicación de fuerza de salto (Jump) y detección de aterrizaje | Diferencia de versión | Comparar con el fragmento de código la justificación que describe is_on_floor(), velocidad de salto, condiciones de entrada y estado de aterrizaje | Distinguir de candidatos que solo aplican gravedad o cambian el estado de animación | sample-35 verifica si la entrada de salto y la comprobación del suelo están dentro del mismo flujo de movimiento |
| 36 | Manejo del deslizamiento al colisionar con la pared (Slide) | | | | |
| 37 | Cambio de dirección del jugador (Facing Left/Right) | | | | |
| 38 | Disminución del recuento de munición (Ammo) | | | | |
| 39 | Transición al estado de recarga (Reload) cuando el cargador está vacío | | | | |
| 40 | Vinculación del evento de clic del botón UI | | | | |
| 41 | Alternar apertura/cierre del menú de Configuración (Settings) | | | | |
| 42 | Actualización de texto al cambiar el idioma (Language) | | | | |
| 43 | Serialización JSON de datos guardados (Save Game) | | | | |
| 44 | Deserialización JSON de datos cargados (Load Game) | | | | |
| 45 | Manejo de errores de lectura/escritura de archivos | | | | |
| 46 | Verificación del estado de conexión de red | | | | |
| 47 | Sincronización mediante llamada a función remota (RPC) | | | | |
| 48 | Carga dinámica de recursos de escena | | | | |
| 49 | Liberación de memoria y descarga de recursos | | | | |
| 50 | Salida de registro de depuración (print o print_debug) | | | | |
api_mapping
Verificar que la evidencia de cómo cambian los nombres, clases, funciones y símbolos de Godot 3 a Godot 4 coincida directamente con el fragmento de código.
| Número | Función | ¿Sintaxis común? | Resultado JSONL relacionado | Resultado JSONL no relacionado | Comentario |
|---|---|---|---|---|---|
| 1 | Inicialización de la función _ready() y configuración del tamaño del viewport |
Sintaxis común | Observación JSONL relacionada sí |
Observación JSONL no relacionada no |
El mapeo que incluye DisplayServer.window_set_size, Vector2i se juzga como sí; el mapeo de AudioServer.get_bus_volume_db se juzga como no |
| 2 | Bucle de actualización por fotograma _process(delta) |
Sintaxis común | Observación JSONL relacionada sí |
Observación JSONL no relacionada no |
El mapeo estable que contiene position.x, delta, _process se juzga como sí; el mapeo de get_node("Sprite2D") se juzga como no |
| 3 | Procesamiento de entrada de movimiento del jugador (WASD o teclas de flecha) | Sintaxis común | Observación JSONL relacionada sí |
Observación JSONL no relacionada no |
El mapeo que incluye CharacterBody2D.move_and_slide, velocity, Vector2 se juzga como sí; el mapeo de Node.connect/conexión de señal se juzga como no |
| 4 | Aplicación de velocidad y aceleración al movimiento del jugador | Diferencia de versión | El registro bidireccional existente sí se excluye de la decisión final |
En la inspección de Godot 3, el lado de api_mapping se divide en sí/no |
Se necesita revisar cómo reaccionan los mapeos de move_and_slide, CharacterBody3D, move_toward, velocity.x, velocity.z, target_velocity según la versión del código |
| 5 | Límite de velocidad máxima del jugador | Diferencia de versión | Observación inicial basada en Godot 3. Respuesta cruda inversa basada en Godot 4: código Godot 4 sí/sí, código Godot 3 no/no |
En el código Godot 4 ambos candidatos de mapeo son sí; en el código Godot 3 ambos son no |
Basado en diferencias de retorno de colisión normal, move_and_slide, velocity, limit_speed. Se requiere análisis de patrones para decidir cómo dividir los valores esperados entre la sintaxis de Godot 4 y Godot 3 |
| 6 | Creación y disparo de proyectil al hacer clic del ratón | Diferencia de versión | Las diferencias de API de creación de proyectiles entre Godot 3/4 y el procesamiento de entrada coinciden como se esperaba | Los candidatos de mapeo no relacionados también se descartan | Al igual que PackedScene.instance() vs instantiate(), la forma source/target está separada e incluida en el flujo de paso 24/24 |
| 7 | Gestión del movimiento y vida útil (time‑to‑live) del proyectil | Diferencia de versión | En Godot 3, el mapeo de conversión se marca como sí |
El mismo mapeo aparece como sí también en el código Godot 4, observándose una inconsistencia |
Total 22/24; si ya es código Godot 4, no debería aplicarse la conversión, por lo que la indicación de origen debe revisarse con mayor claridad en el prompt de verificación |
| 8 | Lógica de IA de seguimiento del jugador por parte del enemigo (Enemy) | Diferencia de versión | La discrepancia 8 no fue la causa directa en el lado de api_mapping | Los candidatos de mapeo no relacionados se descartan según lo esperado | La discrepancia total proviene de docs_chunks. El mapeo sirve como eje auxiliar para verificar cambios de API de IA por versión |
| 9 | Lógica de velocidad y rotación del enemigo | Diferencia de versión | Los mapeos de rotación/movimiento coinciden con el código | Los candidatos de mapeo no relacionados también se descartan | Paso 24/24. Las diferencias de API de velocidad y rotación están relativamente bien separadas |
| 10 | Desaparición del jugador al salir de la pantalla | Sintaxis común | Al ser código común, no se requiere transformación en los JSONL de api_mapping | Los candidatos de transformación no relacionados también son no |
Paso 6/6. En sintaxis común no se adjunta una tabla de migración |
| 11 | Detección de colisiones (Area2D o PhysicsBody) | Diferencia de versión | Verificar si la API de detección de colisiones Area2D/PhysicsBody o los cambios en la conexión de señales son necesarios en el código actual | Diferenciar de los mapeos de aplicación de daño o manejo de vida | sample-11 separa la evaluación del API de detección y la lógica posterior |
| 12 | Cálculo y aplicación de daño al colisionar | Sintaxis común | Verificar si los cambios de API por versión en la aplicación de daño están presentes en el código | Diferenciar de los mapeos que solo describen la señal de detección de colisión | sample-12 distingue si el mapeo es necesario por un cambio real o solo una explicación de lógica de juego |
| 13 | Lógica de reducción de vida del jugador | Sintaxis común | Verificar si el código de reducción de vida del jugador necesita justificación de cambios de API por versión | Diferenciar de los mapeos de vida del enemigo/puntuación/fin del juego | sample-13 observa si la lógica de juego, mayormente, está sobre‑justificada con motivos de migración |
| 14 | Manejo de Game Over cuando la vida del jugador llega a 0 | Sintaxis común | Verificar si los cambios en la API de cambio de escena, pausa o árbol están presentes en el código de Game Over | Diferenciar de los mapeos simples de reducción de vida | sample-14 confirma si la API de transición de estado es la base del mapeo |
| 15 | Lógica de reducción de vida del enemigo | Sintaxis común | Verificar si el código de reducción de vida del enemigo realmente necesita justificación de cambios de API Godot 3→4 | Diferenciar de los mapeos de manejo de vida del jugador o puntuación | sample-15 debe caer en no cuando el objeto objetivo difiere, aun si se encuentra un candidato de mapeo |
| 16 | Eliminación del enemigo al llegar a 0 vida y aumento de puntuación | Sintaxis común | Verificar si las APIs de eliminación, actualización de puntuación y manipulación del árbol de escenas están presentes en el código | Diferenciar de los mapeos simples de daño o actualización de Label | sample-16 separa qué parte (eliminación vs. incremento de puntuación) constituye la base del mapeo |
| 17 | Actualización de la variable de puntuación (Score) | Sintaxis común | Verificar si la actualización de la variable de puntuación necesita una justificación de cambio de API | Diferenciar de los mapeos de actualización de UI o guardado/carga | sample-17 asegura que operaciones simples de variable no se sobre‑evalúen como motivos de migración |
| 18 | Función de actualización del texto del puntaje (Label) | Sintaxis común | Verificar si el modo de acceso al texto del Label o la forma de referenciar nodos cambian en el código actual | Diferenciar de los mapeos de cálculo del valor de puntuación | sample-18 comprueba si expresiones tipo Label.text son comunes o presentan variaciones por versión |
| 19 | Reproducción de música de fondo (BGM) y ajuste de volumen | Sintaxis común | Verificar si los cambios en AudioServer, AudioStreamPlayer o el bus de volumen son realmente necesarios en el código | Diferenciar de los mapeos de reproducción puntual de SFX | sample-19 evita que palabras genéricas de audio activen mapeos innecesarios |
| 20 | Función de reproducción de efectos de sonido (SFX) | Sintaxis común | Verificar si la API de reproducción de SFX o la forma de crear nodos cambia en el código | Diferenciar de los mapeos de bucle/volumen de BGM | sample-20 separa los motivos de migración entre SFX y BGM aunque compartan la misma familia de audio |
| 21 | Implementación del efecto de sacudida de pantalla (Screen Shake) | Diferencia de versión | Verificar si hay cambios de API por versión en Tween, Camera2D, offset o sacudida aleatoria | Diferenciar de los mapeos de seguimiento de cámara o movimiento genérico | sample-21 valida si los candidatos relacionados con la cámara son la base del motivo de conversión para la sacudida de pantalla |
| 22 | Creación del sistema de partículas y coincidencia de posición | Diferencia de versión | Verificar si los cambios relacionados con Particles2D/GPUParticles2D, emitting, position/global_position están directamente en el código | Diferenciar la generación de proyectiles del mapeo de creación de nodos genéricos | sample-22 separa los cambios de la API exclusiva del sistema de partículas del flujo de generación genérico |
| 23 | Función de cambio de escena (Scene Change) | Diferencia de versión | Verificar si los cambios de la familia change_scene, change_scene_to_file, change_scene_to_packed están directamente en el código actual | Diferenciar el mapeo de load()/preload() simple o la visualización del menú principal | sample-23 comprueba si las llamadas de cambio de escena de Godot 3 y las sustitutas de Godot 4 se aplican al código según la versión |
| 24 | Carga y visualización de la escena del menú principal | Diferencia de versión | Verificar si los cambios de carga de escena, instanciación y visualización del menú están necesarios en el código actual | Diferenciar el mapeo de cambio de escena genérico o preload de recursos | sample-24 revisa que el propósito de mostrar el menú principal no se mezcle con los cambios de la API de escena |
| 25 | Alternar la función de pausa del juego (Pause) | Sintaxis común | Verificar si los cambios de pause mode/process mode y tree pause son realmente necesarios en el código actual | Diferenciar el mapeo de UI del menú o de game over | sample-25 comprueba que el código común de pausa no tenga mapeos de migración excesivos |
| 26 | Verificar el estado de entrada del teclado (Input.is_key_pressed) | Diferencia de versión | Verificar si los cambios de constantes de tecla, scancode/keycode y Input.is_key_pressed coinciden directamente con el código | Diferenciar el mapeo de movimiento de action map o entrada de ratón | sample-26 separa los cambios de la API de consulta de estado de tecla de la lógica de juego que usa la entrada |
| 27 | Obtener coordenadas de la posición del ratón (cursor) | Sintaxis común | Verificar si la API de consulta de posición del ratón requiere referencias a cambios por versión | Diferenciar el mapeo de creación de proyectiles al hacer clic o entrada táctil | sample-27 asegura que el código de lectura de coordenadas no tenga referencias de conversión innecesarias |
| 28 | Función de generación de número aleatorio | Diferencia de versión | Verificar si los cambios de randomize, RandomNumberGenerator y la función range están directamente en el código | Diferenciar el mapeo de posición de spawn aleatoria o temporizador de spawn | sample-28 separa los cambios de la API de números aleatorios del propósito de uso del número aleatorio |
| 29 | Spawn de enemigos a intervalos regulares | Diferencia de versión | Verificar si los cambios de señal Timer, conexión timeout, y la familia yield/await están directamente en el código | Diferenciar el mapeo de distribución aleatoria de posición de enemigos o movimiento AI de enemigos | sample-29 revisa la estructura de ejecución periódica junto con la lógica del objetivo de generación |
| 30 | Distribución aleatoria de la posición de enemigos generados | Sintaxis común | Verificar si los cambios reales de API para random range, tamaño del viewport y cálculo del área de spawn son necesarios | Diferenciar el mapeo de spawn basado en temporizador periódico | sample-30 asegura que el código que solo calcula posiciones no tenga mapeos de ciclo de spawn innecesarios |
| 31 | Transición del estado de animación del jugador (Idle, Run, Jump) | Diferencia de versión | Verificar si los cambios de AnimatedSprite/AnimatedSprite2D y AnimationPlayer para la transición de estados coinciden directamente con el código | Diferenciar el mapeo de velocidad de reproducción/seek/control de tiempo | sample-31 separa los cambios de nombres de nodos de animación y los patrones de transición de estado |
| 32 | Control del tiempo de reproducción de la animación | Sintaxis común | Verificar si los cambios de velocidad de reproducción, seek y posición actual son necesarios en el código actual | Diferenciar el mapeo de selección de estado Idle/Run/Jump | sample-32 distingue la API de control del tiempo de reproducción de la API de transición de estado |
| 33 | Ajuste del tamaño del área de colisión | Diferencia de versión | Verificar si los cambios de CollisionShape2D, RectangleShape2D y tamaño/extents de la forma son directamente necesarios en el código | Diferenciar el mapeo de señal de colisión, capa física, daño | sample-33 revisa que no sea la API de detección de colisión sino el cambio de la API de ajuste de tamaño de la forma lo que coincida con el código |
| 34 | Aplicación de gravedad física (Gravity) | Diferencia de versión | Verificar si los cambios de CharacterBody2D/KinematicBody2D, velocidad, y la familia move_and_slide son directamente necesarios en el código | Diferenciar el impulso de salto, verificación de suelo, mapeo de gravedad de Area2D | sample-34 comprueba si la gravedad se acumula en el marco físico y se refleja en el movimiento según el mapeo |
| 35 | Aplicación de fuerza de salto (Jump) y detección de aterrizaje | Diferencia de versión | Verificar si los cambios de is_on_floor(), velocidad de salto, acción Input y move_and_slide coinciden directamente con el código | Diferenciar el movimiento solo con gravedad, estado de animación, mapeo de colisión con paredes | sample-35 revisa si las condiciones de inicio de salto y la detección de aterrizaje requieren el mismo mapeo |
| 36 | Manejo del deslizamiento al colisionar con paredes (Slide) | | | | |
| 37 | Cambio de dirección del jugador (Facing Left/Right) | | | | |
| 38 | Reducción del contador de munición (Ammo) | | | | |
| 39 | Transición al estado de recarga (Reload) cuando el cargador está vacío | | | | |
| 40 | Conexión del evento de clic del botón UI | | | | |
| 41 | Alternar apertura/cierre del menú de Configuración (Settings) | | | | |
| 42 | Actualizar texto al cambiar el idioma (Language) | | | | |
| 43 | Serialización JSON de datos guardados (Save Game) | | | | |
| 44 | Deserialización JSON de datos cargados (Load Game) | | | | |
| 45 | Manejo de errores de lectura/escritura de archivos | | | | |
| 46 | Verificación del estado de conexión de red | | | | |
| 47 | Sincronización mediante llamada a función remota (RPC) | | | | |
| 48 | Carga dinámica de recursos de escena | | | | |
| 49 | Liberación de memoria y descarga de recursos | | | | |
| 50 | Salida de registro de depuración (print o print_debug) | | | | |
label_prototypes
Verifique si la evidencia del ejemplo, que no es solo un cambio de nombre simple sino que implica un cambio completo en la forma de usar la función, la composición de los argumentos y el patrón de llamada, coincide directamente con el fragmento de código.
| número | función | ¿es sintaxis común? | resultado JSONL relacionado | resultado JSONL no relacionado | notas |
|---|---|---|---|---|---|
| 1 | Inicialización de la función _ready() y configuración del tamaño del viewport |
sintaxis común | observación JSONL relacionado sí |
observación JSONL no relacionado no |
el prototipo DisplayServer.window_set_size(Vector2i(1920, 1080)) se juzga como sí; el prototipo AudioStreamPlayer3D se juzga como no |
| 2 | Bucle de actualización por fotograma _process(delta) |
sintaxis común | observación JSONL relacionado sí |
observación JSONL no relacionado no |
el prototipo func _process(delta) y position.x += move_speed * delta se juzga como sí; el prototipo _input(event)/event.is_action_pressed se juzga como no |
| 3 | Procesamiento de entrada de movimiento del jugador (WASD o teclas de flecha) | sintaxis común | observación JSONL relacionado sí |
observación JSONL no relacionado no |
el prototipo Input.is_action_pressed, velocity = direction * move_speed, move_and_slide() se juzga como sí; el prototipo @onready/acceso a ruta de nodo se juzga como no |
| 4 | Aplicación de velocidad y aceleración del jugador | diferencia de versión | el registro bidireccional existente sí se excluye de la decisión final |
en la inspección de Godot 3, la parte de label_prototypes se divide en sí/no |
se necesita revisar si los prototipos por eje move_toward(velocity.x/velocity.z), move_and_slide(), CharacterBody3D son evidencia exclusiva de versión o evidencia de cadena común |
| 5 | Límite de velocidad máxima del jugador | diferencia de versión | observación inicial basada en Godot 3. Respuesta inversa cruda basada en Godot 4: código Godot 4 sí/no, código Godot 3 sí/no |
el prototipo Tween se descarta como no en ambos lados |
CharacterBody2D, move_and_slide(), velocity aparecen en ambos códigos, por lo que el prototipo relacionado se marca como sí en ambos. Es necesario separar la evidencia exclusiva de versión de la evidencia de cadena común |
| 6 | Creación y disparo de proyectil al hacer clic del ratón | diferencia de versión | el patrón de prototipo de creación/disparo de proyectil coincide con el código | los candidatos a prototipo no relacionados también se descartan | incluido en el flujo de paso 24/24. El procesamiento de entrada y el patrón de creación del proyectil están bien separados |
| 7 | Gestión del movimiento y vida útil (time‑to‑live) del proyectil | diferencia de versión | en Godot 3, el prototipo de conversión se marca como sí |
el mismo prototipo aparece como sí también en el código de Godot 4, observándose una inconsistencia |
total 22/24; no debe aplicarse un prototipo “necesita conversión” al código de Godot 4 ya convertido |
| 8 | Lógica de IA de seguimiento del jugador por parte del enemigo (Enemy) | diferencia de versión | la parte de label_prototypes no fue la causa directa de la discrepancia en el ítem 8 | los candidatos a prototipo no relacionados se descartan como se esperaba | la discrepancia total ocurre en docs_chunks. El prototipo se registra como eje auxiliar para observar cambios en el modo de uso del AI de seguimiento |
| 9 | Lógica de velocidad y rotación del enemigo | diferencia de versión | el patrón de llamadas de movimiento/rotación coincide con el código | los candidatos a prototipo no relacionados se descartan como se esperaba | 24/24 aprobado. El cálculo de velocidad de movimiento y el patrón de aplicación de rotación están relativamente bien separados |
| 10 | El jugador desaparece al salir de la pantalla | sintaxis común | al ser código común, los JSONL de label_prototypes no requieren conversión | los candidatos a conversión no relacionados también siguen el flujo no |
6/6 aprobado. En sintaxis común, se confirma que el prototipo no se adjunta innecesariamente |
| 11 | Detección de colisión (Area2D o PhysicsBody) | diferencia de versión | verificar si el uso de señal/callback de detección de colisión corresponde al patrón previo al cambio de código | distinguir del prototipo de aplicación de daño después de la colisión | sample-11 separa el patrón de evento de detección y el patrón de procesamiento de gameplay posterior |
| 12 | Cálculo y aplicación de daño al colisionar | sintaxis común | confirmar si el patrón de llamada que aplica daño tras la colisión está presente directamente en el código actual | distinguir del prototipo de detección simple o de eliminación al llegar a 0 de vida | sample-12 verifica si la composición de argumentos, el objeto objetivo y el orden de aplicación del daño son evidencia del prototipo |
| 13 | Lógica de reducción de vida del jugador | sintaxis común | confirmar si el patrón de golpe/reducción de vida del jugador está presente directamente en el código actual | distinguir del prototipo de reducción de vida del enemigo | sample-13 verifica diferencias de objetivo (player vs enemy) aunque pertenezcan a la misma familia de health |
| 14 | Cuando la vida del jugador llega a 0, manejar Game Over | sintaxis común | confirmar si el patrón de llamada a Game Over después de vida 0 está presente directamente en el código actual | distinguir del prototipo de simple reducción de vida o eliminación de enemigo | sample-14 verifica si después de la condición se describe el cambio de estado y la carga de la escena como prototipo |
| 15 | Lógica de reducción de vida del enemigo | sintaxis común | confirmar si el patrón de daño/reducción de health del enemigo está presente directamente en el código actual | distinguir del prototipo de daño al jugador | sample-15 examina si aparecen falsos positivos cuando los nombres de variables y estados se solapan ampliamente |
| 16 | Cuando la vida del enemigo llega a 0, eliminarlo y añadir puntuación | sintaxis común | confirmar si el patrón que combina eliminación del enemigo y aumento de puntuación está presente directamente en el código actual | distinguir del prototipo de simple actualización de puntuación o eliminación aislada | sample-16 verifica que el prototipo que agrupa varias acciones coincida con el orden real en el SOURCE_CODE |
| 17 | Actualización de la variable de puntuación (Score) | sintaxis común | confirmar si el patrón de actualización de la variable score está presente directamente en el código actual | distinguir del prototipo que solo refleja el texto del Label | sample-17 separa la actualización de datos internos de la actualización de la visualización UI |
| 18 | Función de actualización del texto del Label de puntuación | sintaxis común | confirmar si el patrón de actualización del texto del Label está presente directamente en el código actual | distinguir del prototipo que solo cambia la variable score | sample-18 verifica si el prototipo describe la actualización de la visualización en pantalla, no solo el cambio de valor |
| 19 | Reproducción y control de volumen de la música de fondo (BGM) | sintaxis común | confirmar si el patrón de reproducción/ajuste de volumen del BGM está presente directamente en el código actual | distinguir del prototipo de reproducción puntual de SFX | sample-19 debe enfocarse en la reproducción continua y control de volumen, más que en palabras genéricas de audio |
| 20 | Función de reproducción de efectos de sonido (SFX) | sintaxis común | confirmar si el patrón de llamada/reproducción de SFX está presente directamente en el código actual | distinguir del prototipo de bucle de BGM o control de bus de volumen | sample-20 separa la reproducción breve de efectos del flujo de gestión del BGM |
| 21 | Implementación del efecto de sacudida de pantalla (Screen Shake) | diferencia de versión | confirmar si el patrón de aplicación de intensidad/tiempo/offset de sacudida está presente directamente en el código actual | distinguir del prototipo de seguimiento de cámara o Tween genérico | sample-21 verifica que, aun con Camera2D/Tween presente, el efecto final sea realmente un shake |
| 22 | Creación del sistema de partículas y alineación de posición | diferencia de versión | confirmar si el patrón de creación de partículas, alineación de posición e inicio de emisión está presente directamente en el código actual | distinguir del prototipo de creación de proyectil o nodo genérico | sample-22 verifica que el prototipo cubra la sincronización de posición y el inicio de emisión |
| 23 | Función de cambio de escena (Scene Change) | Diferencia de versión | Verificar si el patrón de llamada que recibe la ruta de la escena y la cambia al SceneTree está presente directamente en el código actual | Distinguir de prototipos de carga simple de recursos, apertura de menú, pausa | sample-23 verifica si el prototipo describe la ruta de entrada del cambio de escena, el objetivo de la llamada y el resultado del cambio |
| 24 | Carga y visualización de la escena del menú principal | Diferencia de versión | Verificar si el patrón de llamada que carga y muestra la escena del menú está presente directamente en el código actual | Distinguir de prototipos de carga simple de recursos, cambio de escena, menú de pausa | sample-24 verifica si el prototipo describe el resultado “mostrar el menú principal” |
| 25 | Alternar la función de pausa del juego | Sintaxis común | Verificar si el patrón que invierte el estado de pausa y agrupa el manejo de UI/entrada está presente directamente en el código actual | Distinguir de prototipos de apertura del menú de configuración o de fin de juego | sample-25 verifica si el cambio de la bandera de pausa y la visualización en pantalla deben considerarse en el mismo flujo |
| 26 | Verificar el estado de entrada del teclado (Input.is_key_pressed) | Diferencia de versión | Verificar si el patrón que hace polling directo del estado de la tecla está presente en el código actual | Distinguir de prototipos de fuerza de acción, vector de movimiento, entrada de ratón | sample-26 registra la consulta de entrada separada de la acción que se ejecuta con esa entrada |
| 27 | Obtener coordenadas de la posición del ratón (cursor) | Sintaxis común | Verificar si el patrón que lee la posición del cursor y la usa en variables o cálculos de posición está presente directamente en el código actual | Distinguir de prototipos de eventos de clic del ratón o creación de proyectiles | sample-27 verifica si la propia consulta de la posición del ratón es el núcleo |
| 28 | Función de generación de número aleatorio | Diferencia de versión | Verificar si el patrón de llamada que genera números aleatorios y especifica rangos está presente directamente en el código actual | Distinguir de prototipos de distribución de posición de spawn, tabla de drop, temporizador de spawn | sample-28 separa la llamada a la API random del uso del resultado random |
| 29 | Spawn de enemigos a intervalos de tiempo específicos | Diferencia de versión | Verificar si el patrón que llama a la función de spawn cada cierto tiempo está presente directamente en el código actual | Distinguir de prototipos de cálculo de posición aleatoria o IA de seguimiento de enemigos | sample-29 verifica que la condición de tiempo, el temporizador y el orden de llamada al spawn sean correctos |
| 30 | Distribución aleatoria de la posición de enemigos spawnados | Sintaxis común | Verificar si el patrón que coloca la posición de los enemigos generados dentro de un rango aleatorio está presente directamente en el código actual | Distinguir de prototipos de bucle de spawn que genera enemigos a intervalos regulares | sample-30 separa el cálculo de distribución/coordenadas del ciclo de generación |
| 31 | Cambio de estado de animación del jugador (Idle, Run, Jump) | Diferencia de versión | Verificar si el patrón que cambia el nombre de la animación según el valor de estado o velocidad está presente directamente en el código actual | Distinguir de prototipos de velocidad de reproducción, seek, control de frame/tiempo | sample-31 verifica que el núcleo sea a qué estado se cambia |
| 32 | Control del tiempo de reproducción de la animación | Sintaxis común | Verificar si el patrón que controla velocidad de reproducción, seek y posición actual de reproducción está presente directamente en el código actual | Distinguir de prototipos de cambio de estado Idle/Run/Jump | sample-32 verifica que el núcleo sea el control del tiempo de reproducción, no la selección de animación |
| 33 | Ajuste del tamaño del área de colisión | Diferencia de versión | Verificar si el patrón que lee o modifica el valor de tamaño del shape de colisión está presente directamente en el código actual | Distinguir de prototipos de manejo de eventos de colisión o aplicación de daño | sample-33 separa si el cambio de tamaño del shape es el núcleo o el procesamiento del resultado de colisión |
| 34 | Aplicación de gravedad física (Gravity) | Diferencia de versión | Verificar si el patrón que acumula gravedad basada en delta en la velocidad y la refleja en la llamada de movimiento está presente directamente en el código actual | Distinguir de prototipos de entrada de salto, detección de aterrizaje, spawn/temporizador | sample-34 verifica que la acumulación de gravedad dentro del bucle de movimiento físico sea el núcleo |
| 35 | Aplicación de fuerza de salto y detección de aterrizaje | Diferencia de versión | Verificar si el patrón que aplica fuerza de salto cuando está en el suelo y luego verifica el aterrizaje está presente directamente en el código actual | Distinguir de prototipos que solo acumulan gravedad en movimiento o solo cambian el estado de animación | sample-35 verifica que la condición de salto, el cambio de velocidad vertical y la evaluación del suelo estén agrupados en un mismo flujo |
| 36 | Manejo del deslizamiento al colisionar con paredes (Slide) | | | | |
| 37 | Cambio de dirección del jugador (Facing Left/Right) | | | | |
| 38 | Reducción del contador de munición (Ammo) | | | | |
| 39 | Cambio al estado de recarga (Reload) cuando el cargador está vacío | | | | |
| 40 | Conexión del evento de clic del botón UI | | | | |
| 41 | Alternar apertura/cierre del menú de Configuración (Settings) | | | | |
| 42 | Actualizar texto al cambiar el idioma (Language) | | | | |
| 43 | Serialización JSON de datos guardados (Save Game) | | | | |
| 44 | Deserialización JSON de datos cargados (Load Game) | | | | |
| 45 | Manejo de errores de lectura/escritura de archivos | | | | |
| 46 | Verificación del estado de conexión de red | | | | |
| 47 | Sincronización mediante llamada a función remota (RPC) | | | | |
| 48 | Carga dinámica de recursos de escena | | | | |
| 49 | Liberación de memoria y descarga de recursos | | | | |
| 50 | Salida de registro de depuración (print o print_debug) | | | | |
Registro adicional del 6 de julio de 2026
Los números del 6 al 10 ya fueron incorporados el 3 de julio de 2026 con el flujo de mejora y se dejó una observación detallada. Por eso, en este documento no dejamos en blanco los ítems 6‑10, sino que añadimos el contenido de la observación existente en las tablas docs_chunks, api_mapping y label_prototypes correspondiente a cada uno.
El 6 de julio de 2026, con base en http://localhost:8520/#item=sample-22, se registraron los ítems del 11 al 22. En este rango se describe, por cada elemento, qué candidato de evidencia corresponde a qué JSONL y qué candidato debe descartarse como otro código/otra transformación/otro patrón.
Registro adicional del 8 de julio de 2026
El 8 de julio de 2026, con base en http://localhost:8520/#item=sample-32, se continuó a partir del ítem 23 hasta el 32. Este tramo también se considera más como una tabla de observación que indica cómo docs_chunks, api_mapping y label_prototypes deben explicar o rechazar el mismo fragmento de código desde distintas perspectivas, más que como una tabla de decisiones definitivas.
Registro adicional del 13 de julio de 2026
El 13 de julio de 2026, con base en http://localhost:8520/#item=sample-35, se registraron los ítems del 33 al 35. Este segmento trata de áreas donde el tamaño de colisión, la gravedad y los movimientos de salto/aterrizaje influyen mutuamente, por lo que es necesario considerar no solo la superposición de cadenas, sino también el propósito del código y su ubicación de aplicación.
Observación inversa del ítem 5
El ítem 5 está incluido en la cantidad objetivo de hoy, pero al inspeccionarlo a la inversa como JSONL según Godot 4, los resultados no se redujeron a pares limpios de sí/no. Por lo tanto, no se decide su confirmación y se deja para el análisis de patrones en la siguiente fase.
El orden de respuesta es docs_chunks #1, docs_chunks #2, api_mapping #1, api_mapping #2, label_prototypes #1, label_prototypes #2.
| Código de inspección | Orden de respuesta | Observación |
|---|---|---|
| Código Godot 4 | sí, sí, sí, sí, sí, no |
Hay muchas cadenas que coinciden directamente con el código, como limit_speed, velocity, move_and_slide(), Input.is_action_pressed, por lo que los candidatos en docs/api se marcan ampliamente como sí. |
| Código Godot 3 | sí, sí, no, no, sí, no |
Los candidatos de docs y el prototipo CharacterBody2D se marcan como sí, pero los candidatos de api_mapping según Godot 4 se marcan como no. |
Este resultado se interpreta más como una señal de que los campos match_terms, required_when_seen_in_code y content dentro del JSONL pueden ser demasiado amplios, en lugar de simplemente un error del modelo. En particular, cadenas comunes como move_and_slide() e Input.is_action_pressed sirven como evidencia directa, pero pueden ser demasiado generales para justificar límites de velocidad o diferencias de versión.
Registro de casos de discrepancia
Falso positivo
Casos en los que la respuesta correcta es no pero se obtuvo sí.
| ID | Función | ¿Sintaxis común? | Tabla | Resumen del JSONL incorrecto | Respuesta de Qwen | Motivo de revisión |
|---|---|---|---|---|---|---|
Falso negativo
Casos en los que la respuesta correcta es sí pero se obtuvo no.
| ID | Función | ¿Sintaxis común? | Tabla | Resumen del JSONL correcto | Respuesta de Qwen | Motivo de revisión |
|---|---|---|---|---|---|---|
Violación del formato de respuesta
Casos en los que, en lugar de sí o no, se respondió con una explicación, JSON, respuesta vacía o varias oraciones.
| ID | Función | ¿Sintaxis común? | Tabla | Respuesta esperada | Respuesta real | Nota |
|---|---|---|---|---|---|---|
Resumen de observaciones
Durante las pruebas se completan los números y respuestas crudas a continuación. Aquí no se fija una decisión definitiva, solo se observa cómo varían las respuestas según los criterios.
| Ítem | docs_chunks | api_mapping | label_prototypes | Total |
|---|---|---|---|---|
| Observaciones de hoy | Registro adicional 23‑32 | Registro adicional 23‑32 | Registro adicional 23‑32 | Registro adicional 23‑32 (según 2026‑07‑08) |
| Observaciones totales | 32/50 registros de prueba | 32/50 registros de prueba | 32/50 registros de prueba | 32/50 registros de prueba |
| Número de fragmentos de código probados | 32/50 | 32/50 | 32/50 | 32/50 |
| Muestras de sintaxis común | Cálculo acumulado pendiente | Cálculo acumulado pendiente | Cálculo acumulado pendiente | Necesario recuento separado después de registrar etiquetas hasta el ítem 32 |
| Muestras de diferencias de versión | Cálculo acumulado pendiente | Cálculo acumulado pendiente | Cálculo acumulado pendiente | Necesario recuento separado después de registrar etiquetas hasta el ítem 32 |
| Coincidencias esperadas en la primera ronda | 5 | 5 | 5 | 15 |
| No coincidencias esperadas en la primera ronda | 0 | 0 | 0 | 0 |
| Respuestas crudas inversas del ítem 5 (Godot 4) | Godot 4 sí/sí, Godot 3 sí/sí |
Godot 4 sí/sí, Godot 3 no/no |
Godot 4 sí/no, Godot 3 sí/no |
Se requiere análisis de patrones |
| Violaciones de formato de respuesta | 0 | 0 | 0 | 0 |
| Necesita revisión | 2 | 2 | 2 | Necesaria redefinición para los ítems 4/5 |
| Juicio actual | Decisión definitiva en suspenso | Decisión definitiva en suspenso | Decisión definitiva en suspenso | Se necesita análisis de patrones posterior, incluyendo el registro adicional 23‑32 |