0.0.3-alpha.1.fix.1

docs/templates/001-NEW_SESSION_PROMPT.md

@@ -1,25 +1,42 @@
 <!-- file: docs/templates/001-NEW_SESSION_PROMPT.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Pattern local — prompt de nouvelle session
 
 ## Usage
 
-Ce pattern prépare le court message opérateur remis après une stable Knowledge publiée. Le prompt détaillé reste un fichier versionné sous `prompts/`.
+Ce pattern prépare le prompt versionné qui permettra d'ouvrir une future release Knowledge.
+
+Le cycle normal crée le prompt de `N+1` pendant les dernières phases de la release `N`, après une revue d'horizon ayant suffisamment défini la mission suivante et avant la clôture stable de `N`. Il doit donc être présent dans la stable `N` publiée.
 
 Une session normale Knowledge ne consulte pas PGR. Une mention PGR n'apparaît que lorsque la release cible contient explicitement une réévaluation/adoption PGR.
 
-## Forme normale
+## Informations connues à la rédaction
 
-Lorsque le rapport post-tag de la baseline est `PASS` :
+Pendant la fin de `N`, les éléments suivants peuvent être établis :
 
 ```text
-Partir de l'archive sasedev-knowledge-vX.Y.Z.zip téléchargée depuis le tag Gitea vX.Y.Z et du rapport post-tag sasedev-knowledge-X.Y.Z-publish.001-report.md. Lire et exécuter prompts/NNN-<NEXT_RELEASE>_START_PROMPT.md. Vérifier intégralement l'archive Knowledge, les règles locales, la gouvernance, l'architecture, la structure documentaire, les deltas/histories, les décisions différées et la cohérence globale avant de préparer <NEXT_RELEASE>-alpha.1.
+release stable attendue   N
+release suivante          N+1
+mission de N+1            décidée par la revue d'horizon
+chemin du prompt           prompts/NNN-<NEXT_RELEASE>_START_PROMPT.md
 ```
 
-`X.Y.Z` désigne la stable autoritaire de départ et `<NEXT_RELEASE>` la release suivante réellement décidée ; ces deux valeurs ne sont pas supposées identiques.
+Le commit stable exact, le SHA-256 de l'archive taggée et le résultat du rapport post-tag de `N` n'existent pas encore nécessairement. Le prompt MUST NOT inventer ces valeurs.
 
-Les noms et versions sont remplacés uniquement par des valeurs établies. Si le rapport post-tag n'existe pas ou n'est pas `PASS`, il n'est pas présenté comme preuve.
+## Forme normale du texte d'introduction de la session suivante
+
+Après publication réelle de `N`, l'opérateur fournit :
+
+```text
+Partir de l'archive sasedev-knowledge-vX.Y.Z.zip téléchargée depuis le tag Gitea vX.Y.Z et du rapport post-tag sasedev-knowledge-X.Y.Z-publish.001-report.md. Considérer cette stable comme la baseline autoritaire de SaseDev Knowledge. Lire et exécuter prompts/NNN-<NEXT_RELEASE>_START_PROMPT.md. Vérifier intégralement l'archive, les règles et owners normatifs locaux, la gouvernance, l'architecture, la structure documentaire, les deltas/histories, les décisions DEFER, la revue d'horizon et la cohérence globale avant de préparer <NEXT_RELEASE>-alpha.1.
+```
+
+Le prompt versionné exige alors de vérifier que l'archive et le rapport fournis correspondent réellement à la stable publiée avant tout développement.
+
+## Rattrapage exceptionnel
+
+Si une stable a été fermée sans prompt suivant parce qu'aucune mission n'était encore décidée, le prompt MAY être créé lors de l'ouverture réelle de la release suivante. Ce cas est documenté comme rattrapage ; il ne devient pas le cycle normal.
 
 ## Réévaluation externe explicite
 

docs/templates/002-RELEASE_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/templates/002-RELEASE_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Pattern local — plan de release
 
@@ -30,4 +30,8 @@ Le nombre de tranches n'est pas fixé. Les phases annoncées restent sous `## Tr
 
 Le plan pilote le travail restant ; il n'est pas un journal de commandes. Les preuves détaillées vivent dans `history/` et les règles durables vivent chez leur owner local.
 
-Un REPLAN met à jour la trajectoire et les responsabilités devenues fausses. Aucune version postérieure n'est réservée uniquement pour remplir la roadmap.
+Un REPLAN met à jour la trajectoire et les responsabilités devenues fausses.
+
+La revue d'horizon de fin de release doit réévaluer la prochaine mission et un horizon borné au-delà d'elle. Lorsque `N+1` est suffisamment décidée, la fin de `N` prépare aussi son prompt versionné de démarrage afin que la stable `N` contienne déjà le handoff vers la suite.
+
+Le changelog n'est pas une intention du plan : son entrée de release est préparée vers la stabilisation à partir du résultat réellement matérialisé, puis finalisée avant la promotion stable.