update-stack-spec

Actualizar la especificación de la pila

Los hechos (versiones, fechas, mediciones, fuentes) los actualizas. Las decisiones las propones al autor y esperas. Los argumentos, si se proporcionan, nombran las herramientas a verificar; de lo contrario, verifica todas.

1. Inventario

Desde stack-spec.md, enumera:

• cada fila de §2 con su línea de versión;
• cada versión, fecha de lanzamiento o afirmación de estabilidad en §3 y §4 ("estable", "candidato a lanzamiento", "alfa", "experimental", un número de versión junto a una herramienta);
• cada fila de Revisitar cuando, como una condición a probar;
• la fecha de versión del encabezado.

2. Verificar cada elemento contra fuentes primarias

Registro, notas de lanzamiento, documentación oficial. Nunca de memoria.

• npm: npm view <pkg> dist-tags time --json. Actual = la versión más reciente con al menos 14 días de antigüedad; enumera las versiones más jóvenes como próximas.
• herramientas de nixpkgs (Node.js, Biome, nixfmt, Wrangler, navegadores Playwright): nix eval --raw nixpkgs#<pkg>.version en nixos-unstable, más la página de lanzamiento del proyecto.
• Funcionalidades de plataforma (Cloudflare, soporte de navegadores): la página de documentación oficial y su fecha.

Registra por herramienta: la línea de versión del spec, la versión actual, y si hay un lanzamiento mayor (o un lanzamiento que el spec espera) entre medio.

3. Clasificar cada cambio

Lee cada nuevo registro de cambios mayor o guía de migración completo, y la documentación en la que se basa el spec. Luego clasifica:

• Hecho (línea de versión, fecha, recuento de paquetes): actualízalo.
• Razón (una desventaja declarada corregida, una nueva introducida): actualiza el texto de la razón; enumérala en el informe.
• Decisión (la elección misma, una alternativa ahora mejor, un desencadenante de Revisitar cuando activado): no edites. Informa: qué cambió, fuente, opciones con costos, recomendación. Espera.

4. Editar

• Mantén el estilo del spec: conciso, regla primero, razón después, fechas ISO; marca el texto de decisión cambiado "Enmendado : …".
• Nuevo hecho → nueva fuente al final de la lista numerada, con "verificado ". Nunca renumeres las fuentes; elimina una solo cuando nada la cite.
• Nunca renumeres las secciones. Un nuevo tema se convierte en la siguiente subsección de su sección; pregunta al autor si un sitio ya usa ese número, e informa el número elegido.
• Actualiza la fecha de versión del encabezado.
• No nombres ningún sitio, usuario o repositorio que use el spec.

5. Verificar y confirmar

• Cada URL nueva o cambiada se resuelve: curl -sIL <url>.
• No se nombra ningún sitio, usuario o repositorio que use el spec.
• Jujutsu, firmado, un commit por tema (ej. "Registrar Astro 8", "Proponer TypeScript 7"), el mensaje indicando qué cambió, por qué y las fuentes verificadas. No hagas push a menos que se solicite.

6. Informar

Por herramienta: versión del spec → actual. Luego: hechos actualizados, razones cambiadas, decisiones propuestas con recomendaciones, próximos lanzamientos que aún no tienen 14 días de antigüedad.