0.0.5-alpha.4

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 ;