0.0.5-alpha.6.fix.3

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