0.1.5-alpha.2

docs/rules/230-ADOPTION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/230-ADOPTION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Existing project adoption rules
 
@@ -50,6 +50,8 @@ OVERRIDE
 DEFER
 ```
 
+Ces classifications n'augmentent pas la force normative d'une règle. En particulier, choisir une solution différente d'un `SHOULD` / `SHOULD NOT` ne crée pas à lui seul un `OVERRIDE` obligatoire ; le projet MAY conserver ce choix comme décision locale et documenter sa raison lorsque cette trace apporte une valeur durable.
+
 ### ADOPT
 
 `ADOPT` signifie que le projet retient le contrat PGR applicable et migre son état local lorsque nécessaire.
@@ -64,9 +66,9 @@ Cette classification ne crée pas une exception : elle reconnaît qu’un choix
 
 ### OVERRIDE
 
-`OVERRIDE` signifie qu’une règle PGR applicable est volontairement remplacée ou raffinée dans un scope local.
+`OVERRIDE` signifie qu'une obligation PGR réellement applicable, ou un contrat localement rendu obligatoire, est volontairement remplacé ou raffiné dans un scope local.
 
-L’override MUST identifier la règle concernée, le scope, la raison et le contrat local retenu. Il ne doit pas être utilisé pour masquer une migration incomplète ou faire disparaître une violation non résolue.
+L'override MUST identifier la règle concernée, le scope, la raison et le contrat local retenu. Il ne doit pas être utilisé pour masquer une migration incomplète ou faire disparaître une violation non résolue. Un simple écart à une recommandation `SHOULD` / `SHOULD NOT` MUST NOT exiger un override uniquement parce que la recommandation n'est pas suivie.
 
 ### DEFER
 
@@ -119,7 +121,7 @@ Une adoption PGR réussie laisse :
 - un projet autonome ;
 - uniquement les owners PGR réellement applicables ;
 - les choix locaux légitimes préservés ;
-- les overrides explicites ;
+- les overrides explicites lorsqu'une obligation applicable est volontairement remplacée ;
 - les domaines différés clairement identifiés ;
 - un historique non falsifié ;
 - une validation proportionnée au changement réellement effectué.

docs/rules/400-VALIDATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/400-VALIDATION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Validation rules
 
@@ -27,6 +27,12 @@ Une preuve déjà acquise MAY être réutilisée tant qu'aucun changement pertin
 
 Les gates de `beta`, `rc` et promotion stable MAY élargir volontairement la validation pour démontrer l'intégration ou la cohérence de release.
 
+## Force normative et résultat des gates
+
+Une gate MUST distinguer une obligation `MUST / MUST NOT` d'une recommandation `SHOULD / SHOULD NOT`. Un écart à un `SHOULD` ou `SHOULD NOT` PGR ne constitue pas à lui seul une preuve en échec et MUST NOT faire passer une tranche en `FAIL`.
+
+Une gate MAY signaler un écart à une recommandation comme observation, diagnostic ou point de revue. Si un projet décide de rendre cette recommandation obligatoire dans un scope local, il doit matérialiser ce contrat local explicitement ; la gate évalue alors ce contrat local, pas le `SHOULD` PGR d'origine.
+
 ## Matrice de validation
 
 Un projet suffisamment structuré SHOULD posséder une matrice de validation canonique, par défaut sous :

docs/rules/500-LANGUAGES.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/500-LANGUAGES.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Règles de profils langage et écosystème
 
@@ -31,7 +31,7 @@ Les profils de cette famille héritent des règles générales PGR et ne doivent
 
 Une règle générale comme l'interdiction de versionner des secrets reste applicable sans être répétée dans chaque profil langage.
 
-Lorsqu'un langage ou un build tool impose une exception réelle à une règle générale, le profil spécifique doit déclarer l'override et sa justification.
+Lorsqu'un langage ou un build tool impose une contradiction réelle avec un `MUST / MUST NOT` général applicable, le profil spécifique MUST déclarer l'override ou l'exception et sa justification. Un choix différent d'un `SHOULD / SHOULD NOT` général ne nécessite pas, à lui seul, un override.
 
 ## Langage et build tool
 

docs/rules/530-TYPESCRIPT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/530-TYPESCRIPT.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Profil TypeScript
 
@@ -15,7 +15,7 @@ Le profil s'applique lorsqu'une partie du source contrôlé est écrite en TypeS
 
 Pour un frontend que l'organisation contrôle, TypeScript **SHOULD** être préféré à du JavaScript non typé dès que le frontend porte une logique durable non triviale.
 
-Cette préférence n'est pas une obligation universelle. Du JavaScript direct MAY rester approprié pour un artefact très petit, un script isolé, une contrainte externe ou un environnement où l'introduction de TypeScript n'apporte pas une valeur proportionnée.
+Cette préférence n'est pas une obligation universelle. Du JavaScript direct MAY rester approprié pour un artefact très petit, un script isolé, une contrainte externe ou un environnement où l'introduction de TypeScript n'apporte pas une valeur proportionnée. Choisir JavaScript ne constitue donc pas à lui seul une non-conformité, n'exige pas automatiquement un `OVERRIDE` et ne crée pas une obligation de justification ; la décision MAY être documentée lorsqu'elle apporte une valeur durable.
 
 La justification de la recommandation est fonctionnelle : TypeScript ajoute une vérification statique avant exécution et permet de détecter une partie des incohérences de types pendant la validation plutôt qu'au runtime.
 
@@ -61,7 +61,7 @@ noEmit = true
 
 `strict` exprime la volonté d'utiliser le contrôle de types renforcé de TypeScript. `noEmit` sépare le type-check de la production des artefacts JavaScript lorsque cette production appartient à un bundler ou à un autre outil.
 
-Pour une baseline stricte, PGR `SHOULD` également activer les contrôles simples suivants sauf incompatibilité documentée :
+Pour une baseline stricte, PGR `SHOULD` également activer les contrôles simples suivants lorsqu'ils sont pertinents pour le package :
 
 ```text
 noUnusedLocals = true

docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Profil écosystème de packages JavaScript
 
@@ -67,7 +67,7 @@ Un package **SHOULD NOT** conserver simultanément plusieurs lockfiles concurren
 
 Lorsqu'un lockfile est versionné, la CI **SHOULD** utiliser le mode de résolution gelé, immutable ou clean-install fourni par le package manager sélectionné. Le nom exact de cette commande reste local à l'outil ; PGR MUST NOT transformer `npm ci` en commande universelle.
 
-L'absence actuelle de lockfiles dans Games reste historique. Lors de l'adoption `0.1.5`, chaque package concerné devra soit `ADOPT` cette recommandation, soit documenter un `OVERRIDE` si une autre politique reste préférable.
+L'absence actuelle de lockfiles dans Games reste historique. Lors de l'adoption `0.1.6`, chaque package concerné devra décider sa politique de lockfile selon son rôle et ses contraintes. Versionner le lockfile reste une recommandation `SHOULD` pour les applications privées, frontends déployables et outils livrés ; conserver une autre politique ne requiert pas à lui seul un `OVERRIDE`, même si la décision locale MAY être documentée lorsqu'elle apporte une valeur durable.
 
 ## Validation
 

docs/rules/700-FRAMEWORKS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/700-FRAMEWORKS.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Règles de profils framework
 
@@ -45,7 +45,7 @@ GENERAL
 + Tauri
 ```
 
-Lorsque PGR gouverne la baseline du projet, les règles des profils hérités restent applicables dans leur scope complet tant qu'un override plus spécifique n'est pas documenté. Un framework ne constitue pas à lui seul une justification pour affaiblir une convention de langage, de plateforme ou de sécurité.
+Lorsque PGR gouverne la baseline du projet, les règles des profils hérités restent applicables dans leur scope avec leur force normative propre. Un framework MUST NOT contredire silencieusement un `MUST / MUST NOT` hérité ; une telle contradiction exige l'override ou l'exception applicable. Un framework MAY choisir différemment d'un `SHOULD / SHOULD NOT` sans que cet écart constitue à lui seul un override ou une non-conformité.
 
 Un projet existant ou imposé de l'extérieur MAY conserver des contraintes différentes. Ces écarts appartiennent alors au niveau project-specific ou à une exception explicite et bornée ; ils ne doivent pas être remontés comme nouvelle règle générale du framework.