diff --git a/ROADMAP.md b/ROADMAP.md index 59cb47d..7f7a836 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,5 +1,5 @@ - + # Roadmap Project Governance Rules @@ -24,7 +24,7 @@ Statuts : `( )` planifié, `(x)` terminé, `(d)` différé, `(c)` annulé. La revue d'horizon de `0.1.0-beta.1` engage les releases suivantes, chacune avec un domaine cohérent et une session/release indépendante : - `(x) 0.1.1` — fondation frontend Web : TypeScript, Vite, Sass/CSS, package/build outputs et validation frontend indépendante ; -- `( ) 0.1.2` — réévaluation pratique du profil Java/Maven/Gradle existant et matérialisation des artefacts génériques réellement nécessaires ; +- `( ) 0.1.2` — réévaluation pratique de Java/Maven/Gradle, séparation des owners lorsque leurs applicabilités divergent et matérialisation uniquement des artefacts génériques réellement nécessaires ; - `( ) 0.1.3` — réévaluation pratique du profil Android existant à partir de Games, sans absorber les décisions propres aux jeux ou à SDL ; - `( ) 0.1.4` — domaine Tauri : réexamen du `DEFER` et matérialisation du skeleton contrôlé seulement si les owners Web issus de `0.1.1` satisfont réellement les conditions de sortie ; - `( ) 0.1.5` — adoption réelle de PGR par `sasedev-games` avec mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ; diff --git a/RULES.md b/RULES.md index 8d1aa8f..d64d829 100644 --- a/RULES.md +++ b/RULES.md @@ -1,5 +1,5 @@ - + # Index normatif Project Governance Rules @@ -82,7 +82,9 @@ 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/520-JAVA.md`](docs/rules/520-JAVA.md) — profil Java : JDK LTS, compatibilité source/bytecode, structure, packages, API et tests. +- [`docs/rules/521-MAVEN.md`](docs/rules/521-MAVEN.md) — spécialisation Maven : ownership du reactor, wrapper conditionnel, validation et outputs. +- [`docs/rules/522-GRADLE.md`](docs/rules/522-GRADLE.md) — spécialisation Gradle : ownership du build, version/wrapper, DSL, propriétés, validation et outputs. - [`docs/rules/530-TYPESCRIPT.md`](docs/rules/530-TYPESCRIPT.md) — profil TypeScript : recommandation contrôlée, type-check et frontières typées. - [`docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md`](docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md) — manifest `package.json`, sélection du package manager, dépendances et responsabilité du lockfile. - [`docs/rules/550-VITE.md`](docs/rules/550-VITE.md) — profil Vite : build tool/dev server recommandé, cache, outputs et frontière avec le host. diff --git a/VERSION b/VERSION index 97b533b..1369075 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.1.2-alpha.2.fix.1 +0.1.2-alpha.3 diff --git a/deltas/0.1.2/alpha.3.md b/deltas/0.1.2/alpha.3.md new file mode 100644 index 0000000..1e24d6a --- /dev/null +++ b/deltas/0.1.2/alpha.3.md @@ -0,0 +1,365 @@ + + + +# Delta 0.1.2-alpha.3 — REPLAN et scission Java / Maven / Gradle + +## Baseline et version + +Baseline attendue : commit opérateur de `0.1.2-alpha.2.fix.1`, réalisé après application de `history/0.1.2/alpha.2.fix.1.md` avec statut `PASS`. Le fix de récupération doit donc être publié avant application de la présente tranche. + +Le hash de ce commit n'est pas anticipé. L'ancien stash `pgr-0.1.2-alpha.3-before-alpha.2-recovery` est uniquement une sauvegarde de l'application effectuée sur le HEAD contaminé ; il ne constitue pas une source autoritaire et doit être abandonné après publication du fix. + +Version avant application : + +```text +0.1.2-alpha.2.fix.1 +``` + +Version après application : + +```text +0.1.2-alpha.3 +``` + +## Motif du REPLAN + +La gate de `alpha.2` valide le contenu normatif ajouté à l'ancien profil combiné. La réconciliation préparatoire de `beta.1` révèle toutefois une ambiguïté d'ownership prévue comme déclencheur de REPLAN dans le plan actif. + +`500-LANGUAGES.md` autorise un langage et son build tool dans un même profil lorsque leur séparation serait artificielle, mais indique qu'ils SHOULD être séparés lorsque plusieurs build tools interchangeables possèdent chacun des règles propres significatives. + +Après `alpha.2`, Maven et Gradle possèdent chacun des contrats substantiels et indépendants : ownership du build, Wrapper, validation et outputs ; Gradle possède en plus sa politique de version système, DSL, propriétés et version catalog. Un profil unique `Java / Maven / Gradle` rend donc l'applicabilité ambiguë : un projet Java n'utilise pas nécessairement les deux build tools, et Gradle n'implique pas nécessairement Java. + +La scission devient une correction d'ownership, pas une préférence de taxonomie. + +## Scope + +REPLACE : + +```text +VERSION +RULES.md +ROADMAP.md +docs/000-README.md +docs/architecture/003-RULE_PROFILE_MODEL.md +docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md +docs/rules/000-README.md +docs/rules/520-JAVA_MAVEN_GRADLE.md +docs/rules/610-ANDROID.md +``` + +ADD : + +```text +docs/rules/520-JAVA.md +docs/rules/521-MAVEN.md +docs/rules/522-GRADLE.md +deltas/0.1.2/alpha.3.md +``` + +DELETE : aucun. + +L'ancien chemin `docs/rules/520-JAVA_MAVEN_GRADLE.md` devient un bridge `SUPERSEDED` non normatif. Il est conservé uniquement parce que des prompts, plans, deltas, histories et études historiques le référencent encore ; ces snapshots ne doivent pas être réécrits a posteriori et les audits de liens doivent rester propres. + +Aucun `history/0.1.2/alpha.3.md` n'est anticipé. + +## Owners après scission + +Le découpage courant devient : + +```text +520 Java +521 Maven +522 Gradle +``` + +### `520-JAVA.md` + +Possède uniquement les règles Java : + +- politique JDK et compatibilité source/bytecode/runtime ; +- structure `src/main/java` / `src/test/java` ; +- packages, modules, imports et visibilité ; +- interfaces/API, annotations, nullabilité et exceptions ; +- tests Java ; +- composition explicite avec Maven ou Gradle selon le build réellement utilisé. + +Il ne possède plus les règles de Wrapper, reactor, Gradle DSL ou outputs des build tools. + +### `521-MAVEN.md` + +Possède les responsabilités Maven : + +- POM parent/root et héritage multi-module ; +- `dependencyManagement` / `pluginManagement` ; +- miroir technique de `VERSION` lorsque Maven l'exige ; +- Maven système versus Wrapper sans cérémonie ; +- validation ciblée puis reactor/`verify` selon le scope ; +- `target/`, état local et futurs audits réellement justifiés. + +Games n'exerce toujours aucun projet Maven : la scission ne prétend donc pas avoir validé une nouvelle convention Maven par corpus ; elle isole seulement les règles déjà existantes et cohérentes. + +### `522-GRADLE.md` + +Possède les responsabilités Gradle validées et clarifiées en `alpha.2` : + +- ownership `settings` / root / module / propriétés partagées ; +- contrainte Gradle système effectivement vérifiée ou Wrapper lorsque pertinent ; +- neutralité Groovy/Kotlin DSL ; +- version catalog optionnel ; +- validation ciblée et `clean` non systématique ; +- `.gradle/`, `build/`, état local et futurs audits réellement justifiés. + +Le niveau Java reste possédé par `520-JAVA.md` lorsqu'un build Gradle construit du Java. + +## Bridge historique + +`520-JAVA_MAVEN_GRADLE.md` passe en révision `4` et ne contient plus de règles courantes. Il indique explicitement : + +```text +SUPERSEDED +520-JAVA.md owner Java courant +521-MAVEN.md spécialisation Maven courante +522-GRADLE.md spécialisation Gradle courante +``` + +Il n'est plus référencé par `RULES.md`, les index de règles ou les compositions courantes. Sa seule responsabilité est la compatibilité documentaire des références historiques. + +## Frontière Android + +`610-ANDROID.md` change uniquement pour refléter la nouvelle composition : + +```text +Android + Gradle -> 600 + 610 + 522 +Android + Java -> + 520 lorsque Java est réellement présent +``` + +Une application Android n'applique pas `520` uniquement parce qu'elle utilise Android ou Gradle. + +Aucune règle AGP, `compileSdk`, `targetSdk`, `minSdk`, NDK, ABI/JNI, manifests/resources, packaging/signing, device/AVD, 16 KB ou SDL3 n'est réévaluée dans cette tranche. Ce scope reste réservé à `0.1.3`. + +## Décision d'artefacts + +La scission n'autorise aucun artefact technique supplémentaire. + +Restent non justifiés : + +```text +skeleton Java/Gradle générique +template Maven ou Gradle générique +audit Python Java/Maven/Gradle +nouveau contrat de validation spécialisé +artefact Maven issu de Games +``` + +Les trois profils sont des owners normatifs nécessaires à l'applicabilité ; ils ne constituent pas une duplication fonctionnelle du build tool officiel. + +## Validation opérateur + +Après application du history `PASS`, commit/push de `alpha.2.fix.1`, abandon de l'ancien stash de sécurité, puis application du présent delta régénéré : + +```bash +test "$(cat VERSION)" = '0.1.2-alpha.3' +git cat-file -e HEAD:history/0.1.2/alpha.2.fix.1.md +test -f history/0.1.2/alpha.2.md +test -f history/0.1.2/alpha.2.fix.1.md +test -f deltas/0.1.2/alpha.3.md +test ! -e history/0.1.2/alpha.3.md + +grep -A2 '^## Statut$' history/0.1.2/alpha.2.md | grep -Fx 'PASS' +grep -A2 '^## Statut$' history/0.1.2/alpha.2.fix.1.md | grep -Fx 'PASS' + +test ! -e Cargo.toml +test ! -e crates/knowledge-domain-lib/src/content_family.rs +test ! -e deltas/0.0.1/alpha.3.fix.2.md +test ! -e history/0.0.1/alpha.3.fix.1.md + +grep -Fx '' docs/rules/520-JAVA_MAVEN_GRADLE.md +grep -Fx '`SUPERSEDED` depuis `0.1.2-alpha.3`.' docs/rules/520-JAVA_MAVEN_GRADLE.md +grep -Fx '' docs/rules/520-JAVA.md +grep -Fx '' docs/rules/521-MAVEN.md +grep -Fx '' docs/rules/522-GRADLE.md +grep -Fx '' docs/rules/610-ANDROID.md +grep -Fx '' docs/architecture/003-RULE_PROFILE_MODEL.md +grep -Fx '' docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md +grep -Fx '' RULES.md +grep -Fx '' docs/rules/000-README.md +grep -Fx '' docs/000-README.md +grep -Fx '' ROADMAP.md + +python3 -B -m unittest discover -s tests -v + +python3 -B scripts/audit_markdown_headers.py \ + README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts +python3 -B scripts/audit_markdown_tables.py \ + README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts +python3 -B scripts/audit_markdown_links.py \ + README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts + +python3 -B - <<'PYGATE' +from pathlib import Path +import re + +history = Path('history/0.1.2/alpha.2.md').read_text(encoding='utf-8') +assert re.search(r'## Statut\s+PASS\s', history) +recovery = Path('history/0.1.2/alpha.2.fix.1.md').read_text(encoding='utf-8') +assert re.search(r'## Statut\s+PASS\s', recovery) + +family = Path('docs/rules/500-LANGUAGES.md').read_text(encoding='utf-8') +for phrase in ( + 'Un langage et son build tool MAY partager un profil', + 'Ils SHOULD être séparés lorsque plusieurs build tools interchangeables possèdent chacun des règles propres significatives.', + 'Une spécialisation de build tool ne devient pas une règle du langage entier.', +): + assert phrase in family, phrase + +legacy = Path('docs/rules/520-JAVA_MAVEN_GRADLE.md').read_text(encoding='utf-8') +for phrase in ( + '`SUPERSEDED` depuis `0.1.2-alpha.3`.', + 'Il ne constitue plus un profil sélectionnable', + '520-JAVA.md', + '521-MAVEN.md', + '522-GRADLE.md', +): + assert phrase in legacy, phrase + +java = Path('docs/rules/520-JAVA.md').read_text(encoding='utf-8') +for phrase in ( + '# Profil Java', + 'JDK utilisé pour construire', + 'niveau Java du code source', + 'niveau de bytecode/runtime minimal supporté', + 'Un projet Java construit avec Maven compose normalement', + 'Un projet Java construit avec Gradle compose normalement', +): + assert phrase in java, phrase +assert '## Maven' not in java +assert '## Gradle' not in java + +maven = Path('docs/rules/521-MAVEN.md').read_text(encoding='utf-8') +for phrase in ( + '# Profil Maven', + 'POM parent/root', + 'PGR MUST NOT ajouter un Maven Wrapper uniquement par cérémonie.', + './mvnw -pl -am test', + 'target/', +): + assert phrase in maven, phrase + +gradle = Path('docs/rules/522-GRADLE.md').read_text(encoding='utf-8') +for phrase in ( + '# Profil Gradle', + 'composition du build et inclusion des projets', + 'effectivement vérifiée', + 'Groovy DSL et Kotlin DSL sont tous deux reconnus.', + 'gradle clean', +): + assert phrase in gradle, phrase + +for forbidden in ( + 'compileSdk', + 'targetSdk', + 'minSdk', + 'NDK', + 'ABI/JNI', + 'APK/AAB', + 'device/AVD', + 'SDL3', +): + assert forbidden not in maven, forbidden + assert forbidden not in gradle, forbidden + +android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8') +assert '520-JAVA.md' in android +assert '522-GRADLE.md' in android +assert '520-JAVA_MAVEN_GRADLE.md' not in android + +architecture = Path('docs/architecture/003-RULE_PROFILE_MODEL.md').read_text(encoding='utf-8') +for phrase in ( + '## Scission Java / Maven / Gradle en `0.1.2`', + '520 — Java', + '521 — Maven', + '522 — Gradle', + 'GENERAL + 500 + 520 + 522 + 600 + 610', + 'bridge `SUPERSEDED` non normatif', +): + assert phrase in architecture, phrase + +for current in ( + 'RULES.md', + 'docs/000-README.md', + 'docs/rules/000-README.md', + 'docs/rules/610-ANDROID.md', +): + assert '520-JAVA_MAVEN_GRADLE.md' not in Path(current).read_text(encoding='utf-8'), current + +plan = Path('docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md').read_text(encoding='utf-8') +for phrase in ( + '## Décision après `alpha.2` et REPLAN', + '`alpha.2.fix.1` restaure l\'état PGR attendu', + 'alpha.3 scission des owners Java / Maven / Gradle', + '520-JAVA.md', + '521-MAVEN.md', + '522-GRADLE.md', + 'bridge documentaire non normatif', + 'aucun template, skeleton, audit Java/Gradle ou nouvel artefact Maven n\'est justifié', +): + assert phrase in plan, phrase + +for foreign in ( + 'Cargo.toml', + 'crates/knowledge-domain-lib/src/content_family.rs', + 'deltas/0.0.1/alpha.3.fix.2.md', + 'history/0.0.1/alpha.3.fix.1.md', +): + assert not Path(foreign).exists(), foreign + +print('0.1.2 alpha.3 owner split audit: clean (recovery baseline confirmed, Java/Maven/Gradle applicability separated, historical bridge preserved, Android boundary preserved)') +PYGATE + +git diff --check + +git add -A + +git diff --cached --check +git status --short +``` + +Le scope indexé attendu avant ajout du history est exactement : + +```text +M ROADMAP.md +M RULES.md +M VERSION +A deltas/0.1.2/alpha.3.md +M docs/000-README.md +M docs/architecture/003-RULE_PROFILE_MODEL.md +M docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md +M docs/rules/000-README.md +M docs/rules/520-JAVA_MAVEN_GRADLE.md +A docs/rules/520-JAVA.md +A docs/rules/521-MAVEN.md +A docs/rules/522-GRADLE.md +M docs/rules/610-ANDROID.md +``` + +La revue qualitative doit confirmer que : + +- la scission suit une différence réelle d'applicabilité, pas une préférence de taille de fichier ; +- l'ancien fichier est uniquement un bridge `SUPERSEDED` et n'apparaît plus dans les index ou compositions courantes ; +- aucune règle Java n'est perdue et aucune règle Maven/Gradle n'est remontée dans `520-JAVA.md` ; +- Maven et Gradle ne s'appliquent que lorsqu'ils sont réellement utilisés ; +- la preuve Games reste principalement une preuve Gradle/Java et ne devient pas une preuve Maven fictive ; +- aucun minimum JDK, Java ou Gradle propre à Games n'est généralisé ; +- Android ne devient pas une condition d'applicabilité de `522-GRADLE.md` et `610` conserve ses responsabilités ; +- les documents historiques ne sont pas réécrits pour masquer l'ancien owner combiné ; +- aucun template, skeleton, audit ou contrat de validation supplémentaire n'est créé. + +## Transition + +### PASS + +Produire `history/0.1.2/alpha.3.md`, puis préparer `0.1.2-beta.1` pour la réconciliation intégrée des trois owners, la décision finale d'artefacts et les mises à jour documentaires durables nécessaires avant RC. + +### FAIL + +Consigner le diagnostic réel dans `history/0.1.2/alpha.3.md`, puis produire `alpha.3.fix.N` ou effectuer un nouveau REPLAN si la scission révèle une responsabilité qui ne peut pas être possédée proprement par `520`, `521` ou `522`. diff --git a/docs/000-README.md b/docs/000-README.md index 255b1de..1482050 100644 --- a/docs/000-README.md +++ b/docs/000-README.md @@ -1,5 +1,5 @@ - + # Documentation PGR @@ -23,7 +23,9 @@ Les templates techniques copiables sous `templates/` restent séparés des instr ## Points d'entrée de 0.1.2 - [`plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md`](plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md) — plan actif de réévaluation pratique du profil Java/Maven/Gradle à partir du corpus Games autoritaire, avec classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` et frontière Android explicite. -- [`rules/520-JAVA_MAVEN_GRADLE.md`](rules/520-JAVA_MAVEN_GRADLE.md) — owner existant à éprouver et corriger seulement sur les ambiguïtés réellement démontrées par Games. +- [`rules/520-JAVA.md`](rules/520-JAVA.md) — owner Java issu de la réévaluation du profil historique combiné ; il possède JDK, compatibilité source/bytecode, structure, API et tests Java. +- [`rules/521-MAVEN.md`](rules/521-MAVEN.md) — spécialisation Maven séparée afin que Maven ne devienne pas implicitement applicable à tout projet Java. +- [`rules/522-GRADLE.md`](rules/522-GRADLE.md) — spécialisation Gradle éprouvée contre Games, avec ownership du build, politique Wrapper/système et propriétés partagées/locales. - [`rules/610-ANDROID.md`](rules/610-ANDROID.md) — owner de contrôle de frontière ; AGP, SDK/NDK, ABI/JNI, manifests, packaging/signing et smokes Android restent hors du scope `0.1.2`. - [`studies/003-V0_1_0_HORIZON_REVIEW.md`](studies/003-V0_1_0_HORIZON_REVIEW.md) — revue ayant engagé `0.1.2` puis la réévaluation Android `0.1.3` comme releases distinctes. - [`../prompts/008-V0_1_2_START_PROMPT.md`](../prompts/008-V0_1_2_START_PROMPT.md) — contrat de reprise autoritaire exécuté pour ouvrir `0.1.2-alpha.1` après publication vérifiée de `v0.1.1`. diff --git a/docs/architecture/003-RULE_PROFILE_MODEL.md b/docs/architecture/003-RULE_PROFILE_MODEL.md index 7b5a3f8..4d322bf 100644 --- a/docs/architecture/003-RULE_PROFILE_MODEL.md +++ b/docs/architecture/003-RULE_PROFILE_MODEL.md @@ -1,5 +1,5 @@ - + # Modèle de profils de règles PGR @@ -204,6 +204,35 @@ Aucune contradiction non résolue de même niveau n'a été identifiée entre le La revue beta n'a pas justifié l'activation d'une famille `700 — frameworks` ou `800 — architecture`. Les règles réellement transversales rencontrées restent déjà possédées par `RULES.md`, les familles existantes ou le présent modèle architectural. +## Scission Java / Maven / Gradle en `0.1.2` + +La réévaluation pratique de `0.1.2` confirme que le profil historique combiné `520 — Java / Maven / Gradle` ne constitue plus le meilleur owner courant. Maven et Gradle sont deux build tools interchangeables possédant chacun des règles propres significatives ; les rendre tous deux applicables par l'intermédiaire d'un unique profil Java crée une ambiguïté de sélection contraire au contrat de [`../rules/500-LANGUAGES.md`](../rules/500-LANGUAGES.md). + +Le découpage courant devient : + +```text +520 — Java +521 — Maven +522 — Gradle +``` + +Les spécialisations de build restent dans la famille `500` et se composent explicitement avec le langage réellement utilisé. Par exemple : + +```text +GENERAL + 500 + 520 + 521 + Java + Maven + +GENERAL + 500 + 520 + 522 + Java + Gradle + +GENERAL + 500 + 520 + 522 + 600 + 610 + Java + Gradle + Android +``` + +Un projet Gradle sans Java n'applique pas `520` uniquement parce qu'il utilise `522`. De même, Maven et Gradle ne sont jamais rendus applicables l'un par l'autre. Les contraintes Android restent possédées par `610` et raffinent `522`, ainsi que `520` uniquement lorsque Java est réellement présent. + +Cette scission remplace l'owner courant combiné sans réécrire les documents historiques qui décrivent fidèlement l'état `0.0.2` à `0.1.1`. L'ancien chemin `520-JAVA_MAVEN_GRADLE.md` reste un bridge `SUPERSEDED` non normatif afin de préserver leurs liens. + ## Activation de la famille framework en `0.0.5` La réconciliation indépendante de KSP et Games apporte le premier framework suffisamment répété pour activer la famille `700` : Tauri 2. Le profil `710-TAURI.md` se compose au-dessus de Rust/Cargo et, selon les targets, des profils plateforme applicables. diff --git a/docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md b/docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md index d05f601..d5d2716 100644 --- a/docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md +++ b/docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md @@ -1,5 +1,5 @@ - + # 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. diff --git a/docs/rules/000-README.md b/docs/rules/000-README.md index 40e669a..1592594 100644 --- a/docs/rules/000-README.md +++ b/docs/rules/000-README.md @@ -1,5 +1,5 @@ - + # Index des règles PGR @@ -19,7 +19,9 @@ 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. +- [`520-JAVA.md`](520-JAVA.md) — profil Java et règles réutilisables propres au langage. +- [`521-MAVEN.md`](521-MAVEN.md) — spécialisation Maven, applicable uniquement aux projets qui utilisent Maven. +- [`522-GRADLE.md`](522-GRADLE.md) — spécialisation Gradle, applicable uniquement aux projets qui utilisent Gradle. - [`530-TYPESCRIPT.md`](530-TYPESCRIPT.md) — profil TypeScript, recommandation pour les frontends contrôlés, type-check et frontières typées. - [`540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md`](540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md) — package manager, `package.json`, dépendances, scripts et responsabilité du lockfile. - [`550-VITE.md`](550-VITE.md) — profil Vite, build tool/dev server recommandé et ownership de son cache et de ses outputs. diff --git a/docs/rules/520-JAVA.md b/docs/rules/520-JAVA.md new file mode 100644 index 0000000..ddda838 --- /dev/null +++ b/docs/rules/520-JAVA.md @@ -0,0 +1,200 @@ + + + +# Profil Java + +## Rôle + +Ce document possède les règles réutilisables propres au langage Java. + +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. + +Maven et Gradle sont des spécialisations de build distinctes possédées respectivement par [`521-MAVEN.md`](521-MAVEN.md) et [`522-GRADLE.md`](522-GRADLE.md). Un projet Java n'applique que le profil du build tool qu'il utilise réellement. + +Android n'est pas défini ici. Une contrainte AGP, SDK Android, `minSdk`, `targetSdk`, `versionCode`, NDK, ABI/JNI, `applicationId`, `namespace`, manifest/resources, signing, packaging APK/AAB, device/AVD ou smoke Android appartient au profil plateforme [`610-ANDROID.md`](610-ANDROID.md) ou à un owner spécialisé et peut raffiner localement les règles Java applicables. + +Une compatibilité JDK plus étroite imposée par une plateforme, un framework ou un build tool reste un override de ce scope plus spécifique. Elle MUST NOT être remontée comme minimum Java général uniquement parce qu'un projet l'exerce. + +## 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. + +Un JDK de build plus récent MAY compiler un projet qui cible un niveau source ou bytecode plus ancien lorsque le build exprime explicitement cette cible et que la toolchain choisie la supporte. Le simple fait qu'une compilation réussisse avec le JDK actif ne constitue pas une déclaration de compatibilité. + +Selon le build, ce contrat peut être matérialisé par une option de release, une toolchain, des niveaux source/target ou un mécanisme équivalent. PGR ne généralise pas un mécanisme particulier à tous les builds Java. + +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. + +Les chemins canoniques correspondants sont donc notamment `src/main/java/`, `src/main/resources/`, `src/test/java/` et `src/test/resources/`. + +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` ; +- 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. + +## Composition avec les build tools + +Un projet Java construit avec Maven compose normalement : + +```text +GENERAL ++ 500 languages / ecosystems ++ 520 Java ++ 521 Maven +``` + +Un projet Java construit avec Gradle compose normalement : + +```text +GENERAL ++ 500 languages / ecosystems ++ 520 Java ++ 522 Gradle +``` + +Une plateforme ou un framework applicable se compose ensuite au-dessus de ces owners. Le choix d'un build tool ne rend pas l'autre profil applicable. diff --git a/docs/rules/520-JAVA_MAVEN_GRADLE.md b/docs/rules/520-JAVA_MAVEN_GRADLE.md index 1bfb1f1..cc0fb75 100644 --- a/docs/rules/520-JAVA_MAVEN_GRADLE.md +++ b/docs/rules/520-JAVA_MAVEN_GRADLE.md @@ -1,341 +1,24 @@ - + -# Profil Java / Maven / Gradle +# Profil Java / Maven / Gradle — superseded -## Rôle +## Statut -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. +`SUPERSEDED` depuis `0.1.2-alpha.3`. -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. +Ce chemin est conservé uniquement afin de ne pas casser les liens contenus dans les plans, prompts, deltas, histories et études historiques qui décrivent fidèlement l'ancien owner combiné. -Android n'est pas défini ici. Une contrainte AGP, SDK Android, `minSdk`, `targetSdk`, `versionCode`, NDK, ABI/JNI, `applicationId`, `namespace`, manifest/resources, signing, packaging APK/AAB, device/AVD ou smoke Android appartient au profil plateforme Android ou à un owner spécialisé et peut raffiner localement les règles Gradle ou JDK de ce document. +Il ne constitue plus un profil sélectionnable et ne possède plus de règles normatives courantes. -Une compatibilité Gradle/JDK plus étroite imposée par une plateforme ou un framework reste un override local. Elle MUST NOT être remontée comme minimum Java/Gradle général uniquement parce qu'un projet l'exerce. +Les owners applicables sont désormais : -## Politique JDK et compatibilité Java +- [`520-JAVA.md`](520-JAVA.md) pour le langage Java ; +- [`521-MAVEN.md`](521-MAVEN.md) pour Maven lorsqu'un projet utilise Maven ; +- [`522-GRADLE.md`](522-GRADLE.md) pour Gradle lorsqu'un projet utilise Gradle. -Pour un projet Java général suivant le profil PGR : +Les contraintes Android restent possédées par [`610-ANDROID.md`](610-ANDROID.md). -- 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. +## Compatibilité documentaire -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. - -Un JDK de build plus récent MAY compiler un projet qui cible un niveau source ou bytecode plus ancien lorsque le build exprime explicitement cette cible et que la toolchain choisie la supporte. Le simple fait qu'une compilation réussisse avec le JDK actif ne constitue pas une déclaration de compatibilité. - -Selon le build, ce contrat peut être matérialisé par une option de release, une toolchain, des niveaux source/target ou un mécanisme équivalent. PGR ne généralise pas un mécanisme particulier à tous les builds Java. - -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. - -Les chemins canoniques correspondants sont donc notamment `src/main/java/`, `src/main/resources/`, `src/test/java/` et `src/test/resources/`. - -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` ; -- 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 -am test -``` - -Exemple avec Maven système : - -```bash -mvn -pl -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 lorsqu'elle est réellement partagée, sans déplacer au root une responsabilité qui appartient à un module particulier. - -Selon le DSL retenu, les propriétaires naturels sont typiquement : - -```text -settings.gradle / settings.gradle.kts - -> composition du build et inclusion des projets - -> politique de résolution des plugins/dépendances lorsqu'elle est réellement globale - -> contraintes de bootstrap ou de version Gradle lorsqu'elles doivent s'appliquer avant la configuration des projets - -build.gradle / build.gradle.kts root - -> plugins, versions ou conventions réellement partagés - -> configuration transverse qui ne doit pas être recopiée dans chaque sous-projet - -build.gradle / build.gradle.kts de module - -> plugins, dépendances, sources, tâches et paramètres propres au module - -gradle.properties partagé - -> propriétés portables, non secrètes et réellement communes au build -``` - -Cette répartition décrit des responsabilités, pas un layout obligatoire. Un build simple MAY légitimement porter moins de fichiers, et une logique transverse devenue importante MAY être extraite dans un script, build logic ou plugin clairement possédé plutôt que dupliquée. - -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. - -Les chemins machine, credentials, secrets et overrides propres à un développeur MUST NOT être introduits dans un `gradle.properties` partagé. Ils doivent utiliser un mécanisme local approprié, par exemple propriétés utilisateur Gradle, variables d'environnement ou fichier local explicitement ignoré lorsque la toolchain en possède un. - -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. Son absence dans un corpus particulier ne constitue pas une règle générale. - -Un projet contrôlé MAY utiliser un Gradle système si sa contrainte de compatibilité est **effectivement vérifiée** par le build ou par une gate exécutée par le projet/CI. Une version seulement écrite dans la documentation sans contrôle exécutable n'est pas une preuve suffisante de compatibilité. - -La vérification peut être portée par `settings.gradle(.kts)`, par une logique de bootstrap ou par une gate dédiée adaptée au projet. PGR n'impose pas l'API Gradle exacte utilisée pour cette vérification. - -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 ::test -``` - -ou, lorsqu'un Gradle système est explicitement retenu : - -```bash -gradle ::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, secrets ou overrides développeur restent hors Git. Cette règle s'applique également aux propriétés Gradle locales : une propriété partagée doit rester portable et non secrète. 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. +Un document historique qui référence ce chemin conserve ainsi une cible lisible sans être réécrit a posteriori. Pour toute décision nouvelle, les trois owners ci-dessus remplacent l'ancien profil combiné. diff --git a/docs/rules/521-MAVEN.md b/docs/rules/521-MAVEN.md new file mode 100644 index 0000000..7582908 --- /dev/null +++ b/docs/rules/521-MAVEN.md @@ -0,0 +1,84 @@ + + + +# Profil Maven + +## Rôle + +Ce document possède les règles réutilisables propres au build tool Maven. + +Il complète [`500-LANGUAGES.md`](500-LANGUAGES.md) et, lorsqu'il construit du code Java, [`520-JAVA.md`](520-JAVA.md). Maven n'est pas une règle implicite de tous les projets Java : ce profil s'applique uniquement lorsqu'un projet utilise réellement Maven. + +Les contraintes imposées par une plateforme ou un framework plus spécifique restent possédées par ce scope plus spécifique et MAY raffiner localement le présent profil. + +## 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 de langage ou de bytecode lorsqu'il appartient au build concerné ; +- `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 ou vérifiée selon les besoins du projet + +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 -am test +``` + +Exemple avec Maven système : + +```bash +mvn -pl -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. + +## Outputs, état local et Git + +Les sorties Maven usuelles sous `target/` ne sont pas versionnées. + +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 locaux contenant chemins machine, credentials, secrets 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). + +PGR lui-même ne possède actuellement aucun projet Maven exécutable à compiler. Aucune commande Maven n'est donc ajoutée aux gates documentaires de PGR uniquement pour exercer le présent profil. + +Aucun audit Maven n'est créé uniquement pour matérialiser un outil. Lorsqu'un skeleton ou projet réel fournira un sujet stable, un audit monotâche MAY vérifier une propriété objectivement structurelle non mieux contrôlée par Maven lui-même, par exemple la cohérence `VERSION`/POM ou un héritage de politique. Il reste read-only et ne lance jamais Maven à la place de ses gates propres. diff --git a/docs/rules/522-GRADLE.md b/docs/rules/522-GRADLE.md new file mode 100644 index 0000000..9827085 --- /dev/null +++ b/docs/rules/522-GRADLE.md @@ -0,0 +1,118 @@ + + + +# Profil Gradle + +## Rôle + +Ce document possède les règles réutilisables propres au build tool Gradle. + +Il complète [`500-LANGUAGES.md`](500-LANGUAGES.md) et, lorsqu'il construit du code Java, [`520-JAVA.md`](520-JAVA.md). Gradle n'est pas une règle implicite de tous les projets Java : ce profil s'applique uniquement lorsqu'un projet utilise réellement Gradle. + +Android n'est pas défini ici. Toute contrainte propre à la plateforme Android appartient à [`610-ANDROID.md`](610-ANDROID.md) ou à un owner spécialisé et MAY raffiner localement le présent profil. + +## Ownership du build + +Un projet Gradle SHOULD centraliser la configuration commune lorsqu'elle est réellement partagée, sans déplacer au root une responsabilité qui appartient à un module particulier. + +Selon le DSL retenu, les propriétaires naturels sont typiquement : + +```text +settings.gradle / settings.gradle.kts + -> composition du build et inclusion des projets + -> politique de résolution des plugins/dépendances lorsqu'elle est réellement globale + -> contraintes de bootstrap ou de version Gradle lorsqu'elles doivent s'appliquer avant la configuration des projets + +build.gradle / build.gradle.kts root + -> plugins, versions ou conventions réellement partagés + -> configuration transverse qui ne doit pas être recopiée dans chaque sous-projet + +build.gradle / build.gradle.kts de module + -> plugins, dépendances, sources, tâches et paramètres propres au module + +gradle.properties partagé + -> propriétés portables, non secrètes et réellement communes au build +``` + +Cette répartition décrit des responsabilités, pas un layout obligatoire. Un build simple MAY légitimement porter moins de fichiers, et une logique transverse devenue importante MAY être extraite dans un script, build logic ou plugin clairement possédé plutôt que dupliquée. + +Les sous-projets SHOULD NOT recopier sans nécessité : + +- la compatibilité de langage lorsqu'elle est commune ; +- les repositories ; +- les versions de plugins ; +- les contraintes de dépendances ; +- les configurations de tests communes. + +Les chemins machine, credentials, secrets et overrides propres à un développeur MUST NOT être introduits dans un `gradle.properties` partagé. Ils doivent utiliser un mécanisme local approprié, par exemple propriétés utilisateur Gradle, variables d'environnement ou fichier local explicitement ignoré lorsque la toolchain en possède un. + +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. Son absence dans un corpus particulier ne constitue pas une règle générale. + +Un projet contrôlé MAY utiliser un Gradle système si sa contrainte de compatibilité est **effectivement vérifiée** par le build ou par une gate exécutée par le projet/CI. Une version seulement écrite dans la documentation sans contrôle exécutable n'est pas une preuve suffisante de compatibilité. + +La vérification peut être portée par `settings.gradle(.kts)`, par une logique de bootstrap ou par une gate dédiée adaptée au projet. PGR n'impose pas l'API Gradle exacte utilisée pour cette vérification. + +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 ::test +``` + +ou, lorsqu'un Gradle système est explicitement retenu : + +```bash +gradle ::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. + +Lorsqu'un projet Gradle construit du Java, la déclaration du niveau source/bytecode reste gouvernée par [`520-JAVA.md`](520-JAVA.md). Gradle peut matérialiser ce contrat via ses mécanismes officiels, mais n'en devient pas le propriétaire normatif. + +## Outputs, état local et Git + +Les caches et sorties Gradle usuels sous `.gradle/` et `build/` ne sont pas versionnés. + +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, secrets ou overrides développeur restent hors Git. Cette règle s'applique également aux propriétés Gradle locales : une propriété partagée doit rester portable et non secrète. 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). + +PGR lui-même ne possède actuellement aucun projet Gradle exécutable à compiler. Aucune commande Gradle n'est donc ajoutée aux gates documentaires de PGR uniquement pour exercer le présent profil. + +De même, aucun audit Gradle n'est créé uniquement pour matérialiser un outil. Lorsqu'un skeleton ou projet réel fournira un sujet stable, un audit monotâche MAY vérifier une propriété objectivement structurelle non mieux contrôlée par Gradle lui-même, par exemple une contrainte de version déclarée. Il reste read-only et ne lance jamais Gradle à la place de ses gates propres. diff --git a/docs/rules/610-ANDROID.md b/docs/rules/610-ANDROID.md index efbd81d..e37f1af 100644 --- a/docs/rules/610-ANDROID.md +++ b/docs/rules/610-ANDROID.md @@ -1,5 +1,5 @@ - + # Profil Android @@ -7,9 +7,9 @@ Ce document possède les règles réutilisables propres à la plateforme Android. -Il complète [`600-PLATFORMS.md`](600-PLATFORMS.md) et, lorsqu'un projet Android utilise Java/Gradle, [`520-JAVA_MAVEN_GRADLE.md`](520-JAVA_MAVEN_GRADLE.md). +Il complète [`600-PLATFORMS.md`](600-PLATFORMS.md), [`522-GRADLE.md`](522-GRADLE.md) lorsqu'un projet Android utilise Gradle et [`520-JAVA.md`](520-JAVA.md) lorsqu'il contient du code Java. Android n'implique pas à lui seul l'applicabilité du profil Java. -Une contrainte Android plus spécifique MAY raffiner les règles générales Java ou Gradle dans le seul scope Android lorsqu'une matrice AGP/Gradle/JDK, un SDK ou une contrainte de distribution l'impose. +Une contrainte Android plus spécifique MAY raffiner les règles générales Gradle et, lorsque Java est applicable, les règles JDK/Java dans le seul scope Android lorsqu'une matrice AGP/Gradle/JDK, un SDK ou une contrainte de distribution l'impose. Les profils Rust/JNI et Tauri ne sont pas définis ici. Ils constituent des compositions plus spécialisées et MUST NOT contaminer le profil Android général. diff --git a/history/0.1.2/alpha.3.md b/history/0.1.2/alpha.3.md new file mode 100644 index 0000000..547b6c8 --- /dev/null +++ b/history/0.1.2/alpha.3.md @@ -0,0 +1,111 @@ + + + +# History 0.1.2-alpha.3 — scission Java / Maven / Gradle + +## Statut + +PASS + +La gate opérateur de `0.1.2-alpha.3` exécutée le `2026-09-27` est propre. La tranche réémise sur la baseline récupérée scinde correctement l'ancien owner combiné en trois owners applicables séparément, conserve le bridge historique `SUPERSEDED` et maintient la frontière Android réservée à `0.1.3`. + +## Baseline opérateur + +Le correctif de récupération précédent a été committé et publié avant application de la tranche : + +```text +commit alpha.2.fix.1 8de2daa +push 17b7ef2..8de2daa master -> master +``` + +Le stash de sécurité de l'ancienne application `alpha.3` sur le HEAD contaminé a ensuite été supprimé. La tranche courante a donc été appliquée uniquement depuis le delta régénéré sur la baseline propre. + +La gate a confirmé : + +```text +VERSION 0.1.2-alpha.3 +history/0.1.2/alpha.2.md PASS +history/0.1.2/alpha.2.fix.1.md PASS et présent dans HEAD +history/0.1.2/alpha.3.md absent pendant la gate +520-JAVA_MAVEN_GRADLE.md version 4, SUPERSEDED +520-JAVA.md version 4 +521-MAVEN.md version 1 +522-GRADLE.md version 1 +610-ANDROID.md version 3 +003-RULE_PROFILE_MODEL.md version 7 +plan 008 version 3 +``` + +Les quatre chemins Knowledge retirés par `alpha.2.fix.1` restent absents. + +## Tests Python + +La suite complète a affiché : + +```text +Ran 48 tests in 0.704s + +OK +``` + +Soit `48/48` tests `PASS`. + +## Audits Markdown + +Les audits ont affiché : + +```text +Markdown header audit: clean (242 file(s)) +Markdown table audit: clean (10 table(s), 242 file(s)) +Markdown link audit: clean (295 local link(s), 242 file(s)) +``` + +## Gate de scission des owners + +Le contrôle spécifique a terminé proprement : + +```text +0.1.2 alpha.3 owner split audit: clean (recovery baseline confirmed, Java/Maven/Gradle applicability separated, historical bridge preserved, Android boundary preserved) +``` + +Il confirme notamment que : + +- `500-LANGUAGES.md` justifie la séparation lorsque plusieurs build tools interchangeables possèdent des règles propres significatives ; +- `520-JAVA.md` possède le langage Java et ne contient plus de sections Maven ou Gradle ; +- `521-MAVEN.md` possède le reactor/POM, le Wrapper conditionnel, les validations Maven et `target/` ; +- `522-GRADLE.md` possède l'ownership `settings`/root/modules/propriétés, la politique système/Wrapper, les DSL reconnus, la validation et les outputs ; +- les contraintes Android ne sont pas remontées dans Maven ou Gradle ; +- `610-ANDROID.md` compose désormais `520-JAVA.md` et `522-GRADLE.md` lorsque ces profils sont réellement applicables ; +- l'ancien `520-JAVA_MAVEN_GRADLE.md` reste uniquement un bridge historique non sélectionnable ; +- les index et compositions courantes ne sélectionnent plus l'ancien owner combiné ; +- aucun template, skeleton, audit ou contrat de validation supplémentaire n'est introduit. + +## Hygiène Git et scope + +`git diff --check` et `git diff --cached --check` n'ont produit aucune erreur. + +Le statut indexé transmis avant ajout du présent history est exactement : + +```text +M ROADMAP.md +M RULES.md +M VERSION +A deltas/0.1.2/alpha.3.md +M docs/000-README.md +M docs/architecture/003-RULE_PROFILE_MODEL.md +M docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md +M docs/rules/000-README.md +A docs/rules/520-JAVA.md +M docs/rules/520-JAVA_MAVEN_GRADLE.md +A docs/rules/521-MAVEN.md +A docs/rules/522-GRADLE.md +M docs/rules/610-ANDROID.md +``` + +Le scope correspond exactement au delta régénéré. + +## Décision + +`0.1.2-alpha.3` est `PASS`. Aucun `alpha.3.fix.N` ni nouveau REPLAN n'est requis. + +`0.1.2-beta.1` peut maintenant réconcilier les trois owners contre Games, la famille `500`, le profil Android et les règles générales de validation. La beta doit décider explicitement si un artefact supplémentaire apporte une valeur réelle ; en l'absence d'un besoin démontré, elle doit consigner qu'aucun template, skeleton, audit Python, contrat de validation ou artefact Maven supplémentaire n'est nécessaire avant RC.