0.0.5-alpha.4

2026-09-25 00:03:51 +02:00
parent a954d7f90a
commit defc9ca4b5
12 changed files with 606 additions and 34 deletions
--- a/docs/000-README.md
+++ b/docs/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 11 -->
+<!-- version: 12 -->

 # Documentation PGR

@@ -25,6 +25,7 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
 - [`plans/005-V0_0_5_RECONCILIATION_PLAN.md`](plans/005-V0_0_5_RECONCILIATION_PLAN.md) — cadrage, classification et trajectoire active de la réconciliation `0.0.5` ;
 - [`studies/001-KSP_GAMES_RECONCILIATION.md`](studies/001-KSP_GAMES_RECONCILIATION.md) — inventaire comparatif des baselines KSP/Games et décisions de généralisation, maintien local ou différé.
 - [`templates/004-FILE_FAMILY_CONTRACTS.md`](templates/004-FILE_FAMILY_CONTRACTS.md) — pattern facultatif pour expliciter les responsabilités et règles de modification de familles de fichiers locales lorsque la complexité le justifie.
+- [`templates/005-RELEASE_PLAN.md`](templates/005-RELEASE_PLAN.md) — pattern de plan de release avec clôture/transition explicites et revue d'horizon proportionnée.

 ## Points d'entrée de 0.0.4

--- a/docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
+++ b/docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
@@ -1,5 +1,5 @@
 <!-- file: docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->

 # Plan 0.0.5 — réconciliation réelle avec KSP et sasedev-games

@@ -40,6 +40,14 @@ L'audit classe la majorité des mécanismes de gouvernance, documentation, valid

 Les audits composites, le Web autonome, WASM, JNI, règles serveur, distribution Games et frontières métier KSP restent différés ou locaux.

+## REPLAN alpha.4 — lifecycle inter-release et horizon
+
+La gate `alpha.3.fix.1` a validé son correctif local. Une revue séparée du plan, de `ROADMAP.md` et des historiques de conception PGR `0.0.1` à `0.0.4` a ensuite confirmé un besoin général non couvert explicitement par le forecast initial : PGR sait piloter une release active, mais n'assigne pas encore assez strictement **où/quand sa fermeture et sa transition sont préparées**, ni **quand l'horizon des versions futures doit être rediscuté**.
+
+Les historiques montrent que plusieurs briques avaient déjà été décidées séparément — moment du `CHANGELOG`, `ROADMAP`, prompt suivant, `REPLAN`, abandon/supersession, continuation inter-session, handoff et distinction `rel.001`/`publish.001`. Le problème n'est donc pas d'inventer un second workflow, mais de les relier dans le contrat du plan et d'éviter qu'elles restent implicites.
+
+Ce constat déclenche le point de décision `REPLAN` prévu par `alpha.1`. Aucun travail antérieur n'est invalidé. Les anciennes tranches `alpha.4` à `alpha.6` sont décalées d'un numéro et restent dans le scope.
+
 ## Trajectoire prévisionnelle

 ### alpha.1 — audit indépendant, étude et plan
@@ -56,21 +64,35 @@ Le template manuel `003-NEW_SESSION_PROMPT.md` reste distinct : il sert au court

 Étendre `300-DOCUMENTATION.md` et la fondation `001` uniquement si nécessaire pour décrire un registre local facultatif des fichiers ou familles dont le rôle et les règles de modification méritent d'être explicites. Fournir une spécification/template documentaire courte plutôt qu'un catalogue universel.

-Le pattern ne doit pas imposer `FILE_CONTRACTS.md` à un petit projet, ni recopier les rôles déjà possédés par PGR.
+Le pattern ne doit pas imposer `FILE_CONTRACTS.md` à un petit projet, ni recopier les rôles déjà possédés par PGR. Le correctif `alpha.3.fix.1` a en outre renforcé l'audit des tables Markdown fenced sans modifier ce scope fonctionnel.

-### alpha.4 — audit Rust de façade/export completeness
+### alpha.4 — REPLAN : clôture, transition et revue d'horizon
+
+Formaliser le lifecycle inter-release qui manquait au plan initial :
+
+- imposer à un plan de release suffisamment complexe d'attribuer noir sur blanc les responsabilités de clôture/transition ;
+- définir la revue d'horizon sans imposer un nombre artificiel de versions futures ;
+- expliciter le passage `idea/study → décision durable → roadmap/plan` ;
+- confirmer qu'une discussion stratégique peut vivre dans une session séparée sans changer `VERSION` ;
+- rendre spontané le message manuel de reprise lorsque la prochaine cible est connue ;
+- permettre la livraison `history courant + delta suivant` dans une même réponse lorsque la suite est déterministe, tout en maintenant deux archives et l'ordre commit/apply ;
+- fournir un pattern réutilisable de plan de release pour l'adoption future dans KSP, Games et d'autres projets.
+
+Cette tranche ne commence pas l'audit Rust ni le profil Tauri.
+
+### alpha.5 — audit Rust de façade/export completeness

 Extraire le noyau réellement commun de `audit_rust_export_completeness.py`, l'aligner avec `510-RUST_CARGO.md`, documenter son caractère facultatif et ses limites, et ajouter des tests positifs/négatifs.

 Cette tranche ne réimporte pas `audit_rust_general_rules.py` en bloc. Toute règle déjà possédée par Rustfmt, Clippy, le compilateur ou les audits PGR existants reste chez son owner actuel.

-### alpha.5 — premier profil framework : Tauri
+### alpha.6 — premier profil framework : Tauri

 Si la revue de `alpha.1` reste confirmée, activer la famille `700 — frameworks` et créer un profil Tauri fondé uniquement sur les invariants communs aux deux corpus : composition avec Rust/Cargo, ownership du build Tauri, hooks frontend, version produit, artefacts générés, configuration sensible et gates de développement/build.

 Les versions exactes de dépendances, ports, fenêtres, plugins, bundles et chemins applicatifs restent des décisions destinataire. Vite/Web/WASM n'entrent pas automatiquement dans ce profil.

-### alpha.6 — décision de skeleton Tauri
+### alpha.7 — décision de skeleton Tauri

 Vérifier si le profil Tauri obtenu permet une skeleton specification utile sans créer de `tauri.conf.json` universel. Si oui, ajouter une specialization composable au-dessus de `001 + 002 + 700/710`. Sinon, consigner explicitement le report et ne pas matérialiser un skeleton décoratif.

@@ -78,13 +100,38 @@ Vérifier si le profil Tauri obtenu permet une skeleton specification utile sans

 Rejouer la matrice de l'étude sur l'état PGR obtenu. Vérifier : owner unique, navigation, absence de règles KSP/Games aspirées par accident, caractère facultatif des patterns/audits concernés, cohérence des skeletons et domaines encore différés.

+Cette tranche réconcilie aussi la documentation durable et vérifie que le présent plan possède un contrat de fermeture exécutable. Le prompt `006` vers `0.1.0` peut être préparé ici si la mission `0.1.0` reste suffisamment connue.
+
 ### rc.1 — scope gelé et gate candidate

-Geler le scope de `0.0.5`, préparer l'entrée candidate du changelog et le prompt `006` de la release suivante si sa mission est suffisamment connue. Rejouer les tests/audits PGR et les validations ciblées des nouveaux scripts/templates/profils réellement livrés.
+Geler le scope de `0.0.5`, préparer l'entrée candidate du changelog, vérifier `ROADMAP.md`, finaliser/vérifier le prompt `006-V0_1_0_START_PROMPT.md` si `0.1.0` reste la cible retenue et rejouer les tests/audits PGR ainsi que les validations ciblées des nouveaux scripts/templates/profils réellement livrés.
+
+Aucune version postérieure à `0.1.0` n'est inventée à cette étape.

 ### stable — 0.0.5

-Promouvoir mécaniquement la RC validée : synchroniser `VERSION`, README/index, ROADMAP, CHANGELOG et statut du plan sans ajouter de nouveau besoin commun. Après history PASS, commit et tag `v0.0.5`, vérifier séparément l'archive publiée.
+Promouvoir mécaniquement la RC validée : synchroniser `VERSION`, README/index, `ROADMAP.md`, `CHANGELOG.md` et statut du présent plan sans ajouter de nouveau besoin commun. Après history PASS, commit et tag `v0.0.5`, vérifier séparément l'archive publiée.
+
+La vérification post-tag doit produire, si le mécanisme reste retenu, `pgr-0.0.5-publish.001-report.md` extérieur au tag. Le message manuel final doit alors indiquer spontanément à l'opérateur de fournir l'archive taggée et ce rapport avec le prompt `006` lors de la session `0.1.0`.
+
+## Clôture et transition
+
+Le présent plan attribue dès maintenant les responsabilités de fermeture :
+
+- la documentation directement liée à chaque capacité évolue dans sa tranche ;
+- `beta.1` réalise la réconciliation durable globale et prépare le prompt suivant si sa mission est connue ;
+- `rc.1` porte le scope freeze, l'entrée `CHANGELOG` candidate, la vérification `ROADMAP` et le prompt suivant candidat ;
+- `rel.001`/stable finalise `CHANGELOG`, marque `0.0.5` terminée dans `ROADMAP`, ferme le présent plan et effectue le promotion gate pré-tag ;
+- `publish.001` vérifie l'archive réellement produite après le tag et fournit la preuve externe requise par la reprise suivante ;
+- aucune de ces opérations ne doit être repoussée implicitement à la session `0.1.0`.
+
+## Revue d'horizon
+
+Pour PGR, la prochaine release engagée est `0.1.0 — première baseline réutilisable`. La trajectoire au-delà n'est pas suffisamment décidée et reste volontairement ouverte ; ce n'est pas un défaut de roadmap.
+
+`0.0.5` ne doit donc pas inventer `0.1.1`, `0.2.0` ou un catalogue de versions futures. Le plan de `0.1.0-alpha.1` devra en revanche identifier un moment de revue d'horizon avant sa fermeture, une fois la baseline réutilisable suffisamment concrète pour juger la suite. Cette revue pourra se tenir dans une session stratégique séparée sans modifier `VERSION`.
+
+Ses sorties autorisées seront : étendre la roadmap avec des objectifs réellement décidés, maintenir l'horizon ouvert avec un prochain déclencheur, différer/mettre en pause la trajectoire ou constater qu'un objectif macro est accompli.

 ## Points de décision

@@ -92,6 +139,8 @@ Un REPLAN est requis si :

 - le contrat de prompt devient une copie exhaustive des règles plutôt qu'un artefact de reprise ;
 - le pattern de contrats de fichiers ajoute plus de cérémonie qu'il n'en retire ;
+- le lifecycle de clôture impose des documents ou versions futures sans valeur opérationnelle ;
+- la revue d'horizon devient un quota de versions à prévoir plutôt qu'un mécanisme de décision ;
 - l'audit de façade Rust ne peut pas être séparé proprement des conventions strictes KSP/Games ;
 - le profil Tauri exige de choisir arbitrairement Vite, WASM, des plugins ou un layout d'application ;
 - le skeleton Tauri n'apporte pas de décisions réutilisables au-delà du profil framework ;
--- a/docs/rules/200-GOVERNANCE.md
+++ b/docs/rules/200-GOVERNANCE.md
@@ -1,5 +1,5 @@
 <!-- file: docs/rules/200-GOVERNANCE.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->

 # Governance rules

@@ -89,7 +89,9 @@ Cette convention pré-1.0 complète SemVer sans modifier sa syntaxe.
 - les études ou décisions encore ouvertes ;
 - les principaux risques et contraintes ;
 - la stratégie de validation et les smokes nécessaires ;
- le dimensionnement des tranches.
+- le dimensionnement des tranches ;
+- lorsque la release possède un plan dédié, les responsabilités de clôture et de transition vers la suite ;
+- l'état de l'horizon de roadmap et, lorsqu'il devient court ou incertain, le moment prévu pour le réexaminer.

 Une tranche cible généralement un volume de travail cohérent et vérifiable. Une durée de l'ordre de 15 à 30 minutes MAY servir d'heuristique de découpage, mais MUST NOT être traitée comme une deadline ou un quota.

@@ -145,6 +147,8 @@ ABANDON

 Une interruption de conversation ou de session MUST NOT créer artificiellement une nouvelle version. Le même état de version et de tranche continue tant que le scope reste valable.

+Une revue stratégique de versions futures MAY également se tenir dans une session séparée. Cette frontière de conversation n'est ni une release, ni une phase SemVer, ni une raison de modifier `VERSION`. Si la discussion produit une décision durable à matérialiser dans le dépôt, cette modification passe ensuite par une tranche gouvernée appropriée.
+
 ## Abandon et supersession

 Une version ou prerelease commencée n'est pas forcée vers stable uniquement pour préserver une séquence esthétique.
--- a/docs/rules/210-WORKFLOW.md
+++ b/docs/rules/210-WORKFLOW.md
@@ -1,5 +1,5 @@
 <!-- file: docs/rules/210-WORKFLOW.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->

 # Workflow artifact rules

@@ -49,13 +49,25 @@ docs/plans/

 Un plan :

- SHOULD être créé pendant le cadrage lorsque plusieurs tranches ou décisions doivent être coordonnées ;
- MAY évoluer lorsque le plan change réellement ;
+- SHOULD être créé ou consolidé pendant `alpha.1` lorsque plusieurs tranches ou décisions doivent être coordonnées ;
+- MAY évoluer lorsque la réalité invalide le forecast ;
 - SHOULD NOT être modifié à chaque tranche uniquement pour recopier l'avancement ;
 - MUST distinguer prévision et état réellement observé ;
 - MUST NOT remplacer ROADMAP, delta ou history.

-Un changement substantiel du plan MAY être porté par une tranche REPLAN conformément aux règles de gouvernance.
+Lorsqu'un plan existe pour une release gouvernée par le workflow PGR, il MUST aussi rendre explicites, de manière proportionnée :
+
+- la mission, le scope et le hors-scope actuellement applicables ;
+- la stratégie de validation et les gates qui conditionnent réellement la fermeture ;
+- la trajectoire prévisionnelle des responsabilités, sans transformer le forecast en promesse immuable ;
+- une section ou un bloc **clôture et transition** indiquant où seront traités la réconciliation documentaire durable, le `CHANGELOG`, la mise à jour de `ROADMAP`, le prompt ou handoff de reprise, la fermeture du plan et la promotion/publication ;
+- l'état de la **revue d'horizon** : soit elle n'est pas nécessaire parce que la roadmap possède déjà un horizon suffisant, soit son déclencheur et le moment où elle sera instruite sont identifiés.
+
+Le plan MUST NOT inventer une version future uniquement pour remplir la rubrique de transition. Lorsque la cible suivante n'est pas suffisamment décidée, il l'indique explicitement et planifie une revue d'horizon ou un handoff approprié plutôt que de fabriquer un numéro, une mission ou un prompt.
+
+Un changement substantiel du plan MAY être porté par une tranche REPLAN conformément aux règles de gouvernance. Le corps du plan reste l'état de pilotage actuellement applicable ; les deltas et histories conservent le détail historique des changements. PGR n'impose pas un journal `Revisions` alimenté à chaque tranche.
+
+À la clôture `completed`, `abandoned` ou `superseded`, le plan devient principalement historique. Il ne doit plus être réécrit pour refléter silencieusement la connaissance acquise dans des releases ultérieures.

 ## Delta

@@ -137,6 +149,18 @@ L'archive history contient uniquement le ou les fichiers history à appliquer po

 Delta et history MUST rester des livraisons séparées afin que la preuve observée ne soit pas confondue avec l'intention prospective.

+Lorsque la gate courante est `PASS` et que la tranche suivante est déjà déterminée par le plan sans décision ouverte, le générateur SHOULD préparer et remettre dans la même réponse :
+
+```text
+archive history de la tranche courante
+
+archive delta de la tranche suivante
+```
+
+Les deux archives restent séparées. Cette optimisation de flux n'autorise jamais l'application du delta suivant avant l'application du history courant et le commit complet de la tranche.
+
+Le delta suivant SHOULD NOT être anticipé lorsqu'une décision opérateur, un REPLAN non résolu, un abandon/supersession, une preuve externe post-tag ou toute autre dépendance peut encore modifier sa baseline ou son scope.
+
 ## Commit de tranche

 Le commit d'une tranche doit représenter l'état complet de cette tranche, y compris son history.
@@ -221,15 +245,19 @@ Le prompt MAY imposer un ordre de lecture détaillé ou une matrice de questions

 ### Création et clôture

-Le prompt SHOULD être finalisé à la clôture stable de la version précédente lorsqu'il prépare la version suivante et que sa mission est suffisamment connue.
+Lorsque la version suivante est suffisamment connue, son prompt SHOULD être amorcé pendant la consolidation finale, vérifié pendant la RC et finalisé pendant la promotion stable. Il MUST être présent dans la stable taggée qui prépare cette reprise.
+
+Lorsque la cible suivante n'est pas suffisamment connue, PGR MUST NOT fabriquer un prompt de version, un numéro ou une mission pour respecter une cérémonie. Le plan et la roadmap indiquent alors que l'horizon reste ouvert et un handoff `NEXT` ou une revue d'horizon porte la continuité nécessaire.

 Une interruption au milieu d'une version MUST NOT produire artificiellement le prompt de la version suivante. La reprise de la tranche courante utilise son état committé et, si nécessaire, un handoff conforme au présent document.

-Lors d'une nouvelle session ouverte depuis une stable publiée, une courte consigne manuelle MAY identifier l'archive du tag, le rapport post-tag lorsqu'il existe réellement, le prompt versionné à lire et la première gate. [`../templates/003-NEW_SESSION_PROMPT.md`](../templates/003-NEW_SESSION_PROMPT.md) décrit cette forme courte ; elle reste distincte du prompt versionné et ne remplace ni son contrat détaillé ni la preuve de publication.
+Lorsqu'une stable publiée possède une cible suivante connue, le générateur MUST remettre spontanément à l'opérateur, après la vérification post-tag applicable, une courte consigne manuelle identifiant l'archive du tag, le rapport post-tag lorsqu'il existe réellement, le prompt versionné à lire et la première gate. [`../templates/003-NEW_SESSION_PROMPT.md`](../templates/003-NEW_SESSION_PROMPT.md) décrit cette forme courte ; elle reste distincte du prompt versionné et ne remplace ni son contrat détaillé ni la preuve de publication.
+
+Si une preuve post-tag externe est requise pour la prochaine reprise, le prompt versionné MAY annoncer à l'avance son nom attendu mais MUST la décrire comme une preuve future extérieure au tag. La consigne manuelle finale ne la présente comme `PASS` qu'après sa production et sa vérification réelles.

 ## Handoff

-Un handoff est un snapshot de continuité utilisé lorsqu'un travail doit être repris sans changer artificiellement de version ou de tranche.
+Un handoff est un snapshot de continuité utilisé lorsqu'un travail doit être repris à une frontière de session ou de responsabilité sans changer artificiellement de version ou de tranche. Un REPLAN traité entièrement dans la même session n'a pas besoin d'un handoff uniquement pour laisser une trace : delta, history et plan possèdent déjà cette trace.

 Le chemin canonique est :

@@ -249,9 +277,21 @@ SUPERSEDE
 NEXT
 ```

-Le handoff SHOULD enregistrer uniquement les informations nécessaires à une reprise fiable : état de version/tranche, résultat déjà acquis, travail restant, risques ou décisions ouvertes et commandes pertinentes.
+Selon le besoin réel, un handoff SHOULD permettre de retrouver sans mémoire conversationnelle :

-Une fois livré comme snapshot de reprise, il SHOULD être traité comme historique plutôt que réécrit continuellement.
+- son type, la version source et une cible éventuelle ;
+- la baseline autoritaire et le dernier état opérateur validé ;
+- le dernier delta validé et tout delta livré mais encore en attente ;
+- l'état du plan, le travail terminé et le travail restant ;
+- les décisions acquises, les questions ouvertes et les validations restantes ;
+- le prompt applicable lorsqu'il existe ;
+- l'instruction exacte de reprise et, lorsque cela aide l'opérateur, un court texte copiable vers la nouvelle session.
+
+Un petit handoff n'a pas à répéter les champs sans valeur pour son cas. Il référence les owners existants plutôt que recopier leurs règles.
+
+Un `NEXT` après stable peut transmettre une version suivante connue. Si l'horizon est volontairement ouvert, il peut au contraire transmettre explicitement le besoin de revue d'horizon sans inventer une release.
+
+Une fois livré comme snapshot de reprise, un handoff SHOULD être traité comme historique plutôt que réécrit continuellement.

 Un changement de conversation ou de session n'est jamais, à lui seul, une raison de changer `VERSION`.

@@ -289,6 +329,10 @@ post-tag verification

 Un identifiant opérationnel tel que `rel.001` ou `publish.001` MAY être utilisé pour distinguer une clôture ou une vérification de publication sans devenir une nouvelle version SemVer produit.

+`rel.001` prouve l'état stable avant création du tag. Une preuve `publish.001`, lorsqu'elle existe, porte sur l'artefact réellement publié après le tag et reste donc extérieure au tag qu'elle vérifie. Elle ne revalide pas fonctionnellement la release.
+
+Lorsqu'un rapport `publish.001` est un prérequis de la session suivante, la clôture post-tag MUST indiquer explicitement à l'opérateur qu'il doit fournir ce rapport avec l'archive taggée. Le démarrage suivant effectue toujours son propre audit d'intake de la baseline ; il ne traite pas pour autant la stable précédente comme une release encore en attente de validation.
+
 ## Conservation et immutabilité

 Deltas, histories, handoffs, plans historiques, études et autres preuves utiles SHOULD être conservés lorsqu'ils expliquent une décision ou permettent une reprise fiable.
--- a/docs/rules/300-DOCUMENTATION.md
+++ b/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 :
--- a/docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+++ b/docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
@@ -1,5 +1,5 @@
 <!-- file: docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->

 # Skeleton — Project governance foundation

@@ -94,6 +94,8 @@ Selon la réalité du projet :

 Pour un projet où plusieurs fichiers ou familles durables ont des responsabilités ou règles de modification difficiles à déduire, la fondation MAY aussi instancier un registre local selon [`../templates/004-FILE_FAMILY_CONTRACTS.md`](../templates/004-FILE_FAMILY_CONTRACTS.md). Ce registre reste facultatif : un projet simple ou déjà explicite n'a rien à matérialiser.

+Lorsqu'une release possède plusieurs tranches ou responsabilités de fermeture, le projet SHOULD utiliser un plan explicite conforme à [`../templates/005-RELEASE_PLAN.md`](../templates/005-RELEASE_PLAN.md) ou une forme locale équivalente. Le plan doit notamment attribuer la clôture/transition et éviter qu'une roadmap arrivée à son horizon soit étendue par spéculation.
+
 Ne pas créer ces fichiers uniquement pour reproduire l'arborescence du dépôt PGR.

 ### Workflow retenu
--- a/docs/templates/003-NEW_SESSION_PROMPT.md
+++ b/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.
--- a/docs/templates/005-RELEASE_PLAN.md
+++ b/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.