# El Sistema de Evidencia — QA Honesto para Juegos con IA

> El sistema de evidencia que usamos para mantener honesto el desarrollo de juegos con IA: grabaciones de ejecución, capturas de mismo estado, auditorías ligadas al código y puertas de aceptación.

Source: https://toolpantry.app/es/gamedev/evidence-system-game-qa

## About

Los agentes de IA construyen rápido — y también pueden decir "listo" cuando una función apenas compila. Este es el sistema de verificación que ejecutamos para atar cada afirmación de nuestros juegos a algo que puedes ver: grabaciones de la compilación real, capturas de mismo estado antes/después, y auditorías ligadas a revisiones exactas del código.

## Quick answer

Por qué existe esto: en el desarrollo con agentes, la frase más barata es "funciona". El sistema de evidencia la vuelve cara: cada función aceptada debe publicarse con una grabación de ejecución, una comparación de mismo estado y una auditoría ligada al código — o se queda en la columna de "no probado" del tablero de estado.

## El modo de fallo que esto arregla

Así se pudre en silencio el desarrollo de juegos con IA: un agente implementa una función, ejecuta las pruebas que él mismo escribió, declara éxito y sigue. Tres días después el sistema de guardado se rompe en un camino que nadie grabó. El código parecía correcto. Las pruebas pasaron. La afirmación nunca fue verdad — solo no había sido falsada.

Nuestra respuesta toma prestado del QA industrial en lugar del unit testing: **la unidad de verificación es una grabación del juego en ejecución, no una marca verde.**

## Regla 1: ninguna afirmación sin evidencia de ejecución

Cada función que cuenta como terminada deja atrás una captura en tiempo real — una grabación sin cortes de una compilación real, recorriendo exactamente el camino que la función dice soportar. No una captura de un buen día; la interacción completa. Cuando decimos "el bucle de decisión de despacho funciona en un teléfono de 844×390", hay un video de 20 segundos donde puedes verlo: las unidades salen, la producción se pausa, las recompensas esperan en el gremio.

Esta sola regla cambia el comportamiento de los agentes más que cualquier prompt: un agente que sabe que debe producir una grabación visible deja de recortar esquinas que habrías descubierto una semana después.

## Regla 2: capturas antes/después de mismo estado

Para cambios de interfaz y comportamiento, las capturas antes/después deben tomarse del *mismo estado* — mismo guardado, misma pantalla, mismo viewport — o no prueban nada. "Ahora se ve mejor" no significa nada si la foto de antes era partida nueva y la de después a mitad de progreso.

| Lo que atrapan las capturas de mismo estado | Lo que las capturas sueltas pierden |
|---|---|
| Deriva de diseño en otros tamaños de viewport | Todo lo que queda fuera de la única captura |
| Renderizado dependiente del estado (bloqueado/disponible/agotado) | Solo el estado "camino feliz" |
| Regresiones en interfaz adyacente que comparte el componente | Todo lo que el autor no estaba mirando |

En la práctica: congela el estado, captura cada tamaño de teléfono (320 → 430px, más modo de letra grande), cambia, y vuelve a capturar. La revisión del diff es mecánica — que es exactamente por qué funciona a escala de agentes.

## Regla 3: auditorías ligadas al código

Evidencia sin revisión es un rumor. Cada lote aceptado recibe una auditoría que ata sus grabaciones y capturas a una revisión exacta del código — un hash, un commit, un manifiesto. Si el código se mueve después, la evidencia vieja no lo bendice en silencio; el lote se re-verifica o la afirmación se retira. Esto también es lo que hace posible el traspaso: un revisor puede comprobar que la compilación que mira es demostrablemente el código que produjo la evidencia.

## El ciclo de vida del contenido (de nuestra propia tubería)

Cada pieza de contenido — evento, función, recurso — pasa por estados explícitos, y nada se salta un paso:

| Estado | Significado |
|---|---|
| drafted | Escrito/generado |
| validated | Referencias y números verificados |
| integrated | Carga en el runtime |
| rendered | Aparece en una pasada de render real con aserciones de diseño |
| runtime-seen | Alcanzado por la entrada normal del jugador y renderizado |
| manually-played | Un humano recorrió las ramas principales |
| accepted | Pasó la puerta de calidad del capítulo |

Por eso nuestros tableros pueden decir "305 eventos renderizan limpio, y la afirmación de 20 horas de contenido no está aceptada todavía" en la misma frase — los estados son separados, y la tubería se niega a difuminarlos.

## Regresión sobre toda la superficie

Todo sistema aceptado se congela como línea base: sus interfaces no pueden cambiar sin una actualización de contrato. Cada lote nuevo vuelve a ejecutar la suite de regresión en todos los viewports de teléfono y ambos modos de letra, y escanea errores de motor y fugas. Las suites son aburridas por diseño — su trabajo es atrapar la milésima rotura pequeña, no ser interesantes.

## Lo que este sistema todavía no ve (sección honesta)

- **Diversión.** Nada aquí mide si el juego es disfrutable. La evidencia prueba comportamiento, no deleite.
- **Feel.** Los tiempos de animación y el "juice" pasan todas las verificaciones técnicas sintiéndose mal; solo un humano lo nota.
- **Exploits nuevos.** Las suites verifican caminos conocidos; los jugadores inventan nuevos. La simulación atrapa algunos; el playtesting atrapa el resto.

Por eso el sistema de evidencia es un piso, no un techo: garantiza que nada se publique *roto*, y deja el juicio de *bueno* donde corresponde — con los humanos.

## Cómo empezar pequeño

1. **Elige una función** — algo con un flujo visible, como menú → acción → resultado.
2. **Grábala una vez, sin cortes** — una captura en tiempo real de la compilación real, no un screencast re-timed.
3. **Congela un par antes/después** — mismo estado, dos tamaños de teléfono.
4. **Átala a una revisión** — incluso un nombre de archivo con el hash del commit es mejor que nada.

Ese es todo el sistema en miniatura. Todo lo demás — estados de ciclo de vida, líneas base de regresión, auditorías — es este patrón escalado. Pruébalo en tu próxima función; la primera regresión que atrapes pagará el hábito.

## FAQ

**¿No es demasiado lento grabar cada función?**

Es más rápido que depurar a ciegas. Una grabación de 20 segundos tarda menos en producirse que escribir una suite de pruebas exhaustiva — y a diferencia de las pruebas, no puede pasar mientras el juego está visiblemente roto. Lo lento es hacerlo después de saltárselo.

**¿Pueden los agentes revisar la evidencia ellos mismos?**

En parte — los agentes pueden mirar grabaciones, comparar capturas y marcar diferencias mecánicamente. Eso es la mayor parte del volumen. La revisión humana se concentra en el gusto y los casos límite, que es exactamente donde vale la pena gastar tiempo humano.

**¿Reemplaza esto a las pruebas unitarias?**

No — son capas. Las pruebas unitarias verifican la lógica en aislamiento; el sistema de evidencia verifica el juego en ejecución. El código generado por IA se beneficia de ambas, porque pasar pruebas es barato de falsificar por accidente y grabar un juego funcionando no lo es.