Bucle prueba → arreglo: informes que un agente puede usar

Para qué sirve

Úsalo cuando ya existe la primera versión y estás en el ciclo jugar → informar → arreglar. Cubre dos tipos de problema:

• Errores: pasa algo que no debería (atravesar el suelo, una puerta que nunca se abre, puntos que se cuentan dos veces). Necesitan pasos para reproducirlos, lo esperado frente a lo real y pruebas.
• Problemas de sensación: todo funciona, pero se siente flotante, resbaladizo, lento o flojo. Necesitan una medida y un objetivo, porque "que se sienta mejor" invita al modelo a añadir partículas, temblor de pantalla y un dash que nadie pidió. Los números objetivo están en ajuste de la sensación de juego.

El bucle se apoya en cinco reglas. Vale la pena adoptarlas aunque nunca pegues las plantillas:

1. Un problema por ronda. Con dos cambios en una ronda, cuando algo mejora o empeora no sabes cuál de los dos fue.
2. Primero las causas, después el código. El modelo enumera hasta tres causas probables, cada una con el archivo y la función que sospecha, y prueba la primera. Así no tapa un síntoma en otro sitio, como subir la fricción para ocultar que la velocidad se aplica dos veces.
3. El cambio más pequeño que pruebe la causa. Un límite estricto (1–2 archivos, unas 20 líneas, sin refactorizar, sin dependencias nuevas) hace que cada diff se revise en menos de un minuto.
4. Medir antes y después. Si el problema todavía no se ve como un número o una línea de log, la única tarea de la ronda es añadir esa lectura.
5. Conservar o revertir, nunca apilar. Un cambio que no ayudó se deshace antes de probar la siguiente idea, para que el código no se llene de medio arreglos.

Una ronda lleva 3–10 minutos. Diez rondas limpias hacen avanzar un prototipo más que una tarde entera de "sigue mal, prueba otra vez".