mise-à-jour-spec-stack

Mettre à jour la spécification de la pile

Les faits (versions, dates, mesures, sources) que vous mettez à jour. Les décisions que vous proposez à l'auteur et attendez. Les arguments, s'ils sont donnés, nomment les outils à vérifier ; sinon vérifiez tout.

1. Inventaire

Depuis stack-spec.md, listez :

• chaque ligne du §2 avec sa ligne de version ;
• chaque version, date de publication ou affirmation de stabilité dans les §3 et §4 (« stable », « release candidate », « alpha », « expérimental », un numéro de version à côté d'un outil) ;
• chaque ligne de Revoir quand, comme condition à tester ;
• la date de version de l'en-tête.

2. Vérifier chaque élément auprès des sources primaires

Registre, notes de version, documentation officielle. Jamais de mémoire.

• npm : npm view <pkg> dist-tags time --json. Actuelle = la version la plus récente datant d'au moins 14 jours ; listez les versions plus récentes comme à venir.
• Outils nixpkgs (Node.js, Biome, nixfmt, Wrangler, navigateurs Playwright) : nix eval --raw nixpkgs#<pkg>.version sur nixos-unstable, plus la page de publication du projet.
• Fonctionnalités de plateforme (Cloudflare, support navigateur) : la page de documentation officielle et sa date.

Enregistrez par outil : la ligne de version de la spécification, la version actuelle, et si une version majeure (ou une version que la spécification attend) se trouve entre les deux.

3. Classifier chaque changement

Lisez intégralement le journal des modifications ou le guide de migration de chaque nouvelle version majeure, ainsi que la documentation sur laquelle la spécification s'appuie. Classez ensuite :

• Fait (ligne de version, date, nombre de paquets) : mettez-le à jour.
• Raison (un inconvénient mentionné corrigé, un nouveau introduit) : mettez à jour le texte de la raison ; listez-la dans le rapport.
• Décision (le choix lui-même, une alternative désormais meilleure, un déclencheur Revoir quand activé) : ne modifiez pas. Rapportez : ce qui a changé, la source, les options avec coûts, la recommandation. Attendez.

4. Éditer

• Gardez le style de la spécification : concis, règle d'abord, raison après, dates ISO ; marquez le texte de décision modifié par « Amendé : … ».
• Nouveau fait → nouvelle source à la fin de la liste numérotée, avec « vérifié ». Ne renumérotez jamais les sources ; supprimez-en une seulement si rien ne la cite.
• Ne renumérotez jamais les sections. Un nouveau sujet devient la sous-section suivante de sa section ; demandez à l'auteur si un site utilise déjà ce numéro, et rapportez le numéro choisi.
• Mettez à jour la date de version de l'en-tête.
• Ne nommez aucun site, utilisateur ou dépôt qui utilise la spécification.

5. Vérifier et valider

• Chaque nouvelle URL ou URL modifiée résout : curl -sIL <url>.
• Aucun site, utilisateur ou dépôt qui utilise la spécification n'est nommé.
• Jujutsu, signé, un commit par thème (par exemple « Enregistrer Astro 8 », « Proposer TypeScript 7 »), le message indiquant ce qui a changé, pourquoi, et les sources vérifiées. N'effectuez pas de push sauf demande explicite.

6. Rapport

Par outil : version de la spécification → version actuelle. Ensuite : faits mis à jour, raisons modifiées, décisions proposées avec recommandations, versions à venir pas encore âgées de 14 jours.