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 historique de la stable 0.1.2, 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é.

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 :

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 :

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.

Décision après alpha.3 et réconciliation beta.1

La gate opérateur de alpha.3 est PASS : 48/48 tests Python, audits Markdown propres, gate de scission propre, bridge historique préservé, frontière Android maintenue et scope Git conforme. Aucun alpha.3.fix.N ni nouveau REPLAN n'est requis.

La réconciliation beta rejoue les trois owners contre Games, 500-LANGUAGES.md, 610-ANDROID.md et les règles générales de validation. Elle confirme :

• 520-JAVA.md reste applicable au langage Java indépendamment du build tool ;
• 521-MAVEN.md ne devient applicable que lorsqu'un projet utilise Maven et n'est pas présenté comme éprouvé par Games, qui ne fournit aucun corpus Maven ;
• 522-GRADLE.md ne devient applicable que lorsqu'un projet utilise Gradle et conserve uniquement les principes génériques démontrés ;
• JDK 25, cible Java 17, Gradle 9.6.0+, Gradle 9.7.1, Groovy DSL et absence de Wrapper restent des décisions locales/corpus et non des minima PGR ;
• AGP, SDK/NDK, ABI/JNI, manifests/resources, packaging/signing, device/AVD, contraintes 16 KB et SDL3 restent possédés hors des owners Java/Maven/Gradle et réservés à la réévaluation Android 0.1.3 ;
• l'ancien 520-JAVA_MAVEN_GRADLE.md reste uniquement un bridge historique SUPERSEDED.

La décision finale d'artefacts pour 0.1.2 est donc aucun artefact technique supplémentaire : aucun nouveau contrat de validation, template, skeleton, audit Python Java/Maven/Gradle ou artefact Maven n'apporte une valeur démontrée par le corpus disponible. Les owners 520/521/522 suffisent et les toolchains officielles restent propriétaires des preuves exécutables.

La beta n'ouvre aucune nouvelle règle fonctionnelle ; elle consolide l'état durable avant rc.1.

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 :

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 :

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 est rejouée et confirmée dans 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 : PASS.

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.

Statut opérateur : PASS.

rc.1 — release candidate

Statut opérateur : PASS.

La gate RC a confirmé les cinq histories antérieurs PASS, le scope Java/Maven/Gradle gelé, le changelog candidat, le prompt 009, les 48/48 tests, les trois audits Markdown et l'hygiène texte/templates. Aucun owner, profil Android, template, skeleton, validation ou script n'a été modifié pendant la RC.

Le prompt 009-V0_1_3_START_PROMPT.md conserve la frontière de release : la réévaluation Android démarre en 0.1.3 seulement depuis une stable v0.1.2 réellement taggée et son rapport post-tag PASS; Tauri reste réservé à 0.1.4 et l'adoption Games à 0.1.5.

rel.1 — promotion stable

Première clôture stable de 0.1.2. La promotion est strictement mécanique : VERSION = 0.1.2, ROADMAP.md marque 0.1.2 terminée, le CHANGELOG perd son marqueur candidate, README/index décrivent la réévaluation Java/Maven/Gradle comme stable et le présent plan devient historique. Aucun owner, profil Android, template, skeleton, validation ou script technique n'est modifié.

Le résultat opérateur de cette tranche appartient à history/0.1.2/rel.1.md, créé seulement après exécution de la gate. Si rel.1 échoue, son history est conservé et un rel.1.fix.N corrige uniquement la fermeture ; la première tranche qui établit réellement la stable est incluse dans le commit 0.1.2 avant le tag v0.1.2.

La vérification post-tag reste séparée : pgr-0.1.2-publish.001-report.md ne peut être produit qu'à partir de l'archive du tag réellement publiée et des preuves Git observées. Le prompt 009 ne devient le point de départ effectif de 0.1.3 qu'après cette preuve post-tag PASS.

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 et la fermeture du plan sont achevés par rel.1. La publication du tag et sa vérification post-tag restent séparées de cette clôture pré-tag.

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.