docs: lo que es cierto tras publicar la v1.1.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.1.0 publicada y `v1` apuntando a ella, el README, la guía de uso y el instalador de la web dejan de avisar de que la calabaza necesita una versión aún sin publicar, y los ejemplos de versión exacta pasan a `@v1.1.0`.
+- `release/checksums.txt` sale de `main`: describe los binarios de la v1.1.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.1.0] - 2026-10-31
 
 Una especie nueva y nada más que cambie para quien ya usa commitling: **la interfaz de `action.yml` es la misma** (mismas entradas con los mismos valores por defecto, misma salida `path`, mismos archivos; solo cambia el texto de ayuda de `species` para nombrar la nueva) y las tarjetas del brote de musgo, el hongo y el cactus son byte a byte las de la v1.0.0. Con `@v1` no hay que hacer nada.

MEMORY.md

@@ -2,6 +2,8 @@
 Última actualización: 2026-10-31 por Claude Code (Opus 5.5, jefe de la fase 6, rama `v1.1-2026-10-31`)
 
 ## Estado actual
+**Tras publicar la v1.1.0 (rama `v1.1-tras-publicar`, se fusiona después de la release y de mover `v1`)**: sin el aviso «la calabaza llega con la 1.1.0» (README, `docs/USO.md`, instalador de la web), ejemplos `@v1.1.0` y sin `release/checksums.txt` en `main` (va en la etiqueta v1.1.0). `@main` compila siempre con Go.
+
 **Versión 1.1.0 (fase 6, 31/10/2026, rama `v1.1-2026-10-31`, PR contra `main`)**: v1.0.0 publicada y `v1` apuntando a ella. Cuarta especie **calabaza** (`pumpkin`; fases Pepita, Plántula, Calabacita, Calabaza y Calabaza gigante) en la Action, la CLI, la galería, los dos generadores y la OG (ahora dos especies por fila). Musgo, hongo y cactus byte a byte iguales (galería de `main` contra la rama: 180 SVG y favicon idénticos; 12 combinaciones de la CLI idénticas; huellas de v0.5.0). De `action.yml` solo cambia la `description` de `species`. El último commit lleva `release/checksums.txt` de la 1.1.0. Avisos «la calabaza llega con la 1.1.0» en README, `docs/USO.md` y el instalador de la web: los quita la rama `v1.1-tras-publicar` (que además borra `release/checksums.txt` de `main`), que se fusiona después de publicar y mover `v1`. Pasos exactos para el orquestador en el informe de la fase 6.
 
 **Tras publicar la v1.0.0 (rama `v1-tras-publicar`, se fusiona después de la release y de mover `v1`)**: sin avisos de «aún no publicada» (README, `docs/USO.md`, web), ejemplos de versión exacta `@v1.0.0` y sin `release/checksums.txt` en `main` (va en la etiqueta v1.0.0; regenerarlo con la misma versión daría SHA-256 distintos de los subidos porque la plantilla embebida cambió). `@main` compila siempre con Go.

README.md

@@ -132,8 +132,6 @@ Las cuatro especies son originales y tienen las mismas reglas, fases, ánimos y
   </tr>
 </table>
 
-La calabaza llega con la versión 1.1.0. Si al usarla el paso falla con «especie no válida», es que `@v1` aún no apunta a la 1.1.0: vuelve a intentarlo cuando se publique.
-
 `species` también acepta `musgo`, `hongo`, `seta` y `calabaza`, sin distinguir mayúsculas.
 
 ### Tarjeta compacta
@@ -264,7 +262,7 @@ No. Es un diseño original, dibujado píxel a píxel para este proyecto.
 
 <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.0.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.1.0`) o el SHA de un commit. Evita `@main`: es la rama de desarrollo.
 </details>
 
 ## Lo que tienes que hacer tú (mantenedor)

SECURITY.md

@@ -22,6 +22,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.0.0`) o a un SHA, nunca a `@main`.
+- Fíjala a `@v1`, a una versión exacta (por ejemplo `@v1.1.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.0.0`) o el SHA de un commit es lo más reproducible.
+- Una etiqueta exacta (`@v1.1.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.0.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.1.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
@@ -178,8 +178,6 @@ Solo cambian el dibujo y el nombre de las fases:
 | 4 | 1.000 XP | Arbusto | Seta grande | Cactus con brazos | Calabaza |
 | 5 | 2.500 XP | Árbol ancestral | Corro de setas | Cactus centenario | Calabaza gigante |
 
-La calabaza llega con la versión 1.1.0. Si al usarla el paso falla con «especie no válida», es que `@v1` aún no apunta a la 1.1.0: vuelve a intentarlo cuando se publique.
-
 Valores que acepta `species` (sin distinguir mayúsculas ni espacios alrededor):
 
 | Especie | Valores válidos |
@@ -330,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.0.0` (o la última de las releases) | Una versión exacta, que nunca cambia | Si quieres controlar tú cuándo actualizas |
+| `@v1.1.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 |
 

internal/gallery/index.html.tmpl

@@ -235,7 +235,6 @@
         <div class="opts">{{range $i, $c := .GenSpecies}}
           <div class="opt"><input type="radio" name="ins-species" value="{{$c.Value}}" id="ins-sp-{{$c.Value}}"{{if eq $i 0}} checked{{end}}><label for="ins-sp-{{$c.Value}}">{{$c.Label}}</label></div>{{end}}
         </div>
-        <p class="note hint">La calabaza llega con la versión 1.1.0: si tu workflow falla con «especie no válida», es que <code>@v1</code> aún no la incluye; vuelve a ejecutarlo cuando se publique.</p>
       </fieldset>
       <fieldset>
         <legend>Tema</legend>