beez-ui 0.6.0 → 0.6.2

package/CHANGELOG.md

@@ -1,5 +1,29 @@
 # Cambios
 
+Todos los cambios relevantes de beez-ui se documentan en este archivo con el formato de [Keep a Changelog](https://keepachangelog.com/es-ES/1.1.0/) y versionado [SemVer](https://semver.org/lang/es/). Cada cambio agrega sus entradas en `[Unreleased]`; `pnpm create-version` las pasa a la versión publicada con su fecha.
+
+## [Unreleased]
+
+## [0.6.2] - 2026-09-26
+
+### Changed
+
+- El comando de release (`pnpm create-version`, alias `pnpm cv`) toma las notas del bloque `[Unreleased]` del CHANGELOG, les asigna la versión y la fecha, y pide a Codex que lo complete cuando está vacío.
+- Las cajas del comando de release ajustan el texto largo en varias líneas en lugar de cortarlo.
+- Un release interrumpido reusa automáticamente el artefacto ya preparado cuando es posterior al último cambio de código.
+
+### Removed
+
+- La opción `--notes` y las preguntas sobre las notas del CHANGELOG y sobre reusar el artefacto preparado.
+
+## 0.6.1 - 2026-09-26
+
+- Actualiza pnpm a 12.6.0 y next a 16.3.6
+- Add terminal UI for interactive prompts and spinners
+- Update release banner and icons for improved visibility
+- Remove create-version script
+- Update release command to create-version and improve documentation
+
 ## 0.6.0 - 2026-09-23
 
 - Actualiza el paquete a la versión 0.6.0.

package/README.md

@@ -201,27 +201,44 @@ El compilador `tsc` es TypeScript 7. Para `typescript-eslint`, se mantiene la [A
 
 ## Crear y publicar una versión
 
-Desde el repositorio de beez-ui, configurar `NPM_TOKEN` con permiso de publicación en el entorno o en `.env`, tomando `.env.example` como referencia. Mantener el archivo local existente si ya está configurado. Después ejecutar:
+Desde el repositorio de beez-ui, configurar `NPM_TOKEN` con permiso de publicación en el entorno o en `.env`, tomando `.env.example` como referencia. Mantener el archivo local existente si ya está configurado.
+
+### Un solo comando: `pnpm create-version` (alias `pnpm cv`)
 
 ```sh
-pnpm run create-version patch
-pnpm run create-version minor --notes "Agrega un componente" --notes "Amplía sus opciones"
-pnpm run create-version 0.5.0 --notes "Describe los cambios de esta versión"
+pnpm create-version                         # diagnóstico, plan y release interactivo
+pnpm create-version --bump minor            # patch | minor | major sin preguntar
+pnpm create-version --set-version 0.7.0     # versión exacta
+pnpm create-version --dry-run               # solo muestra el diagnóstico y el plan
+pnpm cv                                     # alias de pnpm create-version
 ```
 
-Acepta `patch`, `minor`, `major` o una versión estable explícita mayor que la actual. Las notas son opcionales y pueden repetirse. Sin `--notes`, se agrega una entrada básica que indica la nueva versión; las notas explícitas no pueden estar vacías. `pnpm run create-version --help` muestra la sintaxis.
+El comando hace `git fetch`, consulta npm y muestra un panel con la rama, el upstream, el working tree, `main` frente a origin, la versión local, la última versión publicada, los commits posteriores al último cambio de versión y el artefacto ya preparado. Después decide qué falta:
+
+- **Release nuevo**: si hay commits sin publicar, sugiere `patch`, `minor` o `major` según los commits (breaking change, funcionalidades o solo arreglos) y pregunta con las flechas. Las notas salen del bloque `## [Unreleased]` de `CHANGELOG.md` (ver la sección CHANGELOG más abajo); si está vacío, invoca a Codex (`codex exec`) para completarlo desde los commits sin publicar y muestra el resultado, y si Codex no está o no escribe nada válido, el release se corta. Tras confirmar ejecuta el flujo validado completo (ver abajo).
+- **Release a medio terminar**: si `package.json` tiene una versión que npm todavía no tiene, completa solo lo que falta: si `package.json` y `CHANGELOG.md` quedaron sin commitear los commitea primero; después prepara el artefacto (reusa automáticamente el ya preparado cuando es posterior al último cambio de código, y `release:publish` lo vuelve a verificar), pushea el commit de release si todavía no está en origin y publica (la confirmación del inicio cubre la publicación). Nunca vuelve a subir la versión.
+- **Todo al día**: si la versión está publicada y no hay commits nuevos, no hace nada.
+
+`--set-version` sólo acepta el siguiente patch, minor o major de la versión actual (desde `0.6.0`: `0.6.1`, `0.7.0` o `1.0.0`); rechaza versiones menores, iguales, prerelease o que salteen versiones. Los releases salen sólo desde `main` con upstream configurado. Se detiene y explica qué hacer ante otra rama, `HEAD` desacoplado, cambios sin commitear (salvo `CHANGELOG.md` en un release nuevo, que viaja en el commit de release, o `package.json` y `CHANGELOG.md` de un release a medio terminar), secciones de `[Unreleased]` fuera de las de Keep a Changelog, `main` divergida o npm sin respuesta; un bloqueo termina con código 0 porque ya está explicado en pantalla, y un paso fallido termina con código 1. Si `main` está atrás, la actualiza con fast-forward antes de versionar. Si algo falla, basta con volver a ejecutar `pnpm create-version`: retoma desde el primer paso pendiente. Las opciones de cada pregunta están numeradas: se eligen apretando su número, o con las flechas y Enter; cada versión muestra debajo qué significa patch, minor o major. Sin terminal interactiva cada pregunta toma su opción por defecto. El tiempo total que muestra al final no cuenta el tiempo que espera tus respuestas.
+
+La lógica pura vive en `scripts/release-plan.js` y `scripts/changelog.js` (lectura y release de `[Unreleased]`), la invocación de Codex en `scripts/changelog-ai.js`, la lectura de Git y npm en `scripts/release-state.js`, la UI de terminal (cajas, colores, íconos Nerd Font, spinner y selector) en `scripts/terminal-ui.js` y el orquestador en `scripts/release.js`, sin dependencias nuevas. Los íconos requieren una Nerd Font en la terminal.
+
+### CHANGELOG
+
+`CHANGELOG.md` sigue [Keep a Changelog](https://keepachangelog.com/es-ES/1.1.0/). Cada cambio agrega sus entradas en el bloque `## [Unreleased]`, agrupadas en `### Added`, `### Changed`, `### Deprecated`, `### Removed`, `### Fixed` y `### Security` (solo las que apliquen). Nunca se escriben la versión ni la fecha a mano: `pnpm create-version` las agrega al publicar. Las versiones anteriores a este formato (`## 0.6.1 - 2026-09-26`) siguen siendo válidas. La regla completa está en `AGENTS.md`.
 
-El comando ejecuta el flujo completo:
+### Flujo validado de un release nuevo
 
-1. Actualiza `package.json` y agrega la entrada del changelog con fecha UTC, conservando el historial.
-2. Prepara la release: instalación congelada, tests sin React Compiler, build optimizado de JavaScript, tipos y CSS, lint, typechecks, tests unitarios y pruebas de navegador.
-3. Genera el tarball en `releases/<version>-<sha256>/beez-ui-<version>.tgz` y valida su contenido, exports e integridad.
-4. Crea un commit con el contenido validado de `package.json` y `CHANGELOG.md`, conservando otros archivos staged, y pushea ese commit a la rama upstream configurada.
-5. Publica ese mismo artefacto en npm con acceso público y etiqueta `latest`.
+1. Actualiza `package.json` y renombra `## [Unreleased]` a `## [X.Y.Z] - AAAA-MM-DD` (fecha UTC), dejando un `[Unreleased]` vacío arriba y conservando el historial (`scripts/release-version.js`). Si `[Unreleased]` no tiene cambios o usa secciones no válidas, no toca nada.
+2. Commitea en el momento `package.json` y `CHANGELOG.md` (sólo esos dos archivos, conservando otros archivos staged), antes de las validaciones largas: si algo se corta después, queda un commit local y nunca metadata suelta.
+3. Prepara la release: instalación congelada, tests sin React Compiler, build optimizado de JavaScript, tipos y CSS, lint, typechecks, tests unitarios y pruebas de navegador.
+4. Genera el tarball en `releases/<version>-<sha256>/beez-ui-<version>.tgz` y valida su contenido, exports e integridad.
+5. Pushea el commit de release a la rama upstream configurada, sólo si sigue siendo el commit actual.
+6. Publica ese mismo artefacto en npm con acceso público y etiqueta `latest`.
 
-La publicación usa el cliente oficial de npm para admitir su flujo interactivo de verificación en el navegador/2FA. Instalación, build y checks siguen usando pnpm 12. Ejecutar desde una terminal interactiva cuando la cuenta requiera autenticación adicional. El token se carga sólo al publicar, no se imprime y se referencia mediante `${NPM_TOKEN}` en `.npmrc`.
+La publicación usa el cliente oficial de npm para admitir su flujo interactivo de verificación en el navegador/2FA. Instalación, build y checks siguen usando pnpm 12. Ejecutar desde una terminal interactiva cuando la cuenta requiera autenticación adicional. El token se carga sólo al publicar y no se imprime. El repositorio no tiene `.npmrc`: pnpm 12 ignora las variables de entorno en credenciales controladas por el repositorio y avisaba en cada comando. `release:publish` crea un config temporal de npm fuera del repositorio que sólo referencia `${NPM_TOKEN}` (npm lo expande desde el entorno; el token no se escribe en disco ni en la línea de comandos), lo pasa con `--userconfig` y lo borra al terminar, también si la publicación falla (`scripts/npm-auth.js`).
 
-El comando requiere una rama Git con upstream configurado. El commit se limita a los dos archivos de metadatos, incluidos sus cambios previos; revisar el código antes de ejecutar la release. No crea tags ni hace force push. Si cambian el checkout, el upstream o los metadatos durante las validaciones, se detiene. También comprueba que los hooks de Git no hayan agregado archivos ni alterado los metadatos validados antes de pushear. Si falla una validación, el commit o el push, no publica. Los metadatos de la nueva versión quedan disponibles: corregir el error, ejecutar `pnpm release:prepare`, commitear y pushear los metadatos y publicar el artefacto resultante. Si falla el push después del commit, resolver el problema y pushear ese commit antes de publicar el tarball preparado. Si falla la publicación, comprobar primero si npm recibió la versión y reintentar sólo la publicación del mismo tarball. No ejecutar nuevamente `create-version` para reintentar la misma release.
+El commit se limita a los dos archivos de metadatos, incluidos sus cambios previos; revisar el código antes de ejecutar la release. No crea tags ni hace force push. Si cambian el checkout, el upstream o los metadatos durante las validaciones, se detiene. También comprueba que los hooks de Git no hayan agregado archivos ni alterado los metadatos validados antes de pushear. Si falla una validación o el push, no publica y el commit de release queda en local: `pnpm create-version` lo detecta y retoma sólo lo que falte (preparar, pushear, publicar), sin volver a subir la versión. Si falla la publicación, comprobar primero si npm recibió la versión; si no, `pnpm create-version` reintenta sólo la publicación del mismo tarball.
 
 Los pasos individuales siguen disponibles:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "beez-ui",
-  "version": "0.6.0",
+  "version": "0.6.2",
   "description": "Shared UI components with the customizations extracted from TuTribu.",
   "type": "module",
   "sideEffects": [
@@ -289,7 +289,7 @@
     "eslint-plugin-react-hooks": "^7.1.1",
     "happy-dom": "^20.14.0",
     "lucide-react": "^1.41.0",
-    "next": "^16.3.4",
+    "next": "^16.3.6",
     "oxc-parser": "^0.149.0",
     "oxc-transform-react": "^0.149.0",
     "react": "^19.3.0",
@@ -338,7 +338,8 @@
     "lint": "eslint .",
     "test:browser": "pnpm build && playwright test",
     "build": "node scripts/build.js",
-    "create-version": "node scripts/create-version.js",
+    "create-version": "node scripts/release.js",
+    "cv": "node scripts/release.js",
     "release:prepare": "node scripts/prepare-release.js",
     "release:publish": "node scripts/publish-release.js",
     "storybook": "pnpm build && storybook dev -p 6006 --no-open",