Merge branch 'master' into prueba-release

Author: danielaEsc

.github/copilot-instructions.md

@@ -1,42 +1,44 @@
-# Instrucciones para Gestión de Releases (Integración Skill + GA)
+# Instrucciones para Gestión de Releases (Carpeta `release/`)
 
-Cuando se te solicite crear o gestionar releases, utiliza la skill en `release/` como la **interfaz interactiva** para preparar lo que la acción de GitHub `release-please` ejecutará automáticamente en el repositorio.
+Estas instrucciones guían a Copilot sobre cómo intervenir en el flujo de releases cuando se usa `release-please` y la skill de la carpeta `release/`.
 
-**ORDEN OBLIGATORIO:** ANTES de leer o modificar `package.json`, `.release-please-manifest.json` o `CHANGELOG.md`, primero ejecutar la verificación de colisiones (paso 3). La verificación determina qué versión usar; solo después leer/actualizar archivos con esa versión.
+## 1. Detección de contexto
 
----
+- Identificar si el usuario está en:
+  - La rama principal (`master`/`main`) → **Modo A: crear release nuevo**.
+  - Una rama de release creada por `release-please` (por ejemplo `release-please--branches--master--components--simple-test-project` u otra similar) → **Modo B: completar release existente**.
+- Usar el archivo `release/.releaserc.yml` para configuraciones específicas.
+- Referencia de versión: `package.json` (campo `version`) y/o manifestos de `release-please`.
 
-### 1. Detección de Configuración y Estado
+## 2. Modo A – Crear un release nuevo (desde `master`/`main`)
 
-- **Configuración Global:** `release-please-config.json` (define qué archivos rastrear).
-- **Fuente de Verdad (Versiones):** `.release-please-manifest.json`.
-- **Configuración Skill:** `release/.releaserc.yml` (define comportamiento interactivo).
-- **Changelogs:** `release/CHANGELOG.md`.
+Cuando el usuario pida algo como **"Crea un release nuevo desde master usando release-please"** y esté en `master`/`main`:
 
-- **Análisis y Preparación Interactiva (Skill)**
+1. Verificar que se trata de la rama principal.
+2. Validar que los commits recientes siguen Conventional Commits.
+3. Ayudar a disparar el workflow de `release-please` (no crear ramas/PRs manualmente si no es necesario).
+4. Una vez que `release-please` genere el PR de release:
+   - Sugerir al usuario cambiarse a la rama de release y continuar en **Modo B**.
 
-- 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. 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. Modo B – Completar un PR de release-please ya creado (recomendado)
 
-### 3. Ejecución del Release (OBLIGATORIO: rama + PR)
+Cuando el usuario esté en una rama de release creada por `release-please` y pida algo como  
+**"Completa este release en esta rama de release-please: genera o actualiza el CHANGELOG en español, actualiza la versión en package.json y deja todo listo para commit en esta misma rama, sin crear un nuevo PR ni tocar master."**:
 
-**IMPORTANTE:** NUNCA hacer `git push origin master`. Siempre crear rama de release y abrir PR.
+1. **Detección de contexto:**
+   - Confirmar que se está en una rama de release (nombre generado por `release-please`).
+   - No cambiar de rama a `master`/`main` ni crear nuevas ramas de 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.
+2. **Generación de changelog en español:**
+   - Analizar los commits del PR/rama actual (desde el último tag).
+   - Generar o actualizar `release/CHANGELOG.md` con secciones en español (ej. "Características", "Correcciones", "Documentación").
+   - Seguir el formato definido en `.releaserc.yml`.
 
-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:`)
-4. **Push:** `git push origin release/v{version}`. VERIFICAR que después del push, la rama existe en ambos lados: `git branch -a | grep release/v{version}` debe mostrar TANTO la rama local COMO `remotes/origin/release/v{version}`.
-5. **Generar release notes:** Ejecutar `./release/generate-release-notes.sh` para crear `/tmp/release-notes.md` basado en commits convencionales.
-6. **Abrir PR a master:** `gh pr create --title "release v{version}" --body-file /tmp/release-notes.md --base master --head release/v{version}`.
+3. **Cierre de release en la rama actual:**
+   - Actualizar la versión en `package.json` (campo `version`) según la versión del release actual.
+   - Realizar un commit con el mensaje: `chore: release v{version} [spanish changelog]`.
+   - Ejecutar el **Release & Communication Agent** para generar la síntesis para stakeholders (evidencia, riesgos, etc.).
+   - Dejar el PR listo para revisión y merge manual a `master`.  
+   - No crear un nuevo PR ni una nueva versión de release.
 
-**Post-Release:** Solo después del merge del PR en `master`, el GA `release-please-action` podrá gestionar tags y GitHub Releases automáticamente.
-
-### 4. Comunicación
-
-El Release & Communication Agent debe generar una síntesis para stakeholders basada en los cambios detectados en todos los paquetes afectados, incluyendo riesgos y criterios de éxito del rollout.
+> Nota: si ya existe un PR de release abierto, Copilot **no debe** intentar generar otro PR de release ni forzar un nuevo cálculo de versión; solo debe completar el contenido del PR actual.

.github/workflows/packages-security-audit.yml

@@ -0,0 +1,53 @@
+name: release-audit
+
+on:
+  push:
+    branches:
+      - "release/v*"
+
+permissions:
+  contents: read
+
+jobs:
+  write-audit-event:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Generate audit event
+        run: |
+          mkdir -p release
+          ts="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"
+          service="${GITHUB_REPOSITORY##*/}"
+          version="${GITHUB_REF_NAME#release/}"
+
+          jq -n \
+            --arg service "$service" \
+            --arg environment "unknown" \
+            --arg version "$version" \
+            --arg commit "$GITHUB_SHA" \
+            --arg release_branch "$GITHUB_REF_NAME" \
+            --arg pipeline_run_id "$GITHUB_RUN_ID" \
+            --arg requested_by "$GITHUB_ACTOR" \
+            --arg status "created" \
+            --arg timestamp "$ts" \
+            '{
+              service: $service,
+              environment: $environment,
+              version: $version,
+              commit: $commit,
+              release_branch: $release_branch,
+              pipeline_run_id: $pipeline_run_id,
+              approvers: [],
+              requested_by: $requested_by,
+              status: $status,
+              timestamp: $timestamp
+            }' >> release/audit-log.jsonl
+
+      - name: Upload audit log artifact
+        uses: actions/upload-artifact@v4
+        with:
+          name: release-audit-log
+          path: release/audit-log.jsonl
+