0.0.5-alpha.6.fix.3

docs/rules/200-GOVERNANCE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/200-GOVERNANCE.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Governance rules
 
@@ -38,9 +38,20 @@ Lorsqu'un dépôt utilise le fichier racine `VERSION`, ce fichier :
 
 Un manifeste technique MAY refléter exactement `VERSION` lorsque son propre contrat l'exige. Un autre mécanisme de versioning MAY rester indépendant lorsqu'il possède une sémantique différente, par exemple un `versionCode` Android, une révision de document ou une version de protocole.
 
-PGR MUST NOT imposer une égalité globale entre tous les champs contenant un numéro de version.
+PGR MUST NOT imposer une égalité globale entre tous les champs contenant un numéro de version. Pour éviter à la fois les divergences silencieuses et le churn mécanique, chaque valeur de version durable SHOULD être classée selon son rôle réel. Les catégories réutilisables sont notamment :
 
-Un champ de version qui n'est ni requis par l'écosystème ni utile au projet SHOULD être omis plutôt que maintenu comme duplication décorative.
+- `CANONICAL` — identité SemVer exacte de l'unité de release, normalement portée par `VERSION` ;
+- `MIRROR-EXACT` — miroir technique qui suit exactement `VERSION`, prereleases et fixes compris ;
+- `MIRROR-STABLE` — miroir du jalon produit `X.Y.Z` ciblé, stable pendant `X.Y.Z-alpha.*`, `beta.*`, `rc.*` et leurs fixes ;
+- `INDEPENDENT-COUNTER` — compteur technique monotone possédant sa propre sémantique ;
+- `INDEPENDENT-SCHEMA` — version de protocole, format ou schéma indépendante du produit ;
+- `DOCUMENT-REVISION` — révision interne d'un document ou artefact documentaire.
+
+Seul un `MIRROR-EXACT` est normalement modifié à chaque changement de `VERSION`. Un `MIRROR-STABLE` SHOULD être fixé ou vérifié lorsque la cible `X.Y.Z` est ouverte, puis ne pas être réécrit uniquement parce qu'une tranche passe de `alpha.N` à `alpha.N+1`, à un `.fix.N`, à une beta ou à une RC. La promotion stable vérifie qu'il représente toujours la release publiée.
+
+Lorsqu'une prerelease est réellement distribuée comme artefact installable distinct et que son écosystème exige une identité de package propre, le champ concerné peut devenir `MIRROR-EXACT` ou suivre des jalons explicitement définis. Cette décision appartient au plan de versioning/packaging du projet ; elle ne doit pas résulter d'une égalité globale implicite.
+
+Un champ de version qui n'est ni requis par l'écosystème ni utile au projet SHOULD être omis plutôt que maintenu comme duplication décorative. Réciproquement, PGR MUST NOT imposer la suppression d'un champ utile uniquement pour éviter de le modifier à chaque prerelease : il faut d'abord lui attribuer la bonne classe de synchronisation.
 
 ## Schéma SemVer PGR
 

docs/rules/710-TAURI.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/710-TAURI.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Profil Tauri 2
 
@@ -121,23 +121,28 @@ Le répertoire produit par le frontend est un artefact de build lorsqu'il est re
 
 ## Version produit
 
-Lorsque l'application Tauri appartient au même release train que le projet, `VERSION` reste la version canonique de cette unité de release.
+Lorsque l'application Tauri appartient au même release train que le projet, `VERSION` reste la version canonique exacte de cette unité de release. Les champs de version de Tauri et du frontend ne sont toutefois pas obligés de suivre chaque prerelease ou fix : ils sont classés selon [`200-GOVERNANCE.md`](200-GOVERNANCE.md).
 
-Pour Tauri 2, une configuration qui omet la propriété applicative `version` peut utiliser la version du package Cargo du host. Lorsqu'un workspace PGR hérite déjà `workspace.package.version`, cette chaîne SHOULD être préférée si elle évite une duplication sans perdre d'information :
+Tauri 2 accepte une `version` applicative explicite dans `tauri.conf.json` et l'utilise pour les métadonnées/bundles. Si ce champ est absent, Tauri peut utiliser la version du package Cargo du host. PGR MUST NOT imposer l'une de ces deux formes uniquement pour réduire le nombre de fichiers modifiés.
+
+Pour un projet contrôlé qui conserve une `version` explicite dans `tauri.conf.json`, la politique recommandée lorsque les prereleases ne sont pas distribuées comme produits installables distincts est `MIRROR-STABLE` : le champ porte la cible `X.Y.Z` de la version en cours de développement, est fixé ou vérifié à l'ouverture de cette cible et reste stable pendant ses `alpha.*`, `beta.*`, `rc.*` et fixes. La promotion stable vérifie la cohérence sans provoquer de réécriture cérémonielle si la valeur est déjà correcte.
+
+Si le projet distribue réellement des bundles prerelease qui doivent être identifiables séparément, `tauri.conf.json > version` MAY devenir `MIRROR-EXACT` ou suivre des jalons de packaging explicitement documentés. Le choix dépend du contrat de distribution, pas d'une préférence PGR pour l'omission du champ.
+
+Pour un `package.json` frontend privé appartenant à la même application, une propriété `version` conservée SHOULD de même être classée `MIRROR-STABLE` par défaut : elle peut porter `X.Y.Z` pendant tout le développement de cette release sans suivre chaque tranche. Si le package frontend est publié ou versionné indépendamment, il possède alors sa propre unité/version et cette règle ne s'applique plus.
+
+La chaîne de version d'un projet contrôlé peut donc être, par exemple :
 
 ```text
-VERSION
-↓
-workspace.package.version
-↓
-package Cargo du host
-↓
-version applicative Tauri
+VERSION                         = X.Y.Z-alpha.N.fix.M   # CANONICAL
+workspace.package.version       = X.Y.Z-alpha.N.fix.M   # MIRROR-EXACT si le workspace l'a choisi
+tauri.conf.json version         = X.Y.Z                 # MIRROR-STABLE
+package.json version            = X.Y.Z                 # MIRROR-STABLE si conservée
 ```
 
-Si une version Tauri explicite est conservée dans la configuration, elle MUST représenter la même release ou documenter clairement pourquoi elle constitue une unité indépendante.
+Cette classification évite de réécrire `package.json` et `tauri.conf.json` à chaque delta tout en conservant des champs de version utiles et lisibles. Elle remplace explicitement les conventions historiques KSP/Games qui préféraient omettre la version Tauri comme solution générale au churn.
 
-Les numéros de version propres aux plateformes, par exemple Android `versionCode`, restent possédés par le profil plateforme concerné et ne sont pas assimilés au SemVer produit.
+Les numéros propres aux plateformes, par exemple Android `versionCode`, restent possédés par le profil plateforme concerné et ne sont pas assimilés au SemVer produit.
 
 ## Capabilities, permissions et frontière WebView/native