# 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 : ```text 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 : ```text 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 : ```text 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 : ```text 48 / 48 tests PASS ``` Les audits documentaires donnent exactement : ```text 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 : ```text 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 : ```text 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 : ```text 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/` : ```text 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 : ```text :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é : ```text 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 : ```text /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 : ```text 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é. ## Décision après `alpha.2` et REPLAN La gate opérateur de `alpha.2` est `PASS` : `48/48` tests Python, audits Markdown propres, gate Java/Gradle propre, frontière Android préservée et scope Git conforme. Le contenu normatif ajouté dans la tranche n'exige aucun fix fonctionnel. Après cette gate, une contamination inter-projet a toutefois affecté la chaîne de commit/push : des fichiers Knowledge ont été ajoutés et deux documents PGR ont été écrasés. `alpha.2.fix.1` restaure l'état PGR attendu sans modifier les décisions Java/Maven/Gradle de `alpha.2`, conserve son history `PASS` et devient la baseline obligatoire avant réémission de `alpha.3`. L'ancienne application locale de `alpha.3` sur le HEAD contaminé n'est pas réutilisée comme source autoritaire. La préparation de `beta.1` a toutefois exécuté la réconciliation explicitement prévue contre `500-LANGUAGES.md` et `docs/architecture/003-RULE_PROFILE_MODEL.md`. Cette lecture révèle une ambiguïté d'ownership distincte du contenu validé en `alpha.2` : - `500-LANGUAGES.md` autorise un langage et son build tool dans un même profil lorsque leur séparation serait artificielle ; - le même contrat indique qu'ils SHOULD être séparés lorsque plusieurs build tools interchangeables possèdent chacun des règles propres significatives ; - `520-JAVA_MAVEN_GRADLE.md` contient désormais des contrats Maven et Gradle indépendants et substantiels : ownership du build, Wrapper, validation et outputs pour chacun, plus une politique Gradle système/DSL/propriétés qui n'appartient pas à Maven ; - l'applicabilité d'un profil unique `Java / Maven / Gradle` devient donc ambiguë pour un projet Java qui n'utilise qu'un seul de ces build tools, et plus encore pour un projet Gradle qui ne contient pas nécessairement de Java. Le déclencheur de REPLAN prévu par le présent plan est donc atteint : la scission réduit une ambiguïté normative réelle et ne constitue pas une multiplication décorative de fichiers. La trajectoire devient : ```text alpha.3 scission des owners Java / Maven / Gradle beta.1 réconciliation intégrée après scission et décision finale d'artefacts rc.1 gel et release gate rel.1 promotion stable ``` La scission retenue est : ```text 520-JAVA.md 521-MAVEN.md 522-GRADLE.md ``` `520-JAVA_MAVEN_GRADLE.md` devient `SUPERSEDED` et reste uniquement comme bridge documentaire non normatif afin de préserver les liens des prompts, plans, deltas, histories et études historiques. Les documents historiques antérieurs ne sont pas réécrits : ils restent la preuve fidèle du modèle réellement publié à leur époque. La décision d'artefacts techniques ne change pas : aucun template, skeleton, audit Java/Gradle ou nouvel artefact Maven n'est justifié par Games. Les nouveaux fichiers `521` et `522` sont des owners normatifs rendus nécessaires par l'applicabilité, pas des artefacts techniques ajoutés pour remplir la release. Le scope Android reste inchangé et réservé à `0.1.3`. La scission ne modifie que les références nécessaires dans `610-ANDROID.md` afin qu'Android compose explicitement Gradle et Java uniquement lorsqu'ils sont réellement applicables. ## 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 les ambiguïtés ou lacunes démontrées par Games et par la réconciliation des owners ; - séparer Java, Maven et Gradle lorsque leur applicabilité et leurs responsabilités divergent réellement ; - 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 retenus après REPLAN Owners normatifs nécessaires : ```text docs/rules/520-JAVA.md langage Java et compatibilité JDK/source/bytecode docs/rules/521-MAVEN.md spécialisation Maven docs/rules/522-GRADLE.md spécialisation Gradle ``` Le profil combiné historique `docs/rules/520-JAVA_MAVEN_GRADLE.md` est superseded par ces trois owners. Son chemin est conservé comme bridge documentaire non normatif pour éviter de casser les liens historiques ; il n'est plus indexé comme owner courant. Artefacts techniques explicitement non justifiés à ce stade : ```text docs/validation/... aucun nouveau contrat : 400 + profils spécialisés suffisent docs/templates/... aucun fichier générique suffisamment éprouvé hors Android scripts/audit_*.py aucune propriété générique non mieux contrôlée par Java/Maven/Gradle docs/skeletons/... aucun skeleton Java/Gradle générique justifié par le seul corpus Games artefacts Maven aucun corpus Maven réel fourni ``` Cette décision sera rejouée en `beta.1` après validation opérateur de la scission. ## 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. Statut opérateur : **PASS**. ### alpha.3 — REPLAN et scission des owners Scinder le profil combiné en `520-JAVA.md`, `521-MAVEN.md` et `522-GRADLE.md` afin d'aligner l'applicabilité avec `500-LANGUAGES.md` et le modèle de profils. Conserver le contenu normatif validé, convertir l'ancien chemin en bridge `SUPERSEDED` non normatif et mettre à jour uniquement les références courantes nécessaires. Ne pas modifier les documents historiques qui décrivent fidèlement l'ancien owner combiné. Ne pas ajouter de template, skeleton, audit ou artefact Maven/Android. Statut opérateur : **à valider**. ### beta.1 — réconciliation et décision d'artefacts Relire les trois owners issus de la scission 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 et que Maven/Gradle ne deviennent applicables que lorsqu'ils sont réellement utilisés. À 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 l'ancien owner `520`, de `610`, du plan et du scope Git. `alpha.3` ajoute une validation structurelle de la scission et des références courantes, sans simuler une toolchain Java/Maven/Gradle absente de PGR. 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 : ```text 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.