<!-- 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.