0.1.2-alpha.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 19 -->
|
||||
<!-- version: 20 -->
|
||||
|
||||
# Project Governance Rules
|
||||
|
||||
@@ -11,7 +11,7 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.
|
||||
|
||||
## 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 et avec `0.1.1` d’une fondation frontend Web stable, composable et indépendante du host. La release `0.1.2` est ouverte pour réévaluer pratiquement le profil Java/Maven/Gradle à partir de Games, sans absorber le scope Android 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`.
|
||||
|
||||
@@ -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/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/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md`](docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md) — plan actif de réévaluation Java/Maven/Gradle `0.1.2`, fondé sur le corpus Games et borné avant Android `0.1.3` ;
|
||||
- [`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/001-PROJECT_GOVERNANCE_FOUNDATION.md`](docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation composable de gouvernance locale pour un projet adoptant PGR ;
|
||||
|
||||
235
deltas/0.1.2/alpha.1.md
Normal file
235
deltas/0.1.2/alpha.1.md
Normal 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`.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 31 -->
|
||||
<!-- version: 32 -->
|
||||
|
||||
# Documentation PGR
|
||||
|
||||
@@ -20,6 +20,14 @@ 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.
|
||||
|
||||
## Points d'entrée de 0.1.2
|
||||
|
||||
- [`plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md`](plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md) — plan actif de réévaluation pratique du profil Java/Maven/Gradle à partir du corpus Games autoritaire, avec classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` et frontière Android explicite.
|
||||
- [`rules/520-JAVA_MAVEN_GRADLE.md`](rules/520-JAVA_MAVEN_GRADLE.md) — owner existant à éprouver et corriger seulement sur les ambiguïtés réellement démontrées par Games.
|
||||
- [`rules/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`.
|
||||
|
||||
## 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.
|
||||
|
||||
374
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
Normal file
374
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
Normal file
@@ -0,0 +1,374 @@
|
||||
<!-- file: docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Plan 0.1.2 — réévaluation Java / Maven / Gradle
|
||||
|
||||
## Statut et sources
|
||||
|
||||
Plan actif 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.
|
||||
|
||||
## 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 uniquement les ambiguïtés ou lacunes démontrées par Games ;
|
||||
- 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 candidats
|
||||
|
||||
Artefact certain :
|
||||
|
||||
```text
|
||||
docs/rules/520-JAVA_MAVEN_GRADLE.md révision ciblée si alpha.2 confirme les précisions ci-dessus
|
||||
```
|
||||
|
||||
Artefacts conditionnels seulement si une lacune réelle apparaît pendant la révision :
|
||||
|
||||
```text
|
||||
docs/validation/... uniquement si les commandes déjà présentes dans 520 sont insuffisantes comme contrat réutilisable
|
||||
docs/templates/... uniquement si un fichier générique possède assez de décisions stables pour être adapté sans copier Android
|
||||
scripts/audit_*.py uniquement pour une propriété statique générique non déjà contrôlée par Java/Gradle
|
||||
```
|
||||
|
||||
Aucun skeleton Java/Gradle ni artefact Maven nouveau n'est prévu par défaut.
|
||||
|
||||
## 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.
|
||||
|
||||
### beta.1 — réconciliation et décision d'artefacts
|
||||
|
||||
Relire le profil révisé contre Games, `500-LANGUAGES.md`, `610-ANDROID.md` et les règles générales de validation. Vérifier qu'aucun choix local Games ou contrainte Android n'est devenu un `MUST` général.
|
||||
|
||||
À 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.
|
||||
|
||||
### rc.1 — release candidate
|
||||
|
||||
Geler le scope, rejouer la validation PGR complète, contrôler les liens/index, la frontière Android, l'absence d'artefacts Maven non justifiés et la cohérence de la trajectoire `0.1.3` à `0.1.7`.
|
||||
|
||||
Aucune nouvelle règle fonctionnelle n'entre en RC sauf correctif `.fix.N` ou REPLAN explicitement justifié.
|
||||
|
||||
### rel.1 — promotion stable
|
||||
|
||||
Promouvoir mécaniquement la RC validée vers `0.1.2`, fermer le plan, mettre à jour `CHANGELOG.md` et `ROADMAP.md` selon le workflow applicable, préparer le handoff de publication et conserver la prochaine cible engagée `0.1.3` sans l'exécuter avant vérification post-tag de `0.1.2`.
|
||||
|
||||
## Stratégie de validation
|
||||
|
||||
`alpha.1` reste documentaire et structurel : tests Python PGR, audits Markdown, contrôle des couples delta/history, vérification du prompt `008`, de `520`, de `610`, du plan et du scope Git.
|
||||
|
||||
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`, la fermeture du plan et la préparation de la publication sont traités en beta/RC/`rel.1` selon l'état réel de la release.
|
||||
|
||||
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.
|
||||
98
history/0.1.2/alpha.1.md
Normal file
98
history/0.1.2/alpha.1.md
Normal 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.
|
||||
Reference in New Issue
Block a user