docs: lo que es cierto tras publicar la v1.2.0

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.

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.
 </details>
 
 <details><summary>¿Qué versión uso?</summary>
 
-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.
 </details>
 
 ## Lo que tienes que hacer tú (mantenedor)

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.

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.
 

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 |
 | `@<sha>` (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
 

internal/gallery/index.html.tmpl

@@ -315,7 +315,6 @@
     <h3 id="verificar">Binarios verificables</h3>
     <p>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 <a href="https://github.com/BertMarti/commitling/releases">releases</a> lleva además una <strong>atestación de procedencia</strong> firmada por GitHub que dice de qué commit y de qué workflow salió. Si te bajas uno a mano, compruébalo con la <a href="https://cli.github.com/">CLI de GitHub</a> (con la sesión iniciada: <code>gh auth login</code>):</p>
     <div class="code"><button class="copy" type="button" data-copy="att" aria-label="Copiar la orden de verificación" hidden>Copiar</button><pre tabindex="0" aria-label="Orden para verificar un binario"><code id="att">gh attestation verify commitling_{{.Version}}_linux_amd64 --repo BertMarti/commitling</code></pre><p class="copy-msg note" role="status" aria-live="polite"></p></div>
-    <p class="note" id="verificar-aviso">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).</p>
     <p class="note">Cambia el nombre del archivo por el que te hayas bajado (por ejemplo <code>commitling_{{.Version}}_windows_amd64.exe</code>). 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 <code>--signer-workflow BertMarti/commitling/.github/workflows/release.yml</code>. Hace falta <code>gh</code> 2.49 o posterior.</p>
   </section>
 </main>

internal/gallery/page_test.go

@@ -64,7 +64,7 @@ func TestGalleryHasSpeciesFilter(t *testing.T) {
 
 func TestPageExplainsAttestations(t *testing.T) {
 	page := buildPageWithVersion(t, "1.2.0-test")
-	for _, want := range []string{`id="verificar"`, `id="verificar-aviso"`, `gh attestation verify commitling_1.2.0-test_linux_amd64 --repo BertMarti/commitling`, `commitling_1.2.0-test_windows_amd64.exe`} {
+	for _, want := range []string{`id="verificar"`, `gh attestation verify commitling_1.2.0-test_linux_amd64 --repo BertMarti/commitling`, `commitling_1.2.0-test_windows_amd64.exe`} {
 		if !strings.Contains(page, want) {
 			t.Errorf("page lacks %q", want)
 		}