0.0.3-alpha.1.fix.1

docs/rules/210-WORKFLOW.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/210-WORKFLOW.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Workflow local Knowledge
 
@@ -102,7 +102,11 @@ Les commandes ne sont pas différées à une réponse ultérieure. Lorsque le de
 
 ## Prompts et changement de session
 
-Un prompt de démarrage versionné décrit la baseline exacte, les sources requises, la mission et les vérifications nécessaires pour ouvrir une release. Il ne complète pas silencieusement des données manquantes par un état supposé d'une conversation ou d'un workspace non vérifié.
+Un prompt de démarrage versionné décrit la baseline attendue, les sources requises, la mission et les vérifications nécessaires pour ouvrir une release. Il ne complète pas silencieusement des données manquantes par un état supposé d'une conversation ou d'un workspace non vérifié.
+
+Le cycle normal prépare le prompt de la release `N+1` pendant les dernières phases de `N`, après la revue d'horizon qui a suffisamment défini la prochaine mission et avant la clôture stable de `N`. Comme le commit/tag/rapport post-tag définitifs de `N` n'existent pas encore à ce moment, le prompt versionné ne doit pas inventer leur SHA ou leur résultat : il exige que l'introduction de la session suivante fournisse l'archive taggée et le rapport post-tag réels et qu'ils soient vérifiés avant développement.
+
+Si une stable historique a été fermée sans prompt de la release suivante parce que la mission n'était pas encore décidée, le prompt peut exceptionnellement être créé au démarrage réel de cette release ; cette situation est un rattrapage et non le cycle normal.
 
 Une coupure de session au milieu d'une tranche ne change pas `VERSION`. Si nécessaire, un handoff local décrit l'état exact, les décisions acquises, les preuves déjà obtenues et ce qui reste à exécuter.
 
@@ -116,7 +120,7 @@ Le tag stable `vX.Y.Z` est créé seulement après le commit stable. L'archive t
 
 Le rapport post-tag `sasedev-knowledge-X.Y.Z-publish.001-report.md` est une preuve distincte. Il vérifie le tag/archive réellement publiés et ne doit pas être préfabriqué comme preuve du delta `rel.1`.
 
-Le prompt d'une release suivante n'est préparé que si sa mission est réellement décidée. Aucune version future n'est inventée pour remplir un handoff.
+Le prompt d'une release suivante n'est préparé que si sa mission est suffisamment décidée par la revue d'horizon. Lorsqu'elle l'est, ce prompt fait partie des artefacts de fin de la release courante afin que la stable publiée contienne déjà son handoff vers la suite. Les éléments post-tag encore inconnus restent à vérifier au démarrage suivant plutôt qu'à être inventés.
 
 ## Immutabilité des artefacts historiques
 

docs/rules/300-DOCUMENTATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/300-DOCUMENTATION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Documentation locale Knowledge
 
@@ -22,9 +22,9 @@ La révision documentaire augmente lorsqu'un contenu réel du fichier change ; e
 
 `RULES.md` est l'entrée normative locale et renvoie vers les owners détaillés sous `docs/rules/`.
 
-`ROADMAP.md` décrit les objectifs et horizons produits réellement engagés. Il ne sert ni de journal quotidien ni de catalogue exhaustif des prereleases. Une version future n'y est pas réservée sans mission réelle.
+`ROADMAP.md` décrit la release en cours et un horizon borné des prochaines releases. Il distingue explicitement une mission engagée d'une version d'horizon encore révisable ; l'horizon sert à ordonner les dépendances et à préparer la suite sans transformer chaque intention en engagement irrévocable. Il ne sert ni de journal quotidien ni de catalogue exhaustif des prereleases.
 
-`CHANGELOG.md` synthétise les changements utiles aux jalons de release. Les fixes et essais alpha internes ne sont pas transformés en catalogue exhaustif lorsque leur détail appartient déjà aux deltas/histories.
+`CHANGELOG.md` synthétise les changements réellement acquis d'une release. Il n'est normalement pas rédigé au démarrage ou pendant le cadrage alpha à partir d'intentions : une entrée candidate est préparée vers les phases de stabilisation, lorsque l'implémentation et les histories permettent de décrire ce qui existe effectivement, puis finalisée avant la promotion stable. Les fixes et essais alpha internes ne sont pas transformés en catalogue exhaustif lorsque leur détail appartient déjà aux deltas/histories.
 
 `docs/000-README.md` indexe la documentation durable et fournit le chemin de lecture principal.
 
@@ -64,14 +64,16 @@ Le plan est mis à jour lorsqu'une hypothèse de pilotage devient fausse, pas po
 
 ## Revue d'horizon
 
-Lorsqu'une release approche de sa stabilisation et que la suite n'est pas déjà décidée, une revue d'horizon explicite détermine s'il faut engager une prochaine mission, maintenir les domaines futurs non numérotés ou reclasser un `DEFER`.
+Lorsqu'une release approche de sa stabilisation, une revue d'horizon explicite réévalue la release suivante et, autant que les dépendances sont suffisamment connues, au moins les deux releases d'horizon qui la suivent. Elle peut engager la prochaine mission, réordonner ou scinder un horizon, maintenir un domaine non numéroté ou reclasser un `DEFER`.
 
-La revue n'invente pas un numéro de version uniquement pour assurer la continuité documentaire.
+Une version marquée comme horizon n'est pas encore une promesse de scope : son numéro et sa mission peuvent changer à la revue suivante. La roadmap doit néanmoins donner assez de visibilité pour que la release en cours soit développée dans une trajectoire produit cohérente plutôt qu'en isolation.
 
 ## Prompts de nouvelle session
 
 Un prompt normal Knowledge repart de la stable Knowledge, de son rapport post-tag lorsqu'il existe, puis du prompt versionné local. Il vérifie les artefacts Knowledge locaux avant de préparer la tranche suivante.
 
+Le prompt de la release suivante est normalement rédigé pendant les dernières phases de la release courante, après sa revue d'horizon. Il fait partie du handoff livré par la stable courante. Les identifiants post-tag qui n'existent pas encore lors de sa rédaction ne sont pas inventés : la session suivante les reçoit dans son texte d'introduction et les vérifie contre l'archive et le rapport réellement publiés.
+
 Il MUST NOT demander de rechercher ou charger PGR ou un autre référentiel externe, sauf lorsque cette release contient explicitement une réévaluation/adoption de ce référentiel.
 
 Le pattern local est [`../templates/001-NEW_SESSION_PROMPT.md`](../templates/001-NEW_SESSION_PROMPT.md).