8 Commits

Author SHA1 Message Date
585b508578 0.1.2 2026-09-28 01:27:41 +02:00
36b2b2162c 0.1.2-rc.1 2026-09-28 01:21:44 +02:00
4dcb0dd89e 0.1.2-beta.1 2026-09-28 01:03:26 +02:00
226d61b041 0.1.2-alpha.3 2026-09-28 00:05:12 +02:00
8de2daa716 0.1.2-alpha.2.fix.1 2026-09-27 23:12:36 +02:00
17b7ef23a1 0.1.2-alpha.2 2026-09-27 22:44:02 +02:00
6e978bfed8 0.0.1-alpha.3.fix.1 2026-09-27 22:36:07 +02:00
46a159a3bc 0.1.2-alpha.1 2026-09-27 22:27:45 +02:00
30 changed files with 3868 additions and 321 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: CHANGELOG.md --> <!-- file: CHANGELOG.md -->
<!-- version: 13 --> <!-- version: 15 -->
# Changelog Project Governance Rules # Changelog Project Governance Rules
@@ -7,6 +7,15 @@ Ce fichier décrit les changements utiles aux utilisateurs ou intégrateurs des
Les tranches `alpha`, `beta`, `rc`, fixes, validations, audits et détails de développement appartiennent aux plans, deltas et historiques. Ils ne sont pas recopiés ici par défaut. Les tranches `alpha`, `beta`, `rc`, fixes, validations, audits et détails de développement appartiennent aux plans, deltas et historiques. Ils ne sont pas recopiés ici par défaut.
## 0.1.2
- sépare l'ancien profil combiné Java/Maven/Gradle en trois owners indépendants et composables : `520-JAVA`, `521-MAVEN` et `522-GRADLE`, afin qu'un build tool ne devienne pas implicitement applicable à tout projet Java ;
- clarifie la distinction entre JDK utilisé pour construire, niveau Java du code source et niveau de bytecode/runtime supporté, sans généraliser les versions particulières observées dans Games ;
- formalise pour Gradle l'ownership `settings` / root / modules / propriétés partagées, ainsi que le choix proportionné entre Wrapper et Gradle système avec contrainte effectivement vérifiée ;
- conserve Maven comme spécialisation indépendante et cohérente sans prétendre l'avoir éprouvée par Games ni créer d'artefact Maven en l'absence de corpus réel ;
- conserve l'ancien chemin `520-JAVA_MAVEN_GRADLE.md` uniquement comme bridge documentaire `SUPERSEDED` pour les références historiques et n'ajoute aucun template, skeleton, audit Python ou contrat de validation Java/Maven/Gradle non justifié ;
- maintient les responsabilités AGP, SDK/NDK, ABI/JNI, manifests/resources, packaging/signing et smokes Android dans l'owner Android, dont la réévaluation pratique reste la cible distincte `0.1.3`.
## 0.1.1 ## 0.1.1
- établit une fondation frontend Web composable avec quatre owners indépendants : TypeScript, écosystème de package JavaScript, Vite et CSS/Sass, sans transformer un outil concret en obligation universelle ; - établit une fondation frontend Web composable avec quatre owners indépendants : TypeScript, écosystème de package JavaScript, Vite et CSS/Sass, sans transformer un outil concret en obligation universelle ;

View File

@@ -1,5 +1,5 @@
<!-- file: README.md --> <!-- file: README.md -->
<!-- version: 19 --> <!-- version: 22 -->
# Project Governance Rules # Project Governance Rules
@@ -11,9 +11,9 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.
## Statut ## Statut
PGR a clôturé sa phase de fondation `0.0.x`, dispose avec `0.1.0` de sa première baseline réutilisable stable et avec `0.1.1` d’une fondation frontend Web stable, composable et indépendante du host. PGR a clôturé sa phase de fondation `0.0.x`, dispose avec `0.1.0` de sa première baseline réutilisable stable, avec `0.1.1` d’une fondation frontend Web stable et avec `0.1.2` d’owners Java, Maven et Gradle séparés et composables après réévaluation du corpus Games. Le scope Android reste réservé à `0.1.3`.
La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` établit la gouvernance normative et documentaire de PGR lui-même. La release `0.0.2` ajoute les premiers profils réutilisables Rust/Cargo, Java/Maven/Gradle et Android, ainsi que deux audits Markdown. La release `0.0.3` fournit les premiers modèles Rust/Cargo, deux audits de style Rust facultatifs, l'audit des headers Markdown et la spécification du message manuel de reprise. La release `0.0.4` définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils `500 + 510` et les cinq templates existants. La release `0.0.5` réconcilie PGR avec les baselines réelles de `khadhroony-solana-project` et `sasedev-games` : prompts versionnés, contrats documentaires locaux, lifecycle inter-release, profil Rust strict et audits monotâches, premier profil Tauri 2 et décision explicite de différer son skeleton complet jusqu'à matérialisation d'owners Web suffisants. La release `0.1.0` stabilise la première baseline réutilisable : adoption `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, skeletons/templates Rust/Cargo exercés par dry-run, clôture `rel.N`, handoff opérateur automatique et trajectoire `0.1.1` à `0.1.7` issue d'une revue d'horizon explicite. La release `0.1.1` stabilise la fondation frontend Web : owners indépendants TypeScript/package/Vite/CSS-Sass, déclarations de types externes conditionnelles, package manager neutre, validation frontend indépendante du host et skeleton Web composable, tout en conservant le skeleton Tauri en `DEFER` jusqu’à son réexamen `0.1.4`. La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` établit la gouvernance normative et documentaire de PGR lui-même. La release `0.0.2` ajoute les premiers profils réutilisables Rust/Cargo, Java/Maven/Gradle et Android, ainsi que deux audits Markdown. La release `0.0.3` fournit les premiers modèles Rust/Cargo, deux audits de style Rust facultatifs, l'audit des headers Markdown et la spécification du message manuel de reprise. La release `0.0.4` définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils `500 + 510` et les cinq templates existants. La release `0.0.5` réconcilie PGR avec les baselines réelles de `khadhroony-solana-project` et `sasedev-games` : prompts versionnés, contrats documentaires locaux, lifecycle inter-release, profil Rust strict et audits monotâches, premier profil Tauri 2 et décision explicite de différer son skeleton complet jusqu'à matérialisation d'owners Web suffisants. La release `0.1.0` stabilise la première baseline réutilisable : adoption `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, skeletons/templates Rust/Cargo exercés par dry-run, clôture `rel.N`, handoff opérateur automatique et trajectoire `0.1.1` à `0.1.7` issue d'une revue d'horizon explicite. La release `0.1.1` stabilise la fondation frontend Web : owners indépendants TypeScript/package/Vite/CSS-Sass, déclarations de types externes conditionnelles, package manager neutre, validation frontend indépendante du host et skeleton Web composable, tout en conservant le skeleton Tauri en `DEFER` jusqu’à son réexamen `0.1.4`. La release `0.1.2` stabilise trois owners indépendants `520-JAVA`, `521-MAVEN` et `522-GRADLE`, clarifie JDK/source/bytecode et l'ownership Gradle, conserve Maven cohérent sans corpus artificiel et maintient les responsabilités Android dans `610-ANDROID.md` pour leur réévaluation distincte en `0.1.3`.
## Entrées principales ## Entrées principales
@@ -31,6 +31,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
- [`docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md`](docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md) — plan historique de réconciliation `0.0.5` ; - [`docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md`](docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md) — plan historique de réconciliation `0.0.5` ;
- [`docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md`](docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md) — plan historique de la première baseline réutilisable `0.1.0` ; - [`docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md`](docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md) — plan historique de la première baseline réutilisable `0.1.0` ;
- [`docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md`](docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md) — plan historique de la fondation frontend Web stable `0.1.1` ; - [`docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md`](docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md) — plan historique de la fondation frontend Web stable `0.1.1` ;
- [`docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md`](docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.2` : réévaluation Games, scission Java/Maven/Gradle et maintien d'Android hors scope ;
- [`docs/studies/001-KSP_GAMES_RECONCILIATION.md`](docs/studies/001-KSP_GAMES_RECONCILIATION.md) — étude de réconciliation et classification des écarts entre PGR, KSP et Games ; - [`docs/studies/001-KSP_GAMES_RECONCILIATION.md`](docs/studies/001-KSP_GAMES_RECONCILIATION.md) — étude de réconciliation et classification des écarts entre PGR, KSP et Games ;
- [`docs/skeletons/000-README.md`](docs/skeletons/000-README.md) — index des skeleton specifications et de leur contrat de composition ; - [`docs/skeletons/000-README.md`](docs/skeletons/000-README.md) — index des skeleton specifications et de leur contrat de composition ;
- [`docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation composable de gouvernance locale pour un projet adoptant PGR ; - [`docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation composable de gouvernance locale pour un projet adoptant PGR ;

View File

@@ -1,5 +1,5 @@
<!-- file: ROADMAP.md --> <!-- file: ROADMAP.md -->
<!-- version: 12 --> <!-- version: 14 -->
# Roadmap Project Governance Rules # 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 : 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 ; - `(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 ; - `(x) 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.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.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` ; - `( ) 0.1.5` — adoption réelle de PGR par `sasedev-games` avec mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;

View File

@@ -1,5 +1,5 @@
<!-- file: RULES.md --> <!-- file: RULES.md -->
<!-- version: 13 --> <!-- version: 14 -->
# Index normatif Project Governance Rules # 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/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/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/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/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/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. - [`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.

View File

@@ -1 +1 @@
0.1.1 0.1.2

235
deltas/0.1.2/alpha.1.md Normal file
View File

@@ -0,0 +1,235 @@
<!-- file: deltas/0.1.2/alpha.1.md -->
<!-- version: 1 -->
# Delta 0.1.2-alpha.1 — audit de stable et cadrage Java / Gradle
## Baseline et sources
Baseline PGR autoritaire : archive source téléchargée depuis le tag Gitea `v0.1.1`, accompagnée du rapport externe `pgr-0.1.1-publish.001-report.md` avec statut `PASS`.
SHA-256 vérifiés sur les fichiers réellement fournis :
```text
pgr-v0.1.1(1).zip caaf8f456f7f8520172ea7705fd0cf5c5bf0e942dc4a773410bcbe7fe4ce243a
pgr-0.1.1-publish.001-report(1).md 3eafc2767225526a6cba65b3b62a45a664b71a1f2fa049915ec243a196e14bb3
games-v0.3.6(1).zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
```
Les archives locales PGR et Games comportent `(1)` dans leur nom, mais leurs empreintes correspondent exactement aux baselines canoniques `pgr-v0.1.1.zip` et `games-v0.3.6.zip` attendues par le rapport/prompt.
Version avant application :
```text
0.1.1
```
Version après application :
```text
0.1.2-alpha.1
```
## Objet
Exécuter `prompts/008-V0_1_2_START_PROMPT.md` : vérifier intégralement la stable `v0.1.1` et son rapport post-tag, auditer le corpus Games autoritaire sur Java/Gradle et ses preuves historiques, relire `520-JAVA_MAVEN_GRADLE.md`, `610-ANDROID.md` et la revue d'horizon, puis créer le plan `0.1.2` avant toute normalisation importante.
`alpha.1` reste un gate de cadrage. Aucune règle Java/Gradle, règle Android, validation spécialisée, template, skeleton ou audit nouveau n'est encore créé ou modifié.
## Résultat de l'audit d'intake
La stable PGR et son rapport post-tag concordent : SHA-256 attendu, CRC propre, racine unique `pgr/`, `256` fichiers, `36` répertoires en comptant la racine, aucun symlink, absence normale de `.git` et `VERSION=0.1.1`.
Les quatre modules de tests Python ont été rejoués par groupes et donnent `48/48 PASS`. Les audits Markdown sont propres : `231` fichiers pour les headers, `9` tables sur `231` fichiers et `267` liens locaux sur `231` fichiers. Les cinq templates TOML Rust/Cargo sont parsables.
Les `83` couples delta/history de `0.0.1` à `0.1.1` sont complets. La vérité `0.1.1` conserve `alpha.2 FAIL`, `alpha.2.fix.1 PASS`, `alpha.3.fix.1 FAIL`, `alpha.3.fix.2 PASS`, puis `rel.1 PASS`.
Le corpus Games fourni possède exactement le SHA canonique attendu, `502` fichiers et aucun symlink. Ses audits statiques principaux sont propres. Il exerce quatre sources Java canoniques sous `src/main/java/` et un projet Gradle multi-module en Groovy DSL avec ownership identifiable entre `settings.gradle`, root build, `gradle.properties`, modules et scripts Gradle communs.
Les histories Games montrent successivement une preuve avec Wrapper Gradle `9.6.0` + JDK 17, puis la décision durable et validée d'utiliser Gradle système `>= 9.6.0` avec le JDK courant. Les gates suivantes ont utilisé Temurin `25.0.4.1 LTS` et Gradle `9.7.1`, tandis que la glue Java restait explicitement source/target `17`. Cette trajectoire confirme la séparation build JDK / niveau Java et le caractère conditionnel du Wrapper sans généraliser les versions exactes.
Games n'exerce ni Maven, ni version catalog, ni tests Java génériques suffisants pour créer de nouveaux artefacts correspondants. Aucun `pom.xml`, Maven Wrapper, Gradle Wrapper ou `libs.versions.toml` n'est présent dans la stable `0.3.6`.
Les contraintes AGP, SDK/NDK, ABI/JNI, SDL3, manifests, APK/AAB, signing, AVD/devices et smokes restent explicitement hors scope : elles appartiennent à Android ou au produit Games et sont réservées à `0.1.3` pour la réévaluation PGR Android.
Le plan classe les choix observés avec `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` et retient une révision ciblée de `520` plutôt qu'une copie de Games ou une multiplication d'artefacts.
## Scope
REPLACE :
```text
VERSION
README.md
docs/000-README.md
```
ADD :
```text
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
deltas/0.1.2/alpha.1.md
```
DELETE : aucun.
`RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, `docs/rules/520-JAVA_MAVEN_GRADLE.md`, `docs/rules/610-ANDROID.md`, les autres règles, templates, skeletons, validations, scripts, studies, prompts et histories existants restent inchangés dans `alpha.1`.
Aucun `history/0.1.2/alpha.1.md` n'est anticipé avant la gate opérateur.
## Validation opérateur
Après application sur la stable `0.1.1`, depuis la racine du dépôt :
```bash
test "$(cat VERSION)" = '0.1.2-alpha.1'
test -f docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
test -f deltas/0.1.2/alpha.1.md
test ! -e history/0.1.2/alpha.1.md
grep -Fx '<!-- version: 20 -->' README.md
grep -Fx '<!-- version: 32 -->' docs/000-README.md
grep -F '008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md' README.md docs/000-README.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 - <<'PY'
from pathlib import Path
import re
expected = {
'0.0.1': 12,
'0.0.2': 12,
'0.0.3': 10,
'0.0.4': 9,
'0.0.5': 19,
'0.1.0': 10,
'0.1.1': 11,
}
for release, count in expected.items():
deltas = {path.name for path in Path('deltas', release).glob('*.md')}
histories = {path.name for path in Path('history', release).glob('*.md')}
assert len(deltas) == count, (release, len(deltas))
assert deltas == histories, (release, sorted(deltas ^ histories))
statuses = {}
for path in Path('history/0.1.1').glob('*.md'):
text = path.read_text(encoding='utf-8')
match = re.search(r'## Statut\s+(PASS|FAIL|PARTIAL|BLOCKED)\s', text)
assert match is not None, path
statuses[path.name] = match.group(1)
assert statuses['alpha.2.md'] == 'FAIL'
assert statuses['alpha.2.fix.1.md'] == 'PASS'
assert statuses['alpha.3.fix.1.md'] == 'FAIL'
assert statuses['alpha.3.fix.2.md'] == 'PASS'
assert statuses['rel.1.md'] == 'PASS'
roadmap = Path('ROADMAP.md').read_text(encoding='utf-8')
assert '- `(x) 0.1.1`' in roadmap
for release in range(2, 8):
assert f'- `( ) 0.1.{release}`' in roadmap, release
assert '0.1.8' not in roadmap
assert 'skeleton Tauri jusqu\'au réexamen 0.1.4' in roadmap
prompt = Path('prompts/008-V0_1_2_START_PROMPT.md').read_text(encoding='utf-8')
for phrase in (
'Version cible : `0.1.2`',
'Première tranche attendue : `0.1.2-alpha.1`',
'ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8',
'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER',
'Gradle système versus Wrapper',
'Le profil `520` possède également Maven.',
'`0.1.2` MUST NOT absorber les responsabilités',
):
assert phrase in prompt, phrase
profile = Path('docs/rules/520-JAVA_MAVEN_GRADLE.md').read_text(encoding='utf-8')
for phrase in (
'JDK utilisé pour construire',
'PGR MUST NOT ajouter un Maven Wrapper uniquement par cérémonie.',
'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',
):
assert phrase in profile, phrase
android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
for phrase in (
'Matrice AGP / Gradle / JDK',
'`compileSdk`, `targetSdk` et `minSdk`',
'ABI et code natif',
'Signing et secrets',
):
assert phrase in android, phrase
plan = Path('docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
for phrase in (
'Classification initiale des décisions Games',
'`ADOPT`',
'`KEEP-LOCAL`',
'`OVERRIDE`',
'`DEFER`',
'alpha.2 — révision ciblée Java / Gradle',
'beta.1 — réconciliation et décision d\'artefacts',
'AGP 9.4.0',
'Aucun skeleton Java/Gradle ni artefact Maven nouveau n\'est prévu par défaut.',
'0.1.3 — réévaluation pratique du profil Android à partir de Games',
):
assert phrase in plan, phrase
assert Path('docs/rules/520-JAVA_MAVEN_GRADLE.md').read_text(encoding='utf-8').startswith(
'<!-- file: docs/rules/520-JAVA_MAVEN_GRADLE.md -->\n<!-- version: 2 -->'
)
assert Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8').startswith(
'<!-- file: docs/rules/610-ANDROID.md -->\n<!-- version: 2 -->'
)
print('0.1.2 alpha.1 structural audit: clean (83 prior pairs, Games classified, Android 0.1.3 boundary preserved)')
PY
git diff --check
git add VERSION README.md docs/000-README.md \
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md \
deltas/0.1.2/alpha.1.md
git diff --cached --check
git status --short
```
Le scope indexé attendu avant ajout du history est :
```text
M README.md
M VERSION
A deltas/0.1.2/alpha.1.md
M docs/000-README.md
A docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
```
La revue opérateur doit également confirmer que :
- `alpha.1` n'a pas modifié `520-JAVA_MAVEN_GRADLE.md` avant validation du cadrage ;
- `610-ANDROID.md` reste intact et aucune responsabilité Android n'a été absorbée dans le plan Java/Gradle ;
- les versions exactes Games (`Gradle 9.6/9.7.1`, JDK 25, Java 17, AGP 9.4.0) restent des preuves ou choix locaux, pas des contraintes PGR universelles ;
- l'absence de Wrapper dans Games est classée comme choix local compatible avec une politique PGR conditionnelle, pas comme interdiction globale du Wrapper ;
- aucun nouveau template/audit/skeleton Maven ou Gradle n'est créé sans preuve supplémentaire ;
- Games reste un corpus externe non modifié et son adoption reste réservée à `0.1.5` ;
- le skeleton Tauri reste `DEFER` jusqu'à `0.1.4` ;
- aucun nouveau numéro au-delà de `0.1.7` n'est réservé.
## Transition
### PASS
Produire `history/0.1.2/alpha.1.md` à partir des résultats réellement observés. Dans la même réponse, si aucune décision nouvelle n'est ouverte, préparer séparément le delta `0.1.2-alpha.2` consacré à la révision normative ciblée de `520-JAVA_MAVEN_GRADLE.md`, sans modification de `610-ANDROID.md` et sans nouvel artefact Maven.
Après remise du history, fournir automatiquement le bloc Git exact de fermeture conformément à `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`, puis indiquer l'application du delta suivant seulement après succès du commit/push.
### FAIL
Consigner le résultat réel dans le history, puis ouvrir `0.1.2-alpha.1.fix.1` ou un REPLAN selon la cause. Un fix de `alpha.1` doit rester limité au cadrage et ne doit pas absorber la révision normative prévue pour `alpha.2`.

View File

@@ -0,0 +1,213 @@
<!-- file: deltas/0.1.2/alpha.2.fix.1.md -->
<!-- version: 1 -->
# Delta 0.1.2-alpha.2.fix.1 — récupération de contamination inter-projet
## Baseline et diagnostic
Baseline Git observée et déjà publiée sur `origin/master` :
```text
17b7ef23a18c913f986c7d57caf958d33479363d
```
Le commit précédent observé est :
```text
6e978bfed8c1ad10d1888cd3da92aeaf70338b7e
```
La gate opérateur de `0.1.2-alpha.2` avait été exécutée avec succès avant cette chaîne de commits : tests Python, audits Markdown, gate Java/Gradle et contrôles de scope étaient `PASS`. `history/0.1.2/alpha.2.md` conserve donc ce résultat réel.
La publication de la tranche a ensuite été contaminée par des fichiers provenant d'un autre projet. Les preuves Git montrent notamment :
- `6e978bf` porte les vraies modifications PGR de `alpha.2`, mais ajoute aussi `history/0.0.1/alpha.3.fix.1.md` et utilise un message de commit étranger ;
- `17b7ef2` ajoute `Cargo.toml`, `crates/knowledge-domain-lib/src/content_family.rs` et `deltas/0.0.1/alpha.3.fix.2.md` ;
- `17b7ef2` remplace `docs/plans/001-V0_0_1_FOUNDATION_PLAN.md` et `docs/validation/001-VALIDATION_MATRIX.md` par du contenu Knowledge ;
- `git diff --check 17b7ef2^ 17b7ef2` signale en plus une ligne vide finale parasite dans la matrice de validation ;
- les commits étant déjà poussés, le présent fix restaure l'état PGR par un nouveau commit et ne réécrit pas l'historique distant.
Version avant correction au niveau Git publié : état contaminé après `0.1.2-alpha.2`.
Version après application :
```text
0.1.2-alpha.2.fix.1
```
## Objet
Ramener la branche publiée à l'état PGR attendu après `alpha.2`, tout en préservant les vraies modifications Java/Maven/Gradle et leur history `PASS`.
Ce fix est exclusivement un correctif de provenance et d'hygiène Git. Il ne change aucune décision normative de `alpha.2` et n'absorbe ni le REPLAN Java/Maven/Gradle préparé pour la tranche suivante ni le scope Android réservé à `0.1.3`.
## Scope
REPLACE :
```text
VERSION
docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
docs/validation/001-VALIDATION_MATRIX.md
```
ADD :
```text
deltas/0.1.2/alpha.2.fix.1.md
manifests/0.1.2/alpha.2.fix.1.delete.txt
```
DELETE :
```text
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
```
Le manifest de suppression doit contenir exactement ces quatre chemins.
Les fichiers suivants de `alpha.2` MUST rester inchangés par le fix :
```text
deltas/0.1.2/alpha.2.md
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
docs/rules/520-JAVA_MAVEN_GRADLE.md
history/0.1.2/alpha.2.md
```
`docs/rules/610-ANDROID.md` reste également inchangé.
## Restauration autoritaire
`docs/plans/001-V0_0_1_FOUNDATION_PLAN.md` et `docs/validation/001-VALIDATION_MATRIX.md` n'étaient modifiés ni par `alpha.1` ni par `alpha.2`. Leur contenu attendu est donc exactement celui de la stable `v0.1.1`.
Le fix restaure ces deux fichiers depuis cette baseline au lieu de tenter de corriger manuellement le contenu Knowledge injecté.
## Application du manifest
Après extraction du delta, appliquer explicitement le manifest de suppression :
```bash
while IFS= read -r path; do
case "$path" in
''|'#'*) continue ;;
esac
rm -f -- "$path"
done < manifests/0.1.2/alpha.2.fix.1.delete.txt
```
Les éventuels répertoires devenus vides ne sont pas des chemins suivis par Git et n'affectent pas le contenu publié.
## Validation opérateur
Le stash `pgr-0.1.2-alpha.3-before-alpha.2-recovery` doit rester intact pendant toute cette gate. Ne pas exécuter `stash pop` avant fermeture du fix.
```bash
test "$(git rev-parse HEAD)" = '17b7ef23a18c913f986c7d57caf958d33479363d'
test "$(git rev-parse origin/master)" = '17b7ef23a18c913f986c7d57caf958d33479363d'
test "$(cat VERSION)" = '0.1.2-alpha.2.fix.1'
test -f history/0.1.2/alpha.2.md
grep -A2 '^## Statut$' history/0.1.2/alpha.2.md | grep -Fx 'PASS'
test -f deltas/0.1.2/alpha.2.fix.1.md
test ! -e history/0.1.2/alpha.2.fix.1.md
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
git diff --exit-code v0.1.1 -- \
docs/plans/001-V0_0_1_FOUNDATION_PLAN.md \
docs/validation/001-VALIDATION_MATRIX.md
grep -Fx '<!-- version: 2 -->' docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
grep -Fx '<!-- version: 3 -->' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -Fx '<!-- version: 2 -->' docs/rules/610-ANDROID.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
manifest = Path('manifests/0.1.2/alpha.2.fix.1.delete.txt')
paths = [line.strip() for line in manifest.read_text(encoding='utf-8').splitlines() if line.strip() and not line.lstrip().startswith('#')]
expected = [
'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 paths == expected, (paths, expected)
for path in expected:
assert not Path(path).exists(), path
history = Path('history/0.1.2/alpha.2.md').read_text(encoding='utf-8')
assert re.search(r'## Statut\s+PASS\s', history)
alpha2 = Path('deltas/0.1.2/alpha.2.md').read_text(encoding='utf-8')
assert '# Delta 0.1.2-alpha.2 — révision ciblée Java / Gradle' in alpha2
plan = Path('docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
assert plan.startswith('<!-- file: docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md -->\n<!-- version: 2 -->')
profile = Path('docs/rules/520-JAVA_MAVEN_GRADLE.md').read_text(encoding='utf-8')
assert profile.startswith('<!-- file: docs/rules/520-JAVA_MAVEN_GRADLE.md -->\n<!-- version: 3 -->')
android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
assert android.startswith('<!-- file: docs/rules/610-ANDROID.md -->\n<!-- version: 2 -->')
for forbidden in (
'knowledge-domain-lib',
'# Matrice de validation Knowledge',
'knowledge-pgr-server',
):
assert forbidden not in Path('docs/validation/001-VALIDATION_MATRIX.md').read_text(encoding='utf-8'), forbidden
print('0.1.2 alpha.2.fix.1 recovery audit: clean (foreign Knowledge paths removed, PGR baseline restored, alpha.2 preserved)')
PYGATE
git diff --check
git add -A
git diff --cached --check
git status --short
```
Le scope indexé attendu est :
```text
D Cargo.toml
M VERSION
D crates/knowledge-domain-lib/src/content_family.rs
D deltas/0.0.1/alpha.3.fix.2.md
A deltas/0.1.2/alpha.2.fix.1.md
M docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
M docs/validation/001-VALIDATION_MATRIX.md
D history/0.0.1/alpha.3.fix.1.md
A manifests/0.1.2/alpha.2.fix.1.delete.txt
```
L'ordre exact peut varier ; l'ensemble des chemins doit être identique.
## Transition
### PASS
Produire `history/0.1.2/alpha.2.fix.1.md`, commit/push sous l'identité `0.1.2-alpha.2.fix.1`, puis abandonner le stash préparé à partir de l'ancien HEAD contaminé et réémettre la tranche `alpha.3` sur la baseline corrigée.
La tranche `alpha.3` devra être régénérée ; le stash actuel sert uniquement de sauvegarde de sécurité et ne doit pas devenir la source autoritaire du nouveau delta.
### FAIL
Conserver les résultats réels dans `history/0.1.2/alpha.2.fix.1.md` et poursuivre sous `alpha.2.fix.N`. Ne pas restaurer `alpha.3` tant que l'état PGR publié n'est pas propre.

259
deltas/0.1.2/alpha.2.md Normal file
View File

@@ -0,0 +1,259 @@
<!-- file: deltas/0.1.2/alpha.2.md -->
<!-- version: 1 -->
# Delta 0.1.2-alpha.2 — révision ciblée Java / Gradle
## Baseline et version
Baseline attendue : commit opérateur de `0.1.2-alpha.1`, réalisé après application de `history/0.1.2/alpha.1.md` avec statut `PASS`.
Le hash de ce commit n'est pas anticipé.
Version avant application :
```text
0.1.2-alpha.1
```
Version après application :
```text
0.1.2-alpha.2
```
## Objet
Appliquer la révision normative ciblée décidée après l'audit Games de `alpha.1` sans transformer les choix locaux du corpus en prescriptions générales.
La tranche précise uniquement :
- la distinction entre JDK de build, niveau source et bytecode/runtime supporté ;
- la possibilité pour un JDK plus récent de cibler explicitement un niveau Java plus ancien ;
- l'ownership naturel de `settings.gradle(.kts)`, du build root, des builds de modules et de `gradle.properties` partagé ;
- la nécessité qu'une politique « Gradle système » possède une contrainte effectivement vérifiée ;
- la séparation entre configuration Gradle partagée portable et état local/machine/secrets ;
- la frontière entre règles Java/Gradle générales et overrides Android.
Les sections Maven sont relues et conservées sans nouvel artefact : Games `0.3.6` ne contient aucun projet Maven permettant de justifier une normalisation supplémentaire.
## Scope
REPLACE :
```text
VERSION
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
docs/rules/520-JAVA_MAVEN_GRADLE.md
```
ADD :
```text
deltas/0.1.2/alpha.2.md
```
DELETE : aucun.
`docs/rules/610-ANDROID.md`, `RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, les autres profils, templates, skeletons, validations, scripts et tests restent inchangés.
Aucun `history/0.1.2/alpha.2.md` n'est anticipé.
## Décisions Java
Le contrat existant est conservé et rendu plus explicite :
```text
JDK de build
!= niveau Java du code source
!= niveau de bytecode/runtime minimal supporté
```
Un JDK de build plus récent peut être utilisé avec une cible Java plus ancienne lorsque cette cible est déclarée explicitement par le build et réellement supportée par la toolchain.
PGR ne rend obligatoire ni `--release`, ni une toolchain Java, ni `sourceCompatibility`/`targetCompatibility` pour tous les builds. Le mécanisme concret dépend de Maven, Gradle, du plugin et du projet ; le contrat important est que la compatibilité ne soit pas une conséquence implicite du JDK actif.
Les versions Games observées restent locales : ni JDK 25 LTS ni Java 17 ne deviennent un minimum PGR.
## Décisions Gradle
### Ownership
La responsabilité est explicitée sans imposer le layout Games :
```text
settings.gradle(.kts)
composition du build
politiques globales de résolution lorsqu'elles existent
contraintes de bootstrap/version devant agir avant les projets
build root
plugins, versions et conventions réellement partagés
build de module
plugins, dépendances, sources, tâches et paramètres locaux au module
gradle.properties partagé
propriétés portables, non secrètes et réellement communes
```
Une logique transverse devenue importante peut être extraite dans un script, build logic ou plugin possédé plutôt que dupliquée. Aucun de ces mécanismes n'est rendu obligatoire.
### Gradle système et Wrapper
Le Wrapper reste conditionnel : il est recommandé lorsqu'il apporte une reproductibilité utile, mais son absence dans Games reste `KEEP-LOCAL` et n'est pas généralisée.
Lorsqu'un projet choisit un Gradle système, sa contrainte de compatibilité doit être effectivement vérifiée par le build ou par une gate exécutée par le projet/CI. Une version écrite uniquement dans la documentation ne suffit pas.
PGR ne reprend ni le minimum `9.6.0` ni l'API `GradleVersion.current()` de Games comme règle universelle. Ils constituent une implémentation valide d'une politique locale, pas la forme obligatoire de la vérification.
### Propriétés et état local
Un `gradle.properties` partagé doit rester portable et non secret. Les chemins machine, credentials, secrets et overrides développeur utilisent un mécanisme local approprié et restent hors Git.
Le version catalog reste optionnel. Groovy DSL et Kotlin DSL restent tous deux reconnus ; le choix Groovy de Games reste `KEEP-LOCAL`.
## Maven
Aucun `pom.xml`, Maven Wrapper ou projet Maven n'existe dans le corpus Games autoritaire. Les sections Maven de `520` ont donc uniquement été relues pour vérifier qu'elles restent cohérentes avec la philosophie générale : centraliser ce qui est réellement commun, ne pas imposer un Wrapper par cérémonie, préférer les gates ciblées et ne pas automatiser `clean` sans besoin.
Aucun template, skeleton, audit ou autre artefact Maven n'est ajouté.
## Frontière Android
`610-ANDROID.md` n'est pas modifié.
Les éléments suivants restent hors scope de `0.1.2` :
```text
AGP et sa matrice de compatibilité
compileSdk / targetSdk / minSdk
NDK et ABI
JNI / AAR / Prefab
applicationId / namespace
manifests / resources
APK / AAB / signing
Variant API Android
devices / AVD / smokes Android
contraintes 16 KB
SDL3 et architecture Games
```
`520` documente seulement qu'une plateforme ou un framework peut imposer un override plus étroit sans transformer cet override en minimum Java/Gradle général.
## Validation opérateur
Après application du history `PASS`, commit/push de `alpha.1`, puis application du présent delta :
```bash
test "$(cat VERSION)" = '0.1.2-alpha.2'
git cat-file -e HEAD:history/0.1.2/alpha.1.md
test -f history/0.1.2/alpha.1.md
test -f deltas/0.1.2/alpha.2.md
test ! -e history/0.1.2/alpha.2.md
grep -A2 '^## Statut$' history/0.1.2/alpha.1.md | grep -Fx 'PASS'
grep -Fx '<!-- version: 2 -->' docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
grep -Fx '<!-- version: 3 -->' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -Fx '<!-- version: 2 -->' docs/rules/610-ANDROID.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.1.md').read_text(encoding='utf-8')
assert re.search(r'## Statut\s+PASS\s', history)
profile = Path('docs/rules/520-JAVA_MAVEN_GRADLE.md').read_text(encoding='utf-8')
for phrase in (
'Un JDK de build plus récent MAY compiler un projet qui cible un niveau source ou bytecode plus ancien',
'Le simple fait qu\'une compilation réussisse avec le JDK actif ne constitue pas une déclaration de compatibilité.',
'composition du build et inclusion des projets',
'plugins, dépendances, sources, tâches et paramètres propres au module',
'propriétés portables, non secrètes et réellement communes au build',
'effectivement vérifiée',
'Une version seulement écrite dans la documentation sans contrôle exécutable n\'est pas une preuve suffisante',
'Son absence dans un corpus particulier ne constitue pas une règle générale.',
):
assert phrase in profile, phrase
for phrase in (
'AGP',
'`minSdk`',
'`targetSdk`',
'NDK',
'ABI/JNI',
'packaging APK/AAB',
'device/AVD',
):
assert phrase in profile, phrase
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.1`',
'La gate opérateur de `alpha.1` est `PASS`',
'`KEEP-LOCAL` : Groovy DSL, absence de Wrapper dans Games, JDK 25 LTS et cible Java 17',
'`OVERRIDE` : matrice AGP/Gradle/JDK et autres contraintes de plateforme Android',
'`DEFER` : version catalog, skeleton Java/Gradle, audit Python Java/Gradle et nouveaux artefacts Maven',
'`alpha.2` est donc bornée à la révision du profil `520`',
):
assert phrase in plan, phrase
android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
assert android.startswith('<!-- file: docs/rules/610-ANDROID.md -->\n<!-- version: 2 -->')
for path in (
'docs/templates',
'docs/skeletons',
'scripts',
):
assert Path(path).is_dir(), path
print('0.1.2 alpha.2 Java/Gradle audit: clean (JDK/source/bytecode explicit, Gradle ownership and system-version verification clarified, Android boundary preserved)')
PYGATE
git diff --check
git add VERSION \
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md \
docs/rules/520-JAVA_MAVEN_GRADLE.md \
deltas/0.1.2/alpha.2.md
git diff --cached --check
git status --short
```
Le scope indexé attendu avant ajout du history est :
```text
M VERSION
A deltas/0.1.2/alpha.2.md
M docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
M docs/rules/520-JAVA_MAVEN_GRADLE.md
```
La revue qualitative doit confirmer que :
- aucune version JDK ou Java observée dans Games n'est devenue un minimum général ;
- un Gradle système reste permis seulement avec une contrainte réellement vérifiée ;
- le Wrapper reste conditionnel et le Groovy DSL n'est pas privilégié normativement ;
- `gradle.properties` partagé ne devient pas un emplacement pour secrets ou chemins machine ;
- les sections Maven n'ont pas acquis de règle provenant d'un corpus qui n'exerce pas Maven ;
- aucune responsabilité Android n'a été déplacée hors de `610` ou démarrée prématurément dans `0.1.2` ;
- aucun template, skeleton ou audit supplémentaire n'a été créé pour matérialiser artificiellement la release.
## Transition
### PASS
Produire `history/0.1.2/alpha.2.md`, puis préparer `0.1.2-beta.1` pour la réconciliation finale du profil contre Games, `500-LANGUAGES.md`, `610-ANDROID.md` et les règles générales de validation, ainsi que la décision explicite sur l'absence ou la nécessité d'artefacts supplémentaires.
### FAIL
Consigner le diagnostic réel dans `history/0.1.2/alpha.2.md` et rester dans `alpha.2.fix.N` sauf REPLAN justifié. Le fix MUST rester borné à la révision Java/Gradle et ne doit pas absorber `beta.1` ou le scope Android `0.1.3`.

365
deltas/0.1.2/alpha.3.md Normal file
View File

@@ -0,0 +1,365 @@
<!-- file: deltas/0.1.2/alpha.3.md -->
<!-- version: 1 -->
# 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 '<!-- version: 4 -->' 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 '<!-- version: 4 -->' docs/rules/520-JAVA.md
grep -Fx '<!-- version: 1 -->' docs/rules/521-MAVEN.md
grep -Fx '<!-- version: 1 -->' docs/rules/522-GRADLE.md
grep -Fx '<!-- version: 3 -->' docs/rules/610-ANDROID.md
grep -Fx '<!-- version: 7 -->' docs/architecture/003-RULE_PROFILE_MODEL.md
grep -Fx '<!-- version: 3 -->' docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
grep -Fx '<!-- version: 14 -->' RULES.md
grep -Fx '<!-- version: 16 -->' docs/rules/000-README.md
grep -Fx '<!-- version: 33 -->' docs/000-README.md
grep -Fx '<!-- version: 13 -->' 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 <module> -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`.

275
deltas/0.1.2/beta.1.md Normal file
View File

@@ -0,0 +1,275 @@
<!-- file: deltas/0.1.2/beta.1.md -->
<!-- version: 1 -->
# Delta 0.1.2-beta.1 — réconciliation intégrée et décision finale d'artefacts
## Baseline et version
Baseline attendue : commit opérateur de `0.1.2-alpha.3`, réalisé après application de `history/0.1.2/alpha.3.md` avec statut `PASS`.
Version avant application :
```text
0.1.2-alpha.3
```
Version après application :
```text
0.1.2-beta.1
```
## Objet
Cette tranche exécute la réconciliation prévue après la scission des owners Java, Maven et Gradle. Elle ne crée aucune nouvelle règle fonctionnelle et ne modifie aucun des profils `520-JAVA.md`, `521-MAVEN.md`, `522-GRADLE.md` ou `610-ANDROID.md`.
La beta confirme que la séparation `520/521/522` résout l'ambiguïté d'applicabilité sans importer les choix locaux Games ni ouvrir le scope Android.
## Scope
REPLACE :
```text
VERSION
README.md
docs/000-README.md
docs/architecture/003-RULE_PROFILE_MODEL.md
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
```
ADD :
```text
deltas/0.1.2/beta.1.md
```
DELETE : aucun.
Aucun `history/0.1.2/beta.1.md` n'est anticipé.
## Réconciliation des owners
La revue confirme les contrats suivants :
```text
520-JAVA.md Java uniquement
521-MAVEN.md Maven uniquement lorsqu'il est réellement utilisé
522-GRADLE.md Gradle uniquement lorsqu'il est réellement utilisé
```
La composition reste explicite. Un projet Java/Maven applique `520 + 521`; un projet Java/Gradle applique `520 + 522`; un projet Gradle sans Java n'applique pas `520` par simple transitivité.
L'ancien `520-JAVA_MAVEN_GRADLE.md` reste un bridge `SUPERSEDED` non normatif pour la compatibilité documentaire historique et ne redevient pas sélectionnable.
## Réconciliation contre Games
Games fournit une preuve réelle pour Java et Gradle, mais aucune preuve Maven. La beta confirme donc que :
- la séparation JDK de build / niveau source / bytecode-runtime est généralisable ;
- l'ownership `settings` / root / module / propriétés partagées est généralisable ;
- une politique Gradle système doit avoir une contrainte effectivement vérifiée ;
- le Wrapper reste un mécanisme conditionnel de reproductibilité ;
- Groovy DSL et absence de Wrapper restent des choix locaux Games ;
- JDK 25, Java 17, Gradle 9.6.0+ et Gradle 9.7.1 ne deviennent aucun minimum PGR ;
- aucun contenu Maven nouveau n'est déduit d'un corpus qui n'utilise pas Maven.
## Frontière Android
La beta ne modifie pas `610-ANDROID.md`.
Restent explicitement hors du scope `0.1.2` :
```text
AGP
compileSdk / targetSdk / minSdk
SDK / NDK
ABI / JNI
manifests / resources
APK / AAB / signing
Variant API
AVD / devices / smokes Android
contraintes 16 KB
SDL3 et architecture produit Games
```
Ces responsabilités restent réservées à `0.1.3` ou à un owner plus spécifique.
## Décision finale d'artefacts
Aucun artefact technique supplémentaire n'est justifié pour `0.1.2`.
Ne sont donc pas ajoutés :
```text
nouveau contrat docs/validation/
template Java/Maven/Gradle générique
skeleton Java/Gradle générique
audit Python Java/Maven/Gradle
artefact Maven déduit de Games
```
La raison est positive et vérifiable : les trois owners couvrent déjà les responsabilités génériques démontrées, tandis que Java, Maven et Gradle eux-mêmes possèdent les preuves exécutables de compilation/build/test. Ajouter un artefact uniquement pour remplir la release introduirait de la duplication ou une convention insuffisamment éprouvée.
## Documentation durable
La tranche actualise :
- le statut racine de la release ;
- l'index documentaire `0.1.2` ;
- le modèle architectural avec la décision beta durable ;
- le plan actif avec le `PASS` de `alpha.3` et la décision finale d'artefacts.
Aucun changement n'est requis dans `RULES.md`, `docs/rules/000-README.md` ou `ROADMAP.md`, déjà réconciliés pendant `alpha.3`.
## Validation opérateur
Après application du history `PASS` de `alpha.3`, commit/push de `alpha.3`, puis application du présent delta :
```bash
test "$(cat VERSION)" = '0.1.2-beta.1'
git cat-file -e HEAD:history/0.1.2/alpha.3.md
test -f history/0.1.2/alpha.3.md
test -f deltas/0.1.2/beta.1.md
test ! -e history/0.1.2/beta.1.md
grep -A2 '^## Statut$' history/0.1.2/alpha.3.md | grep -Fx 'PASS'
grep -Fx '<!-- version: 21 -->' README.md
grep -Fx '<!-- version: 34 -->' docs/000-README.md
grep -Fx '<!-- version: 8 -->' docs/architecture/003-RULE_PROFILE_MODEL.md
grep -Fx '<!-- version: 4 -->' docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
grep -Fx '<!-- version: 4 -->' docs/rules/520-JAVA.md
grep -Fx '<!-- version: 1 -->' docs/rules/521-MAVEN.md
grep -Fx '<!-- version: 1 -->' docs/rules/522-GRADLE.md
grep -Fx '<!-- version: 4 -->' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -Fx '<!-- version: 3 -->' docs/rules/610-ANDROID.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.3.md').read_text(encoding='utf-8')
assert re.search(r'## Statut\s+PASS\s', history)
java = Path('docs/rules/520-JAVA.md').read_text(encoding='utf-8')
maven = Path('docs/rules/521-MAVEN.md').read_text(encoding='utf-8')
gradle = Path('docs/rules/522-GRADLE.md').read_text(encoding='utf-8')
legacy = Path('docs/rules/520-JAVA_MAVEN_GRADLE.md').read_text(encoding='utf-8')
android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
architecture = Path('docs/architecture/003-RULE_PROFILE_MODEL.md').read_text(encoding='utf-8')
plan = Path('docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
assert '# Profil Java' in java
assert '# Profil Maven' in maven
assert '# Profil Gradle' in gradle
assert '`SUPERSEDED` depuis `0.1.2-alpha.3`.' in legacy
assert 'Il ne constitue plus un profil sélectionnable' in legacy
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
for local_choice in (
'JDK 25',
'source/target 17',
'Gradle 9.6.0',
'Gradle 9.7.1',
'AGP 9.4.0',
):
assert local_choice not in java, local_choice
assert local_choice not in maven, local_choice
assert local_choice not in gradle, local_choice
for android_term in (
'compileSdk',
'targetSdk',
'minSdk',
'NDK',
'ABI/JNI',
'APK/AAB',
'device/AVD',
'SDL3',
):
assert android_term not in maven, android_term
assert android_term not in gradle, android_term
assert 'Matrice AGP / Gradle / JDK' in android
assert '`compileSdk`, `targetSdk` et `minSdk`' in android
for phrase in (
'## Réconciliation beta de Java / Maven / Gradle en `0.1.2`',
'aucune preuve Maven réelle',
'Aucun nouveau contrat sous `docs/validation/`, template, skeleton ou audit Python Java/Maven/Gradle n\'est justifié.',
):
assert phrase in architecture, phrase
for phrase in (
'## Décision après `alpha.3` et réconciliation `beta.1`',
'La gate opérateur de `alpha.3` est `PASS`',
'aucun artefact technique supplémentaire',
'aucun corpus Maven',
'`0.1.3`',
):
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 beta.1 reconciliation audit: clean (owners stable, Games-local choices not generalized, no extra artifacts justified, Android boundary preserved)')
PYGATE
git diff --check
git add README.md VERSION \
docs/000-README.md \
docs/architecture/003-RULE_PROFILE_MODEL.md \
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md \
deltas/0.1.2/beta.1.md
git diff --cached --check
git status --short
```
Le scope indexé attendu avant ajout du history est exactement :
```text
M README.md
M VERSION
A deltas/0.1.2/beta.1.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
```
La revue qualitative doit confirmer que :
- aucun choix local Games n'est promu comme minimum générique ;
- Maven n'est pas présenté comme validé par Games ;
- les owners `520/521/522` restent indépendants et composables ;
- aucun nouveau fichier technique n'est ajouté pour satisfaire une structure théorique ;
- Android reste entièrement hors du scope fonctionnel de `0.1.2` ;
- la documentation durable reflète la scission et la décision d'artefacts sans réécrire les snapshots historiques.
## Transition
### PASS
Produire `history/0.1.2/beta.1.md`, puis préparer `0.1.2-rc.1` pour le gel de scope et la release gate complète.
### FAIL
Consigner le diagnostic réel dans `history/0.1.2/beta.1.md`, puis produire `beta.1.fix.N` ou effectuer un REPLAN uniquement si un défaut d'ownership ou de frontière ne peut pas être corrigé localement.

359
deltas/0.1.2/rc.1.md Normal file
View File

@@ -0,0 +1,359 @@
<!-- file: deltas/0.1.2/rc.1.md -->
<!-- version: 1 -->
# Delta 0.1.2-rc.1 — gel du scope et gate de release candidate
## Baseline et version
Baseline attendue : commit opérateur de `0.1.2-beta.1`, réalisé après application de `history/0.1.2/beta.1.md` avec statut `PASS`.
Le hash de ce commit n'est pas anticipé.
Version avant application :
```text
0.1.2-beta.1
```
Version après application :
```text
0.1.2-rc.1
```
## Objet et gel
La RC gèle le scope fonctionnel de `0.1.2` sur :
- `520-JAVA.md` comme owner du langage Java, de la compatibilité JDK/source/bytecode-runtime, de la structure, de l'API et des tests Java ;
- `521-MAVEN.md` comme spécialisation Maven uniquement lorsqu'un projet utilise réellement Maven ;
- `522-GRADLE.md` comme spécialisation Gradle uniquement lorsqu'un projet utilise réellement Gradle ;
- la distinction JDK de build / niveau Java source / niveau de bytecode-runtime sans généraliser les versions particulières de Games ;
- l'ownership Gradle `settings` / root / modules / propriétés partagées, avec séparation de l'état local ;
- le Wrapper comme mécanisme conditionnel de reproductibilité et Gradle système comme politique valide seulement lorsque sa contrainte est effectivement vérifiée ;
- l'ancien `520-JAVA_MAVEN_GRADLE.md` comme bridge `SUPERSEDED` non normatif afin de préserver les liens historiques ;
- la décision beta qu'aucun template, skeleton, audit Python, contrat de validation ou artefact Maven supplémentaire n'est justifié par le corpus disponible ;
- la frontière Android : AGP, SDK/NDK, ABI/JNI, manifests/resources, packaging/signing, devices/AVD, contraintes 16 KB et SDL3 restent hors des owners Java/Maven/Gradle et sont réévalués séparément en `0.1.3`.
Le changelog reçoit une entrée candidate `0.1.2` orientée utilisateurs. Le prompt `009-V0_1_3_START_PROMPT.md` est préparé pour la prochaine cible engagée Android à partir de Games.
Aucune nouvelle règle fonctionnelle n'entre dans cette RC. Les owners `520/521/522`, le bridge historique, `610-ANDROID.md`, les templates, skeletons, validations et scripts d'audit sont vérifiés mais non modifiés.
## Scope
REPLACE :
```text
VERSION
CHANGELOG.md
docs/000-README.md
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
```
ADD :
```text
deltas/0.1.2/rc.1.md
prompts/009-V0_1_3_START_PROMPT.md
```
DELETE : aucun.
Le history `beta.1` est livré séparément et MUST être appliqué/committé avant ce delta.
## Gate opérateur de release candidate
Après application du history `PASS` de `beta.1`, commit/push de `beta.1`, puis application du présent delta :
```bash
test "$(cat VERSION)" = '0.1.2-rc.1'
git cat-file -e HEAD:history/0.1.2/beta.1.md
test -f history/0.1.2/beta.1.md
test -f deltas/0.1.2/rc.1.md
test -f prompts/009-V0_1_3_START_PROMPT.md
test ! -e history/0.1.2/rc.1.md
grep -A2 '^## Statut$' history/0.1.2/beta.1.md | grep -Fx 'PASS'
grep -Fx '<!-- version: 14 -->' CHANGELOG.md
grep -Fx '## 0.1.2 (candidate)' CHANGELOG.md
grep -Fx '<!-- version: 35 -->' docs/000-README.md
grep -Fx '<!-- version: 5 -->' docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
grep -Fx '<!-- version: 13 -->' ROADMAP.md
grep -Fx '<!-- version: 1 -->' prompts/009-V0_1_3_START_PROMPT.md
grep -Fx '<!-- version: 4 -->' docs/rules/520-JAVA.md
grep -Fx '<!-- version: 1 -->' docs/rules/521-MAVEN.md
grep -Fx '<!-- version: 1 -->' docs/rules/522-GRADLE.md
grep -Fx '<!-- version: 4 -->' docs/rules/520-JAVA_MAVEN_GRADLE.md
grep -Fx '<!-- version: 3 -->' docs/rules/610-ANDROID.md
```
Contrôle d'intégration de la RC :
```bash
python3 -B - <<'PYGATE'
from pathlib import Path
import re
expected = {
"alpha.1.md": "PASS",
"alpha.2.md": "PASS",
"alpha.2.fix.1.md": "PASS",
"alpha.3.md": "PASS",
"beta.1.md": "PASS",
}
histories = {path.name for path in Path("history/0.1.2").glob("*.md")}
assert histories == set(expected), histories
for name, status in expected.items():
text = Path("history/0.1.2", name).read_text(encoding="utf-8")
assert re.search(rf"## Statut\s+{status}\s", text), (name, status)
deltas = {path.name for path in Path("deltas/0.1.2").glob("*.md")}
assert deltas == set(expected) | {"rc.1.md"}, deltas
changelog = Path("CHANGELOG.md").read_text(encoding="utf-8")
assert "## 0.1.2 (candidate)" in changelog
section = changelog.split("## 0.1.2 (candidate)", 1)[1].split("## 0.1.1", 1)[0]
for phrase in (
"trois owners indépendants",
"520-JAVA",
"521-MAVEN",
"522-GRADLE",
"JDK utilisé pour construire",
"Wrapper",
"Gradle système",
"SUPERSEDED",
"réévaluation pratique reste la cible distincte `0.1.3`",
):
assert phrase in section, phrase
for forbidden in (
"alpha.1",
"alpha.2",
"alpha.3",
"beta.1",
"rc.1",
):
assert forbidden not in section, forbidden
java = Path("docs/rules/520-JAVA.md").read_text(encoding="utf-8")
maven = Path("docs/rules/521-MAVEN.md").read_text(encoding="utf-8")
gradle = Path("docs/rules/522-GRADLE.md").read_text(encoding="utf-8")
legacy = Path("docs/rules/520-JAVA_MAVEN_GRADLE.md").read_text(encoding="utf-8")
android = Path("docs/rules/610-ANDROID.md").read_text(encoding="utf-8")
assert "# Profil Java" in java
assert "# Profil Maven" in maven
assert "# Profil Gradle" in gradle
assert "`SUPERSEDED` depuis `0.1.2-alpha.3`." in legacy
assert "Il ne constitue plus un profil sélectionnable" in legacy
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
for local_choice in (
"JDK 25",
"source/target 17",
"Gradle 9.6.0",
"Gradle 9.7.1",
"AGP 9.4.0",
):
assert local_choice not in java, local_choice
assert local_choice not in maven, local_choice
assert local_choice not in gradle, local_choice
for android_term in (
"compileSdk",
"targetSdk",
"minSdk",
"NDK",
"ABI/JNI",
"APK/AAB",
"device/AVD",
"SDL3",
):
assert android_term not in maven, android_term
assert android_term not in gradle, android_term
for phrase in (
"Matrice AGP / Gradle / JDK",
"`compileSdk`, `targetSdk` et `minSdk`",
"ABI et code natif",
"Signing et secrets",
):
assert phrase in android, phrase
roadmap = Path("ROADMAP.md").read_text(encoding="utf-8")
assert "- `( ) 0.1.2`" in roadmap
for version in ("0.1.3", "0.1.4", "0.1.5", "0.1.6", "0.1.7"):
assert f"- `( ) {version}`" in roadmap, version
assert "- `( ) 0.1.8`" not in roadmap
assert "skeleton Tauri jusqu'au réexamen 0.1.4" in roadmap
plan = Path("docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md").read_text(encoding="utf-8")
for phrase in (
"### beta.1 — réconciliation et décision d'artefacts",
"Statut opérateur : **PASS**.",
"### rc.1 — release candidate",
"Statut opérateur : **à valider**.",
"prompts/009-V0_1_3_START_PROMPT.md",
"Aucune nouvelle règle fonctionnelle n'entre en RC",
):
assert phrase in plan, phrase
prompt = Path("prompts/009-V0_1_3_START_PROMPT.md").read_text(encoding="utf-8")
for phrase in (
"archive source téléchargée depuis le tag Gitea `v0.1.2`",
"pgr-0.1.2-publish.001-report.md",
"0.1.3-alpha.1",
"ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8",
"610-ANDROID.md",
"520-JAVA.md",
"522-GRADLE.md",
"ADOPT / KEEP-LOCAL / OVERRIDE / DEFER",
"Android Gradle Plugin / Gradle / JDK",
"compileSdk",
"targetSdk",
"minSdk",
"NDK",
"ABI",
"JNI",
"signing",
"16 KB",
"réservé à `0.1.4`",
"adoption Games `0.1.5`",
):
assert phrase in prompt, phrase
for forbidden 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(forbidden).exists(), forbidden
java_related = sorted(
str(path)
for root in (Path("docs/templates"), Path("docs/skeletons"), Path("docs/validation"), Path("scripts"))
for path in root.rglob("*")
if path.is_file() and any(word in path.name.lower() for word in ("java", "maven", "gradle"))
)
assert java_related == [], java_related
print("0.1.2 rc.1 integration audit: clean (5 prior histories, frozen Java/Maven/Gradle owners, candidate changelog and prompt 009 verified, Android boundary preserved)")
PYGATE
```
Rejouer ensuite les preuves PGR :
```bash
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
```
Vérifier également l'hygiène texte et la parsabilité des templates de baseline sans prétendre simuler une toolchain Java/Maven/Gradle absente :
```bash
python3 -B - <<'PYHYGIENE'
from pathlib import Path
import json
import tomllib
for path in sorted(Path("templates/rust-cargo").rglob("*.toml")):
tomllib.loads(path.read_text(encoding="utf-8"))
json.loads(Path("templates/web-typescript/package.json").read_text(encoding="utf-8"))
json.loads(Path("templates/web-typescript/tsconfig.json").read_text(encoding="utf-8"))
roots = (
Path("VERSION"),
Path("README.md"),
Path("RULES.md"),
Path("ROADMAP.md"),
Path("CHANGELOG.md"),
Path("docs"),
Path("deltas"),
Path("history"),
Path("prompts"),
Path("templates"),
)
files = []
for root in roots:
if root.is_file():
files.append(root)
elif root.is_dir():
files.extend(path for path in root.rglob("*") if path.is_file())
for path in files:
try:
data = path.read_bytes()
text = data.decode("utf-8")
except UnicodeDecodeError:
continue
assert b"\r" not in data, path
assert text.endswith("\n"), path
for number, line in enumerate(text.splitlines(), 1):
assert line == line.rstrip(" \t"), (path, number)
print("0.1.2 rc.1 text/template hygiene: clean")
PYHYGIENE
git diff --check
git add VERSION CHANGELOG.md docs/000-README.md \
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md \
prompts/009-V0_1_3_START_PROMPT.md \
deltas/0.1.2/rc.1.md
git diff --cached --check
git status --short
```
Le scope indexé attendu avant ajout du history de `rc.1` est exactement :
```text
M CHANGELOG.md
M VERSION
A deltas/0.1.2/rc.1.md
M docs/000-README.md
M docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
A prompts/009-V0_1_3_START_PROMPT.md
```
## Revue opérateur complémentaire
Confirmer que :
- le scope normatif Java/Maven/Gradle est gelé ;
- aucun owner `520/521/522`, bridge historique, profil Android, template, skeleton, contrat de validation ou script d'audit n'est modifié par la RC ;
- le changelog candidat décrit les capacités utiles de `0.1.2` sans recopier les tranches internes ni l'incident de chaîne de commit ;
- aucun choix local Games n'est promu comme minimum Java/Maven/Gradle générique ;
- Maven n'est pas présenté comme éprouvé par Games ;
- l'absence d'artefacts Java/Maven/Gradle supplémentaires reste une décision positive fondée sur le corpus, pas un oubli ;
- Android reste hors du scope fonctionnel de `0.1.2` et le prompt `009` ne devient exécutable qu'après publication vérifiée de `v0.1.2` ;
- le prompt `009` ne transforme pas SDL3, les jeux ou Tauri Android en règles Android générales ;
- le skeleton Tauri reste réservé à `0.1.4` et l'adoption Games à `0.1.5` ;
- `0.1.8` n'est pas réservé ;
- aucune preuve `javac`, Maven, Gradle ou Android n'est revendiquée localement alors que PGR ne contient pas d'artefact exécutable correspondant dans cette RC.
## Transition
### PASS
Produire `history/0.1.2/rc.1.md`, l'appliquer puis committer/pousser `rc.1`. Continuer avec `0.1.2-rel.1` pour la promotion mécanique vers la stable, la clôture roadmap/plan/changelog et la gate pré-tag.
### FAIL
Consigner le diagnostic réel dans `history/0.1.2/rc.1.md`. Corriger uniquement la release candidate dans `rc.1.fix.N` tant qu'aucun défaut normatif plus large ne justifie un REPLAN. Ne pas préparer `rel.1` tant que la RC n'a pas obtenu `PASS`.

288
deltas/0.1.2/rel.1.md Normal file
View File

@@ -0,0 +1,288 @@
<!-- file: deltas/0.1.2/rel.1.md -->
<!-- version: 1 -->
# Delta 0.1.2 rel.1 — promotion stable pré-tag
## Baseline et version
Baseline : `0.1.2-rc.1`, avec `history/0.1.2/rc.1.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
Version avant application :
```text
0.1.2-rc.1
```
Version après application :
```text
0.1.2
```
`rel.1` identifie la clôture opérationnelle ; il ne fait pas partie de la version SemVer du produit.
## Objet
Promouvoir mécaniquement la RC validée vers la stable `0.1.2` sans rouvrir le scope fonctionnel.
La tranche finalise uniquement la présentation et les métadonnées de release : version stable, roadmap terminée, changelog sans marqueur `candidate`, README/index en état stable et plan `008` historique. Aucun owner Java/Maven/Gradle, bridge historique, profil Android, template, skeleton, validation ou script d'audit n'est modifié.
La validation de cette tranche est **pré-tag**. Le tag `v0.1.2`, son archive source Gitea et le rapport `pgr-0.1.2-publish.001-report.md` ne sont pas déclarés existants par ce delta. Ils suivent uniquement un history `rel.1` `PASS`, le commit stable `0.1.2` et la publication réelle du tag.
## Scope
REPLACE :
```text
VERSION
README.md
ROADMAP.md
CHANGELOG.md
docs/000-README.md
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
```
ADD :
```text
deltas/0.1.2/rel.1.md
```
DELETE : aucun.
Le history `rc.1` est livré séparément. Le history `rel.1` sera produit uniquement après la gate opérateur.
## Validation opérateur pré-tag
Après application sur le commit contenant `history/0.1.2/rc.1.md` :
```bash
test "$(cat VERSION)" = '0.1.2'
git cat-file -e HEAD:history/0.1.2/rc.1.md
test -f history/0.1.2/rc.1.md
test -f deltas/0.1.2/rel.1.md
test -f prompts/009-V0_1_3_START_PROMPT.md
test ! -e history/0.1.2/rel.1.md
grep -A2 '^## Statut$' history/0.1.2/rc.1.md | grep -Fx 'PASS'
grep -Fx '<!-- version: 22 -->' README.md
grep -Fx '<!-- version: 14 -->' ROADMAP.md
grep -Fx '<!-- version: 15 -->' CHANGELOG.md
grep -Fx '<!-- version: 36 -->' docs/000-README.md
grep -Fx '<!-- version: 6 -->' docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
grep -F -- '- `(x) 0.1.2`' ROADMAP.md
grep -Fx '## 0.1.2' CHANGELOG.md
grep -F 'avec `0.1.2` d’owners Java, Maven et Gradle séparés et composables' README.md
grep -F 'plan historique de la stable `0.1.2`' README.md docs/000-README.md
python3 -B - <<'PYGATE'
from pathlib import Path
import re
expected = {
"alpha.1.md": "PASS",
"alpha.2.md": "PASS",
"alpha.2.fix.1.md": "PASS",
"alpha.3.md": "PASS",
"beta.1.md": "PASS",
"rc.1.md": "PASS",
}
for name, status in expected.items():
delta = Path("deltas/0.1.2", name)
history = Path("history/0.1.2", name)
assert delta.is_file(), name
assert history.is_file(), name
text = history.read_text(encoding="utf-8")
assert re.search(rf"## Statut\s+{status}\s", text), (name, status)
pending = {path.name for path in Path("deltas/0.1.2").glob("*.md")} - {
path.name for path in Path("history/0.1.2").glob("*.md")
}
assert pending == {"rel.1.md"}, pending
roadmap = Path("ROADMAP.md").read_text(encoding="utf-8")
assert "- `(x) 0.1.2`" in roadmap
for version in ("0.1.3", "0.1.4", "0.1.5", "0.1.6", "0.1.7"):
assert f"- `( ) {version}`" in roadmap, version
assert "- `( ) 0.1.8`" not in roadmap
assert "skeleton Tauri jusqu'au réexamen 0.1.4" in roadmap
changelog = Path("CHANGELOG.md").read_text(encoding="utf-8")
assert "## 0.1.2" in changelog.splitlines()
assert "## 0.1.2 (candidate)" not in changelog
section = changelog.split("## 0.1.2", 1)[1].split("## 0.1.1", 1)[0]
for phrase in (
"trois owners indépendants",
"520-JAVA",
"521-MAVEN",
"522-GRADLE",
"JDK utilisé pour construire",
"Wrapper",
"Gradle système",
"SUPERSEDED",
"réévaluation pratique reste la cible distincte `0.1.3`",
):
assert phrase in section, phrase
for forbidden in ("alpha.1", "alpha.2", "alpha.3", "beta.1", "rc.1", "rel.1"):
assert forbidden not in section, forbidden
readme = Path("README.md").read_text(encoding="utf-8")
assert "avec `0.1.2` d’owners Java, Maven et Gradle séparés et composables" in readme
assert "plan historique de la stable `0.1.2`" in readme
index = Path("docs/000-README.md").read_text(encoding="utf-8")
assert "plan historique de la stable `0.1.2`" in index
assert "à exécuter uniquement après publication et vérification post-tag de `v0.1.2`" in index
plan = Path("docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md").read_text(encoding="utf-8")
assert "Plan historique de la stable `0.1.2`" in plan
assert "### rc.1 — release candidate\n\nStatut opérateur : **PASS**." in plan
assert "history/0.1.2/rel.1.md" in plan
assert "pgr-0.1.2-publish.001-report.md" in plan
assert "commit `0.1.2` avant le tag `v0.1.2`" in plan
prompt = Path("prompts/009-V0_1_3_START_PROMPT.md").read_text(encoding="utf-8")
assert "tag Gitea `v0.1.2`" in prompt
assert "pgr-0.1.2-publish.001-report.md" in prompt
assert "0.1.3-alpha.1" in prompt
assert "réservé à `0.1.4`" in prompt
assert "adoption Games `0.1.5`" in prompt
for path, version in (
("docs/rules/520-JAVA.md", 4),
("docs/rules/521-MAVEN.md", 1),
("docs/rules/522-GRADLE.md", 1),
("docs/rules/520-JAVA_MAVEN_GRADLE.md", 4),
("docs/rules/610-ANDROID.md", 3),
):
lines = Path(path).read_text(encoding="utf-8").splitlines()
assert lines[1] == f"<!-- version: {version} -->", (path, lines[1])
legacy = Path("docs/rules/520-JAVA_MAVEN_GRADLE.md").read_text(encoding="utf-8")
assert "`SUPERSEDED` depuis `0.1.2-alpha.3`." in legacy
assert "Il ne constitue plus un profil sélectionnable" in legacy
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
for forbidden 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(forbidden).exists(), forbidden
java_related = sorted(
str(path)
for root in (Path("docs/templates"), Path("docs/skeletons"), Path("docs/validation"), Path("scripts"))
for path in root.rglob("*")
if path.is_file() and any(word in path.name.lower() for word in ("java", "maven", "gradle"))
)
assert java_related == [], java_related
workflow = Path("docs/rules/210-WORKFLOW.md").read_text(encoding="utf-8")
assert "history rel.1 FAIL / PARTIAL / BLOCKED" in workflow
assert "premier history rel.N[/fix.M] PASS qui établit réellement la stable" in workflow
assert "commit X.Y.Z" in workflow
print("0.1.2 rel.1 stable gate audit: clean (6 prior histories, rel.1 pending, stable Java/Maven/Gradle presentation and post-tag handoff coherent)")
PYGATE
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 - <<'PYHYGIENE'
from pathlib import Path
import json
import tomllib
for path in sorted(Path("templates/rust-cargo").rglob("*.toml")):
tomllib.loads(path.read_text(encoding="utf-8"))
json.loads(Path("templates/web-typescript/package.json").read_text(encoding="utf-8"))
json.loads(Path("templates/web-typescript/tsconfig.json").read_text(encoding="utf-8"))
roots = (
Path("VERSION"), Path("README.md"), Path("RULES.md"), Path("ROADMAP.md"), Path("CHANGELOG.md"),
Path("docs"), Path("deltas"), Path("history"), Path("prompts"), Path("templates"),
)
files = []
for root in roots:
if root.is_file():
files.append(root)
elif root.is_dir():
files.extend(path for path in root.rglob("*") if path.is_file())
for path in files:
try:
data = path.read_bytes()
text = data.decode("utf-8")
except UnicodeDecodeError:
continue
assert b"\r" not in data, path
assert text.endswith("\n"), path
for number, line in enumerate(text.splitlines(), 1):
assert line == line.rstrip(" \t"), (path, number)
print("0.1.2 rel.1 text/template hygiene: clean")
PYHYGIENE
git diff --check
git add VERSION README.md ROADMAP.md CHANGELOG.md docs/000-README.md \
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md \
deltas/0.1.2/rel.1.md
git diff --cached --check
git status --short
```
Le scope attendu avant ajout du history est exactement :
```text
M CHANGELOG.md
M README.md
M ROADMAP.md
M VERSION
A deltas/0.1.2/rel.1.md
M docs/000-README.md
M docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
```
La RC a déjà reconfirmé les owners gelés, la frontière Android, le contrat du prompt `009` et l'absence d'artefacts Java/Maven/Gradle supplémentaires. Comme `rel.1` ne modifie aucun artefact technique, la promotion stable rejoue les tests PGR, les audits documentaires et l'hygiène des templates sans simuler de toolchain Java/Maven/Gradle absente du dépôt.
## Revue opérateur complémentaire
Confirmer que :
- le scope fonctionnel de `rc.1` ne change pas ;
- `0.1.2` est présenté comme stable de manière cohérente dans VERSION/README/ROADMAP/CHANGELOG/index/plan ;
- les histories `alpha.1`, `alpha.2`, `alpha.2.fix.1`, `alpha.3`, `beta.1` et `rc.1` restent conservés avec leur statut réel `PASS` ;
- `520-JAVA`, `521-MAVEN` et `522-GRADLE` restent gelés et l'ancien owner combiné reste uniquement un bridge historique `SUPERSEDED` ;
- aucune version particulière de Games ne devient un minimum PGR ;
- le profil Android reste inchangé et `0.1.3` conserve seul sa réévaluation pratique ;
- le skeleton Tauri reste réservé au réexamen `0.1.4` et l'adoption Games à `0.1.5` ;
- la roadmap engagée `0.1.3` à `0.1.7` reste intacte sans `0.1.8` ;
- le prompt `009` reste conditionnel à une vraie publication de `v0.1.2` et à un rapport post-tag `PASS` réel ;
- aucune preuve post-tag n'est anticipée.
## Transition
### PASS
Produire séparément `history/0.1.2/rel.1.md`, l'appliquer, puis créer le commit stable sous le message exact :
```text
0.1.2
```
Après push de la branche canonique, créer et publier le tag annoté `v0.1.2`. Vérifier localement et à distance l'objet tag et son commit déréférencé. Télécharger ensuite l'archive source depuis le tag Gitea et la fournir au générateur avec les sorties Git de publication afin de produire `pgr-0.1.2-publish.001-report.md` à partir de preuves réelles.
Le prompt `009-V0_1_3_START_PROMPT.md` ne devient la reprise effective de `0.1.3` qu'après un rapport post-tag `PASS`.
### FAIL
Consigner le diagnostic réel dans `history/0.1.2/rel.1.md`, ne pas créer le tag et corriger uniquement la fermeture dans `rel.1.fix.1` avant toute publication.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md --> <!-- file: docs/000-README.md -->
<!-- version: 31 --> <!-- version: 36 -->
# Documentation PGR # Documentation PGR
@@ -20,6 +20,17 @@ D'autres collections telles que `ideas/`, `studies/`, `reference/` ou `formats/`
Les templates techniques copiables sous `templates/` restent séparés des instructions documentaires sous `docs/templates/`. Les répertoires workflow de racine (`deltas/`, `history/`, `handoffs/`, `manifests/`, `prompts/`, `scripts/`) restent séparés de `docs/` parce qu'ils portent le processus de développement et de livraison lui-même. Les templates techniques copiables sous `templates/` restent séparés des instructions documentaires sous `docs/templates/`. Les répertoires workflow de racine (`deltas/`, `history/`, `handoffs/`, `manifests/`, `prompts/`, `scripts/`) restent séparés de `docs/` parce qu'ils portent le processus de développement et de livraison lui-même.
## 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 historique de la stable `0.1.2`, de la réévaluation Games à la scission `520/521/522`, avec frontière Android explicite.
- [`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`.
- [`../prompts/009-V0_1_3_START_PROMPT.md`](../prompts/009-V0_1_3_START_PROMPT.md) — prompt préparé par la RC pour la réévaluation Android `0.1.3`, à exécuter uniquement après publication et vérification post-tag de `v0.1.2`.
## Points d'entrée de 0.1.1 ## Points d'entrée de 0.1.1
- [`plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md`](plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md) — plan historique de la stable `0.1.1`, de l'audit des corpus à la fondation Web composable et à la préparation du futur réexamen Tauri. - [`plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md`](plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md) — plan historique de la stable `0.1.1`, de l'audit des corpus à la fondation Web composable et à la préparation du futur réexamen Tauri.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/003-RULE_PROFILE_MODEL.md --> <!-- file: docs/architecture/003-RULE_PROFILE_MODEL.md -->
<!-- version: 6 --> <!-- version: 8 -->
# Modèle de profils de règles PGR # Modèle de profils de règles PGR
@@ -204,6 +204,53 @@ 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. 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.
## Réconciliation beta de Java / Maven / Gradle en `0.1.2`
La réconciliation `beta.1` confirme la scission introduite en `alpha.3` sans ajouter de quatrième owner ou d'artefact technique générique. Les owners courants restent :
```text
520 — Java
521 — Maven
522 — Gradle
```
Le corpus Games apporte une preuve pratique pour Java et Gradle, mais aucune preuve Maven réelle. Cette asymétrie ne remet pas en cause `521-MAVEN.md` : elle interdit seulement de présenter Games comme validation d'une convention Maven nouvelle ou de créer un artefact Maven à partir d'un corpus qui n'en possède pas.
La revue confirme également que les décisions locales Games ne deviennent pas des minima généraux : ni JDK 25, ni cible Java 17, ni Gradle 9.6.0+, ni Groovy DSL, ni absence de Wrapper ne sont imposés par les profils courants. Seuls les principes réutilisables démontrés sont conservés : séparation JDK/source/bytecode, ownership du build, contrainte système effectivement vérifiée et Wrapper conditionnel.
Aucun nouveau contrat sous `docs/validation/`, template, skeleton ou audit Python Java/Maven/Gradle n'est justifié. Les toolchains officielles restent propriétaires des preuves exécutables lorsque des artefacts Java/Maven/Gradle réels existent.
Enfin, Android reste un raffinement de plateforme : `610-ANDROID.md` possède AGP, SDK/NDK, ABI/JNI, manifests/resources, packaging/signing et smokes. La réconciliation `0.1.2` ne constitue pas le démarrage de `0.1.3`.
## Activation de la famille framework en `0.0.5` ## 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. 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.

View File

@@ -0,0 +1,467 @@
<!-- file: docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md -->
<!-- version: 6 -->
# Plan 0.1.2 — réévaluation Java / Maven / Gradle
## Statut et sources
Plan historique de la stable `0.1.2`, créé pendant `0.1.2-alpha.1` conformément à `prompts/008-V0_1_2_START_PROMPT.md`, après audit indépendant de la stable taggée `v0.1.1`, de son rapport post-tag `PASS` et du corpus Games autoritaire réellement fourni.
Sources autoritaires de reprise PGR :
```text
pgr-v0.1.1(1).zip caaf8f456f7f8520172ea7705fd0cf5c5bf0e942dc4a773410bcbe7fe4ce243a
pgr-0.1.1-publish.001-report(1).md 3eafc2767225526a6cba65b3b62a45a664b71a1f2fa049915ec243a196e14bb3
```
Les noms locaux comportent `(1)`, mais l'archive PGR possède exactement le SHA-256 canonique enregistré par le rapport `publish.001`. Le rapport est `PASS`, porte sur cette même archive et confirme le commit stable `4893a04f4945f7cdc62d1294626a597353023a94`. Le tag annoté `v0.1.1` possède l'objet tag `09a3fe1501449a02a7edbbe9e897246b5434e15c` et se déréférence vers ce commit stable.
Corpus principal réellement fourni pour instruire Java/Gradle :
```text
games-v0.3.6(1).zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
```
Le nom local comporte `(1)`, mais son SHA-256 correspond exactement à la baseline canonique `games-v0.3.6.zip` attendue par le prompt `008`. Games est donc le corpus autoritaire prévu pour cette réévaluation.
## Audit de la stable `v0.1.1`
### Intégrité de l'archive et preuve post-tag
L'archive stable contient `292` entrées sous une racine unique `pgr/`, soit `256` fichiers et `36` répertoires en comptant la racine. Son CRC est propre, aucun lien symbolique n'est présent et `.git` est absent comme attendu pour une archive de tag Gitea.
`VERSION` vaut exactement `0.1.1`. `CHANGELOG.md` contient l'entrée stable `0.1.1`, `ROADMAP.md` marque `0.1.1` terminé et conserve `0.1.2` à `0.1.7` engagés sans réserver `0.1.8`.
La publication observée suit le workflow courant :
```text
tranche de clôture rel.1
history rel.1 PASS
commit stable 0.1.1
tag v0.1.1
publish.001 preuve externe post-tag PASS
```
Le SHA de l'objet tag annoté reste distinct du commit stable ; la référence déréférencée pointe bien sur le même commit que `HEAD` et `origin/master` observés dans le rapport.
### Tests, audits et hygiène
Les quatre modules de tests Python de la stable ont été rejoués par groupes dans l'environnement d'analyse :
```text
48 / 48 tests PASS
```
Les audits documentaires donnent exactement :
```text
Markdown header audit: clean (231 file(s))
Markdown table audit: clean (9 table(s), 231 file(s))
Markdown link audit: clean (267 local link(s), 231 file(s))
```
Les cinq templates TOML Rust/Cargo restent parsables. Aucun symlink ni output courant tel que `target/`, `node_modules/`, `dist/` ou `__pycache__/` n'est embarqué dans la stable.
### Chaîne delta/history et vérité opérateur
Les `83` deltas publiés de `0.0.1` à `0.1.1` disposent tous d'un history portant la même identité.
Pour `0.1.1`, la vérité opérateur est conservée :
```text
alpha.1 PASS
alpha.2 FAIL
alpha.2.fix.1 PASS
alpha.3 PASS
alpha.3.fix.1 FAIL
alpha.3.fix.2 PASS
alpha.4 PASS
alpha.5 PASS
beta.1 PASS
rc.1 PASS
rel.1 PASS
```
Les `FAIL` ne sont ni écrasés ni réécrits après leurs corrections.
### État des owners et décisions différées
La stable possède notamment :
```text
510 Rust / Cargo
520 Java / Maven / Gradle
530 TypeScript
540 JavaScript package ecosystem
550 Vite
560 CSS / Sass
610 Android
710 Tauri 2
```
La fondation Web `0.1.1` est stable et son skeleton est indépendant du host. Le skeleton Tauri reste `DEFER` jusqu'au réexamen réservé à `0.1.4` ; `0.1.2` n'a donc aucune raison de rouvrir cette décision.
Le profil `520-JAVA_MAVEN_GRADLE.md` est l'owner à réévaluer. Le profil `610-ANDROID.md` reste l'owner des contraintes Android et sert ici uniquement à contrôler la frontière de responsabilité, pas à démarrer `0.1.3`.
## Audit du corpus Games `0.3.6`
### Intégrité et portée
L'archive Games contient `652` entrées sous une racine unique `games/`, soit `502` fichiers et `150` répertoires. Son CRC est propre et aucun lien symbolique n'est présent.
La version produit est portée par `Cargo.toml` et vaut `0.3.6`. L'absence d'un fichier racine `VERSION` dans ce corpus n'est pas interprétée comme un défaut PGR : Games n'est pas encore dans sa release d'adoption `0.3.7` / PGR `0.1.5`.
Les audits statiques rejoués sur l'archive donnent :
```text
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
games.sasedev workspace audit: clean
Markdown table audit: clean (6 table(s), 319 file(s))
Distribution layout audit: clean (55 required path(s), 11 forbidden path(s) absent)
```
Ces contrôles attestent l'intégrité structurelle du corpus utilisé pour l'étude ; ils ne remplacent pas les validations Gradle/Android historiques déjà consignées par Games.
### Structure Java observée
Le corpus contient quatre sources Java, toutes sous la convention `src/main/java/` :
```text
Android/common/src/main/java/com/sasedev/games/common/NativeBridge.java
Android/common/src/main/java/com/sasedev/games/common/SaseGameActivity.java
Android/game-reflex-poc/src/main/java/com/sasedev/games/reflex/ReflexActivity.java
Android/game-snake-poc/src/main/java/com/sasedev/games/snake/SnakeActivity.java
```
Les déclarations de package correspondent à leurs chemins. Les imports présents sont explicites ; aucun wildcard import n'est observé. La visibilité est bornée par la responsabilité des classes et les classes finales qui n'ont pas vocation à être étendues le sont effectivement.
Le corpus n'exerce pas de suite Java générique sous `src/test/java/`. Il ne fournit donc pas une preuve suffisante pour renforcer ou spécialiser les règles de tests Java du profil `520` au-delà de ce qui existe déjà.
Les responsabilités `Activity`, JNI, SDL3 et API Android rencontrées dans ces sources restent des responsabilités Android ou produit. Leur présence ne transforme pas ces contrats en règles Java générales.
### Build Gradle observé
Le projet Android est un build Gradle multi-module en Groovy DSL comprenant :
```text
:common
:game-reflex-poc
:game-snake-poc
```
L'ownership est réparti de manière identifiable :
- `settings.gradle` possède la composition des modules, la résolution des plugins/dépendances et le contrôle du minimum Gradle ;
- le `build.gradle` root possède les versions des plugins appliqués aux sous-projets ;
- `gradle.properties` porte des propriétés partagées non secrètes du build ;
- chaque `build.gradle` de module porte sa configuration locale et ses dépendances ;
- les scripts sous `Android/gradle/` portent une logique de build commune devenue suffisamment importante pour ne pas être dupliquée dans chaque module.
Cette répartition corrobore le principe PGR de centraliser ce qui est réellement commun sans imposer un layout ou une abstraction identique à tous les projets Gradle.
### JDK, niveau Java et compatibilité
L'historique Games fournit une preuve particulièrement utile pour la distinction déjà exigée par `520`.
Une première preuve `0.3.3-0-pre.2` a utilisé un Gradle Wrapper `9.6.0` et Temurin `17` via `JAVA_HOME`. Cette combinaison a ensuite été volontairement remplacée par un contrat moins restrictif : Gradle système `>= 9.6.0` et JDK courant de l'environnement.
Les gates `0-pre.3` à `0-pre.5` ont validé :
```text
JDK de build Temurin 25.0.4.1 LTS
Gradle exécuté 9.7.1
niveau Java source/target 17
```
La preuve démontre qu'un JDK de build plus récent peut exécuter la toolchain tout en produisant un code Java ciblant un niveau plus ancien explicitement déclaré. Elle ne justifie ni d'imposer Java 17 à PGR, ni d'imposer JDK 25, ni de transformer une contrainte Android en règle Java générale.
### Gradle système versus Wrapper
La trajectoire Games est utile précisément parce qu'elle a exercé les deux politiques :
1. wrapper exact introduit pour une preuve bornée et reproductible ;
2. retrait du wrapper lorsque la décision durable est devenue « Gradle système compatible, minimum vérifié » ;
3. contrôle de `GradleVersion.current()` contre `9.6.0` dans `settings.gradle` ;
4. validation réelle avec Gradle `9.7.1`.
Cette trajectoire confirme qu'un Wrapper est un moyen de reproductibilité, pas une obligation cérémonielle, et qu'un Gradle système peut être une politique durable lorsque sa contrainte est explicitement vérifiée.
Le minimum exact `9.6.0` est toutefois lié à la stack Android observée et reste hors de toute règle Gradle générale.
### DSL, dépendances et versions
Games utilise uniquement le Groovy DSL pour son projet Gradle natif. Ce choix ne fournit aucune preuve permettant de rendre Groovy obligatoire ou de déprécier Kotlin DSL dans PGR.
Aucun version catalog n'est présent. Les versions de plugins réellement partagées sont centralisées au root ; les repositories sont possédés au niveau `settings.gradle`. Cette organisation confirme la valeur de l'ownership partagé mais ne justifie pas d'imposer `libs.versions.toml`, `RepositoriesMode.FAIL_ON_PROJECT_REPOS` ou un repository particulier à tous les builds Gradle.
Aucun projet Maven, `pom.xml` ou Maven Wrapper n'est présent. Games n'autorise donc aucun nouvel artefact Maven dans `0.1.2` ; les règles Maven existantes seront seulement relues pour cohérence avec le contrat général du profil.
### Outputs, état local et validation
La stable Games ignore explicitement les caches et outputs Gradle :
```text
/Android/.gradle/
/Android/**/build/
```
`local.properties` reste également hors Git. Cette pratique corrobore la séparation PGR entre configuration partagée versionnée, état machine local et outputs générés.
Les gates historiques utilisent directement les tâches Gradle pertinentes (`assembleDebug`, `bundleRelease`, etc.) et n'emploient `clean` que lorsqu'une phase de stabilisation a réellement besoin de reconstruire depuis un état nettoyé. Cela confirme le principe PGR : tâches ciblées pendant le développement, gates plus larges lorsque le scope ou la phase le justifie, et aucun `clean` systématique comme pseudo-preuve.
## Frontière Android obligatoire
Les éléments suivants sont observés dans Games mais appartiennent explicitement à `610-ANDROID.md`, à une spécialisation Android/Rust/JNI ou au produit Games :
```text
AGP 9.4.0
compileSdk / targetSdk / minSdk
NDK et ABI Android
AAR SDL3 et Prefab
JNI et bibliothèques natives
applicationId / namespace / manifests / resources
APK / AAB / signing
Variant API Android
AVD, devices et smokes Android
contraintes 16 KB
choix SDL3 et architecture des jeux
```
Aucun de ces éléments ne doit devenir une règle Java/Gradle générale pendant `0.1.2`.
Une contrainte Gradle ou JDK plus étroite imposée par AGP constitue un raffinement de plateforme. `0.1.2` peut documenter cette frontière dans `520`, mais ne réécrit pas le profil Android et ne commence pas `0.1.3`.
## Classification initiale des décisions Games
La classification suivante guide les tranches normatives ; elle ne constitue pas encore une adoption de Games, réservée à `0.1.5`.
| Décision observée | Classification | Traitement `0.1.2` |
|--------------------------------------------------------------------------------|----------------------------------|--------------------------------------------------------------------------------------------|
| Séparer JDK de build et niveau Java produit | `ADOPT` | conserver et clarifier dans `520` |
| Utiliser la structure Java canonique `src/main/java` et des packages cohérents | `ADOPT` | conserver les règles existantes, sans importer les responsabilités Android |
| Centraliser la configuration Gradle réellement commune | `ADOPT` | préciser les owners `settings` / root / sous-projets sans imposer le layout Games |
| Gradle système avec contrainte minimale effectivement vérifiée | `ADOPT` comme politique possible | renforcer le contrat de vérifiabilité, sans imposer `9.6.0` |
| Absence durable de Gradle Wrapper dans Games | `KEEP-LOCAL` | conserver le Wrapper comme option PGR de reproductibilité, pas comme obligation |
| Groovy DSL | `KEEP-LOCAL` | maintenir Groovy et Kotlin DSL comme choix valides ; ne pas copier la préférence Games |
| JDK 25 LTS de build et source/target 17 | `KEEP-LOCAL` | ne généraliser que leur séparation conceptuelle |
| Matrice AGP/Gradle/JDK plus étroite | `OVERRIDE` de plateforme | reste possédée par `610` / Android, hors normalisation `520` |
| Version catalog | `DEFER` | aucun besoin démontré ; rester optionnel |
| Nouveaux templates/audits Maven | `DEFER` | aucun corpus Maven réel fourni |
| Skeleton Java/Gradle générique | `DEFER` | Games n'exerce qu'un build Gradle Android ; preuve insuffisante pour un skeleton générique |
| Audit Python Java/Gradle | `DEFER` | aucune propriété générique non mieux contrôlée par Java/Gradle n'est encore démontrée |
## Réévaluation du profil `520`
Le profil existant est globalement cohérent avec les preuves Games : il distingue déjà JDK de build et niveau Java, rend les Wrappers conditionnels, reconnaît Gradle système, accepte Groovy/Kotlin DSL, déconseille `clean` systématique et ignore les outputs/caches.
La release doit donc privilégier une correction ciblée plutôt qu'une réécriture. Les points à instruire en priorité sont :
1. préciser que la compatibilité Java ne se résume pas au JDK actif et qu'un JDK de build plus récent peut cibler un niveau produit plus ancien explicitement déclaré ;
2. rendre explicite qu'une politique « Gradle système » doit posséder une contrainte vérifiable par le build ou la gate, pas seulement une version écrite dans une documentation ;
3. préciser les responsabilités naturelles de `settings.gradle(.kts)`, du root build et des sous-projets sans transformer les APIs modernes observées dans Games en obligations universelles ;
4. distinguer `gradle.properties` partagé et portable des propriétés locales, chemins machine, secrets ou overrides utilisateur ;
5. conserver la neutralité Groovy/Kotlin DSL et le caractère conditionnel du Wrapper/version catalog ;
6. relire les sections Maven pour cohérence, sans créer de nouvel artefact Maven faute de corpus ;
7. vérifier qu'aucune règle Java/Gradle n'absorbe AGP, SDK, NDK, ABI/JNI, packaging ou smokes Android.
Le regroupement actuel Java/Maven/Gradle dans un seul owner est également relu au regard de `500-LANGUAGES.md`. Une scission documentaire ne sera effectuée que si elle réduit réellement les responsabilités ambiguës. En l'absence de corpus Maven, `0.1.2` ne créera pas artificiellement un nouvel owner Maven uniquement pour satisfaire une préférence de découpage.
## Décision après `alpha.1`
La gate opérateur de `alpha.1` est `PASS` : `48/48` tests Python, audits Markdown propres, audit structurel propre et scope Git conforme. Aucun `alpha.1.fix.N` ni REPLAN n'est requis.
La revue confirme la classification initiale sans l'élargir :
- `ADOPT` : distinction JDK de build / niveau source / bytecode-runtime, ownership Gradle explicite et politique Gradle système seulement si sa contrainte est effectivement vérifiée ;
- `KEEP-LOCAL` : Groovy DSL, absence de Wrapper dans Games, JDK 25 LTS et cible Java 17 ;
- `OVERRIDE` : matrice AGP/Gradle/JDK et autres contraintes de plateforme Android ;
- `DEFER` : version catalog, skeleton Java/Gradle, audit Python Java/Gradle et nouveaux artefacts Maven.
`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.
## Décision après `alpha.3` et réconciliation `beta.1`
La gate opérateur de `alpha.3` est `PASS` : `48/48` tests Python, audits Markdown propres, gate de scission propre, bridge historique préservé, frontière Android maintenue et scope Git conforme. Aucun `alpha.3.fix.N` ni nouveau REPLAN n'est requis.
La réconciliation beta rejoue les trois owners contre Games, `500-LANGUAGES.md`, `610-ANDROID.md` et les règles générales de validation. Elle confirme :
- `520-JAVA.md` reste applicable au langage Java indépendamment du build tool ;
- `521-MAVEN.md` ne devient applicable que lorsqu'un projet utilise Maven et n'est pas présenté comme éprouvé par Games, qui ne fournit aucun corpus Maven ;
- `522-GRADLE.md` ne devient applicable que lorsqu'un projet utilise Gradle et conserve uniquement les principes génériques démontrés ;
- JDK 25, cible Java 17, Gradle 9.6.0+, Gradle 9.7.1, Groovy DSL et absence de Wrapper restent des décisions locales/corpus et non des minima PGR ;
- AGP, SDK/NDK, ABI/JNI, manifests/resources, packaging/signing, device/AVD, contraintes 16 KB et SDL3 restent possédés hors des owners Java/Maven/Gradle et réservés à la réévaluation Android `0.1.3` ;
- l'ancien `520-JAVA_MAVEN_GRADLE.md` reste uniquement un bridge historique `SUPERSEDED`.
La décision finale d'artefacts pour `0.1.2` est donc **aucun artefact technique supplémentaire** : aucun nouveau contrat de validation, template, skeleton, audit Python Java/Maven/Gradle ou artefact Maven n'apporte une valeur démontrée par le corpus disponible. Les owners `520/521/522` suffisent et les toolchains officielles restent propriétaires des preuves exécutables.
La beta n'ouvre aucune nouvelle règle fonctionnelle ; elle consolide l'état durable avant `rc.1`.
## 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.
Elle MUST :
- conserver les choix Java/Gradle qui sont déjà correctement généralisés ;
- 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 ;
- ne créer un nouvel artefact Java/Gradle que s'il évite une duplication réelle ou matérialise un contrat absent du profil actuel.
Elle MUST NOT :
- modifier Games ;
- démarrer l'adoption Games `0.1.5` ;
- réécrire `610-ANDROID.md` ou commencer `0.1.3` ;
- créer ou réexaminer le skeleton Tauri avant `0.1.4` ;
- 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 retenus après REPLAN
Owners normatifs nécessaires :
```text
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
```
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/... 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
```
Cette décision est rejouée et confirmée dans `beta.1` après validation opérateur de la scission.
## Trajectoire prévisionnelle de `0.1.2`
### alpha.1 — audit de stable, corpus et plan
Vérifier `v0.1.1`, son rapport `publish.001`, le corpus Games, la frontière Android et la classification initiale. Créer le présent plan sans modifier encore `520` ou `610`.
### alpha.2 — révision ciblée Java / Gradle
Réviser `520-JAVA_MAVEN_GRADLE.md` uniquement sur les points réellement démontrés : compatibilité JDK/source/bytecode, ownership Gradle, contrainte système vérifiable, Wrapper conditionnel, DSL, propriétés partagées/locales, validation et outputs.
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 : **PASS**.
### beta.1 — réconciliation et décision d'artefacts
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.
La beta met également à jour les index/documentation durable nécessaires à la release et prépare la clôture sans ouvrir `0.1.3` prématurément.
Statut opérateur : **PASS**.
### rc.1 — release candidate
Statut opérateur : **PASS**.
La gate RC a confirmé les cinq histories antérieurs `PASS`, le scope Java/Maven/Gradle gelé, le changelog candidat, le prompt `009`, les `48/48` tests, les trois audits Markdown et l'hygiène texte/templates. Aucun owner, profil Android, template, skeleton, validation ou script n'a été modifié pendant la RC.
Le prompt `009-V0_1_3_START_PROMPT.md` conserve la frontière de release : la réévaluation Android démarre en `0.1.3` seulement depuis une stable `v0.1.2` réellement taggée et son rapport post-tag `PASS`; Tauri reste réservé à `0.1.4` et l'adoption Games à `0.1.5`.
### rel.1 — promotion stable
Première clôture stable de `0.1.2`. La promotion est strictement mécanique : `VERSION = 0.1.2`, `ROADMAP.md` marque `0.1.2` terminée, le `CHANGELOG` perd son marqueur `candidate`, README/index décrivent la réévaluation Java/Maven/Gradle comme stable et le présent plan devient historique. Aucun owner, profil Android, template, skeleton, validation ou script technique n'est modifié.
Le résultat opérateur de cette tranche appartient à `history/0.1.2/rel.1.md`, créé seulement après exécution de la gate. Si `rel.1` échoue, son history est conservé et un `rel.1.fix.N` corrige uniquement la fermeture ; la première tranche qui établit réellement la stable est incluse dans le commit `0.1.2` avant le tag `v0.1.2`.
La vérification post-tag reste séparée : `pgr-0.1.2-publish.001-report.md` ne peut être produit qu'à partir de l'archive du tag réellement publiée et des preuves Git observées. Le prompt `009` ne devient le point de départ effectif de `0.1.3` qu'après cette preuve post-tag `PASS`.
## 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 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.
Si une tranche ultérieure ajoute un artefact Gradle exécutable réel, sa validation doit utiliser Java/Gradle officiels en plus des audits PGR applicables. Un audit Python ne remplacera ni `javac`, ni Gradle, ni Maven.
La validation reste proportionnée : aucune commande `clean` systématique et aucune gate Android uniquement parce que Games a servi de corpus d'étude.
## Déclencheurs de REPLAN
Un REPLAN est requis notamment si :
- la révision montre que `520` doit être scindé en plusieurs owners pour éviter une ambiguïté normative réelle ;
- un besoin Maven réel apparaît et exige un corpus ou une preuve absente de la baseline actuelle ;
- une modification supposée générique dépend en réalité d'AGP, du SDK/NDK, de JNI ou du packaging Android ;
- un template/audit candidat exige de copier une structure Games plutôt que de matérialiser un contrat réutilisable ;
- la release ne peut pas rester bornée sans absorber une responsabilité explicitement réservée à `0.1.3` ou `0.1.4`.
Un REPLAN ne sert pas à ajouter des artefacts pour remplir la release ; il sert à corriger son découpage lorsque les owners réels l'exigent.
## Clôture et transition
La réconciliation documentaire durable, le `CHANGELOG`, la mise à jour de `ROADMAP` et la fermeture du plan sont achevés par `rel.1`. La publication du tag et sa vérification post-tag restent séparées de cette clôture pré-tag.
La roadmap possède déjà un horizon suffisant jusqu'à `0.1.7`. Aucune nouvelle revue d'horizon n'est requise par défaut pendant `0.1.2`.
La prochaine release engagée après publication vérifiée de `0.1.2` reste :
```text
0.1.3 — réévaluation pratique du profil Android à partir de Games
```
Le prompt de démarrage de `0.1.3` ne doit être préparé que dans une tranche où la clôture `0.1.2` est suffisamment déterminée, puis exécuté seulement après stable taggée et preuve post-tag applicable.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/000-README.md --> <!-- file: docs/rules/000-README.md -->
<!-- version: 15 --> <!-- version: 16 -->
# Index des règles PGR # 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. - [`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. - [`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. - [`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. - [`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. - [`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. - [`550-VITE.md`](550-VITE.md) — profil Vite, build tool/dev server recommandé et ownership de son cache et de ses outputs.

200
docs/rules/520-JAVA.md Normal file
View File

@@ -0,0 +1,200 @@
<!-- file: docs/rules/520-JAVA.md -->
<!-- version: 4 -->
# 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<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.
## 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.

View File

@@ -1,316 +1,24 @@
<!-- file: docs/rules/520-JAVA_MAVEN_GRADLE.md --> <!-- file: docs/rules/520-JAVA_MAVEN_GRADLE.md -->
<!-- version: 2 --> <!-- version: 4 -->
# 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`, signing ou packaging APK/AAB appartient au profil plateforme Android et peut surcharger 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.
## Politique JDK et compatibilité Java Les owners applicables sont désormais :
Pour un projet Java général suivant le profil PGR : - [`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.
- le JDK de développement SHOULD être une version LTS ; Les contraintes Android restent possédées par [`610-ANDROID.md`](610-ANDROID.md).
- 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 : ## Compatibilité documentaire
```text 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é.
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.
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<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.

84
docs/rules/521-MAVEN.md Normal file
View File

@@ -0,0 +1,84 @@
<!-- file: docs/rules/521-MAVEN.md -->
<!-- version: 1 -->
# 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 <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.
## 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.

118
docs/rules/522-GRADLE.md Normal file
View File

@@ -0,0 +1,118 @@
<!-- file: docs/rules/522-GRADLE.md -->
<!-- version: 1 -->
# 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 :<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.
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.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/610-ANDROID.md --> <!-- file: docs/rules/610-ANDROID.md -->
<!-- version: 2 --> <!-- version: 3 -->
# Profil Android # Profil Android
@@ -7,9 +7,9 @@
Ce document possède les règles réutilisables propres à la plateforme Android. 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. 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.

98
history/0.1.2/alpha.1.md Normal file
View File

@@ -0,0 +1,98 @@
<!-- file: history/0.1.2/alpha.1.md -->
<!-- version: 1 -->
# History 0.1.2-alpha.1 — audit de stable, corpus et plan Java/Gradle
## Statut
PASS
La gate opérateur de `0.1.2-alpha.1` exécutée le `2026-09-27` est propre. La stable `v0.1.1`, le corpus Games autoritaire, le plan de réévaluation Java/Maven/Gradle et la frontière Android réservée à `0.1.3` sont cohérents ; aucun fix de cadrage n'est requis avant `alpha.2`.
## Contrôles d'identité
Les contrôles opérateur ont confirmé :
```text
VERSION 0.1.2-alpha.1
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md présent
deltas/0.1.2/alpha.1.md présent
history/0.1.2/alpha.1.md absent pendant la gate
README.md version 20
docs/000-README.md version 32
```
Les deux index référencent bien le plan actif `008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md`.
## Tests Python
La suite complète a affiché :
```text
Ran 48 tests in 0.763s
OK
```
Soit `48/48` tests `PASS`.
## Audits Markdown
Les audits ont affiché :
```text
Markdown header audit: clean (233 file(s))
Markdown table audit: clean (10 table(s), 233 file(s))
Markdown link audit: clean (273 local link(s), 233 file(s))
```
## Validation structurelle
Le contrôle spécifique de la tranche a terminé proprement :
```text
0.1.2 alpha.1 structural audit: clean (83 prior pairs, Games classified, Android 0.1.3 boundary preserved)
```
Il confirme notamment :
- les `83` couples delta/history antérieurs complets ;
- la conservation de `alpha.2 FAIL`, `alpha.2.fix.1 PASS`, `alpha.3.fix.1 FAIL`, `alpha.3.fix.2 PASS` et `rel.1 PASS` pour `0.1.1` ;
- l'engagement de `0.1.2` à `0.1.7` sans réservation de `0.1.8` ;
- le maintien du skeleton Tauri jusqu'au réexamen `0.1.4` ;
- la présence dans le prompt `008` du corpus Games canonique, de la classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, de la comparaison Gradle système/Wrapper et de la responsabilité Maven du profil `520` ;
- la présence dans `520` des contrats JDK/Gradle/Wrapper déjà existants ;
- la présence dans `610` des responsabilités Android qui doivent rester hors de `0.1.2` ;
- la présence dans le plan des tranches `alpha.2`, `beta.1`, `rc.1` et `rel.1`, ainsi que de la frontière `0.1.3`.
## 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 README.md
M VERSION
A deltas/0.1.2/alpha.1.md
M docs/000-README.md
A docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
```
Le scope correspond exactement au delta annoncé.
## Décision
`0.1.2-alpha.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
La réévaluation Games autorise la tranche normative ciblée prévue :
```text
0.1.2-alpha.2
```
`alpha.2` doit réviser uniquement `520-JAVA_MAVEN_GRADLE.md` sur les ambiguïtés réellement démontrées : compatibilité JDK/source/bytecode, ownership Gradle, contrainte Gradle système effectivement vérifiable, séparation configuration partagée/état local et validation proportionnée.
Le profil `610-ANDROID.md` reste inchangé. AGP, SDK/NDK, ABI/JNI, manifests/resources, APK/AAB, signing, devices/AVD, smokes Android et choix SDL restent réservés à `0.1.3` ou aux owners spécialisés correspondants.
Aucun template, skeleton, audit Java/Gradle ou nouvel artefact Maven n'est justifié à ce stade.

View File

@@ -0,0 +1,125 @@
<!-- file: history/0.1.2/alpha.2.fix.1.md -->
<!-- version: 1 -->
# History 0.1.2-alpha.2.fix.1 — récupération de contamination inter-projet
## Statut
PASS
La gate opérateur de `0.1.2-alpha.2.fix.1` exécutée le `2026-09-27` est propre. Le correctif retire les fichiers Knowledge introduits accidentellement dans la branche PGR, restaure les deux documents PGR écrasés depuis la stable autoritaire `v0.1.1` et conserve intégralement le contenu normatif validé de `alpha.2`.
## Baseline Git observée
Avant application du fix, la branche locale et distante pointaient toutes deux sur le commit contaminé :
```text
17b7ef23a18c913f986c7d57caf958d33479363d
```
Le stash de sécurité contenant l'ancienne application locale de `alpha.3` a été créé avant récupération et n'a pas été restauré pendant la gate.
La version appliquée pendant la gate est :
```text
0.1.2-alpha.2.fix.1
```
## Récupération vérifiée
Les quatre chemins étrangers annoncés par le manifest sont absents après application :
```text
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
```
Le manifest `manifests/0.1.2/alpha.2.fix.1.delete.txt` contient exactement ces quatre chemins.
Les deux fichiers PGR écrasés ont été restaurés exactement à leur contenu de `v0.1.1` :
```text
docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
docs/validation/001-VALIDATION_MATRIX.md
```
La commande `git diff --exit-code v0.1.1 -- <ces deux fichiers>` n'a produit aucune différence.
## Préservation de `alpha.2`
La tranche normative précédente reste intacte et son history reste `PASS` :
```text
history/0.1.2/alpha.2.md PASS
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md version 2
docs/rules/520-JAVA_MAVEN_GRADLE.md version 3
docs/rules/610-ANDROID.md version 2
```
Le fix ne modifie donc aucune décision Java/Maven/Gradle ni aucune responsabilité Android.
## Tests Python
La suite complète a affiché :
```text
Ran 48 tests in 0.721s
OK
```
Soit `48/48` tests `PASS`.
## Audits Markdown
Les audits ont affiché :
```text
Markdown header audit: clean (237 file(s))
Markdown table audit: clean (10 table(s), 237 file(s))
Markdown link audit: clean (273 local link(s), 237 file(s))
```
## Gate de récupération
Le contrôle spécifique a terminé proprement :
```text
0.1.2 alpha.2.fix.1 recovery audit: clean (foreign Knowledge paths removed, PGR baseline restored, alpha.2 preserved)
```
Il confirme que :
- le manifest de suppression est exact ;
- aucun chemin Knowledge contaminant ne subsiste ;
- `history/0.1.2/alpha.2.md` conserve son statut `PASS` ;
- le delta `alpha.2`, le plan `008`, le profil `520` et le profil Android sont préservés ;
- la matrice de validation restaurée ne contient plus de contenu Knowledge.
## 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
D Cargo.toml
M VERSION
D crates/knowledge-domain-lib/src/content_family.rs
D deltas/0.0.1/alpha.3.fix.2.md
A deltas/0.1.2/alpha.2.fix.1.md
M docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
M docs/validation/001-VALIDATION_MATRIX.md
D history/0.0.1/alpha.3.fix.1.md
A manifests/0.1.2/alpha.2.fix.1.delete.txt
```
Le scope correspond exactement au correctif annoncé.
## Décision
`0.1.2-alpha.2.fix.1` est `PASS`.
La contamination inter-projet est corrigée sans réécriture de l'historique Git distant. L'ancienne application locale de `alpha.3` ne doit pas être restaurée comme source autoritaire : le stash de sécurité peut être supprimé après commit/push du présent fix, puis `alpha.3` doit être réappliquée depuis le delta régénéré sur cette baseline propre.

93
history/0.1.2/alpha.2.md Normal file
View File

@@ -0,0 +1,93 @@
<!-- file: history/0.1.2/alpha.2.md -->
<!-- version: 1 -->
# History 0.1.2-alpha.2 — révision ciblée Java / Gradle
## Statut
PASS
La gate opérateur de `0.1.2-alpha.2` exécutée le `2026-09-27` est propre. Les précisions Java/Gradle issues de la réévaluation Games sont validées sans transfert de responsabilités Android vers le profil `520` et sans création d'artefact Maven, skeleton ou audit artificiel.
## Baseline opérateur
Avant la gate de `alpha.2`, le history `PASS` de `alpha.1` a été ajouté au commit puis publié :
```text
commit alpha.1 46a159a
branche distante 4893a04..46a159a master -> master
```
La gate de `alpha.2` a ensuite confirmé :
```text
VERSION 0.1.2-alpha.2
history/0.1.2/alpha.1.md présent dans HEAD et workspace
deltas/0.1.2/alpha.2.md présent
history/0.1.2/alpha.2.md absent pendant la gate
plan 008 version 2
520-JAVA_MAVEN_GRADLE.md version 3
610-ANDROID.md version 2
history alpha.1 PASS
```
## Tests Python
La suite complète a affiché :
```text
Ran 48 tests in 0.683s
OK
```
Soit `48/48` tests `PASS`.
## Audits Markdown
Les audits ont affiché :
```text
Markdown header audit: clean (235 file(s))
Markdown table audit: clean (10 table(s), 235 file(s))
Markdown link audit: clean (273 local link(s), 235 file(s))
```
## Gate Java / Gradle
Le contrôle spécifique de la tranche a terminé proprement :
```text
0.1.2 alpha.2 Java/Gradle audit: clean (JDK/source/bytecode explicit, Gradle ownership and system-version verification clarified, Android boundary preserved)
```
Il confirme notamment :
- la séparation explicite entre JDK de build, niveau source et bytecode/runtime supporté ;
- l'ownership de `settings.gradle(.kts)`, du build root, des modules et des propriétés partagées ;
- l'exigence d'une contrainte effectivement vérifiée lorsqu'un Gradle système est retenu ;
- le caractère conditionnel du Wrapper et du version catalog ;
- le maintien de Groovy DSL et Kotlin DSL comme choix reconnus ;
- le maintien de `610-ANDROID.md` en révision `2` pendant cette tranche ;
- l'absence de nouvel artefact Maven, skeleton ou audit Java/Gradle.
## 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 VERSION
A deltas/0.1.2/alpha.2.md
M docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
M docs/rules/520-JAVA_MAVEN_GRADLE.md
```
Le scope correspond exactement au delta annoncé.
## Décision
`0.1.2-alpha.2` est `PASS`. Aucun `alpha.2.fix.N` n'est requis.
La préparation de la réconciliation `beta.1` doit néanmoins confronter la structure documentaire obtenue à `500-LANGUAGES.md` et à `docs/architecture/003-RULE_PROFILE_MODEL.md`, comme prévu par le plan. Un `PASS` de la gate `alpha.2` valide son contenu ; il n'interdit pas un REPLAN si cette réconciliation révèle une ambiguïté d'ownership distincte du scope validé.

111
history/0.1.2/alpha.3.md Normal file
View File

@@ -0,0 +1,111 @@
<!-- file: history/0.1.2/alpha.3.md -->
<!-- version: 1 -->
# 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.

101
history/0.1.2/beta.1.md Normal file
View File

@@ -0,0 +1,101 @@
<!-- file: history/0.1.2/beta.1.md -->
<!-- version: 1 -->
# History 0.1.2-beta.1 — réconciliation intégrée Java / Maven / Gradle
## Statut
PASS
La gate opérateur de `0.1.2-beta.1` exécutée le `2026-09-28` a réussi. Elle confirme que les owners Java, Maven et Gradle issus de la scission restent indépendants et composables, que les choix locaux Games ne deviennent pas des minima PGR, qu'aucun artefact technique supplémentaire n'est justifié et que le scope Android reste réservé à `0.1.3`.
## Baseline opérateur
La tranche `0.1.2-alpha.3` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `beta.1` :
```text
commit 226d61b
message 0.1.2-alpha.3
push origin/master PASS
```
Après application de `beta.1`, les contrôles initiaux ont confirmé :
```text
VERSION 0.1.2-beta.1
history/0.1.2/alpha.3.md présent dans HEAD et le workspace
deltas/0.1.2/beta.1.md présent
history/0.1.2/beta.1.md absent pendant la gate
README.md version 21
docs/000-README.md version 34
docs/architecture/003-RULE_PROFILE_MODEL.md version 8
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md version 4
docs/rules/520-JAVA.md version 4
docs/rules/521-MAVEN.md version 1
docs/rules/522-GRADLE.md version 1
docs/rules/520-JAVA_MAVEN_GRADLE.md version 4
docs/rules/610-ANDROID.md version 3
```
Le history `alpha.3` a été retrouvé avec statut `PASS`.
## Réconciliation Java / Maven / Gradle
La gate spécifique a affiché :
```text
0.1.2 beta.1 reconciliation audit: clean (owners stable, Games-local choices not generalized, no extra artifacts justified, Android boundary preserved)
```
Elle confirme notamment :
- `520-JAVA.md` possède Java indépendamment du build tool ;
- `521-MAVEN.md` ne s'applique que lorsque Maven est réellement utilisé et n'est pas présenté comme éprouvé par Games ;
- `522-GRADLE.md` ne s'applique que lorsque Gradle est réellement utilisé ;
- l'ancien `520-JAVA_MAVEN_GRADLE.md` reste un bridge `SUPERSEDED` non sélectionnable ;
- JDK 25, `source/target 17`, Gradle `9.6.0`, Gradle `9.7.1` et AGP `9.4.0` ne deviennent pas des minima des owners Java/Maven/Gradle ;
- les responsabilités Android restent possédées par `610-ANDROID.md` ;
- aucun nouveau contrat `docs/validation/`, template, skeleton, audit Python Java/Maven/Gradle ou artefact Maven n'est justifié.
Les quatre chemins Knowledge introduits accidentellement pendant la chaîne antérieure restent absents après le recovery `alpha.2.fix.1`.
## Tests et audits PGR
La suite Python globale a exécuté `48` tests, tous réussis :
```text
Ran 48 tests in 0.787s
OK
```
Les audits documentaires sont propres :
```text
Markdown header audit: clean (244 file(s))
Markdown table audit: clean (10 table(s), 244 file(s))
Markdown link audit: clean (295 local link(s), 244 file(s))
```
## Contrôles Git
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
Le statut indexé transmis avant ajout du présent history est exactement :
```text
M README.md
M VERSION
A deltas/0.1.2/beta.1.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
```
Le scope correspond exactement au delta `beta.1`. Aucun owner `520/521/522`, bridge historique, profil Android, template, skeleton, contrat de validation ou script d'audit n'a été modifié par cette tranche.
## Décision
`0.1.2-beta.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
La release peut entrer en `0.1.2-rc.1` pour geler le scope, préparer le changelog candidat, rejouer le release gate complet et préparer le prompt de reprise `0.1.3` sans démarrer la réévaluation Android avant publication vérifiée de `v0.1.2`.

129
history/0.1.2/rc.1.md Normal file
View File

@@ -0,0 +1,129 @@
<!-- file: history/0.1.2/rc.1.md -->
<!-- version: 1 -->
# History 0.1.2-rc.1 — release candidate Java / Maven / Gradle
## Statut
PASS
La gate opérateur de `0.1.2-rc.1` exécutée le `2026-09-28` a réussi. Elle confirme le gel des owners Java, Maven et Gradle, l'intégrité des histories antérieurs, le changelog candidat, le prompt de reprise `009`, les tests Python, les audits Markdown et l'hygiène texte/templates avant promotion stable.
## Baseline opérateur
La tranche `0.1.2-beta.1` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `rc.1` :
```text
commit 4dcb0dd
message 0.1.2-beta.1
push origin/master PASS
```
Après application du delta `rc.1`, les contrôles initiaux ont confirmé :
```text
VERSION 0.1.2-rc.1
history/0.1.2/beta.1.md présent dans HEAD et le workspace
deltas/0.1.2/rc.1.md présent
prompts/009-V0_1_3_START_PROMPT.md présent
history/0.1.2/rc.1.md absent pendant la gate
CHANGELOG.md version 14
docs/000-README.md version 35
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md version 5
ROADMAP.md version 13
prompts/009-V0_1_3_START_PROMPT.md version 1
docs/rules/520-JAVA.md version 4
docs/rules/521-MAVEN.md version 1
docs/rules/522-GRADLE.md version 1
docs/rules/520-JAVA_MAVEN_GRADLE.md version 4
docs/rules/610-ANDROID.md version 3
```
Le history `beta.1` a été retrouvé avec statut `PASS`.
## Gate d'intégration RC
Le contrôle structurel a affiché :
```text
0.1.2 rc.1 integration audit: clean (5 prior histories, frozen Java/Maven/Gradle owners, candidate changelog and prompt 009 verified, Android boundary preserved)
```
Il a vérifié les cinq histories antérieurs avec statut `PASS` :
```text
alpha.1 PASS
alpha.2 PASS
alpha.2.fix.1 PASS
alpha.3 PASS
beta.1 PASS
```
Avant application du présent history, `rc.1.md` est la seule tranche `0.1.2` possédant un delta sans history.
La gate a également confirmé :
- le `CHANGELOG` candidat `0.1.2` sans détails de tranches ;
- `520-JAVA`, `521-MAVEN` et `522-GRADLE` comme owners gelés et l'ancien owner combiné comme bridge `SUPERSEDED` non sélectionnable ;
- l'absence de généralisation de JDK 25, Java 17, Gradle 9.6.0/9.7.1 ou AGP 9.4.0 ;
- le maintien des responsabilités Android dans `610-ANDROID.md` ;
- la roadmap `0.1.2` à `0.1.7` sans réservation de `0.1.8` ;
- le `DEFER` du skeleton Tauri jusqu'au réexamen `0.1.4` ;
- le prompt `009` ciblant `0.1.3-alpha.1` uniquement depuis une future archive du tag `v0.1.2` et son rapport post-tag réel ;
- l'absence de template, skeleton, validation ou audit Python Java/Maven/Gradle supplémentaire ;
- l'absence persistante des chemins Knowledge introduits accidentellement puis retirés par `alpha.2.fix.1`.
## Tests et audits PGR
La suite Python globale a exécuté `48` tests, tous réussis :
```text
Ran 48 tests in 0.732s
OK
```
Les audits documentaires sont propres :
```text
Markdown header audit: clean (247 file(s))
Markdown table audit: clean (10 table(s), 247 file(s))
Markdown link audit: clean (307 local link(s), 247 file(s))
```
L'hygiène texte/templates a également réussi :
```text
0.1.2 rc.1 text/template hygiene: clean
```
Les templates TOML Rust/Cargo et JSON Web ont été parsés ; aucun retour chariot, whitespace final ni fichier texte sans newline finale n'a été détecté dans le corpus contrôlé.
## Contrôles Git
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
Le statut indexé transmis avant ajout du présent history est exactement :
```text
M CHANGELOG.md
M VERSION
A deltas/0.1.2/rc.1.md
M docs/000-README.md
M docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
A prompts/009-V0_1_3_START_PROMPT.md
```
Le scope correspond exactement à la RC annoncée. Aucun owner Java/Maven/Gradle, bridge historique, profil Android, template, skeleton, validation ou script d'audit n'a été modifié pendant la RC.
## Décision
`0.1.2-rc.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
La transition autorisée est la promotion mécanique pré-tag :
```text
0.1.2-rel.1
```
Cette promotion ne doit pas rouvrir le scope fonctionnel. Elle doit uniquement présenter `0.1.2` comme stable, produire sa propre gate pré-tag et préparer le handoff de publication sans anticiper le rapport post-tag.

151
history/0.1.2/rel.1.md Normal file
View File

@@ -0,0 +1,151 @@
<!-- file: history/0.1.2/rel.1.md -->
<!-- version: 1 -->
# History 0.1.2-rel.1 — promotion stable pré-tag
## Statut
PASS
La gate opérateur de `0.1.2-rel.1` exécutée le `2026-09-28` a réussi. Elle confirme la promotion mécanique de la release candidate vers la stable `0.1.2`, la cohérence des histories antérieurs, la présentation stable Java/Maven/Gradle, les tests PGR, les audits documentaires et l'hygiène texte/templates avant création du tag.
## Baseline opérateur
La tranche `0.1.2-rc.1` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `rel.1` :
```text
commit 36b2b21
message 0.1.2-rc.1
push origin/master PASS
```
Après application du delta `rel.1`, les contrôles initiaux ont confirmé :
```text
VERSION 0.1.2
history/0.1.2/rc.1.md présent dans HEAD et le workspace
deltas/0.1.2/rel.1.md présent
prompts/009-V0_1_3_START_PROMPT.md présent
history/0.1.2/rel.1.md absent pendant la gate
README.md version 22
ROADMAP.md version 14
CHANGELOG.md version 15
docs/000-README.md version 36
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md version 6
```
Le history `rc.1` a été retrouvé avec statut `PASS`.
La présentation stable est établie :
```text
ROADMAP.md 0.1.2 marqué terminé
CHANGELOG.md entrée `## 0.1.2` sans suffixe `(candidate)`
README.md owners Java, Maven et Gradle séparés et composables
docs index plan 008 classé historique
```
## Gate stable pré-tag
Le contrôle structurel a affiché :
```text
0.1.2 rel.1 stable gate audit: clean (6 prior histories, rel.1 pending, stable Java/Maven/Gradle presentation and post-tag handoff coherent)
```
Il a vérifié les six histories antérieurs avec statut `PASS` :
```text
alpha.1 PASS
alpha.2 PASS
alpha.2.fix.1 PASS
alpha.3 PASS
beta.1 PASS
rc.1 PASS
```
Avant application du présent history, `rel.1.md` est la seule tranche `0.1.2` possédant un delta sans history.
La gate a également confirmé :
- `0.1.2` terminé dans la roadmap ;
- `0.1.3` à `0.1.7` engagés sans réservation de `0.1.8` ;
- le `CHANGELOG` stable sans suffixe `(candidate)` et sans détails de tranches ;
- le plan `008` classé historique ;
- `520-JAVA`, `521-MAVEN` et `522-GRADLE` gelés dans leur état validé ;
- l'ancien `520-JAVA_MAVEN_GRADLE` conservé uniquement comme bridge `SUPERSEDED` non sélectionnable ;
- l'absence de généralisation des choix Games locaux tels que JDK 25, Java 17, Gradle 9.6.0/9.7.1 ou AGP 9.4.0 ;
- le maintien des responsabilités Android dans `610-ANDROID.md` et de la réévaluation Android dans `0.1.3` ;
- le skeleton Tauri toujours réservé au réexamen `0.1.4` et l'adoption Games à `0.1.5` ;
- le prompt `009` préparé pour démarrer `0.1.3` uniquement depuis le tag réel `v0.1.2` et un rapport post-tag `publish.001` `PASS` ;
- l'absence de template, skeleton, validation ou audit Python Java/Maven/Gradle supplémentaire ;
- l'absence persistante des chemins Knowledge retirés par `alpha.2.fix.1` ;
- la convention de clôture `rel.N`, puis commit stable `X.Y.Z` avant création du tag.
## Validation Java/Maven/Gradle
Les preuves Java/Gradle issues du corpus Games ont été réconciliées avant la RC et les owners correspondants n'ont pas été modifiés pendant `rel.1`.
La promotion stable n'a donc pas simulé de toolchain Java, Maven ou Gradle absente du dépôt PGR. Elle a rejoué les gates réellement possédées par PGR afin de vérifier que la promotion documentaire et les métadonnées de release n'ont invalidé aucune propriété du référentiel.
Aucun corpus Maven réel n'a été inventé pour justifier un artefact supplémentaire, et aucun scope Android n'a été absorbé dans `0.1.2`.
## Tests et audits PGR
La suite Python globale a exécuté `48` tests, tous réussis :
```text
Ran 48 tests in 0.745s
OK
```
Les audits documentaires sont propres :
```text
Markdown header audit: clean (249 file(s))
Markdown table audit: clean (10 table(s), 249 file(s))
Markdown link audit: clean (307 local link(s), 249 file(s))
```
L'hygiène texte/templates a également affiché :
```text
0.1.2 rel.1 text/template hygiene: clean
```
Les templates TOML Rust/Cargo et JSON Web ont été parsés avec succès ; aucun retour chariot, whitespace final ni fichier texte sans newline finale n'a été détecté dans le corpus contrôlé.
## Contrôles Git
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
Le statut indexé transmis avant ajout du présent history est exactement :
```text
M CHANGELOG.md
M README.md
M ROADMAP.md
M VERSION
A deltas/0.1.2/rel.1.md
M docs/000-README.md
M docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
```
Le scope correspond exactement à la promotion stable annoncée. Aucun owner Java/Maven/Gradle, bridge historique, profil Android, template, skeleton, validation ou script d'audit n'a été modifié pendant `rel.1`.
## Décision
`0.1.2-rel.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
Conformément à la convention stable PGR, le présent history doit être inclus dans le commit final nommé exactement :
```text
0.1.2
```
Le commit stable doit être poussé sur `origin/master` avant création du tag annoté `v0.1.2`.
Le rapport `pgr-0.1.2-publish.001-report.md` ne pourra être produit qu'après réception des preuves post-publication réelles : identité du commit stable, propreté du workspace, objet et cible déréférencée du tag local, références distantes du tag et archive ZIP téléchargée depuis le tag Gitea.
Le prompt `009-V0_1_3_START_PROMPT.md` ne devient la reprise effective de `0.1.3` qu'après un rapport post-tag `PASS`.

View File

@@ -0,0 +1,4 @@
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

View File

@@ -0,0 +1,92 @@
<!-- file: prompts/009-V0_1_3_START_PROMPT.md -->
<!-- version: 1 -->
# Prompt de démarrage 0.1.3 — réévaluation pratique Android
## Baseline et cible
Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`.
La baseline attendue au démarrage effectif de `0.1.3` est l'archive source téléchargée depuis le tag Gitea `v0.1.2`, accompagnée du rapport post-tag `pgr-0.1.2-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`.
Version cible : `0.1.3`. Première tranche attendue : `0.1.3-alpha.1`.
Le corpus principal attendu pour confronter Android à un projet réel est une archive autoritaire récente de `sasedev-games`. Si aucune baseline plus récente n'est explicitement fournie, la baseline de référence déjà auditée reste :
```text
games-v0.3.6.zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
```
Une archive source peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu'elle ne peut contenir.
## Reprise manuelle après publication
Après vérification réelle de l'archive du tag `v0.1.2` et du rapport post-tag `PASS`, la consigne de nouvelle session doit suivre le pattern de [`../docs/templates/003-NEW_SESSION_PROMPT.md`](../docs/templates/003-NEW_SESSION_PROMPT.md) et citer les artefacts réellement obtenus.
La forme attendue, si les noms et le statut sont confirmés, est :
```text
Partir de l'archive pgr-v0.1.2.zip téléchargée depuis le tag Gitea v0.1.2 et du rapport post-tag pgr-0.1.2-publish.001-report.md. Lire et exécuter prompts/009-V0_1_3_START_PROMPT.md. Vérifier intégralement la stable PGR, puis réévaluer le profil Android à partir du corpus Games autoritaire avant de préparer 0.1.3-alpha.1, sans absorber le scope Tauri réservé à 0.1.4 ni les décisions produit propres aux jeux/SDL.
```
Ce texte ne doit pas être remis comme preuve de publication avant le `publish.001 PASS` réel.
## Mission
Réévaluer pratiquement [`../docs/rules/610-ANDROID.md`](../docs/rules/610-ANDROID.md) à partir du corpus Games réellement fourni, en composant explicitement les owners Java et Gradle stabilisés par `0.1.2`, puis matérialiser uniquement les règles, validations, templates ou skeletons Android génériques dont la valeur réutilisable est démontrée.
`alpha.1` MUST commencer par :
1. auditer indépendamment la stable `v0.1.2` et son rapport post-tag lorsqu'il est fourni ;
2. auditer le corpus Games réellement fourni, en particulier sa structure `Android/`, sa matrice AGP/Gradle/JDK, ses SDK/NDK/ABI/JNI, manifests/resources, packaging et preuves opérateur historiques ;
3. relire `610-ANDROID.md`, [`../docs/rules/520-JAVA.md`](../docs/rules/520-JAVA.md), [`../docs/rules/522-GRADLE.md`](../docs/rules/522-GRADLE.md), [`../docs/rules/600-PLATFORMS.md`](../docs/rules/600-PLATFORMS.md) et [`../docs/studies/003-V0_1_0_HORIZON_REVIEW.md`](../docs/studies/003-V0_1_0_HORIZON_REVIEW.md) ;
4. créer le plan `0.1.3` avant toute normalisation importante ;
5. classifier les décisions observées avec `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` plutôt que copier Games dans PGR.
## Questions à instruire
La release doit notamment réexaminer :
- structure Android dans un dépôt exclusivement Android versus multi-plateforme, sans imposer artificiellement `Android/` lorsque le dépôt n'en a pas besoin ;
- composition réelle avec Java et Gradle sans rendre Java obligatoire pour tout projet Android ni réabsorber les owners `520/522` dans `610` ;
- matrice Android Gradle Plugin / Gradle / JDK et forme de contrainte la moins restrictive réellement compatible ;
- séparation entre `compileSdk`, `targetSdk` et `minSdk`, avec justification produit/compatibilité plutôt que copie des valeurs Games ;
- Android SDK, NDK et toolchains natives uniquement lorsqu'elles sont réellement applicables ;
- ABI, JNI, bibliothèques natives, packaging et frontières de responsabilité entre Android, langage natif et produit ;
- manifests, resources, namespaces/application IDs, variantes et configuration de build ;
- signing, secrets, keystores et propriétés locales, avec séparation stricte entre configuration versionnée et état machine sensible ;
- outputs/caches Android/Gradle, `local.properties` et autres états locaux à exclure de Git ;
- packaging APK/AAB, bundles de release et contrôles réellement nécessaires ;
- Android Lint, tests JVM/instrumentés, installation sur device/AVD et smokes, sélectionnés proportionnellement au changement ;
- contraintes de distribution modernes telles que l'alignement mémoire/16 KB uniquement lorsqu'elles sont démontrées par une exigence Android réelle et possédées au bon niveau ;
- nécessité éventuelle d'un contrat de validation ou skeleton Android, sans en créer un par symétrie si le profil et les outils officiels suffisent.
## Frontières obligatoires
`0.1.3` MUST NOT :
- migrer Games vers PGR ;
- transformer SDL3, la logique des jeux, leurs Activities concrètes ou leur architecture produit en règles Android générales ;
- rouvrir Java/Maven/Gradle `0.1.2` sauf défaut transversal réellement démontré ;
- réexaminer ou créer le skeleton Tauri, réservé à `0.1.4` ;
- absorber les contraintes Android propres à Tauri dans le profil Android général sans preuve indépendante ;
- démarrer l'adoption Games `0.1.5` ;
- créer un owner WASM, serveur Rust ou deployment/operations par proximité ;
- réserver une nouvelle release au-delà de la roadmap engagée sans nouvelle revue d'horizon justifiée.
Une contrainte observée uniquement à cause de SDL, d'un moteur de jeu, de Tauri ou d'une chaîne JNI particulière doit rester classifiée comme responsabilité produit/framework/spécialisation lorsqu'elle n'est pas générique à Android.
## Principes
- Partir des responsabilités réellement exercées par Games, pas d'un catalogue théorique Android.
- Les versions AGP, Gradle, JDK, SDK et NDK du corpus ne deviennent pas des `MUST` PGR sans preuve générique.
- Utiliser les outils Android/Gradle officiels lorsqu'une validation porte sur un artefact exécutable réel ; un audit Python read-only ne remplace ni Gradle, ni Android Lint, ni les toolchains SDK/NDK, ni une preuve device lorsque celle-ci est réellement requise.
- Ne pas imposer un Wrapper, une ABI, un device/AVD, une variante ou une commande `clean` par cérémonie.
- Conserver la distinction `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` afin de préparer l'adoption Games `0.1.5` sans la commencer.
- Conserver une frontière nette avec Tauri afin que `0.1.4` puisse réexaminer son propre `DEFER` avec la stable Android alors disponible.
## Workflow
Suivre [`../RULES.md`](../RULES.md), [`../docs/rules/210-WORKFLOW.md`](../docs/rules/210-WORKFLOW.md), [`../docs/rules/230-ADOPTION.md`](../docs/rules/230-ADOPTION.md) et [`../docs/rules/400-VALIDATION.md`](../docs/rules/400-VALIDATION.md).
La séquence reste : delta → gate opérateur → history constaté → application du history → commit/push → delta suivant. Les commandes de handoff sont remises automatiquement conformément à [`../docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`](../docs/templates/006-OPERATOR_COMMAND_HANDOFF.md).