Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.1.2-alpha.3

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-28 00:05:12 +02:00
parent 8de2daa716
commit 226d61b041
14 changed files with 1006 additions and 355 deletions
Download Patch File Download Diff File Expand all files Collapse all files

79
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Plan 0.1.2 — réévaluation Java / Maven / Gradle
@@ -280,6 +280,44 @@ La revue confirme la classification initiale sans l'élargir :
`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.
@@ -287,7 +325,8 @@ La release doit produire un profil Java/Maven/Gradle mieux éprouvé par une imp
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 ;
- 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 ;
@@ -302,23 +341,29 @@ Elle MUST NOT :
- 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
## Artefacts retenus après REPLAN
Artefact certain :
Owners normatifs nécessaires :
```text
docs/rules/520-JAVA_MAVEN_GRADLE.md révision ciblée si alpha.2 confirme les précisions ci-dessus
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
```
Artefacts conditionnels seulement si une lacune réelle apparaît pendant la révision :
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/... 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
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
```
Aucun skeleton Java/Gradle ni artefact Maven nouveau n'est prévu par défaut.
Cette décision sera rejouée en `beta.1` après validation opérateur de la scission.
## Trajectoire prévisionnelle de `0.1.2`
@@ -332,9 +377,19 @@ Réviser `520-JAVA_MAVEN_GRADLE.md` uniquement sur les points réellement démon
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 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.
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.
@@ -352,7 +407,7 @@ Promouvoir mécaniquement la RC validée vers `0.1.2`, fermer le plan, mettre à
## 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.
`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.