# Prompt de démarrage 0.1.2 — réévaluation Java / Maven / Gradle ## Baseline et cible Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`. La baseline attendue au démarrage effectif de `0.1.2` est l'archive source téléchargée depuis le tag Gitea `v0.1.1`, accompagnée du rapport post-tag `pgr-0.1.1-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`. Version cible : `0.1.2`. Première tranche attendue : `0.1.2-alpha.1`. Le corpus principal attendu pour confronter Java/Gradle à un projet réel est une archive autoritaire récente de `sasedev-games`. Si aucune baseline plus récente n'est explicitement fournie, la baseline de référence déjà auditée reste : ```text games-v0.3.6.zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8 ``` Une archive source peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu'elle ne peut contenir. ## Reprise manuelle après publication Après vérification réelle de l'archive du tag `v0.1.1` et du rapport post-tag `PASS`, la consigne de nouvelle session doit suivre le pattern de [`../docs/templates/003-NEW_SESSION_PROMPT.md`](../docs/templates/003-NEW_SESSION_PROMPT.md) et citer les artefacts réellement obtenus. La forme attendue, si les noms et le statut sont confirmés, est : ```text Partir de l'archive pgr-v0.1.1.zip téléchargée depuis le tag Gitea v0.1.1 et du rapport post-tag pgr-0.1.1-publish.001-report.md. Lire et exécuter prompts/008-V0_1_2_START_PROMPT.md. Vérifier intégralement la stable PGR, puis réévaluer le profil Java/Maven/Gradle à partir du corpus Games autoritaire avant de préparer 0.1.2-alpha.1, sans absorber le scope Android réservé à 0.1.3. ``` Ce texte ne doit pas être remis comme preuve de publication avant le `publish.001 PASS` réel. ## Mission Réévaluer pratiquement le profil existant [`../docs/rules/520-JAVA_MAVEN_GRADLE.md`](../docs/rules/520-JAVA_MAVEN_GRADLE.md) à partir du corpus Games réellement fourni, puis matérialiser uniquement les règles, templates, validations ou audits Java/Gradle génériques qui apportent une valeur réutilisable démontrée. `alpha.1` MUST commencer par : 1. auditer indépendamment la stable `v0.1.1` et son rapport post-tag lorsqu'il est fourni ; 2. auditer le corpus Games réellement fourni, en particulier sa structure Java/Gradle et les preuves historiques pertinentes ; 3. relire `520-JAVA_MAVEN_GRADLE.md`, [`../docs/rules/610-ANDROID.md`](../docs/rules/610-ANDROID.md) et [`../docs/studies/003-V0_1_0_HORIZON_REVIEW.md`](../docs/studies/003-V0_1_0_HORIZON_REVIEW.md) ; 4. créer le plan `0.1.2` avant toute normalisation importante ; 5. classifier les décisions observées avec `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` plutôt que copier Games dans PGR. ## Questions à instruire La release doit notamment réexaminer : - politique JDK : LTS de build, niveau source/bytecode/runtime et compatibilité réelle ; - structure source Java, packages, visibilité, imports, nullabilité, exceptions et tests ; - ownership Gradle root versus sous-projets, configuration partagée et duplication ; - Gradle système versus Wrapper, avec reproductibilité proportionnée et sans wrapper cérémoniel ; - DSL Gradle Groovy/Kotlin sans imposer arbitrairement celui observé dans Games ; - dépendances, plugins, repositories, version catalogs et contraintes de version seulement lorsqu'ils apportent une valeur générique ; - outputs/caches Gradle et état local à exclure de Git ; - validations ciblées versus gates globales, sans `clean` systématique ; - séparation claire entre ce qui appartient réellement à Java/Gradle et ce qui appartient à Android. Le profil `520` possède également Maven. Games ne constitue pas à lui seul une preuve suffisante pour inventer de nouveaux templates ou audits Maven s'il n'exerce pas Maven. Les règles Maven existantes doivent être relues pour cohérence, mais tout nouvel artefact Maven exige un besoin ou corpus réel. ## Frontière Android obligatoire `0.1.2` MUST NOT absorber les responsabilités possédées par [`../docs/rules/610-ANDROID.md`](../docs/rules/610-ANDROID.md), notamment : - Android Gradle Plugin et contraintes qui lui sont propres ; - Android SDK, `minSdk`, `targetSdk`, `compileSdk` ; - NDK, ABI, JNI et packaging natif ; - manifests, resources Android et application IDs ; - signing, APK/AAB, devices/AVD et smokes Android ; - décisions SDL ou autres choix propres au produit Games. Une contrainte Gradle/JDK découverte uniquement parce qu'Android ou Tauri Android l'impose doit rester classifiée comme contrainte de plateforme/framework, pas devenir automatiquement une règle Java/Gradle générale. ## Hors scope `0.1.2` MUST NOT : - migrer Games vers PGR ; - réécrire le profil Android ou démarrer `0.1.3` ; - réexaminer le skeleton Tauri, réservé à `0.1.4` ; - rouvrir la fondation Web `0.1.1` sans défaut transversal réellement démontré ; - créer un owner WASM, serveur Rust ou deployment/operations par proximité ; - réserver une nouvelle release au-delà de la roadmap engagée sans nouvelle revue d'horizon justifiée. ## Principes - Partir des responsabilités réellement exercées par Games, pas d'un catalogue théorique Java/Gradle. - Les choix locaux du corpus ne deviennent pas des `MUST` PGR sans preuve générique. - Utiliser la toolchain officielle Java/Gradle lorsque la validation porte sur un artefact exécutable réel ; un audit Python read-only ne remplace ni `javac`, ni Gradle, ni Maven. - Ne pas introduire automatiquement un Wrapper, un version catalog, Kotlin DSL, Maven ou un plugin simplement parce que l'écosystème les permet. - Conserver une frontière nette avec Android afin que `0.1.3` puisse réévaluer la plateforme avec ses propres owners et preuves. ## Workflow Suivre [`../RULES.md`](../RULES.md), [`../docs/rules/210-WORKFLOW.md`](../docs/rules/210-WORKFLOW.md), [`../docs/rules/230-ADOPTION.md`](../docs/rules/230-ADOPTION.md) et [`../docs/rules/400-VALIDATION.md`](../docs/rules/400-VALIDATION.md). La séquence reste : delta → gate opérateur → history constaté → application du history → commit/push → delta suivant. Les commandes de handoff sont remises automatiquement conformément à [`../docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`](../docs/templates/006-OPERATOR_COMMAND_HANDOFF.md).