fix: enforce strict conventional commit check to prevent empty release PRs

Author: danielaEsc

.github/copilot-instructions.md

@@ -17,9 +17,10 @@ Cuando se te solicite crear o gestionar releases, utiliza la skill en `release/`
 
 - Analiza commits siguiendo **Conventional Commits**.
 - Si el usuario pide un release, ejecutar en este orden (NO cambiar el orden):
-  1.  **Verificación de cambios PRIMERO:** Ejecutar `git log --oneline {última_rama_remota}..master` para verificar si hay commits nuevos desde el último release. SI NO HAY COMMITS, responder: "No hay cambios para este release" y DETENER el proceso. NO crear release si no hay cambios.
-  2.  **Verificación de versión:** (a) Leer `.release-please-manifest.json` para la versión actual. (b) **Usar la rama remota como fuente de verdad:** Ejecutar `git ls-remote --heads origin | grep "refs/heads/release/v"` para identificar la **última rama remota publicada**. La siguiente versión será el patch inmediatamente posterior (ej. si última es `remotes/origin/release/v1.4.5`, usar `1.4.6` sin saltos). (c) **Verificar que la rama NO existe en remoto:** Ejecutar `git ls-remote --heads origin "release/v{version}"`. Si existe en remoto, usar siguiente versión. Si existe localmente pero no en remoto, proceder con esa versión (eliminar la rama local si es necesario para evitar conflictos).
-  3.  **Solo después:** Leer y actualizar `package.json`, `release/CHANGELOG.md`, manifest con la versión elegida.
+  1.  **Verificación de cambios PRIMERO:** Ejecutar `git log --oneline {última_rama_remota}..master` para verificar si hay 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.
+  2.  **Verificación de versión:** (a) Leer `.release-please-manifest.json` para la versión actual. (b) **Usar la rama remota como fuente de verdad:** Ejecutar `git ls-remote --heads origin` para identificar la **última rama remota publicada**. La siguiente versión será el patch inmediatamente posterior. (c) **Verificar que la rama NO existe en remoto:** Ejecutar `git ls-remote --heads origin "release/v{version}"`. Si existe en remoto, usar siguiente versión. Si existe localmente pero no en remoto, proceder con esa versión (eliminar la rama local si es necesario para evitar conflictos).
+  3.  **Generación y validación de notas:** Ejecutar `./release/generate-release-notes.sh {última_rama_remota}` para crear `/tmp/release-notes.md`. Si el script falla o el archivo está vacío, DETENER el proceso.
+  4.  **Solo después:** Leer y actualizar `package.json`, `release/CHANGELOG.md`, manifest con la versión elegida.
 
 ### 3. Ejecución del Release (OBLIGATORIO: rama + PR)
 

release/generate-release-notes.sh

@@ -5,8 +5,9 @@
 
 set -e
 
-# Obtener commits desde master hasta HEAD
-commits=$(git log --oneline --pretty=format:'%s' origin/master..HEAD 2>/dev/null || git log --oneline --pretty=format:'%s' master..HEAD)
+# Obtener commits desde un base (opcional, default origin/master) hasta HEAD
+base_ref=${1:-origin/master}
+commits=$(git log --oneline --pretty=format:'%s' "$base_ref"..HEAD 2>/dev/null || git log --oneline --pretty=format:'%s' master..HEAD)
 
 # Inicializar secciones
 features=""
@@ -73,4 +74,9 @@ if [[ -n $chores ]]; then
     echo -e "$chores" >> "$output"
 fi
 
+if [[ ! -s "$output" ]]; then
+    echo "ERROR: No se generaron notas de versión. No hay commits convencionales relevantes."
+    exit 1
+fi
+
 echo "Release notes generado en $output"

release/skill.md

@@ -8,10 +8,11 @@ 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 desde el último release. SI NO HAY COMMITS, 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.
   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.
+- **Generación de notas:** Siempre ejecutar `./release/generate-release-notes.sh {última_rama_remota}`. Si el script falla o el archivo `/tmp/release-notes.md` no contiene información relevante de commits, ABORTAR la creación del PR.
 - La rama `release/v{version}` debe existir SIMULTÁNEAMENTE en GitHub (remoto) Y localmente, o no existir en ninguno de los dos. PROHIBIDO tener rama solo en uno de los lados.
 - Invoca al Release & Communication Agent para producir notas de versión y gestionar comunicación.