0.0.1-alpha.3.fix.1

docs/rules/520-JAVA_MAVEN_GRADLE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/520-JAVA_MAVEN_GRADLE.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Profil Java / Maven / Gradle
 
@@ -9,7 +9,9 @@ Ce document possède les règles réutilisables propres au langage Java et à se
 
 Il complète [`500-LANGUAGES.md`](500-LANGUAGES.md). Les règles de gouvernance, documentation et validation restent possédées par leurs familles générales.
 
-Android n'est pas défini ici. Une contrainte AGP, SDK Android, `minSdk`, `targetSdk`, `versionCode`, signing ou packaging APK/AAB appartient au profil plateforme Android et peut surcharger localement les règles Gradle ou JDK de ce document.
+Android n'est pas défini ici. Une contrainte AGP, SDK Android, `minSdk`, `targetSdk`, `versionCode`, NDK, ABI/JNI, `applicationId`, `namespace`, manifest/resources, signing, packaging APK/AAB, device/AVD ou smoke Android appartient au profil plateforme Android ou à un owner spécialisé et peut raffiner localement les règles Gradle ou JDK de ce document.
+
+Une compatibilité Gradle/JDK plus étroite imposée par une plateforme ou un framework reste un override local. Elle MUST NOT être remontée comme minimum Java/Gradle général uniquement parce qu'un projet l'exerce.
 
 ## Politique JDK et compatibilité Java
 
@@ -32,6 +34,10 @@ niveau de bytecode/runtime minimal supporté
 
 Le niveau Java ciblé MUST être déclaré explicitement par le build lorsqu'il affecte la compatibilité. Il ne doit pas dépendre implicitement du JDK actif sur la machine.
 
+Un JDK de build plus récent MAY compiler un projet qui cible un niveau source ou bytecode plus ancien lorsque le build exprime explicitement cette cible et que la toolchain choisie la supporte. Le simple fait qu'une compilation réussisse avec le JDK actif ne constitue pas une déclaration de compatibilité.
+
+Selon le build, ce contrat peut être matérialisé par une option de release, une toolchain, des niveaux source/target ou un mécanisme équivalent. PGR ne généralise pas un mécanisme particulier à tous les builds Java.
+
 Une hausse de la version Java minimale supportée constitue un changement de compatibilité et MUST être justifiée comme telle.
 
 PGR MUST NOT imposer une version exacte de JDK uniquement parce qu'un corpus historique ou un autre projet utilise cette version.
@@ -225,16 +231,29 @@ Les gates globales telles que le reactor complet, `verify` ou le packaging de to
 
 ## Gradle — ownership du build
 
-Un projet Gradle SHOULD centraliser la configuration commune au niveau root lorsqu'elle est réellement partagée.
+Un projet Gradle SHOULD centraliser la configuration commune lorsqu'elle est réellement partagée, sans déplacer au root une responsabilité qui appartient à un module particulier.
 
-Selon le DSL retenu, les propriétaires typiques sont :
+Selon le DSL retenu, les propriétaires naturels sont typiquement :
 
 ```text
 settings.gradle / settings.gradle.kts
-build.gradle / build.gradle.kts
-gradle.properties
+    -> composition du build et inclusion des projets
+    -> politique de résolution des plugins/dépendances lorsqu'elle est réellement globale
+    -> contraintes de bootstrap ou de version Gradle lorsqu'elles doivent s'appliquer avant la configuration des projets
+
+build.gradle / build.gradle.kts root
+    -> plugins, versions ou conventions réellement partagés
+    -> configuration transverse qui ne doit pas être recopiée dans chaque sous-projet
+
+build.gradle / build.gradle.kts de module
+    -> plugins, dépendances, sources, tâches et paramètres propres au module
+
+gradle.properties partagé
+    -> propriétés portables, non secrètes et réellement communes au build
 ```
 
+Cette répartition décrit des responsabilités, pas un layout obligatoire. Un build simple MAY légitimement porter moins de fichiers, et une logique transverse devenue importante MAY être extraite dans un script, build logic ou plugin clairement possédé plutôt que dupliquée.
+
 Les sous-projets SHOULD NOT recopier sans nécessité :
 
 - la compatibilité Java ;
@@ -243,6 +262,8 @@ Les sous-projets SHOULD NOT recopier sans nécessité :
 - les contraintes de dépendances ;
 - les configurations de tests communes.
 
+Les chemins machine, credentials, secrets et overrides propres à un développeur MUST NOT être introduits dans un `gradle.properties` partagé. Ils doivent utiliser un mécanisme local approprié, par exemple propriétés utilisateur Gradle, variables d'environnement ou fichier local explicitement ignoré lorsque la toolchain en possède un.
+
 Un version catalog tel que `gradle/libs.versions.toml` MAY être utilisé lorsque la taille du projet le justifie. PGR MUST NOT l'imposer pour un projet qui n'en tire aucun bénéfice réel.
 
 ## Gradle Wrapper et version de Gradle
@@ -258,7 +279,11 @@ latest compatible
 
 Le projet MUST choisir la forme la moins restrictive qui prouve réellement sa compatibilité.
 
-Un Gradle Wrapper SHOULD être versionné lorsqu'il apporte une reproductibilité utile pour la distribution, la CI ou l'onboarding. Un projet contrôlé MAY utiliser un Gradle système si sa contrainte de compatibilité est explicitement vérifiée.
+Un Gradle Wrapper SHOULD être versionné lorsqu'il apporte une reproductibilité utile pour la distribution, la CI ou l'onboarding. Son absence dans un corpus particulier ne constitue pas une règle générale.
+
+Un projet contrôlé MAY utiliser un Gradle système si sa contrainte de compatibilité est **effectivement vérifiée** par le build ou par une gate exécutée par le projet/CI. Une version seulement écrite dans la documentation sans contrôle exécutable n'est pas une preuve suffisante de compatibilité.
+
+La vérification peut être portée par `settings.gradle(.kts)`, par une logique de bootstrap ou par une gate dédiée adaptée au projet. PGR n'impose pas l'API Gradle exacte utilisée pour cette vérification.
 
 Une plateforme ou un framework plus spécifique MAY imposer une contrainte plus étroite. Cette contrainte ne se propage jamais implicitement aux autres projets Gradle.
 
@@ -303,7 +328,7 @@ Les métadonnées IDE spécifiques à une machine restent ignorées sauf excepti
 
 Les wrappers retenus sont une exception volontaire : ils peuvent être générés par l'outil, mais leurs fichiers nécessaires au bootstrap reproductible sont versionnés.
 
-Les fichiers de configuration locale contenant chemins machine, credentials ou overrides développeur restent hors Git. Un template est ajouté uniquement lorsqu'un utilisateur doit réellement préparer une valeur non régénérée automatiquement.
+Les fichiers de configuration locale contenant chemins machine, credentials, secrets ou overrides développeur restent hors Git. Cette règle s'applique également aux propriétés Gradle locales : une propriété partagée doit rester portable et non secrète. Un template est ajouté uniquement lorsqu'un utilisateur doit réellement préparer une valeur non régénérée automatiquement.
 
 ## Validation et futurs audits PGR