0.0.5-alpha.4

docs/templates/003-NEW_SESSION_PROMPT.md

@@ -1,24 +1,25 @@
 <!-- file: docs/templates/003-NEW_SESSION_PROMPT.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Spécification du prompt manuel de nouvelle session
 
 ## Usage
 
-Cette spécification sert à préparer un court message de reprise après une stable publiée. Le prompt de démarrage propre à la version suivante reste un fichier `prompts/NNN-VX_Y_Z_START_PROMPT.md` finalisé selon [`210-WORKFLOW.md`](../rules/210-WORKFLOW.md). Le message manuel indique où commencer et quelles preuves fournir ; il ne copie ni ce prompt, ni le plan, ni le history de la release.
+Cette spécification sert à préparer le court message opérateur remis après une stable publiée. Le prompt de démarrage propre à la version suivante reste un fichier `prompts/NNN-VX_Y_Z_START_PROMPT.md` finalisé selon [`210-WORKFLOW.md`](../rules/210-WORKFLOW.md). Le message manuel indique où commencer et quelles preuves fournir ; il ne copie ni ce prompt, ni le plan, ni le history de la release.
 
-La comparaison des prompts PGR `002` et `003` montre une structure récurrente (baseline taggée, cible, première tranche et mission). `003` ajoute le rapport de vérification post-tag et un texte transmis explicitement à l'opérateur. Une forme courte commune réduit les oublis lors de la clôture suivante, sans rendre obligatoires des champs propres à PGR dans les autres projets.
+Lorsque la cible suivante est connue et que la vérification post-tag applicable est terminée, ce message doit être remis spontanément à l'opérateur sans attendre qu'il le réclame. Lorsque la cible suivante n'est pas suffisamment décidée, PGR ne fabrique pas de version ou de prompt : le message de clôture indique que l'horizon reste ouvert et pointe vers le handoff ou la revue d'horizon applicable.
 
 ## Champs à renseigner
 
-1. **Baseline** : identifier le tag stable, le nom réel de l'archive source téléchargée depuis ce tag et la forge d'origine. Une archive sans `.git` demande une vérification interne ; elle ne prouve pas à elle seule le commit du tag.
-2. **Preuve post-tag** : si un rapport de publication/vérification distinct existe et est réellement `PASS`, indiquer son chemin exact et le joindre. Sinon, signaler explicitement qu'il est absent ou que son état n'est pas `PASS` ; ne jamais fabriquer cette preuve ni la confondre avec le tag.
+1. **Baseline** : identifier le tag stable, le nom réel de l'archive source téléchargée depuis ce tag et la forge d'origine. Une archive sans `.git` est normale pour une archive de tag et se vérifie par sa cohérence interne ; elle ne porte pas elle-même les métadonnées Git du dépôt.
+2. **Preuve post-tag** : si un rapport de publication/vérification distinct existe et est réellement `PASS`, indiquer son chemin exact et demander qu'il soit fourni avec l'archive. Sinon, signaler explicitement son état réel ; ne jamais fabriquer cette preuve ni la confondre avec le tag.
 3. **Contrat de reprise** : indiquer le chemin du prompt `prompts/NNN-VX_Y_Z_START_PROMPT.md` existant dans la baseline, la version cible et la première tranche attendue. Le prompt versionné possède la mission détaillée et le scope de la release.
 4. **Intake** : demander la vérification de l'archive, des règles applicables, de la gouvernance, de la structure documentaire et des deltas/histories avant de préparer la première tranche. Adapter la liste aux artefacts effectivement présents et aux risques du projet.
+5. **Horizon ouvert** : si aucune version suivante n'est encore suffisamment décidée, remplacer le contrat de reprise de version par l'instruction exacte de revue/handoff applicable ; ne pas inventer un `NEXT` artificiel.
 
 ## Forme à remplir et à remettre
 
-Après vérification des chemins et de l'état réel du rapport, écrire **une seule phrase** adaptée au projet. Si le rapport est `PASS` et fourni :
+Après vérification des chemins et de l'état réel du rapport, écrire **une seule phrase** adaptée au projet lorsque la cible suivante est connue. Si le rapport est `PASS` et fourni :
 
 ```text
 Partir de l'archive <nom exact du ZIP issu du tag vX.Y.Z> et du rapport post-tag <chemin exact du rapport PASS>. Lire et exécuter <chemin du prompt de démarrage dans la baseline>. Vérifier l'archive, les règles, la gouvernance, la structure documentaire, les deltas/histories et la cohérence globale avant de préparer <version cible-alpha.1>.
@@ -26,4 +27,6 @@ Partir de l'archive <nom exact du ZIP issu du tag vX.Y.Z> et du rapport post-tag
 
 Si le rapport est absent ou non validé, retirer « et du rapport post-tag ... » de la phrase et préciser séparément son état réel à la nouvelle session. Conserver les noms exacts de la forge et des fichiers du projet : la forme `<nom exact du ZIP>` n'est qu'un champ de rédaction.
 
-Rédiger le texte manuel à la clôture après le contrôle de l'archive publiée et le remettre à l'opérateur. Une interruption au milieu d'une prerelease suit le mécanisme de reprise de la tranche courante prévu dans `210-WORKFLOW.md` ; elle ne crée pas artificiellement un nouveau prompt de version.
+Si l'horizon est ouvert, remettre plutôt une consigne courte qui identifie la stable publiée, les preuves disponibles et le handoff/revue d'horizon à reprendre. Cette consigne ne doit contenir ni numéro de version hypothétique, ni faux prompt de démarrage.
+
+Une interruption au milieu d'une prerelease suit le mécanisme de reprise de la tranche courante prévu dans `210-WORKFLOW.md` ; elle ne crée pas artificiellement un nouveau prompt de version.

docs/templates/005-RELEASE_PLAN.md

@@ -0,0 +1,85 @@
+<!-- file: docs/templates/005-RELEASE_PLAN.md -->
+<!-- version: 1 -->
+
+# Pattern — plan de release
+
+## Usage
+
+Ce pattern aide un projet gouverné par PGR à construire un plan de release suffisamment précis pour piloter plusieurs tranches sans transformer le plan en journal d'activité. Il complète `alpha.1` et [`210-WORKFLOW.md`](../rules/210-WORKFLOW.md) ; il n'impose ni le titre exact des sections, ni un nombre fixe de prereleases.
+
+Un petit changement qui ne nécessite pas de plan dédié n'a pas à instancier ce pattern.
+
+## Contrat minimal
+
+Un plan utile doit permettre de comprendre :
+
+- d'où part la release et quelle mission elle doit rendre vraie ;
+- ce qui est acquis, ouvert, inclus et explicitement hors-scope ;
+- comment les risques, validations et smokes importants seront traités ;
+- comment le travail est découpé actuellement et quels signaux imposeraient un REPLAN ;
+- **où et quand la release sera clôturée** : documentation durable, `CHANGELOG`, `ROADMAP`, prompt/handoff suivant, plan et publication ;
+- si l'horizon de roadmap doit être revu avant la fermeture et, si oui, à quel moment ou selon quel déclencheur.
+
+## Forme candidate
+
+```markdown
+# Plan X.Y.Z — <mission courte>
+
+## Statut et sources
+
+Baseline, prompt, rapports ou corpus réellement autoritaires.
+
+## Mission
+
+Résultat attendu de la release.
+
+## État acquis et questions ouvertes
+
+Décisions déjà établies et points qui doivent encore être instruits.
+
+## Scope et hors-scope
+
+Frontières fonctionnelles, techniques et documentaires.
+
+## Stratégie de validation
+
+Gates, smokes et preuves importantes ; renvois vers la matrice plutôt que copie exhaustive.
+
+## Trajectoire prévisionnelle
+
+Responsabilité attendue de chaque tranche. Le forecast reste révisable.
+
+## Déclencheurs de REPLAN
+
+Signaux qui obligeraient à recalculer le travail restant.
+
+## Clôture et transition
+
+- réconciliation documentaire durable : <tranche/moment> ;
+- entrée CHANGELOG candidate/finale : <tranche/moment> ;
+- revue/mise à jour ROADMAP : <tranche/moment> ;
+- prompt ou handoff de reprise : <tranche/moment ou cible encore ouverte> ;
+- fermeture du plan : <tranche/moment> ;
+- promotion stable et vérification post-tag : <mécanisme>.
+
+## Revue d'horizon
+
+- état : <non nécessaire / requise / horizon volontairement ouvert> ;
+- raison : <pourquoi> ;
+- moment ou déclencheur : <quand> ;
+- sorties autorisées : <étendre / laisser ouvert / différer-pause / objectif accompli>.
+```
+
+## Règles d'adaptation
+
+Le plan doit rester proportionné. Une responsabilité déjà possédée par une règle, une matrice ou une étude est référencée plutôt que recopiée. Les résultats détaillés des gates restent dans `history/`.
+
+La rubrique `Clôture et transition` est un contrat d'attribution des responsabilités, pas l'obligation d'exécuter tous les travaux en fin de release. Une documentation directement liée à une fonctionnalité continue d'évoluer dans la tranche qui la modifie.
+
+La rubrique `Revue d'horizon` peut simplement indiquer qu'aucune revue n'est nécessaire parce que la roadmap s'étend déjà suffisamment. Si la prochaine version n'est pas décidée, cette rubrique doit l'assumer explicitement plutôt que fabriquer une roadmap.
+
+PGR n'impose pas un journal de révisions systématique dans le plan. Un REPLAN met à jour les parties devenues fausses et le delta/history correspondant conserve la preuve du changement.
+
+## Critère de sortie
+
+Le plan est prêt lorsqu'il autorise le développement sans laisser ambiguës les responsabilités de fermeture, les validations majeures ni le devenir de l'horizon macro. Après stable, abandon ou supersession, il devient une référence historique de la release.