0.0.5-alpha.4

docs/rules/300-DOCUMENTATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/300-DOCUMENTATION.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Documentation rules
 
@@ -47,9 +47,9 @@ Il SHOULD NOT devenir un fichier monolithique contenant toutes les règles spéc
 
 ### `ROADMAP.md`
 
-`ROADMAP.md` décrit la trajectoire macro du projet : objectifs de versions, grandes étapes et ordre fonctionnel attendu.
+`ROADMAP.md` décrit la trajectoire macro **engagée** du projet : objectifs de versions, grandes étapes et ordre fonctionnel attendu. Elle n'est ni un catalogue de toutes les possibilités futures, ni une obligation de prévoir arbitrairement plusieurs versions à l'avance.
 
-Il MUST NOT devenir un journal des prereleases ou recopier les histories de tranche.
+Il MUST NOT devenir un journal des prereleases ou recopier les histories de tranche. Une idée, une étude ou une possibilité encore spéculative reste chez son owner tant qu'une décision suffisante ne justifie pas son entrée dans la trajectoire engagée.
 
 Lorsqu'un projet utilise des statuts de roadmap, la convention PGR est :
 
@@ -62,6 +62,30 @@ Lorsqu'un projet utilise des statuts de roadmap, la convention PGR est :
 
 Une autre convention MAY être adoptée par un projet si elle est explicitement définie et cohérente.
 
+Une roadmap à horizon fini est valide. Le projet MUST NOT inventer un numéro de version, un objectif ou un engagement uniquement pour éviter que la roadmap se termine.
+
+### Revue d'horizon
+
+Une revue d'horizon est une activité de gouvernance qui décide si la trajectoire macro connue doit être étendue, maintenue volontairement ouverte, mise en pause ou considérée accomplie. Elle n'est pas une nouvelle phase SemVer.
+
+Une revue SHOULD être planifiée lorsque l'un des signaux suivants devient pertinent :
+
+- la release courante ou la suivante est la dernière entrée engagée de la roadmap alors que le projet doit continuer ;
+- un jalon important change ce qu'il est raisonnable de planifier ensuite ;
+- plusieurs ideas/studies ou décisions récentes peuvent modifier la trajectoire ;
+- les hypothèses qui fondaient les versions futures ont été invalidées par le travail réel.
+
+La revue MAY avoir lieu dans une tranche de la release courante ou dans une session stratégique séparée. Une session séparée ne change pas `VERSION` par elle-même.
+
+Une revue d'horizon produit l'un des résultats utiles suivants :
+
+- **étendre** `ROADMAP.md` avec des objectifs suffisamment décidés ;
+- **laisser l'horizon ouvert** et enregistrer le déclencheur ou le moment de la prochaine revue ;
+- **différer/mettre en pause** une trajectoire sans fabriquer de remplaçant ;
+- **constater l'accomplissement** de l'objectif macro si aucune suite n'est nécessaire.
+
+Le plan actif SHOULD indiquer si une telle revue est nécessaire avant sa fermeture et où elle aura lieu.
+
 ### `CHANGELOG.md`
 
 `CHANGELOG.md` décrit les changements utiles aux utilisateurs ou intégrateurs d'une release.
@@ -131,6 +155,22 @@ Si une décision est déjà imposée par une contrainte explicite et qu'aucune a
 
 Les décisions durables doivent ensuite être reflétées dans l'architecture, les règles, objectifs ou autres documents vivants qui possèdent réellement ce contrat.
 
+La maturation typique MAY suivre :
+
+```text
+idea
+  ↓
+study
+  ↓
+decision durable / architecture / règle
+  ↓
+roadmap ou plan lorsqu'un engagement de réalisation existe
+  ↓
+implementation
+```
+
+Toutes les possibilités n'ont pas à parcourir cette chaîne. Une idée ou une étude MAY être rejetée, différée, superseded ou rester inconclusive. Une conclusion `retained` ne crée pas automatiquement une promesse de roadmap : le passage vers `ROADMAP.md` exige encore une décision d'engagement macro explicite.
+
 ## Documents vivants et snapshots historiques
 
 PGR distingue :