diff --git a/CHANGELOG.md b/CHANGELOG.md
index dfb9e1f..452bbfc 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -6,6 +6,11 @@ El formato sigue [Keep a Changelog](https://keepachangelog.com/es-ES/1.1.0/) y e
## [Sin publicar]
+### Cambiado
+
+- Con la v1.2.0 publicada y `v1` apuntando a ella, el README, la guía de uso y la web dejan de avisar de que las atestaciones llegan con una versión aún sin publicar, y los ejemplos de versión exacta pasan a `@v1.2.0`.
+- `release/checksums.txt` sale de `main`: describe los binarios de la v1.2.0 ya publicada (va en su etiqueta) y no los de `main`, que ha cambiado. La próxima versión lo vuelve a generar en su commit.
+
## [1.2.0] - 2026-11-02
Binarios que se pueden verificar y una galería más fácil de recorrer. **La interfaz de `action.yml` no cambia** (mismas entradas, misma salida `path`, mismos archivos) y todas las tarjetas SVG son byte a byte las de la v1.1.0: con `@v1` no hay que hacer nada.
diff --git a/README.md b/README.md
index 1a3a117..c1b61aa 100644
--- a/README.md
+++ b/README.md
@@ -271,13 +271,11 @@ gh attestation verify commitling_1.2.0_linux_amd64 --repo BertMarti/commitling
```
Si dice «Verification succeeded», el archivo no ha cambiado ni un byte desde que lo compiló y firmó un workflow de `BertMarti/commitling`. Para exigir además que fuera el workflow «Release» (el que publica los binarios), añade `--signer-workflow BertMarti/commitling/.github/workflows/release.yml`. Hace falta `gh` 2.49 o posterior.
-
-> La 1.2.0 aún no está publicada: hasta entonces, las releases no tienen atestación.
¿Qué versión uso?
-Usa `BertMarti/commitling@v1` para recibir mejoras compatibles. Si quieres fijar una versión concreta, usa una etiqueta exacta (por ejemplo `@v1.1.0`) o el SHA de un commit. Evita `@main`: es la rama de desarrollo.
+Usa `BertMarti/commitling@v1` para recibir mejoras compatibles. Si quieres fijar una versión concreta, usa una etiqueta exacta (por ejemplo `@v1.2.0`) o el SHA de un commit. Evita `@main`: es la rama de desarrollo.
## Lo que tienes que hacer tú (mantenedor)
diff --git a/SECURITY.md b/SECURITY.md
index 73756aa..aff9e71 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -23,6 +23,6 @@ Respondo en cuanto pueda (proyecto personal, sin plazos garantizados).
## Buenas prácticas para quien usa la Action
-- Fíjala a `@v1`, a una versión exacta (por ejemplo `@v1.1.0`) o a un SHA, nunca a `@main`.
+- Fíjala a `@v1`, a una versión exacta (por ejemplo `@v1.2.0`) o a un SHA, nunca a `@main`.
- Da a tu workflow solo `permissions: contents: write` (lo necesita para guardar el SVG) y nada más.
- No hace falta ningún token personal: basta el `GITHUB_TOKEN` del propio workflow.
diff --git a/docs/DESARROLLO.md b/docs/DESARROLLO.md
index fd9e63b..bf31043 100644
--- a/docs/DESARROLLO.md
+++ b/docs/DESARROLLO.md
@@ -105,7 +105,7 @@ La entrada de la Action `keep-on-error` está activa por defecto. Si la caída e
## Versiones y GitHub Marketplace
- `BertMarti/commitling@v1` sigue la versión mayor 1: la etiqueta móvil `v1` apunta a la última versión compatible y la mueve Alberto al publicar.
-- Una etiqueta exacta (`@v1.1.0`) o el SHA de un commit es lo más reproducible.
+- Una etiqueta exacta (`@v1.2.0`) o el SHA de un commit es lo más reproducible.
- `@main` funciona, pero es la rama de desarrollo; los ejemplos nunca la usan (`TestExamplesUseV1`).
- La Action declara nombre, descripción y `branding` (icono `feather`, color `green`) en `action.yml`, que es lo que muestra el Marketplace. **La interfaz de `action.yml` (entradas, salida `path`, archivos y formato del SVG) no se rompe**: hay perfiles que la usan a diario.
diff --git a/docs/USO.md b/docs/USO.md
index 8e3d0bd..f6075c2 100644
--- a/docs/USO.md
+++ b/docs/USO.md
@@ -113,7 +113,7 @@ Qué hace este archivo, en cristiano:
- `schedule` / `cron`: lo ejecuta solo cada día a las 05:23 UTC (07:23 en el horario de verano de la España peninsular, 06:23 en invierno). GitHub puede retrasar unos minutos las ejecuciones programadas.
- `workflow_dispatch`: añade el botón **Run workflow** para lanzarlo a mano.
- `permissions: contents: write`: le permite guardar la imagen en tu repositorio. Sin esto fallaría al guardar.
-- `BertMarti/commitling@v1`: es la Action de commitling, que crea el archivo `commitling.svg`. `@v1` significa «la versión 1»: recibes las mejoras compatibles sin tocar nada. Si prefieres fijar una versión exacta, usa una etiqueta exacta de las [releases](https://github.com/BertMarti/commitling/releases), por ejemplo `@v1.1.0`.
+- `BertMarti/commitling@v1`: es la Action de commitling, que crea el archivo `commitling.svg`. `@v1` significa «la versión 1»: recibes las mejoras compatibles sin tocar nada. Si prefieres fijar una versión exacta, usa una etiqueta exacta de las [releases](https://github.com/BertMarti/commitling/releases), por ejemplo `@v1.2.0`.
- El último paso guarda `commitling.svg` en tu repositorio solo si ha cambiado, con un commit «chore: actualiza commitling».
### Paso 3. Añade la imagen a tu README
@@ -328,7 +328,7 @@ En el workflow, la línea `uses: BertMarti/commitling@...` decide qué versión
| Escribes | Qué significa | Cuándo usarla |
|---|---|---|
| `@v1` | La versión mayor 1: la etiqueta `v1` se mueve con cada versión 1.x compatible, así que recibes mejoras y correcciones sin tocar nada | Lo recomendado |
-| `@v1.1.0` (o la última de las releases) | Una versión exacta, que nunca cambia | Si quieres controlar tú cuándo actualizas |
+| `@v1.2.0` (o la última de las releases) | Una versión exacta, que nunca cambia | Si quieres controlar tú cuándo actualizas |
| `@` (huella de un commit) | Una copia exacta del código, la opción más reproducible | Si te importa la máxima seguridad |
| `@main` | La rama de desarrollo, que puede cambiar en cualquier momento (y romper tu workflow) | Solo para probar cambios |
@@ -362,7 +362,7 @@ gh attestation verify commitling_1.2.0_linux_amd64 --repo BertMarti/commitling -
Hace falta `gh` 2.49 o posterior (`gh --version`); las versiones anteriores no tienen `gh attestation`.
-> La 1.2.0 aún no está publicada: hasta entonces, las releases (1.1.0 y anteriores) no tienen atestación.
+Las releases anteriores a la 1.2.0 no tienen atestación (la Action las verifica igual, con la huella SHA-256).
## 7. Desde la línea de órdenes y la imagen de vista previa
diff --git a/internal/gallery/index.html.tmpl b/internal/gallery/index.html.tmpl
index cf97fc0..9a1b567 100644
--- a/internal/gallery/index.html.tmpl
+++ b/internal/gallery/index.html.tmpl
@@ -315,7 +315,6 @@
Binarios verificables
La Action usa un binario ya compilado de cada versión y, antes de ejecutarlo, comprueba su huella SHA-256 con la lista que viaja dentro de la propia Action: si no coincide, lo descarta y compila el código con Go. A partir de la 1.2.0, cada binario de las releases lleva además una atestación de procedencia firmada por GitHub que dice de qué commit y de qué workflow salió. Si te bajas uno a mano, compruébalo con la CLI de GitHub (con la sesión iniciada: gh auth login):
La 1.2.0 aún no está publicada: hasta entonces, las releases no tienen atestación (la Action sigue verificando la huella como siempre).
Cambia el nombre del archivo por el que te hayas bajado (por ejemplo commitling_{{.Version}}_windows_amd64.exe). Si la orden dice «Verification succeeded», el archivo no ha cambiado ni un byte desde que lo compiló y firmó un workflow de este repositorio. Para exigir además que fuera el workflow «Release» (el que publica los binarios), añade --signer-workflow BertMarti/commitling/.github/workflows/release.yml. Hace falta gh 2.49 o posterior.