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

0.0.2-alpha.4

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-23 15:05:35 +02:00
parent 34ac3a9286
commit 70ff272b79
6 changed files with 600 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
RULES.md
View File

@@ -1,5 +1,5 @@
<!-- file: RULES.md -->
<!-- version: 7 -->
<!-- version: 8 -->
# Index normatif Project Governance Rules
@@ -80,6 +80,7 @@ Familles actuellement actives :
- [`docs/rules/400-VALIDATION.md`](docs/rules/400-VALIDATION.md) — sélection proportionnelle des preuves, catégories de validation, tests utiles, doubles de test et autorité opérateur.
- [`docs/rules/500-LANGUAGES.md`](docs/rules/500-LANGUAGES.md) — contrat commun des profils langage, écosystème et spécialisations de build associées.
- [`docs/rules/510-RUST_CARGO.md`](docs/rules/510-RUST_CARGO.md) — profil Rust/Cargo : workspace, manifests, dépendances, lints, API, formatage, tests et validation spécialisée.
- [`docs/rules/520-JAVA_MAVEN_GRADLE.md`](docs/rules/520-JAVA_MAVEN_GRADLE.md) — profil Java et spécialisations Maven/Gradle : toolchain LTS, structure, dépendances, tests et validation de build.
- [`docs/rules/600-PLATFORMS.md`](docs/rules/600-PLATFORMS.md) — contrat commun des profils plateforme et de leur compatibilité de target/runtime.
Le modèle de composition et d'ownership des profils est défini dans [`docs/architecture/003-RULE_PROFILE_MODEL.md`](docs/architecture/003-RULE_PROFILE_MODEL.md).

2
VERSION
View File

@@ -1 +1 @@
0.0.2-alpha.3
0.0.2-alpha.4

162
deltas/0.0.2/alpha.4.md Normal file
View File

@@ -0,0 +1,162 @@
<!-- file: deltas/0.0.2/alpha.4.md -->
<!-- version: 1 -->
# Delta 0.0.2-alpha.4 — profil Java / Maven / Gradle
## Baseline
Version attendue avant application :
```text
0.0.2-alpha.3
```
Le history `history/0.0.2/alpha.3.md` MUST avoir été appliqué et committé avant ce delta.
Version après application :
```text
0.0.2-alpha.4
```
## Objet
Matérialiser le deuxième profil technologique de PGR : `Java / Maven / Gradle`.
Cette tranche conserve une frontière explicite entre :
```text
Java
→ règles du langage et de l'API
Maven / Gradle
→ spécialisations de build
Android / frameworks futurs
→ contraintes plus spécifiques qui pourront surcharger localement Java ou Gradle
```
Aucune règle Android, AGP, SDK, `minSdk`, `targetSdk`, `versionCode`, APK/AAB ou JNI n'est absorbée dans ce profil.
## Réconciliation retenue
Le profil reprend les principes déjà établis par PGR et les corpus de conception revus pour cette release :
- JDK LTS par défaut, dernière LTS compatible utilisée en priorité ;
- bascule vers une LTS plus ancienne lorsqu'une dépendance ou un outil l'exige ;
- non-LTS uniquement par exception justifiée ;
- séparation entre JDK de build et niveau Java/runtime supporté ;
- structure standard `src/main/java`, `src/main/resources`, `src/test/java`, `src/test/resources` ;
- packages orientés responsabilités et visibilité minimale ;
- imports explicites ;
- interfaces uniquement lorsqu'une vraie frontière existe ;
- pas de Lombok/convenience codegen implicite par défaut, sans interdire les annotations fonctionnelles de frameworks ;
- nullabilité et exceptions explicites ;
- tests unitaires/intégration/environnement séparables ;
- politique Maven centralisée dans le parent/root ;
- `dependencyManagement` / `pluginManagement` utilisés pour la politique commune sans ajouter artificiellement les dépendances aux modules ;
- Maven Wrapper conditionnel selon le besoin de reproductibilité ;
- configuration Gradle commune centralisée ;
- version catalog Gradle uniquement si la complexité le justifie ;
- contrainte Gradle exprimée comme minimum, range, pin exact ou latest compatible selon la vraie matrice ;
- Gradle Wrapper recommandé lorsqu'il apporte une reproductibilité réelle, sans interdire un Gradle système explicitement contraint ;
- un DSL Gradle cohérent par projet, sans transformer Groovy/Kotlin DSL en préférence de langage applicatif ;
- tâches ciblées pendant le développement, gates globales lorsque leur preuve devient utile ;
- `clean` traité comme maintenance ;
- outputs/caches/état local hors Git, avec wrappers comme exception volontaire lorsqu'ils sont retenus.
## Profil créé
Le nouveau propriétaire normatif est :
```text
docs/rules/520-JAVA_MAVEN_GRADLE.md
```
Il complète la famille `500 — languages / ecosystems` et n'introduit pas de nouvelle famille de navigation.
Aucun audit Java/Maven/Gradle n'est ajouté : le dépôt PGR ne contient actuellement aucun projet de ce type sur lequel une telle gate fournirait une preuve réelle.
## Scope
REPLACE :
```text
VERSION
RULES.md
docs/rules/000-README.md
```
ADD :
```text
docs/rules/520-JAVA_MAVEN_GRADLE.md
deltas/0.0.2/alpha.4.md
```
DELETE : aucun.
Aucun manifest de suppression n'est nécessaire.
## Validation opérateur
```bash
test "$(cat VERSION)" = "0.0.2-alpha.4"
test -f docs/rules/520-JAVA_MAVEN_GRADLE.md
test -f deltas/0.0.2/alpha.4.md
grep -F 'le JDK de développement SHOULD être une version LTS' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -F 'JDK utilisé pour construire' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -F 'src/main/' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -F 'Lombok et les outils équivalents de convenience/codegen implicite SHOULD NOT être utilisés par défaut' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -F 'Le fichier PGR `VERSION` reste la version canonique de l' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -F 'PGR MUST NOT ajouter un Maven Wrapper uniquement par cérémonie.' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -F 'minimum seulement' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -F 'Un Gradle Wrapper SHOULD être versionné lorsqu' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -F 'Groovy DSL et Kotlin DSL sont tous deux reconnus.' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -F 'gradle clean` est une opération de maintenance' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -F 'Aucune commande Maven/Gradle n' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -F '520-JAVA_MAVEN_GRADLE.md' RULES.md
grep -F '520-JAVA_MAVEN_GRADLE.md' docs/rules/000-README.md
python3 -B scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
git diff --check
git add VERSION RULES.md docs/rules/000-README.md docs/rules/520-JAVA_MAVEN_GRADLE.md deltas/0.0.2/alpha.4.md
git diff --cached --check
git status --short
```
La sortie attendue avant ajout du history est :
```text
M RULES.md
M VERSION
A deltas/0.0.2/alpha.4.md
M docs/rules/000-README.md
A docs/rules/520-JAVA_MAVEN_GRADLE.md
```
Revue opérateur complémentaire :
- confirmer que les règles Java restent distinctes des contraintes propres à Maven/Gradle ;
- confirmer que les contraintes Android restent hors de ce profil et pourront surcharger localement Gradle/JDK en `alpha.5` ;
- confirmer que la politique JDK privilégie les LTS sans pin exact arbitraire ;
- confirmer que Lombok/convenience codegen est distingué des annotations fonctionnelles de frameworks ;
- confirmer que Maven Wrapper et Gradle Wrapper sont des choix de reproductibilité justifiés, pas des obligations cérémonielles universelles ;
- confirmer qu'aucune commande Maven/Gradle réelle n'est exigée pour valider cette tranche documentaire dans le dépôt PGR lui-même.
## Transition
### PASS
Créer et appliquer séparément `history/0.0.2/alpha.4.md`, committer la tranche, puis préparer `0.0.2-alpha.5` consacré au profil plateforme Android.
### FAIL
Rester dans `0.0.2-alpha.4.fix.M` tant que les frontières Java/build tool ou les politiques de compatibilité restent incorrectes. Effectuer un REPLAN si la tranche révèle une dérive significative du scope.

3
docs/rules/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/000-README.md -->
<!-- version: 8 -->
<!-- version: 9 -->
# Index des règles PGR
@@ -17,6 +17,7 @@ Les règles générales actuellement nécessaires restent dans `RULES.md`. La fa
- [`400-VALIDATION.md`](400-VALIDATION.md) — matrice de validation, preuves proportionnelles, tests/audits/diagnostics, doubles de test et autorité du gate opérateur.
- [`500-LANGUAGES.md`](500-LANGUAGES.md) — contrat commun des profils langage/écosystème et de leurs spécialisations de build.
- [`510-RUST_CARGO.md`](510-RUST_CARGO.md) — profil Rust/Cargo et règles réutilisables propres à cet écosystème.
- [`520-JAVA_MAVEN_GRADLE.md`](520-JAVA_MAVEN_GRADLE.md) — profil Java et spécialisations de build Maven/Gradle.
- [`600-PLATFORMS.md`](600-PLATFORMS.md) — contrat commun des profils plateforme.
Le modèle transversal d'ownership, d'applicabilité et de composition est décrit dans [`../architecture/003-RULE_PROFILE_MODEL.md`](../architecture/003-RULE_PROFILE_MODEL.md).

314
docs/rules/520-JAVA_MAVEN_GRADLE.md Normal file
View File

@@ -0,0 +1,314 @@
<!-- file: docs/rules/520-JAVA_MAVEN_GRADLE.md -->
<!-- version: 1 -->
# Profil Java / Maven / Gradle
## Rôle
Ce document possède les règles réutilisables propres au langage Java et à ses deux spécialisations de build principales retenues ici : Maven et Gradle.
Il complète [`500-LANGUAGES.md`](500-LANGUAGES.md). Les règles de gouvernance, documentation et validation restent possédées par leurs familles générales.
Android n'est pas défini ici. Une contrainte AGP, SDK Android, `minSdk`, `targetSdk`, `versionCode`, signing ou packaging APK/AAB appartient au profil plateforme Android et peut surcharger localement les règles Gradle ou JDK de ce document.
## Politique JDK et compatibilité Java
Pour un projet Java général suivant le profil PGR :
- le JDK de développement SHOULD être une version LTS ;
- la dernière LTS compatible disponible dans l'environnement SHOULD être utilisée par défaut ;
- une LTS plus ancienne MAY être sélectionnée lorsqu'un outil, framework, serveur, CI ou environnement d'exécution l'exige ;
- une version Java non-LTS SHOULD NOT être introduite sans besoin technique explicite.
PGR MUST distinguer :
```text
JDK utilisé pour construire
≠
niveau Java du code source
≠
niveau de bytecode/runtime minimal supporté
```
Le niveau Java ciblé MUST être déclaré explicitement par le build lorsqu'il affecte la compatibilité. Il ne doit pas dépendre implicitement du JDK actif sur la machine.
Une hausse de la version Java minimale supportée constitue un changement de compatibilité et MUST être justifiée comme telle.
PGR MUST NOT imposer une version exacte de JDK uniquement parce qu'un corpus historique ou un autre projet utilise cette version.
## Structure source Java
Un module Java classique SHOULD conserver la structure reconnue par l'écosystème :
```text
src/
├── main/
│ ├── java/
│ └── resources/
└── test/
├── java/
└── resources/
```
PGR SHOULD NOT remplacer cette convention par une arborescence propriétaire telle que `sources/`, `java-code/` ou `tests-java/` sans contrainte réelle.
Lorsqu'un projet distingue des tests d'intégration, environnementaux ou live, il SHOULD utiliser un source set ou un module explicitement déclaré par le build plutôt que détourner `src/test/`.
## Packages et ownership
Un package Java représente une responsabilité architecturale, pas seulement un dossier.
La racine de package SHOULD être stable et appartenir au projet ou à l'organisation. Les sous-packages SHOULD refléter des responsabilités telles que `config`, `transport`, `store`, `logging` ou `protocol`.
Les packages génériques tels que `misc`, `stuff`, `helpers`, `common` ou `util` SHOULD NOT devenir des dépotoirs. Lorsqu'un élément est partagé, son propriétaire architectural doit d'abord être identifié.
Un package utilitaire petit et cohérent MAY exister lorsque sa responsabilité est claire.
## Nommage des modules
Lorsqu'un dépôt multi-langage ou multi-module utilise déjà une nomenclature de rôles commune, les modules Java SHOULD conserver les mêmes suffixes conceptuels afin de rester lisibles à l'échelle du dépôt.
Exemples usuels :
```text
foo-api
foo-lib
foo-app
foo-cli
foo-server
foo-service
foo-worker
foo-tool
foo-demo
foo-smoke
foo-poc
```
Ce vocabulaire est une convention de rôle et non une obligation de créer artificiellement des modules séparés.
## Imports
Les imports wildcard SHOULD NOT être utilisés :
```java
import foo.*;
import static foo.Bar.*;
```
Les imports explicites sont préférés afin de conserver l'origine des symboles visible.
Les imports statiques SHOULD être évités par défaut dans le code produit lorsqu'une forme qualifiée reste lisible. Une règle de test ou de framework plus spécifique MAY autoriser une convention différente lorsqu'elle est réellement idiomatique et bornée.
## Visibilité et API
La visibilité minimale appropriée est la règle par défaut :
```text
private
→ package-private
→ protected
→ public
```
Une méthode ou un type MUST NOT devenir `public` uniquement pour faciliter un test.
Une interface Java SHOULD exister lorsqu'elle représente une vraie frontière : plusieurs implémentations, contrat consommé indépendamment, adaptation de plateforme, API publique ou autre séparation architecturale réelle.
PGR SHOULD NOT généraliser le pattern `Foo` / `FooImpl` lorsqu'une seule implémentation existe sans frontière utile.
## Annotations et génération implicite
PGR n'interdit pas les annotations en tant que mécanisme Java.
Les annotations fonctionnelles faisant partie du contrat officiel d'un framework ou d'une API sont légitimes, par exemple pour la persistance, la validation, l'injection, le routage ou d'autres mécanismes officiellement documentés.
En revanche, Lombok et les outils équivalents de convenience/codegen implicite SHOULD NOT être utilisés par défaut lorsqu'ils servent principalement à masquer du boilerplate, générer des constructeurs/getters/setters ou modifier implicitement l'API visible dans la source.
Une exception exige une justification explicite et reste attachée au projet ou framework concerné.
## Nullabilité
`null` SHOULD apparaître uniquement lorsqu'il appartient explicitement au contrat.
Une API ne devrait pas laisser le caller deviner si l'absence est possible. Selon le cas, le contrat peut employer :
- `Optional<T>` ;
- une collection vide ;
- une exception appropriée ;
- un type résultat plus explicite ;
- une annotation de nullabilité reconnue par le projet.
PGR MUST NOT imposer `Optional` partout. L'objectif est l'explicitation du contrat, pas une cérémonie syntaxique.
## Exceptions
Java possède un mécanisme natif d'exceptions ; PGR ne recrée pas automatiquement un modèle `Result` autour de toutes les opérations.
La distinction checked/unchecked appartient au contrat de la couche concernée.
Un `catch` SHOULD exister uniquement lorsque la couche sait réellement traiter, traduire ou enrichir l'erreur. Les captures silencieuses de `Exception` ou `Throwable` sont interdites hors mécanisme de frontière explicitement spécialisé.
Lorsqu'une erreur est traduite, sa cause SHOULD être préservée lorsque cette information reste pertinente.
Une couche SHOULD exposer ses propres erreurs de contrat plutôt que propager sans contrôle les détails techniques d'une dépendance interne.
## Tests Java
Les tests comportementaux et structurels gardent des responsabilités distinctes.
Les tests unitaires résident normalement sous `src/test/java/`. Les tests d'intégration, environnementaux ou live SHOULD être séparés par source set, module ou tâche lorsque leur exécution possède des préconditions différentes.
Les tests MUST NOT :
- rendre publique une API uniquement pour l'atteindre ;
- rechercher des chaînes dans les sources pour simuler un audit d'architecture ;
- vérifier une prerelease en codant en dur la version courante ;
- ouvrir `VERSION`, `pom.xml` ou `build.gradle` uniquement pour confirmer leur synchronisation.
Les contraintes structurelles appartiennent au build system, au compilateur, à un linter adapté ou à un audit read-only.
## Maven — ownership du build
Dans un projet Maven multi-module, le POM parent/root SHOULD centraliser ce qui est réellement commun :
- version du projet lorsqu'elle doit être reflétée par Maven ;
- niveau Java cible ;
- `dependencyManagement` ;
- `pluginManagement` ;
- configuration commune de compilation et de tests.
Les modules SHOULD hériter de cette politique lorsque Maven le permet et ne pas recopier les mêmes versions/configurations sans nécessité.
Le fichier PGR `VERSION` reste la version canonique de l'unité de release. Le `pom.xml` racine porte un miroir technique lorsque Maven exige cette valeur. Les enfants SHOULD hériter de la version parent afin d'éviter les modifications mécaniques répétées de nombreux POM.
`dependencyManagement` centralise les contraintes de version communes ; il ne signifie pas qu'une dépendance doit être effectivement ajoutée à tous les modules. Chaque module déclare uniquement ce qu'il utilise.
## Maven Wrapper
Deux politiques sont légitimes :
```text
Maven système
→ environnement contrôlé
→ contrainte de version documentée
Maven Wrapper
→ distribution / CI / onboarding reproductible
→ wrapper versionné
```
PGR MUST NOT ajouter un Maven Wrapper uniquement par cérémonie.
Lorsqu'un wrapper est retenu, ses fichiers requis sont versionnés et constituent une exception explicite à la politique générale qui ignore les outputs générés.
## Validation Maven
Le développement SHOULD privilégier les gates ciblées avant le reactor complet.
Exemple avec wrapper :
```bash
./mvnw -pl <module> -am test
```
Exemple avec Maven système :
```bash
mvn -pl <module> -am test
```
Les gates globales telles que le reactor complet, `verify` ou le packaging de tous les modules SHOULD être réservées aux changements transverses et aux phases où elles fournissent une preuve supplémentaire réelle.
`clean` est une opération de maintenance et MUST NOT précéder automatiquement chaque validation.
## Gradle — ownership du build
Un projet Gradle SHOULD centraliser la configuration commune au niveau root lorsqu'elle est réellement partagée.
Selon le DSL retenu, les propriétaires typiques sont :
```text
settings.gradle / settings.gradle.kts
build.gradle / build.gradle.kts
gradle.properties
```
Les sous-projets SHOULD NOT recopier sans nécessité :
- la compatibilité Java ;
- les repositories ;
- les versions de plugins ;
- les contraintes de dépendances ;
- les configurations de tests communes.
Un version catalog tel que `gradle/libs.versions.toml` MAY être utilisé lorsque la taille du projet le justifie. PGR MUST NOT l'imposer pour un projet qui n'en tire aucun bénéfice réel.
## Gradle Wrapper et version de Gradle
La contrainte Gradle doit refléter la matrice réellement supportée par le projet :
```text
minimum seulement
range min..max
version exacte/pinnée
latest compatible
```
Le projet MUST choisir la forme la moins restrictive qui prouve réellement sa compatibilité.
Un Gradle Wrapper SHOULD être versionné lorsqu'il apporte une reproductibilité utile pour la distribution, la CI ou l'onboarding. Un projet contrôlé MAY utiliser un Gradle système si sa contrainte de compatibilité est explicitement vérifiée.
Une plateforme ou un framework plus spécifique MAY imposer une contrainte plus étroite. Cette contrainte ne se propage jamais implicitement aux autres projets Gradle.
## DSL Gradle
PGR ne transforme pas une préférence de langage applicatif en interdiction du DSL de build.
Groovy DSL et Kotlin DSL sont tous deux reconnus. Un projet SHOULD retenir un DSL canonique et éviter de les mélanger arbitrairement.
Le code applicatif Java reste Java par défaut lorsque rien n'impose Kotlin/Groovy. Les scripts Gradle SHOULD rester aussi déclaratifs et courts que raisonnablement possible.
Une logique de build devenue importante SHOULD être déplacée vers une abstraction ou un plugin clairement possédé plutôt que grossir indéfiniment les scripts root.
## Validation Gradle
Les tâches ciblées sont préférées pendant le développement :
```bash
./gradlew :<module>:test
```
ou, lorsqu'un Gradle système est explicitement retenu :
```bash
gradle :<module>:test
```
Les tâches globales `check`, `build`, `assemble` ou de packaging complet SHOULD être sélectionnées lorsqu'elles correspondent réellement au scope, typiquement lors d'un changement transverse ou dans les phases de stabilisation/release.
`gradle clean` est une opération de maintenance et MUST NOT être utilisé comme précondition automatique à chaque build.
## Outputs, état local et Git
Les sorties de build et caches usuels ne sont pas versionnés :
```text
Maven: target/
Gradle: .gradle/, build/
```
Les métadonnées IDE spécifiques à une machine restent ignorées sauf exception explicitement partagée selon les règles générales du projet.
Les wrappers retenus sont une exception volontaire : ils peuvent être générés par l'outil, mais leurs fichiers nécessaires au bootstrap reproductible sont versionnés.
Les fichiers de configuration locale contenant chemins machine, credentials ou overrides développeur restent hors Git. Un template est ajouté uniquement lorsqu'un utilisateur doit réellement préparer une valeur non régénérée automatiquement.
## Validation et futurs audits PGR
Les catégories et l'autorité du gate restent possédées par [`400-VALIDATION.md`](400-VALIDATION.md).
Ce profil définit des commandes et politiques Java/Maven/Gradle, mais PGR lui-même ne possède actuellement aucun projet Java, Maven ou Gradle à compiler. Aucune commande Maven/Gradle n'est donc ajoutée à la gate documentaire de cette tranche.
De même, aucun audit Java/Maven/Gradle n'est créé uniquement pour matérialiser un outil.
Lorsqu'un skeleton ou projet réel fournira un sujet stable, des audits monotâches MAY vérifier séparément des propriétés objectivement structurelles, par exemple la cohérence `VERSION`/POM, l'héritage d'une politique Maven ou la contrainte Gradle déclarée. Ils resteront read-only et ne lanceront jamais Maven ou Gradle à la place de leurs gates propres.

119
history/0.0.2/alpha.4.md Normal file
View File

@@ -0,0 +1,119 @@
<!-- file: history/0.0.2/alpha.4.md -->
<!-- version: 1 -->
# History 0.0.2-alpha.4 — profil Java / Maven / Gradle
## Statut
FAIL
La tranche `0.0.2-alpha.4` n'est pas validée `PASS` telle quelle.
Le contenu principal est cohérent et presque toute la gate a réussi, mais une commande obligatoire du delta n'a produit aucun match :
```bash
grep -F 'src/main/' docs/rules/520-JAVA_MAVEN_GRADLE.md
```
La sortie observée est vide. Pour `grep -F`, l'absence de correspondance correspond à un code de retour non nul.
Il s'agit d'un défaut de cohérence entre le texte du profil et la gate de validation, pas d'un défaut de la politique Java/Maven/Gradle elle-même.
## Baseline
Version contrôlée :
```text
0.0.2-alpha.4
```
Le profil attendu et le delta sont présents :
```text
docs/rules/520-JAVA_MAVEN_GRADLE.md
deltas/0.0.2/alpha.4.md
```
## Contrôles réussis observés
Les contrôles suivants ont produit les correspondances attendues :
```text
le JDK de développement SHOULD être une version LTS
JDK utilisé pour construire
Lombok et les outils équivalents de convenience/codegen implicite SHOULD NOT être utilisés par défaut
Le fichier PGR `VERSION` reste la version canonique de l'unité de release
PGR MUST NOT ajouter un Maven Wrapper uniquement par cérémonie.
minimum seulement
Un Gradle Wrapper SHOULD être versionné lorsqu'il apporte une reproductibilité utile
Groovy DSL et Kotlin DSL sont tous deux reconnus.
`gradle clean` est une opération de maintenance
Aucune commande Maven/Gradle n'est donc ajoutée à la gate documentaire de cette tranche.
```
Les références de navigation vers `520-JAVA_MAVEN_GRADLE.md` ont également été trouvées dans :
```text
RULES.md
docs/rules/000-README.md
```
L'audit Markdown a réussi :
```text
Markdown table audit: clean (2 table(s), 56 file(s))
```
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
Le scope Git observé avant le présent history est :
```text
M RULES.md
M VERSION
A deltas/0.0.2/alpha.4.md
M docs/rules/000-README.md
A docs/rules/520-JAVA_MAVEN_GRADLE.md
```
## Défaut exact
Le document contient une arborescence structurée :
```text
src/
├── main/
│ ├── java/
│ └── resources/
└── test/
├── java/
└── resources/
```
mais la gate cherche littéralement la chaîne :
```text
src/main/
```
Cette chaîne n'existe pas dans cette représentation arborescente.
La tranche ne peut donc pas être enregistrée `PASS` tant que sa propre gate n'est pas reproductible telle qu'elle est spécifiée.
## Décision
Aucun REPLAN n'est requis.
Le correctif est local et conserve exactement l'objectif de `alpha.4` :
```text
0.0.2-alpha.4.fix.1
```
Il doit seulement rendre explicites dans le profil les chemins Java canoniques déjà décrits conceptuellement, puis rejouer une gate cohérente.
## Résultat
`0.0.2-alpha.4` est enregistré `FAIL`.
La seule transition autorisée est `0.0.2-alpha.4.fix.1`.