docs: allow multiple pending release branches if new changes exist

Author: danielaEsc

.github/copilot-instructions.md

@@ -28,6 +28,8 @@ Cuando se te solicite crear o gestionar releases, utiliza la skill en `release/`
 
 **REGLA CRÍTICA - Sincronización de Ramas:** La rama `release/v{version}` debe existir SIMULTÁNEAMENTE en GitHub (remoto) Y en el repositorio local, o no existir en ninguno de los dos. PROHIBIDO tener la rama solo en uno de los lados.
 
+**MULTIPLE PENDING RELEASES:** Es totalmente válido tener múltiples ramas de release y PRs abiertos al mismo tiempo (ej. `v1.4.7` y `v1.4.8`). NO detener el proceso si hay PRs sin fusionar; si hay commits nuevos en `master` respecto a la última rama remota, proceder a crear la siguiente versión.
+
 1. **Base y rama nueva:** Siempre partir de `master`: `git checkout master && git pull origin master && git checkout -b release/v{version}`. La rama se crea desde `master` limpio.
 2. **Actualizar archivos:** `package.json`, `.release-please-manifest.json`, `release/CHANGELOG.md`.
 3. **Commit:** `git add ... && git commit -m "release v{version}"` (sin prefijo `chore:`)

release/skill.md

@@ -8,7 +8,7 @@ Este documento describe la "skill" que reside en la carpeta `release/` y que per
 - Actúa como la **interfaz interactiva de GitHub Actions (GA)**, permitiendo previsualizar y preparar lo que `release-please` automatizará.
 - Inspecciona commits recientes siguiendo conventional commits.
 - **Orden obligatorio:** Antes de leer `package.json` o `CHANGELOG.md`, ejecutar en este orden:
-  1. **Verificación de cambios:** Ejecutar `git log --oneline {última_rama_remota}..master` para detectar commits nuevos. Además, se debe validar que existan commits convencionales relevantes (feat, fix, etc.). SI NO HAY CAMBIOS RELEVANTES o las notas de versión resultantes están vacías, responder "No hay cambios para este release" y DETENER el proceso.
+  1. **Verificación de cambios:** Ejecutar `git log --oneline {última_rama_remota}..master` para detectar commits nuevos. Además, se debe validar que existan commits convencionales relevantes (feat, fix, etc.). SI NO HAY CAMBIOS RELEVANTES o las notas de versión resultantes están vacías, responder "No hay cambios para este release" y DETENER el proceso. **IMPORTANTE:** Si hay cambios nuevos, el proceso DEBE continuar aunque existan ramas de release anteriores sin fusionar (`v1.4.7`, `v1.4.8`, etc.). NO es necesario esperar al merge para crear el siguiente release.
   2. **Verificación de versión:** Leer `.release-please-manifest.json` para versión actual. Usar rama remota como fuente de verdad: `git ls-remote --heads origin` para identificar la última rama remota (`release/vX.Y.Z`). Siguiente versión = patch inmediatamente posterior.
   3. **Confirmar disponibilidad (Local y Remoto):** Verificar que la nueva versión NO existe en remoto (`git ls-remote --heads origin "release/v{version}"`). Si existe en remoto, usar siguiente versión. Verificar si existe localmente; si existe localmente pero no en remoto, se puede proceder (eliminando la rama local si es necesario para evitar conflictos).
   4. **Solo después:** Leer y modificar `package.json`, `CHANGELOG.md` y `.release-please-manifest.json` con versión elegida.