0.1.0-alpha.2

docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Plan 0.1.0 — première baseline PGR réutilisable
 
@@ -156,11 +156,20 @@ Les numéros exacts `0.1.1`, `0.1.2`, etc. ne sont pas réservés dans `alpha.1`
 
 Après cette vague d'adoption `0.1.x`, les axes plus larges — projets documentaires/spécifications tels que `saselang-bible`, généricité hors logiciel et autres familles technologiques — restent candidats pour une trajectoire `0.2.x`/`0.3.x` à décider ultérieurement, sans réservation artificielle aujourd'hui.
 
+Deux horizons supplémentaires sont acquis comme **candidats différés**, sans numéro réservé :
+
+- après application réelle de PGR à Games puis KSP, une release `0.1.x` non prioritaire pourra introduire des audits Python read-only reproduisant uniquement le sous-ensemble des conventions Rust/Clippy vérifiable statiquement sans Cargo ni `rustc`; ces audits devront utiliser les options PGR existantes, documenter explicitement les lints `FULL / LIMITED / UNSUPPORTED` et MUST NOT être présentés comme équivalents à `cargo clippy`, qui reste la validation autoritaire ;
+- à plus long terme, une série dédiée au déploiement et à l'exploitation devra être étudiée, potentiellement dans un horizon `0.4.x` ou `0.5.x` mais sans réservation actuelle : reverse proxies tels que Nginx/Apache, bases PostgreSQL/MySQL ou autres, conteneurs Docker/Compose, hébergement Linux/services, environnements et secrets, migrations/backup, health/observabilité et skeletons/audits de déploiement composables.
+
+Ces horizons ne modifient pas la mission de `0.1.0` et ne doivent pas être absorbés par les tranches courantes.
+
 ## Trajectoire prévisionnelle de `0.1.0`
 
 ### alpha.1 — audit de stable et plan
 
-Vérifier intégralement `v0.0.5`, son rapport post-tag, les owners normatifs, profils, templates, skeletons, audits, chaîne delta/history et décisions différées. Consigner le cadrage présent sans changement normatif ni migration externe.
+Statut opérateur : **PASS**.
+
+La stable `v0.0.5`, son rapport post-tag, les owners normatifs, profils, templates, skeletons, audits, chaîne delta/history et décisions différées ont été vérifiés. Le cadrage a été consigné sans changement normatif ni migration externe.
 
 ### alpha.2 — clôture stable et identité `rel.N`
 

docs/rules/200-GOVERNANCE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/200-GOVERNANCE.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Governance rules
 
@@ -77,6 +77,8 @@ vX.Y.Z
 
 `rel.N` MAY identifier une livraison ou un artefact de clôture, mais MUST NOT être traité comme une version produit SemVer.
 
+Pour les nouvelles releases gouvernées par cette convention, `N` commence à `1` et sa représentation canonique n'utilise pas de zéro de padding : `rel.1`, `rel.2`, etc. Les formes historiques déjà publiées telles que `rel.001` restent des snapshots immuables et MUST NOT être renommées rétroactivement.
+
 Avant `1.0.0`, PGR recommande la convention suivante lorsqu'elle correspond au projet :
 
 - `X = 0` indique que le contrat public durable n'est pas encore stabilisé ;
@@ -126,6 +128,16 @@ La promotion stable MUST néanmoins exécuter son propre gate proportionné pour
 
 Le tag stable canonique est `vX.Y.Z`.
 
+La clôture opérationnelle `rel.N[/fix.M]` n'est pas une prerelease SemVer et MAY intervenir alors que `VERSION` porte déjà `X.Y.Z`. En l'absence d'une convention locale explicitement documentée, PGR impose la distinction suivante pour le message du commit de clôture :
+
+```text
+rel.1 FAIL / PARTIAL / BLOCKED          -> X.Y.Z-rel.1
+rel.1.fix.1 FAIL / PARTIAL / BLOCKED    -> X.Y.Z-rel.1.fix.1
+première tranche de clôture PASS        -> X.Y.Z
+```
+
+Le commit nommé `X.Y.Z` MUST inclure le history qui établit effectivement le `PASS` stable. Le tag `vX.Y.Z` MUST être créé seulement après ce commit. Une clôture échouée MUST rester identifiable par son nom de tranche et MUST NOT être présentée comme le commit stable final.
+
 La vérification d'une publication ou d'une archive produite après le tag est une preuve distincte de la validation pré-tag.
 
 ## Correctifs de tranche

docs/rules/210-WORKFLOW.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/210-WORKFLOW.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Workflow artifact rules
 
@@ -86,6 +86,8 @@ alpha.3.md
 alpha.3.fix.1.md
 beta.1.md
 rc.1.md
+rel.1.md
+rel.1.fix.1.md
 ```
 
 Un delta MUST :
@@ -174,9 +176,26 @@ current delta changes
 
 doivent être présents, alors que le delta suivant MUST rester absent.
 
-Le message de commit MAY suivre les conventions du projet. PGR n'impose pas Conventional Commits, GitFlow ou une topologie universelle de branches.
+Pour une tranche alpha, beta, RC ou autre tranche qui n'établit pas la stable, le message de commit MAY suivre les conventions du projet tant que l'état et la tranche restent identifiables. PGR n'impose pas Conventional Commits, GitFlow ou une topologie universelle de branches.
 
-L'important est que l'état et la tranche restent identifiables et que le repository ne mélange pas deux tranches non clôturées.
+La clôture stable `rel.N[/fix.M]` possède une règle plus stricte afin de distinguer une tentative de fermeture de l'identité stable réellement obtenue. En l'absence d'un mapping local explicitement documenté :
+
+```text
+history rel.1 FAIL / PARTIAL / BLOCKED
+    -> commit X.Y.Z-rel.1
+
+history rel.1.fix.1 FAIL / PARTIAL / BLOCKED
+    -> commit X.Y.Z-rel.1.fix.1
+
+premier history rel.N[/fix.M] PASS qui établit réellement la stable
+    -> commit X.Y.Z
+```
+
+Le suffixe opérationnel n'est donc conservé dans le message du commit que tant que la clôture n'a pas obtenu le `PASS` stable. Le commit `X.Y.Z` MUST contenir le delta de clôture concerné et son history `PASS`; il MUST précéder le tag canonique `vX.Y.Z`.
+
+Un projet qui possède une convention de message différente MAY utiliser un mapping équivalent, mais il MUST conserver sans ambiguïté la distinction entre tentative de clôture échouée et commit stable final.
+
+Le repository ne doit jamais mélanger deux tranches non clôturées dans un même commit.
 
 ## Manifest de suppression
 
@@ -327,9 +346,11 @@ published source archive
 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.
+Un identifiant opérationnel tel que `rel.1` ou `publish.001` MAY être utilisé pour distinguer une clôture ou une vérification de publication sans devenir une nouvelle version SemVer produit. La famille `rel.N` utilise la représentation sans zéro de padding définie par la gouvernance ; les anciennes formes `rel.001*` déjà publiées restent historiques et immuables.
 
-`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.
+`rel.1` est la première tranche de clôture stable pré-tag d'une nouvelle release utilisant cette convention. Si elle échoue, `rel.1.fix.N` corrige uniquement cette fermeture. La première de ces tranches qui obtient réellement `PASS` est incluse dans le commit stable `X.Y.Z`, puis seulement le tag `vX.Y.Z` est créé.
+
+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. La présente règle ne renomme pas `publish.001`; son identité reste indépendante de la correction `rel.001` -> `rel.1`.
 
 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.