pgr/docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md

Plan 0.1.2 — réévaluation Java / Maven / Gradle

Statut et sources

Plan actif créé pendant 0.1.2-alpha.1 conformément à prompts/008-V0_1_2_START_PROMPT.md, après audit indépendant de la stable taggée v0.1.1, de son rapport post-tag PASS et du corpus Games autoritaire réellement fourni.

Sources autoritaires de reprise PGR :

pgr-v0.1.1(1).zip                    caaf8f456f7f8520172ea7705fd0cf5c5bf0e942dc4a773410bcbe7fe4ce243a
pgr-0.1.1-publish.001-report(1).md   3eafc2767225526a6cba65b3b62a45a664b71a1f2fa049915ec243a196e14bb3

Les noms locaux comportent (1), mais l'archive PGR possède exactement le SHA-256 canonique enregistré par le rapport publish.001. Le rapport est PASS, porte sur cette même archive et confirme le commit stable 4893a04f4945f7cdc62d1294626a597353023a94. Le tag annoté v0.1.1 possède l'objet tag 09a3fe1501449a02a7edbbe9e897246b5434e15c et se déréférence vers ce commit stable.

Corpus principal réellement fourni pour instruire Java/Gradle :

games-v0.3.6(1).zip                  ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8

Le nom local comporte (1), mais son SHA-256 correspond exactement à la baseline canonique games-v0.3.6.zip attendue par le prompt 008. Games est donc le corpus autoritaire prévu pour cette réévaluation.

Audit de la stable v0.1.1

Intégrité de l'archive et preuve post-tag

L'archive stable contient 292 entrées sous une racine unique pgr/, soit 256 fichiers et 36 répertoires en comptant la racine. Son CRC est propre, aucun lien symbolique n'est présent et .git est absent comme attendu pour une archive de tag Gitea.

VERSION vaut exactement 0.1.1. CHANGELOG.md contient l'entrée stable 0.1.1, ROADMAP.md marque 0.1.1 terminé et conserve 0.1.2 à 0.1.7 engagés sans réserver 0.1.8.

La publication observée suit le workflow courant :

tranche de clôture  rel.1
history             rel.1 PASS
commit stable       0.1.1
tag                  v0.1.1
publish.001          preuve externe post-tag PASS

Le SHA de l'objet tag annoté reste distinct du commit stable ; la référence déréférencée pointe bien sur le même commit que HEAD et origin/master observés dans le rapport.

Tests, audits et hygiène

Les quatre modules de tests Python de la stable ont été rejoués par groupes dans l'environnement d'analyse :

48 / 48 tests PASS

Les audits documentaires donnent exactement :

Markdown header audit: clean (231 file(s))
Markdown table audit:  clean (9 table(s), 231 file(s))
Markdown link audit:   clean (267 local link(s), 231 file(s))

Les cinq templates TOML Rust/Cargo restent parsables. Aucun symlink ni output courant tel que target/, node_modules/, dist/ ou __pycache__/ n'est embarqué dans la stable.

Chaîne delta/history et vérité opérateur

Les 83 deltas publiés de 0.0.1 à 0.1.1 disposent tous d'un history portant la même identité.

Pour 0.1.1, la vérité opérateur est conservée :

alpha.1          PASS
alpha.2          FAIL
alpha.2.fix.1    PASS
alpha.3          PASS
alpha.3.fix.1    FAIL
alpha.3.fix.2    PASS
alpha.4          PASS
alpha.5          PASS
beta.1           PASS
rc.1             PASS
rel.1            PASS

Les FAIL ne sont ni écrasés ni réécrits après leurs corrections.

État des owners et décisions différées

La stable possède notamment :

510  Rust / Cargo
520  Java / Maven / Gradle
530  TypeScript
540  JavaScript package ecosystem
550  Vite
560  CSS / Sass
610  Android
710  Tauri 2

La fondation Web 0.1.1 est stable et son skeleton est indépendant du host. Le skeleton Tauri reste DEFER jusqu'au réexamen réservé à 0.1.4 ; 0.1.2 n'a donc aucune raison de rouvrir cette décision.

Le profil 520-JAVA_MAVEN_GRADLE.md est l'owner à réévaluer. Le profil 610-ANDROID.md reste l'owner des contraintes Android et sert ici uniquement à contrôler la frontière de responsabilité, pas à démarrer 0.1.3.

Audit du corpus Games 0.3.6

Intégrité et portée

L'archive Games contient 652 entrées sous une racine unique games/, soit 502 fichiers et 150 répertoires. Son CRC est propre et aucun lien symbolique n'est présent.

La version produit est portée par Cargo.toml et vaut 0.3.6. L'absence d'un fichier racine VERSION dans ce corpus n'est pas interprétée comme un défaut PGR : Games n'est pas encore dans sa release d'adoption 0.3.7 / PGR 0.1.5.

Les audits statiques rejoués sur l'archive donnent :

General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
games.sasedev workspace audit: clean
Markdown table audit: clean (6 table(s), 319 file(s))
Distribution layout audit: clean (55 required path(s), 11 forbidden path(s) absent)

Ces contrôles attestent l'intégrité structurelle du corpus utilisé pour l'étude ; ils ne remplacent pas les validations Gradle/Android historiques déjà consignées par Games.

Structure Java observée

Le corpus contient quatre sources Java, toutes sous la convention src/main/java/ :

Android/common/src/main/java/com/sasedev/games/common/NativeBridge.java
Android/common/src/main/java/com/sasedev/games/common/SaseGameActivity.java
Android/game-reflex-poc/src/main/java/com/sasedev/games/reflex/ReflexActivity.java
Android/game-snake-poc/src/main/java/com/sasedev/games/snake/SnakeActivity.java

Les déclarations de package correspondent à leurs chemins. Les imports présents sont explicites ; aucun wildcard import n'est observé. La visibilité est bornée par la responsabilité des classes et les classes finales qui n'ont pas vocation à être étendues le sont effectivement.

Le corpus n'exerce pas de suite Java générique sous src/test/java/. Il ne fournit donc pas une preuve suffisante pour renforcer ou spécialiser les règles de tests Java du profil 520 au-delà de ce qui existe déjà.

Les responsabilités Activity, JNI, SDL3 et API Android rencontrées dans ces sources restent des responsabilités Android ou produit. Leur présence ne transforme pas ces contrats en règles Java générales.

Build Gradle observé

Le projet Android est un build Gradle multi-module en Groovy DSL comprenant :

:common
:game-reflex-poc
:game-snake-poc

L'ownership est réparti de manière identifiable :

• settings.gradle possède la composition des modules, la résolution des plugins/dépendances et le contrôle du minimum Gradle ;
• le build.gradle root possède les versions des plugins appliqués aux sous-projets ;
• gradle.properties porte des propriétés partagées non secrètes du build ;
• chaque build.gradle de module porte sa configuration locale et ses dépendances ;
• les scripts sous Android/gradle/ portent une logique de build commune devenue suffisamment importante pour ne pas être dupliquée dans chaque module.

Cette répartition corrobore le principe PGR de centraliser ce qui est réellement commun sans imposer un layout ou une abstraction identique à tous les projets Gradle.

JDK, niveau Java et compatibilité

L'historique Games fournit une preuve particulièrement utile pour la distinction déjà exigée par 520.

Une première preuve 0.3.3-0-pre.2 a utilisé un Gradle Wrapper 9.6.0 et Temurin 17 via JAVA_HOME. Cette combinaison a ensuite été volontairement remplacée par un contrat moins restrictif : Gradle système >= 9.6.0 et JDK courant de l'environnement.

Les gates 0-pre.3 à 0-pre.5 ont validé :

JDK de build       Temurin 25.0.4.1 LTS
Gradle exécuté     9.7.1
niveau Java        source/target 17

La preuve démontre qu'un JDK de build plus récent peut exécuter la toolchain tout en produisant un code Java ciblant un niveau plus ancien explicitement déclaré. Elle ne justifie ni d'imposer Java 17 à PGR, ni d'imposer JDK 25, ni de transformer une contrainte Android en règle Java générale.

Gradle système versus Wrapper

La trajectoire Games est utile précisément parce qu'elle a exercé les deux politiques :

1. wrapper exact introduit pour une preuve bornée et reproductible ;
2. retrait du wrapper lorsque la décision durable est devenue « Gradle système compatible, minimum vérifié » ;
3. contrôle de GradleVersion.current() contre 9.6.0 dans settings.gradle ;
4. validation réelle avec Gradle 9.7.1.

Cette trajectoire confirme qu'un Wrapper est un moyen de reproductibilité, pas une obligation cérémonielle, et qu'un Gradle système peut être une politique durable lorsque sa contrainte est explicitement vérifiée.

Le minimum exact 9.6.0 est toutefois lié à la stack Android observée et reste hors de toute règle Gradle générale.

DSL, dépendances et versions

Games utilise uniquement le Groovy DSL pour son projet Gradle natif. Ce choix ne fournit aucune preuve permettant de rendre Groovy obligatoire ou de déprécier Kotlin DSL dans PGR.

Aucun version catalog n'est présent. Les versions de plugins réellement partagées sont centralisées au root ; les repositories sont possédés au niveau settings.gradle. Cette organisation confirme la valeur de l'ownership partagé mais ne justifie pas d'imposer libs.versions.toml, RepositoriesMode.FAIL_ON_PROJECT_REPOS ou un repository particulier à tous les builds Gradle.

Aucun projet Maven, pom.xml ou Maven Wrapper n'est présent. Games n'autorise donc aucun nouvel artefact Maven dans 0.1.2 ; les règles Maven existantes seront seulement relues pour cohérence avec le contrat général du profil.

Outputs, état local et validation

La stable Games ignore explicitement les caches et outputs Gradle :

/Android/.gradle/
/Android/**/build/

local.properties reste également hors Git. Cette pratique corrobore la séparation PGR entre configuration partagée versionnée, état machine local et outputs générés.

Les gates historiques utilisent directement les tâches Gradle pertinentes (assembleDebug, bundleRelease, etc.) et n'emploient clean que lorsqu'une phase de stabilisation a réellement besoin de reconstruire depuis un état nettoyé. Cela confirme le principe PGR : tâches ciblées pendant le développement, gates plus larges lorsque le scope ou la phase le justifie, et aucun clean systématique comme pseudo-preuve.

Frontière Android obligatoire

Les éléments suivants sont observés dans Games mais appartiennent explicitement à 610-ANDROID.md, à une spécialisation Android/Rust/JNI ou au produit Games :

AGP 9.4.0
compileSdk / targetSdk / minSdk
NDK et ABI Android
AAR SDL3 et Prefab
JNI et bibliothèques natives
applicationId / namespace / manifests / resources
APK / AAB / signing
Variant API Android
AVD, devices et smokes Android
contraintes 16 KB
choix SDL3 et architecture des jeux

Aucun de ces éléments ne doit devenir une règle Java/Gradle générale pendant 0.1.2.

Une contrainte Gradle ou JDK plus étroite imposée par AGP constitue un raffinement de plateforme. 0.1.2 peut documenter cette frontière dans 520, mais ne réécrit pas le profil Android et ne commence pas 0.1.3.

Classification initiale des décisions Games

La classification suivante guide les tranches normatives ; elle ne constitue pas encore une adoption de Games, réservée à 0.1.5.

Décision observée	Classification	Traitement 0.1.2
Séparer JDK de build et niveau Java produit	ADOPT	conserver et clarifier dans 520
Utiliser la structure Java canonique src/main/java et des packages cohérents	ADOPT	conserver les règles existantes, sans importer les responsabilités Android
Centraliser la configuration Gradle réellement commune	ADOPT	préciser les owners settings / root / sous-projets sans imposer le layout Games
Gradle système avec contrainte minimale effectivement vérifiée	ADOPT comme politique possible	renforcer le contrat de vérifiabilité, sans imposer 9.6.0
Absence durable de Gradle Wrapper dans Games	KEEP-LOCAL	conserver le Wrapper comme option PGR de reproductibilité, pas comme obligation
Groovy DSL	KEEP-LOCAL	maintenir Groovy et Kotlin DSL comme choix valides ; ne pas copier la préférence Games
JDK 25 LTS de build et source/target 17	KEEP-LOCAL	ne généraliser que leur séparation conceptuelle
Matrice AGP/Gradle/JDK plus étroite	OVERRIDE de plateforme	reste possédée par 610 / Android, hors normalisation 520
Version catalog	DEFER	aucun besoin démontré ; rester optionnel
Nouveaux templates/audits Maven	DEFER	aucun corpus Maven réel fourni
Skeleton Java/Gradle générique	DEFER	Games n'exerce qu'un build Gradle Android ; preuve insuffisante pour un skeleton générique
Audit Python Java/Gradle	DEFER	aucune propriété générique non mieux contrôlée par Java/Gradle n'est encore démontrée

Réévaluation du profil 520

Le profil existant est globalement cohérent avec les preuves Games : il distingue déjà JDK de build et niveau Java, rend les Wrappers conditionnels, reconnaît Gradle système, accepte Groovy/Kotlin DSL, déconseille clean systématique et ignore les outputs/caches.

La release doit donc privilégier une correction ciblée plutôt qu'une réécriture. Les points à instruire en priorité sont :

1. préciser que la compatibilité Java ne se résume pas au JDK actif et qu'un JDK de build plus récent peut cibler un niveau produit plus ancien explicitement déclaré ;
2. rendre explicite qu'une politique « Gradle système » doit posséder une contrainte vérifiable par le build ou la gate, pas seulement une version écrite dans une documentation ;
3. préciser les responsabilités naturelles de settings.gradle(.kts), du root build et des sous-projets sans transformer les APIs modernes observées dans Games en obligations universelles ;
4. distinguer gradle.properties partagé et portable des propriétés locales, chemins machine, secrets ou overrides utilisateur ;
5. conserver la neutralité Groovy/Kotlin DSL et le caractère conditionnel du Wrapper/version catalog ;
6. relire les sections Maven pour cohérence, sans créer de nouvel artefact Maven faute de corpus ;
7. vérifier qu'aucune règle Java/Gradle n'absorbe AGP, SDK, NDK, ABI/JNI, packaging ou smokes Android.

Le regroupement actuel Java/Maven/Gradle dans un seul owner est également relu au regard de 500-LANGUAGES.md. Une scission documentaire ne sera effectuée que si elle réduit réellement les responsabilités ambiguës. En l'absence de corpus Maven, 0.1.2 ne créera pas artificiellement un nouvel owner Maven uniquement pour satisfaire une préférence de découpage.

Décision après alpha.1

La gate opérateur de alpha.1 est PASS : 48/48 tests Python, audits Markdown propres, audit structurel propre et scope Git conforme. Aucun alpha.1.fix.N ni REPLAN n'est requis.

La revue confirme la classification initiale sans l'élargir :

• ADOPT : distinction JDK de build / niveau source / bytecode-runtime, ownership Gradle explicite et politique Gradle système seulement si sa contrainte est effectivement vérifiée ;
• KEEP-LOCAL : Groovy DSL, absence de Wrapper dans Games, JDK 25 LTS et cible Java 17 ;
• OVERRIDE : matrice AGP/Gradle/JDK et autres contraintes de plateforme Android ;
• DEFER : version catalog, skeleton Java/Gradle, audit Python Java/Gradle et nouveaux artefacts Maven.

alpha.2 est donc bornée à la révision du profil 520. Le profil 610-ANDROID.md reste inchangé et aucun template, skeleton, audit ou artefact Maven n'est ajouté.

Mission de 0.1.2

La release doit produire un profil Java/Maven/Gradle mieux éprouvé par une implémentation réelle tout en restant générique.

Elle MUST :

• conserver les choix Java/Gradle qui sont déjà correctement généralisés ;
• corriger uniquement les ambiguïtés ou lacunes démontrées par Games ;
• classer les contraintes Android comme overrides de plateforme plutôt que règles générales ;
• utiliser Java/Gradle eux-mêmes comme autorité lorsqu'une validation exécutable est nécessaire ;
• conserver Maven cohérent sans inventer de template, audit ou skeleton en l'absence de corpus Maven ;
• ne créer un nouvel artefact Java/Gradle que s'il évite une duplication réelle ou matérialise un contrat absent du profil actuel.

Elle MUST NOT :

• modifier Games ;
• démarrer l'adoption Games 0.1.5 ;
• réécrire 610-ANDROID.md ou commencer 0.1.3 ;
• créer ou réexaminer le skeleton Tauri avant 0.1.4 ;
• rouvrir les owners Web 530 à 560 sans défaut transversal démontré ;
• introduire Maven, Kotlin DSL, version catalog, Wrapper ou plugin par simple possibilité écosystème.

Artefacts candidats

Artefact certain :

docs/rules/520-JAVA_MAVEN_GRADLE.md   révision ciblée si alpha.2 confirme les précisions ci-dessus

Artefacts conditionnels seulement si une lacune réelle apparaît pendant la révision :

docs/validation/...                    uniquement si les commandes déjà présentes dans 520 sont insuffisantes comme contrat réutilisable
docs/templates/...                     uniquement si un fichier générique possède assez de décisions stables pour être adapté sans copier Android
scripts/audit_*.py                     uniquement pour une propriété statique générique non déjà contrôlée par Java/Gradle

Aucun skeleton Java/Gradle ni artefact Maven nouveau n'est prévu par défaut.

Trajectoire prévisionnelle de 0.1.2

alpha.1 — audit de stable, corpus et plan

Vérifier v0.1.1, son rapport publish.001, le corpus Games, la frontière Android et la classification initiale. Créer le présent plan sans modifier encore 520 ou 610.

alpha.2 — révision ciblée Java / Gradle

Réviser 520-JAVA_MAVEN_GRADLE.md uniquement sur les points réellement démontrés : compatibilité JDK/source/bytecode, ownership Gradle, contrainte système vérifiable, Wrapper conditionnel, DSL, propriétés partagées/locales, validation et outputs.

Relire les sections Maven pour cohérence sans ajouter d'artefact Maven. Conserver toutes les contraintes Android dans leur owner actuel.

beta.1 — réconciliation et décision d'artefacts

Relire le profil révisé contre Games, 500-LANGUAGES.md, 610-ANDROID.md et les règles générales de validation. Vérifier qu'aucun choix local Games ou contrainte Android n'est devenu un MUST général.

À ce stade seulement, décider si un contrat de validation, template ou audit générique supplémentaire apporte une valeur réelle. S'il n'en apporte pas, consigner explicitement qu'aucun artefact supplémentaire n'est nécessaire plutôt que créer une tranche décorative.

La beta met également à jour les index/documentation durable nécessaires à la release et prépare la clôture sans ouvrir 0.1.3 prématurément.

rc.1 — release candidate

Geler le scope, rejouer la validation PGR complète, contrôler les liens/index, la frontière Android, l'absence d'artefacts Maven non justifiés et la cohérence de la trajectoire 0.1.3 à 0.1.7.

Aucune nouvelle règle fonctionnelle n'entre en RC sauf correctif .fix.N ou REPLAN explicitement justifié.

rel.1 — promotion stable

Promouvoir mécaniquement la RC validée vers 0.1.2, fermer le plan, mettre à jour CHANGELOG.md et ROADMAP.md selon le workflow applicable, préparer le handoff de publication et conserver la prochaine cible engagée 0.1.3 sans l'exécuter avant vérification post-tag de 0.1.2.

Stratégie de validation

alpha.1 reste documentaire et structurel : tests Python PGR, audits Markdown, contrôle des couples delta/history, vérification du prompt 008, de 520, de 610, du plan et du scope Git.

Lorsqu'une tranche modifie uniquement des règles PGR et ne contient aucun projet Java/Gradle exécutable, PGR ne doit pas simuler un build Java. Les preuves Games historiques peuvent justifier une décision, mais elles ne deviennent pas une gate opérateur PGR locale.

Si une tranche ultérieure ajoute un artefact Gradle exécutable réel, sa validation doit utiliser Java/Gradle officiels en plus des audits PGR applicables. Un audit Python ne remplacera ni javac, ni Gradle, ni Maven.

La validation reste proportionnée : aucune commande clean systématique et aucune gate Android uniquement parce que Games a servi de corpus d'étude.

Déclencheurs de REPLAN

Un REPLAN est requis notamment si :

• la révision montre que 520 doit être scindé en plusieurs owners pour éviter une ambiguïté normative réelle ;
• un besoin Maven réel apparaît et exige un corpus ou une preuve absente de la baseline actuelle ;
• une modification supposée générique dépend en réalité d'AGP, du SDK/NDK, de JNI ou du packaging Android ;
• un template/audit candidat exige de copier une structure Games plutôt que de matérialiser un contrat réutilisable ;
• la release ne peut pas rester bornée sans absorber une responsabilité explicitement réservée à 0.1.3 ou 0.1.4.

Un REPLAN ne sert pas à ajouter des artefacts pour remplir la release ; il sert à corriger son découpage lorsque les owners réels l'exigent.

Clôture et transition

La réconciliation documentaire durable, le CHANGELOG, la mise à jour de ROADMAP, la fermeture du plan et la préparation de la publication sont traités en beta/RC/rel.1 selon l'état réel de la release.

La roadmap possède déjà un horizon suffisant jusqu'à 0.1.7. Aucune nouvelle revue d'horizon n'est requise par défaut pendant 0.1.2.

La prochaine release engagée après publication vérifiée de 0.1.2 reste :

0.1.3 — réévaluation pratique du profil Android à partir de Games

Le prompt de démarrage de 0.1.3 ne doit être préparé que dans une tranche où la clôture 0.1.2 est suffisamment déterminée, puis exécuté seulement après stable taggée et preuve post-tag applicable.