[BertMarti]

Versión 1.0.0

La 0.8.0 nunca se publicó: todo lo hecho desde la v0.7.0 (fases 1 a 4: seguridad, instalación guiada, especie cactus, selector de tema, binario precompilado…) sale como v1.0.0. CLI y Action quedan alineadas en 1.0.0. La interfaz de action.yml no cambia y las tarjetas del musgo y del hongo son byte a byte las de v0.7.0.

Qué cambia

• Versión 1.0.0 en cmd/commitling/main.go (y su test), el pie de la web y la documentación; CHANGELOG [1.0.0] - 2026-10-26 con resumen y enlaces de comparación.
• Binario precompilado activo: commit de release/checksums.txt de la 1.0.0 (scripts/build-release.sh out/rel --write, Go 1.27.3, generado tras el último cambio de código). Al publicar la release, release.yml recompila con --check y sube los 6 binarios.
• CI: el job action fuerza la ruta de go run (COMMITLING_RELEASE_URL a un puerto cerrado), porque con la release publicada usaría el binario, se saltaría setup-go y el chequeo «Go parcheado en todas las llamadas» fallaría en main. El job binario prueba además la Action con el checksums.txt del repositorio contra la release real (hoy: 404 → go run; tras publicar: binario verificado; mismo SVG) y exige que coincida con los binarios recompilados.
• Docs: «v0.8.0» → «v1.0.0» (los avisos de «aún no publicada» se mantienen hasta la release); fuera la falsa promesa del Marketplace (la Action no está publicada allí) y el aviso obsoleto «la etiqueta v1 aún no existe» de docs/USO.md; DESARROLLO.md y la skill publicar-version explican el ciclo de release/checksums.txt; PLAN con «Después de la 1.0»; SECURITY, AGENTS y MEMORY al día.

Compatibilidad del perfil (crítico)

• Con release/checksums.txt y sin release publicada, el paso bin recibe un 404 y compila con Go: probado en local (linux/arm64, URL real → ::notice:: y go run) y en el job binario. Con binarios publicados (servidor local) descarga, verifica el SHA-256 y el SVG es idéntico al de go run.
• v1 no se mueve en esta PR: el perfil sigue en v0.7.0 hasta publicar.

Tras fusionar (orquestador)

1. gh release create v1.0.0 --repo BertMarti/commitling --target main --title "v1.0.0 · Primera versión estable" --notes-file <notas> (notas en mejoras-informes/release-commitling-v1.0.0.md, sin la primera línea «Título:»).
2. Comprobar que el workflow «Release» sube 6 binarios y checksums.txt.
3. git fetch --tags && git tag -f v1 v1.0.0 && git push -f origin v1.
4. Abrir y fusionar el PR de la rama v1-tras-publicar (avisos fuera, ejemplos @v1.0.0, borra release/checksums.txt).

Cómo probarlo

gofmt -l ., go vet ./..., GOFLAGS=-p=2 go test ./..., scripts/build-release.sh out/rel --check.

Quién hizo qué

• Claude Opus 5.5 (jefe): versión, CI, checksums, docs, pruebas de la ruta del binario, revisión.
• Gemini 3 Flash (OpenCode, delegado): resumen del CHANGELOG y borrador de las notas de la release (revisado y corregido por Claude).

🤖 Generated with Claude Code