v0.1.0-pre.074-fix001

docs/rules/VERSION_DEVELOPMENT_LIFECYCLE.md

@@ -0,0 +1,89 @@
+<!-- file: docs/rules/VERSION_DEVELOPMENT_LIFECYCLE.md -->
+<!-- version: 1 -->
+
+# Cycle de développement d’une version fonctionnelle
+
+## 1. Objet
+
+Toute nouvelle version fonctionnelle doit être préparée, exécutée et clôturée selon un cycle documentaire explicite.
+
+La numérotation du plan suit la version réellement décidée. Le plan ne détermine pas artificiellement le numéro de version.
+
+## 2. Première prerelease obligatoire
+
+La première prerelease d’une nouvelle version fonctionnelle, généralement `X.Y.Z-pre.001`, doit prioritairement :
+
+- étudier les objectifs de la version ;
+- inventorier les capacités existantes réutilisables ;
+- identifier les dépendances et prérequis ;
+- définir les éléments hors périmètre ;
+- relever les risques, ambiguïtés et validations nécessaires ;
+- produire un plan structuré des étapes de développement ;
+- proposer un découpage approximatif des futures prereleases ;
+- définir les critères de clôture fonctionnelle et documentaire.
+
+Une version importante ne doit pas commencer directement par une modification fonctionnelle dispersée sans ce cadrage.
+
+## 3. Plan temporaire de version
+
+Lorsque la version contient plusieurs lots ou décisions architecturales, créer un document temporaire de planification.
+
+Ce document peut contenir davantage d’explications que le ROADMAP général :
+
+- pourquoi les étapes sont ordonnées ainsi ;
+- alternatives examinées ;
+- dépendances entre lots ;
+- validations intermédiaires ;
+- points de décision ;
+- reports possibles ;
+- critères d’arrêt ou de réorientation.
+
+Le plan reste approximatif. Il peut évoluer lorsque le code, les tests ou les sources officielles révèlent de nouvelles contraintes.
+
+## 4. Développement par prereleases
+
+Chaque prerelease doit :
+
+- traiter un lot cohérent ;
+- mettre à jour les changelogs des crates réellement affectées ;
+- retirer des TODO les tâches réellement terminées ;
+- mettre à jour le plan temporaire lorsque l’ordre ou le périmètre change ;
+- exécuter les validations exigées par les règles du workspace ;
+- livrer un `delta.md` traçant les changements.
+
+Les correctifs mineurs d’une prerelease sont repliés dans son entrée de changelog. Un correctif substantiel peut recevoir une entrée dédiée selon les règles documentaires.
+
+## 5. Dernière prerelease de finalisation
+
+La dernière prerelease d’une version fonctionnelle doit principalement :
+
+- exécuter les validations finales ;
+- corriger les écarts résiduels ;
+- finaliser la documentation générale ;
+- finaliser les documents des crates modifiées ou ajoutées ;
+- supprimer des TODO les tâches clôturées ;
+- reporter explicitement les tâches non réalisées ;
+- transformer le plan temporaire en état final utile au ROADMAP ;
+- mettre à jour le changelog général pour la version `X.Y.Z` ;
+- préparer l’archive ou la livraison finale.
+
+Le ROADMAP conserve les objectifs et trajectoires utiles. Il ne doit pas devenir un journal détaillé des prereleases.
+
+## 6. Archivage du plan
+
+Après clôture de la version :
+
+- le plan temporaire n’est plus normatif ;
+- ses informations durables doivent avoir été reprises dans le ROADMAP, les décisions, guides, TODO ou changelogs appropriés ;
+- le plan doit être déplacé sous `olddocs/archivekbot3/` ;
+- ses références actives doivent être corrigées avant archivage.
+
+## 7. Arrêt anticipé d’une version
+
+Lorsqu’une version est interrompue pour une migration, une urgence ou un changement de priorité :
+
+- documenter l’état réellement atteint ;
+- distinguer les capacités terminées des travaux incomplets ;
+- reporter les tâches restantes vers une version identifiée ;
+- mettre à jour les changelogs concernés ;
+- archiver le plan après reprise de ses informations utiles.