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 :

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 et citer les artefacts réellement obtenus.

La forme attendue, si les noms et le statut sont confirmés, est :

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 à 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 :

auditer indépendamment la stable v0.1.1 et son rapport post-tag lorsqu'il est fourni ;
auditer le corpus Games réellement fourni, en particulier sa structure Java/Gradle et les preuves historiques pertinentes ;
relire 520-JAVA_MAVEN_GRADLE.md, ../docs/rules/610-ANDROID.md et ../docs/studies/003-V0_1_0_HORIZON_REVIEW.md ;
créer le plan 0.1.2 avant toute normalisation importante ;
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, 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, ../docs/rules/210-WORKFLOW.md, ../docs/rules/230-ADOPTION.md et ../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.

6.3 KiB Raw Blame History