0.1.3-alpha.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 22 -->
|
||||
<!-- version: 23 -->
|
||||
|
||||
# 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, 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`.
|
||||
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. La release `0.1.3-alpha.1` ouvre maintenant la réévaluation pratique du profil Android à partir de la baseline Games autoritaire, sans absorber Tauri ni l’adoption Games.
|
||||
|
||||
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`.
|
||||
|
||||
@@ -32,6 +32,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
|
||||
- [`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 historique de la stable `0.1.2` : réévaluation Games, scission Java/Maven/Gradle et maintien d'Android hors scope ;
|
||||
- [`docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan actif de la réévaluation pratique Android `0.1.3`, fondé sur Games avec classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
|
||||
- [`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 ;
|
||||
|
||||
247
deltas/0.1.3/alpha.1.md
Normal file
247
deltas/0.1.3/alpha.1.md
Normal file
@@ -0,0 +1,247 @@
|
||||
<!-- file: deltas/0.1.3/alpha.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.3-alpha.1 — audit de stable et cadrage Android
|
||||
|
||||
## Baseline et sources
|
||||
|
||||
Baseline PGR autoritaire : archive source téléchargée depuis le tag Gitea `v0.1.2`, accompagnée du rapport externe `pgr-0.1.2-publish.001-report.md` avec statut `PASS`.
|
||||
|
||||
SHA-256 vérifiés sur les fichiers réellement fournis :
|
||||
|
||||
```text
|
||||
pgr-v0.1.2(1).zip 0ef8facab0c6f92ca427f5f13d38d6c4a4c1cc16174a20ecdab48991bd88d0e6
|
||||
pgr-0.1.2-publish.001-report.md 0f6b4e2a685a957fa647a7db009320ada0fc67948737d8344cc3773bcaeb6a9c
|
||||
games-v0.3.6(2).zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
|
||||
```
|
||||
|
||||
Les archives locales PGR et Games comportent respectivement `(1)` et `(2)` dans leur nom, mais leurs empreintes correspondent exactement aux baselines canoniques `pgr-v0.1.2.zip` et `games-v0.3.6.zip` attendues par le rapport/prompt.
|
||||
|
||||
Version avant application :
|
||||
|
||||
```text
|
||||
0.1.2
|
||||
```
|
||||
|
||||
Version après application :
|
||||
|
||||
```text
|
||||
0.1.3-alpha.1
|
||||
```
|
||||
|
||||
## Objet
|
||||
|
||||
Exécuter `prompts/009-V0_1_3_START_PROMPT.md` : vérifier intégralement la stable `v0.1.2` et son rapport post-tag, auditer le corpus Games autoritaire sur Android et ses preuves historiques, relire `610-ANDROID.md`, `520-JAVA.md`, `522-GRADLE.md`, `600-PLATFORMS.md`, la validation générale et la revue d'horizon, puis créer le plan `0.1.3` avant toute normalisation Android importante.
|
||||
|
||||
`alpha.1` reste un gate de cadrage. Aucune règle Android, règle Java/Gradle, 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/`, `316` entrées, `276` fichiers, `40` répertoires, aucun symlink, absence normale de `.git` et `VERSION=0.1.2`.
|
||||
|
||||
Le rapport `publish.001` est `PASS` et confirme le commit stable `585b508578aae337f6940110d4ca47c694a052d5`, l'objet tag annoté `cea2c7a06cde844ffa7411f73bb22685a3214414` et la déréférence de `v0.1.2` vers le commit stable.
|
||||
|
||||
La suite PGR donne `48/48` tests `PASS`. Les audits Markdown sont propres : `250` fichiers pour les headers, `10` tables sur `250` fichiers et `307` liens locaux sur `250` fichiers. Les templates TOML Rust/Cargo et JSON Web contrôlés sont parsables.
|
||||
|
||||
Les `90` couples delta/history de `0.0.1` à `0.1.2` sont complets. Les sept histories `0.1.2` sont tous `PASS`, y compris `alpha.2.fix.1` qui conserve la récupération historique de contamination inter-projet.
|
||||
|
||||
Le corpus Games fourni possède exactement le SHA canonique attendu, `652` entrées, `502` fichiers, `150` répertoires et aucun symlink. Ses audits statiques principaux sont propres : règles Rust, exports, workspace, tableaux Markdown et layout de distribution.
|
||||
|
||||
Le sous-projet Android natif exerce un build Gradle multi-module sous `Android/` avec `common`, `game-reflex-poc` et `game-snake-poc`, quatre sources Java, manifests/resources, namespaces/application IDs, configuration locale ignorée et scripts Gradle communs.
|
||||
|
||||
La baseline Games utilise AGP `9.4.0`, Gradle système `>= 9.6.0`, JDK de build compatible `>= 17`, niveau Java source/target `17`, `compileSdk 36`, `targetSdk 36`, `minSdk 21`, NDK `28.2.13676358` et SDL3 `3.4.16`. Ces valeurs restent des décisions et preuves Games, pas des minima PGR.
|
||||
|
||||
Les histories Games démontrent le passage d'une preuve initiale Wrapper/JDK 17 vers un Gradle système avec minimum exécutable et JDK courant, puis des builds réels avec Temurin `25.0.4.1 LTS` + Gradle `9.7.1` tout en conservant Java `17` comme niveau source/target.
|
||||
|
||||
Le pipeline natif Games exerce `cargo ndk`, JNI, SDL3 et quatre ABI (`arm64-v8a`, `armeabi-v7a`, `x86_64`, `x86`). Les histories prouvent APK Debug, AAB Release, contenu natif packagé, smokes AVD x86_64 et appareil ARM64 réel, runtime API 21 ainsi qu'une preuve `PAGE_SIZE=16384` sur Android 15/API 35 x86_64.
|
||||
|
||||
Ces responsabilités spécialisées ne sont pas copiées dans PGR. Le plan classe les décisions avec `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, conserve Tauri en `DEFER` jusqu'à `0.1.4`, l'adoption Games jusqu'à `0.1.5` et prévoit une vérification des exigences Android officielles courantes avant toute normalisation de contraintes évolutives telles que 16 KB.
|
||||
|
||||
## Scope
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
README.md
|
||||
docs/000-README.md
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
|
||||
deltas/0.1.3/alpha.1.md
|
||||
```
|
||||
|
||||
DELETE : aucun.
|
||||
|
||||
`RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, `docs/rules/610-ANDROID.md`, `docs/rules/520-JAVA.md`, `docs/rules/522-GRADLE.md`, `docs/rules/600-PLATFORMS.md`, les autres règles, templates, skeletons, validations, scripts, studies, prompts et histories existants restent inchangés dans `alpha.1`.
|
||||
|
||||
Aucun `history/0.1.3/alpha.1.md` n'est anticipé avant la gate opérateur.
|
||||
|
||||
## Validation opérateur
|
||||
|
||||
Après application sur la stable `0.1.2`, depuis la racine du dépôt :
|
||||
|
||||
```bash
|
||||
test "$(cat VERSION)" = '0.1.3-alpha.1'
|
||||
test -f docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
|
||||
test -f deltas/0.1.3/alpha.1.md
|
||||
test ! -e history/0.1.3/alpha.1.md
|
||||
|
||||
grep -Fx '<!-- version: 23 -->' README.md
|
||||
grep -Fx '<!-- version: 37 -->' docs/000-README.md
|
||||
grep -F '009-V0_1_3_ANDROID_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,
|
||||
'0.1.2': 7,
|
||||
}
|
||||
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.2').glob('*.md'):
|
||||
text = path.read_text(encoding='utf-8')
|
||||
match = re.search(r'## Statut\s+(?:`?)(PASS|FAIL|PARTIAL|BLOCKED)', text)
|
||||
assert match is not None, path
|
||||
statuses[path.name] = match.group(1)
|
||||
assert len(statuses) == 7, statuses
|
||||
assert set(statuses.values()) == {'PASS'}, statuses
|
||||
assert statuses['alpha.2.fix.1.md'] == 'PASS'
|
||||
assert statuses['rel.1.md'] == 'PASS'
|
||||
|
||||
roadmap = Path('ROADMAP.md').read_text(encoding='utf-8')
|
||||
assert '- `(x) 0.1.2`' in roadmap
|
||||
for release in range(3, 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/009-V0_1_3_START_PROMPT.md').read_text(encoding='utf-8')
|
||||
for phrase in (
|
||||
'Version cible : `0.1.3`',
|
||||
'Première tranche attendue : `0.1.3-alpha.1`',
|
||||
'ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8',
|
||||
'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER',
|
||||
'structure `Android/`',
|
||||
'compileSdk`, `targetSdk` et `minSdk',
|
||||
'alignement mémoire/16 KB',
|
||||
'skeleton Tauri, réservé à `0.1.4`',
|
||||
"démarrer l'adoption Games `0.1.5`",
|
||||
):
|
||||
assert phrase in prompt, phrase
|
||||
|
||||
android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
|
||||
assert android.startswith('<!-- file: docs/rules/610-ANDROID.md -->\n<!-- version: 3 -->')
|
||||
for phrase in (
|
||||
'Android n\'implique pas à lui seul l\'applicabilité du profil Java.',
|
||||
'Matrice AGP / Gradle / JDK',
|
||||
'`compileSdk`, `targetSdk` et `minSdk`',
|
||||
'ABI et code natif',
|
||||
'Niveaux de tests Android',
|
||||
'APK, AAB et artefacts de distribution',
|
||||
):
|
||||
assert phrase in android, phrase
|
||||
|
||||
assert Path('docs/rules/520-JAVA.md').read_text(encoding='utf-8').startswith(
|
||||
'<!-- file: docs/rules/520-JAVA.md -->\n<!-- version: 4 -->'
|
||||
)
|
||||
assert Path('docs/rules/522-GRADLE.md').read_text(encoding='utf-8').startswith(
|
||||
'<!-- file: docs/rules/522-GRADLE.md -->\n<!-- version: 1 -->'
|
||||
)
|
||||
assert Path('docs/rules/600-PLATFORMS.md').read_text(encoding='utf-8').startswith(
|
||||
'<!-- file: docs/rules/600-PLATFORMS.md -->\n<!-- version: 1 -->'
|
||||
)
|
||||
|
||||
plan = Path('docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
|
||||
for phrase in (
|
||||
'Classification initiale des décisions Games',
|
||||
'`ADOPT`',
|
||||
'`KEEP-LOCAL`',
|
||||
'`OVERRIDE`',
|
||||
'`DEFER`',
|
||||
'alpha.2 — structure, composition et contrats Android de base',
|
||||
'alpha.3 — natif, packaging, distribution et validation',
|
||||
'beta.1 — réconciliation et décision d\'artefacts',
|
||||
'AGP `9.4.0`',
|
||||
'Gradle système `>= 9.6.0`',
|
||||
'NDK `r28c`',
|
||||
'PAGE_SIZE=16384',
|
||||
'documentation Android officielle courante',
|
||||
'0.1.4 — domaine Tauri',
|
||||
'0.1.5',
|
||||
):
|
||||
assert phrase in plan, phrase
|
||||
|
||||
assert not Path('docs/validation/006-ANDROID_VALIDATION.md').exists()
|
||||
assert not Path('history/0.1.3/alpha.1.md').exists()
|
||||
|
||||
print('0.1.3 alpha.1 structural audit: clean (90 prior pairs, Games Android classified, Tauri/adoption boundaries preserved)')
|
||||
PY
|
||||
|
||||
git diff --check
|
||||
git add VERSION README.md docs/000-README.md \
|
||||
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
|
||||
deltas/0.1.3/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.3/alpha.1.md
|
||||
M docs/000-README.md
|
||||
A docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
|
||||
```
|
||||
|
||||
La revue opérateur doit également confirmer que :
|
||||
|
||||
- `alpha.1` n'a pas modifié `610-ANDROID.md` avant validation du cadrage ;
|
||||
- les versions exactes Games (AGP/Gradle/JDK/SDK/NDK/SDL3) restent des preuves ou choix locaux, pas des contraintes PGR universelles ;
|
||||
- `Android/` reste une convention de séparation multi-plateforme et n'est pas imposé artificiellement à un dépôt Android-only ;
|
||||
- Java reste un owner composé seulement lorsqu'il existe réellement du code Java ;
|
||||
- les quatre ABI, JNI, `cargo ndk`, SDL3, Activities et assets Games restent des responsabilités produit/framework/spécialisation ;
|
||||
- aucune exigence 16 KB n'est normalisée sans vérification des sources Android officielles courantes ;
|
||||
- aucun nouveau template, audit, skeleton ou contrat de validation Android n'est créé par symétrie ;
|
||||
- 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.3/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.3-alpha.2` consacré à la structure, la composition et aux contrats Android de base définis par le plan, sans absorber encore les détails natifs/packaging de `alpha.3`.
|
||||
|
||||
Après remise du history, fournir automatiquement le bloc opérateur exact pour appliquer le history, committer/pusher `0.1.3-alpha.1`, puis seulement appliquer le delta suivant conformément à `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`.
|
||||
|
||||
### FAIL
|
||||
|
||||
Consigner le résultat réel dans le history, puis ouvrir `0.1.3-alpha.1.fix.1` ou un REPLAN selon la cause. Aucun changement prévu pour `alpha.2` ne doit être absorbé silencieusement dans le fix.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 36 -->
|
||||
<!-- version: 37 -->
|
||||
|
||||
# Documentation PGR
|
||||
|
||||
@@ -20,6 +20,15 @@ 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.3
|
||||
|
||||
- [`plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan actif de la réévaluation pratique Android, créé après audit de `v0.1.2` et du corpus Games autoritaire.
|
||||
- [`rules/610-ANDROID.md`](rules/610-ANDROID.md) — owner Android à réévaluer ; il reste inchangé dans `alpha.1` avant normalisation des décisions démontrées.
|
||||
- [`rules/520-JAVA.md`](rules/520-JAVA.md) et [`rules/522-GRADLE.md`](rules/522-GRADLE.md) — owners composés uniquement lorsqu'un projet Android contient réellement du Java ou utilise Gradle.
|
||||
- [`rules/600-PLATFORMS.md`](rules/600-PLATFORMS.md) et [`rules/400-VALIDATION.md`](rules/400-VALIDATION.md) — contrats généraux de plateforme et de preuve auxquels la spécialisation Android doit rester conforme.
|
||||
- [`studies/003-V0_1_0_HORIZON_REVIEW.md`](studies/003-V0_1_0_HORIZON_REVIEW.md) — revue ayant engagé Android `0.1.3`, Tauri `0.1.4` puis l'adoption Games `0.1.5` comme scopes distincts.
|
||||
- [`../prompts/009-V0_1_3_START_PROMPT.md`](../prompts/009-V0_1_3_START_PROMPT.md) — contrat de reprise exécuté pour ouvrir `0.1.3-alpha.1` après publication vérifiée de `v0.1.2`.
|
||||
|
||||
## 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.
|
||||
|
||||
459
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
Normal file
459
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
Normal file
@@ -0,0 +1,459 @@
|
||||
<!-- file: docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Plan 0.1.3 — réévaluation pratique Android
|
||||
|
||||
## Statut et sources
|
||||
|
||||
Plan actif de `0.1.3`, créé pendant `0.1.3-alpha.1` conformément à `prompts/009-V0_1_3_START_PROMPT.md`, après audit indépendant de la stable taggée `v0.1.2`, de son rapport post-tag `PASS` et du corpus Games autoritaire réellement fourni.
|
||||
|
||||
Sources autoritaires de reprise PGR réellement fournies :
|
||||
|
||||
```text
|
||||
pgr-v0.1.2(1).zip 0ef8facab0c6f92ca427f5f13d38d6c4a4c1cc16174a20ecdab48991bd88d0e6
|
||||
pgr-0.1.2-publish.001-report.md 0f6b4e2a685a957fa647a7db009320ada0fc67948737d8344cc3773bcaeb6a9c
|
||||
```
|
||||
|
||||
Le nom local de l'archive PGR comporte `(1)`, mais son SHA-256 correspond exactement à l'archive canonique `pgr-v0.1.2.zip` enregistrée par le rapport `publish.001`. Le rapport est `PASS`, porte sur cette même archive et confirme le commit stable `585b508578aae337f6940110d4ca47c694a052d5`. Le tag annoté `v0.1.2` possède l'objet tag `cea2c7a06cde844ffa7411f73bb22685a3214414` et se déréférence vers ce commit stable.
|
||||
|
||||
Corpus principal réellement fourni pour instruire Android :
|
||||
|
||||
```text
|
||||
games-v0.3.6(2).zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
|
||||
```
|
||||
|
||||
Le nom local comporte `(2)`, mais son SHA-256 correspond exactement à la baseline canonique `games-v0.3.6.zip` prévue par le prompt `009` et par le rapport de publication `0.1.2`. Games est donc le corpus Android autoritaire de cette réévaluation.
|
||||
|
||||
## Audit de la stable `v0.1.2`
|
||||
|
||||
### Intégrité de l'archive et preuve post-tag
|
||||
|
||||
L'archive stable contient `316` entrées sous une racine unique `pgr/`, soit `276` fichiers et `40` répertoires. 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.2`. `CHANGELOG.md` contient l'entrée stable `0.1.2`, `ROADMAP.md` marque `0.1.2` terminé et conserve `0.1.3` à `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.2
|
||||
tag v0.1.2
|
||||
publish.001 preuve externe post-tag PASS
|
||||
```
|
||||
|
||||
Le SHA de l'objet tag annoté reste distinct du commit stable ; la référence distante déréférencée pointe sur le même commit que `HEAD` et `origin/master` observés dans le rapport.
|
||||
|
||||
### Tests, audits et hygiène
|
||||
|
||||
La suite Python de la stable a été rejouée dans l'environnement d'analyse :
|
||||
|
||||
```text
|
||||
48 / 48 tests PASS
|
||||
```
|
||||
|
||||
Les audits documentaires donnent :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (250 file(s))
|
||||
Markdown table audit: clean (10 table(s), 250 file(s))
|
||||
Markdown link audit: clean (307 local link(s), 250 file(s))
|
||||
```
|
||||
|
||||
Les cinq templates TOML Rust/Cargo et les deux fichiers JSON Web contrôlés restent parsables.
|
||||
|
||||
### Chaîne delta/history et vérité opérateur
|
||||
|
||||
Les `90` deltas publiés de `0.0.1` à `0.1.2` disposent tous d'un history portant la même identité.
|
||||
|
||||
Pour `0.1.2`, la vérité opérateur est :
|
||||
|
||||
```text
|
||||
alpha.1 PASS
|
||||
alpha.2 PASS
|
||||
alpha.2.fix.1 PASS
|
||||
alpha.3 PASS
|
||||
beta.1 PASS
|
||||
rc.1 PASS
|
||||
rel.1 PASS
|
||||
```
|
||||
|
||||
La récupération de contamination inter-projet de `alpha.2.fix.1` reste conservée historiquement ; aucun des quatre chemins Knowledge accidentels n'est présent dans la stable publiée.
|
||||
|
||||
### Owners applicables avant réévaluation
|
||||
|
||||
La stable `0.1.2` possède des owners désormais séparés et composables :
|
||||
|
||||
```text
|
||||
520 Java
|
||||
521 Maven
|
||||
522 Gradle
|
||||
600 plateformes
|
||||
610 Android
|
||||
710 Tauri 2
|
||||
```
|
||||
|
||||
`610-ANDROID.md` est en révision interne `3`. Il compose déjà `522-GRADLE.md` lorsqu'un projet Android utilise Gradle et `520-JAVA.md` lorsqu'il contient du Java ; Android n'implique donc pas à lui seul l'applicabilité du profil Java.
|
||||
|
||||
La présente release réévalue les responsabilités Android elles-mêmes. Elle ne rouvre Java/Maven/Gradle que si un défaut transversal réellement démontré l'exige.
|
||||
|
||||
## 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 du workspace est `0.3.6` dans `Cargo.toml`. Games n'a pas encore effectué son adoption PGR réservée à `0.1.5` ; l'absence d'un fichier racine PGR `VERSION` n'est donc pas interprétée comme un défaut de la baseline.
|
||||
|
||||
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. Ils ne remplacent pas les preuves Gradle/Android historiques consignées par Games.
|
||||
|
||||
### Structure Android observée
|
||||
|
||||
Le sous-projet Android natif contient `20` fichiers versionnés sous `Android/` et forme un build Gradle multi-module séparé du workspace Cargo :
|
||||
|
||||
```text
|
||||
Android/
|
||||
├── common/
|
||||
├── game-reflex-poc/
|
||||
├── game-snake-poc/
|
||||
├── gradle/
|
||||
├── libs/
|
||||
├── build.gradle
|
||||
├── gradle.properties
|
||||
├── settings.gradle
|
||||
└── .gitignore
|
||||
```
|
||||
|
||||
Le choix `Android/` répond ici à une architecture réellement multi-plateforme. Il ne prouve pas qu'un dépôt exclusivement Android devrait ajouter artificiellement ce niveau.
|
||||
|
||||
Les modules exercent deux responsabilités différentes :
|
||||
|
||||
```text
|
||||
common Android Library partagée
|
||||
game-*-poc applications Android indépendantes
|
||||
```
|
||||
|
||||
Les noms exacts `common`, `game-reflex-poc` et `game-snake-poc` restent des décisions produit Games.
|
||||
|
||||
### Composition Java et Gradle
|
||||
|
||||
Le corpus contient quatre sources Java sous `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
|
||||
```
|
||||
|
||||
Java est donc réellement applicable à Games, mais son usage est une composition du projet Android et non une propriété universelle d'Android.
|
||||
|
||||
Le build Android utilise Gradle en Groovy DSL. L'ownership observé est cohérent avec `522-GRADLE.md` :
|
||||
|
||||
- `settings.gradle` possède modules, repositories et contrainte minimale Gradle ;
|
||||
- le `build.gradle` root possède la version AGP partagée ;
|
||||
- `gradle.properties` possède des propriétés partagées non secrètes ;
|
||||
- les modules possèdent leur configuration Android et leurs dépendances ;
|
||||
- les scripts sous `Android/gradle/` possèdent la logique commune d'assets et de build natif devenue trop importante pour être dupliquée.
|
||||
|
||||
### Matrice AGP / Gradle / JDK et niveau Java
|
||||
|
||||
La baseline courante déclare ou documente :
|
||||
|
||||
```text
|
||||
AGP 9.4.0
|
||||
Gradle >= 9.6.0
|
||||
JDK de build >= 17, non épinglé par le projet
|
||||
niveau Java source/target 17
|
||||
```
|
||||
|
||||
L'histoire Games exerce deux politiques successives : une preuve initiale avec Wrapper Gradle `9.6.0` et JDK `17`, puis une décision durable utilisant Gradle système avec minimum exécutable `>= 9.6.0` et le JDK courant de l'environnement.
|
||||
|
||||
Les gates ultérieures ont réellement utilisé Temurin `25.0.4.1 LTS` et Gradle `9.7.1` tout en conservant `source/target 17` pour la glue Java.
|
||||
|
||||
Cette trajectoire confirme la séparation entre JDK de build et niveau Java. Les valeurs exactes restent des preuves Games et ne deviennent pas des minima PGR universels.
|
||||
|
||||
### SDK Android et compatibilité produit
|
||||
|
||||
Les modules exercent :
|
||||
|
||||
```text
|
||||
compileSdk 36
|
||||
targetSdk 36
|
||||
minSdk 21
|
||||
```
|
||||
|
||||
`compileSdk`, `targetSdk` et `minSdk` remplissent des responsabilités distinctes dans le corpus. Games ne fournit aucune raison de coupler mécaniquement leur évolution.
|
||||
|
||||
Le `minSdk 21` est lié au contrat produit/toolchain de Games, notamment au support SDL3 retenu. Sa preuve historique inclut l'installation et le démarrage de Snake sur un AVD Android 5.0/API 21 x86.
|
||||
|
||||
Ces valeurs ne sont donc pas copiées comme defaults PGR ; elles servent à éprouver la nécessité de justifier les niveaux selon build, distribution, dépendances et compatibilité utilisateur.
|
||||
|
||||
### NDK, ABI, JNI et frontière native
|
||||
|
||||
Games exerce réellement un pipeline natif Rust/SDL3 :
|
||||
|
||||
```text
|
||||
NDK 28.2.13676358 / r28c
|
||||
cargo-ndk build Rust Android
|
||||
JNI bridge Java/Rust spécifique Games
|
||||
SDL3 AAR externe non vendorizé
|
||||
```
|
||||
|
||||
Les applications déclarent quatre ABI :
|
||||
|
||||
```text
|
||||
arm64-v8a
|
||||
armeabi-v7a
|
||||
x86_64
|
||||
x86
|
||||
```
|
||||
|
||||
Les preuves historiques montrent le build et le packaging des quatre ABI, mais cette liste répond au produit Games et à sa toolchain Rust/SDL3. PGR ne doit pas en déduire une liste universelle d'ABI Android.
|
||||
|
||||
La responsabilité Android générique porte sur la déclaration et la preuve des ABI supportées lorsqu'un projet possède du natif. Les détails JNI, `cargo ndk`, extraction SDL3, noms de bibliothèques, features Rust et staging généré restent des responsabilités de spécialisation ou du produit tant qu'aucun owner séparé n'est justifié.
|
||||
|
||||
### Manifests, resources, namespaces et identités applicatives
|
||||
|
||||
Les deux applications possèdent chacune :
|
||||
|
||||
```text
|
||||
src/main/AndroidManifest.xml
|
||||
src/main/res/values/strings.xml
|
||||
namespace
|
||||
applicationId
|
||||
```
|
||||
|
||||
Les manifests déclarent les Activities launcher réellement utilisées et aucune permission Android additionnelle n'est observée dans ces deux fichiers.
|
||||
|
||||
Les `namespace` et `applicationId` sont propres à chaque application. Leur forme concrète `com.sasedev.games.*`, les Activities et les labels appartiennent au produit Games ; la séparation de responsabilité entre namespace de code, identité applicative, manifest et resources est en revanche réutilisable.
|
||||
|
||||
### Version applicative
|
||||
|
||||
Les deux applications Games utilisent actuellement :
|
||||
|
||||
```text
|
||||
versionCode 2
|
||||
versionName 0.2.0
|
||||
```
|
||||
|
||||
alors que le workspace global vaut `0.3.6`.
|
||||
|
||||
Cette différence est légitime dans ce corpus : les applications Android ont leur propre identité de version produit. Elle confirme le caractère conditionnel de la règle PGR actuelle qui ne synchronise `VERSION` et `versionName` que lorsque l'application appartient réellement au même release train.
|
||||
|
||||
`versionCode` reste un compteur Android distinct dont la monotonie appartient à l'application publiée concernée.
|
||||
|
||||
### Configuration locale, outputs et signing
|
||||
|
||||
`Android/.gitignore` exclut explicitement :
|
||||
|
||||
```text
|
||||
.gradle/
|
||||
**/build/
|
||||
local.properties
|
||||
libs/*.aar
|
||||
**/src/main/jniLibs/
|
||||
```
|
||||
|
||||
La baseline ne versionne ni `local.properties`, ni keystore, ni credentials de signing. Les AAR SDL3 sont également exclus et apportés localement.
|
||||
|
||||
Les builds `bundleRelease` historiques ne nécessitent aucun secret versionné ; sans configuration de signature externe ils produisent des AAB de validation qui ne sont pas présentés comme artefacts directement publiables sur un store.
|
||||
|
||||
Cette pratique corrobore la séparation entre configuration partagée, état machine local, outputs générés, dépendances locales non vendorizées et secrets de release.
|
||||
|
||||
### Packaging APK / AAB et preuves runtime
|
||||
|
||||
Les histories `0.3.3` fournissent des preuves opérateur successives :
|
||||
|
||||
- APK Debug Snake puis Snake/Reflex construits et inspectés ;
|
||||
- AAB Release Snake/Reflex produits ;
|
||||
- contenu natif vérifié sous `lib/<abi>/` dans les APK et `base/lib/<abi>/` dans les AAB ;
|
||||
- installation et démarrage sur AVD x86_64 ;
|
||||
- installation et démarrage sur appareil ARM64 réel ;
|
||||
- preuve API 21/x86 pour le minimum supporté ;
|
||||
- preuve Android 15/API 35 x86_64 avec `PAGE_SIZE=16384` ;
|
||||
- répétition large en beta puis RC après stabilisation.
|
||||
|
||||
Ces preuves montrent qu'un build natif ou une cross-compilation ne suffit pas à prouver à lui seul le package final ou le comportement runtime.
|
||||
|
||||
### Contrainte 16 KB observée
|
||||
|
||||
Games a vérifié pour ses bibliothèques natives 64 bits `arm64-v8a` et `x86_64` des segments ELF `LOAD` alignés au moins à `2**14`, puis un `zipalign -P 16` réussi sur les APK. Un AVD `ps16k` a fourni une preuve runtime avec `getconf PAGE_SIZE=16384`.
|
||||
|
||||
Cette preuve est importante, mais elle reste liée à un besoin de distribution Android réel et à la présence de bibliothèques natives. `0.1.3` doit vérifier la forme générique et actuelle de cette exigence auprès des sources Android officielles avant d'en faire une règle normative PGR. Elle ne doit pas devenir une gate universelle pour un projet Android sans code natif ou sans canal de distribution concerné.
|
||||
|
||||
## Classification initiale des décisions Games
|
||||
|
||||
La classification initiale guide la réévaluation ; elle n'est pas une adoption de Games.
|
||||
|
||||
| Observation ou décision | Classification | Traitement prévu |
|
||||
|---------------------------------------------------------------------------------|----------------|-------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Dépôt multi-plateforme avec zone Android distincte | `ADOPT` | conserver un contrat conditionnel : racine Android dédiée lorsque l'architecture en a réellement besoin, sans l'imposer à un dépôt Android-only |
|
||||
| Composition Android + Gradle + Java seulement lorsqu'applicables | `ADOPT` | maintenir la composition explicite `600 + 610 + 522 [+ 520]` |
|
||||
| Matrice AGP / Gradle / JDK explicitement compatible | `ADOPT` | conserver le principe et vérifier que la contrainte choisie reste la moins restrictive réellement démontrée |
|
||||
| Séparation JDK de build / niveau Java | `ADOPT` | réutiliser les owners `520/522`, sans copier les versions Games |
|
||||
| Distinction `compileSdk` / `targetSdk` / `minSdk` | `ADOPT` | conserver trois contrats séparés et justifier leurs changements selon leur responsabilité |
|
||||
| `VERSION` distinct du `versionName` de produits indépendants | `ADOPT` | conserver la synchronisation uniquement lorsqu'un même release train la justifie |
|
||||
| État local, outputs Gradle et secrets hors Git | `ADOPT` | consolider `local.properties`, caches, build outputs et signing au bon owner |
|
||||
| ABI déclarées et prouvées lorsqu'il existe du code natif | `ADOPT` | garder le contrat conditionnel sans liste universelle |
|
||||
| APK/AAB, install et smoke sélectionnés selon le risque | `ADOPT` | intégrer à la validation Android proportionnée, sans full matrix systématique |
|
||||
| Chemin exact `Android/` de Games | `KEEP-LOCAL` | preuve d'un layout multi-plateforme valide, pas layout obligatoire de tout dépôt Android |
|
||||
| Groovy DSL | `KEEP-LOCAL` | `522-GRADLE.md` reste neutre Groovy/Kotlin DSL |
|
||||
| Gradle système `>= 9.6.0` sans Wrapper | `KEEP-LOCAL` | choix Games compatible avec `522`; ne pas interdire ni imposer le Wrapper |
|
||||
| AGP `9.4.0`, Gradle `9.7.1`, JDK `25.0.4.1`, Java `17` | `KEEP-LOCAL` | valeurs de preuve, jamais minima PGR génériques |
|
||||
| SDK `36/36/21`, NDK `r28c`, SDL3 `3.4.16` | `KEEP-LOCAL` | contraintes Games/framework/produit |
|
||||
| Quatre ABI et cibles Rust correspondantes | `KEEP-LOCAL` | matrice produit/toolchain, pas contrat Android universel |
|
||||
| `cargo ndk`, bridge JNI, extraction SDL3 et staging `jniLibs` | `KEEP-LOCAL` | spécialisation Rust/SDL/JNI hors du profil Android général |
|
||||
| Modules `common` / `game-*`, Activities, labels et assets | `KEEP-LOCAL` | architecture produit Games |
|
||||
| Exemple PGR de layout contenant systématiquement `gradlew*` | `OVERRIDE` | réviser l'exemple pour ne pas présenter le Wrapper comme élément structurel obligatoire |
|
||||
| Formulation PGR poussant `minSdk` « aussi bas que raisonnablement supportable » | `OVERRIDE` | réexaminer vers un choix de compatibilité produit explicitement justifié, sans préférence artificielle vers le minimum le plus bas |
|
||||
| Détail normatif 16 KB / page size | `DEFER` | vérifier les exigences Android/distribution officielles courantes avant normalisation ciblée |
|
||||
| Création d'un owner JNI/Rust Android | `DEFER` | aucun owner nouveau sans besoin générique démontré ; Games reste un corpus spécialisé |
|
||||
| Skeleton ou contrat de validation Android dédié | `DEFER` | décider seulement après révision de `610` et analyse des lacunes restantes |
|
||||
| Skeleton Tauri | `DEFER` | réservé à `0.1.4` |
|
||||
| Adoption réelle de Games | `DEFER` | réservée à `0.1.5` |
|
||||
|
||||
## Réévaluation initiale de `610-ANDROID.md`
|
||||
|
||||
Le profil courant contient déjà une part importante des contrats démontrés par Games : structure conditionnelle, matrice AGP/Gradle/JDK, niveaux SDK séparés, version Android, configuration locale, signing, modules, dépendances, ABI conditionnelles, niveaux de tests, validation proportionnée, manifests/resources et artefacts APK/AAB.
|
||||
|
||||
`0.1.3` ne doit donc pas réécrire ce profil pour produire du volume. La révision doit se concentrer sur les écarts réellement démontrés :
|
||||
|
||||
1. rendre les exemples de structure neutres vis-à-vis du choix Wrapper/système déjà possédé par `522-GRADLE.md` ;
|
||||
2. confirmer qu'Android reste neutre quant au langage applicatif et n'active `520-JAVA.md` que lorsque Java est réellement présent ;
|
||||
3. rendre la politique `minSdk` explicitement orientée contrat produit/compatibilité plutôt que « minimum le plus bas » comme objectif en soi ;
|
||||
4. clarifier ownership Android versus build tool pour AGP, Gradle, JDK et propriétés locales ;
|
||||
5. mieux séparer NDK/ABI/package Android des détails JNI/Rust/SDL spécifiques ;
|
||||
6. intégrer uniquement les contraintes de distribution modernes réellement vérifiées et applicables, notamment 16 KB si les sources officielles courantes le justifient ;
|
||||
7. déterminer si le profil suffit à exprimer la validation Android ou si un contrat `docs/validation/` apporte une réduction réelle de duplication.
|
||||
|
||||
## Mission de `0.1.3`
|
||||
|
||||
La release doit produire un profil Android pratiquement éprouvé contre Games tout en restant utilisable par un projet Android qui ne ressemble pas à Games.
|
||||
|
||||
Elle MUST :
|
||||
|
||||
- conserver Android comme spécialisation de `600-PLATFORMS.md` ;
|
||||
- composer explicitement `522-GRADLE.md` et `520-JAVA.md` uniquement lorsqu'ils sont réellement applicables ;
|
||||
- distinguer build tool, SDK Android, compatibilité utilisateur et contraintes de distribution ;
|
||||
- traiter NDK et ABI uniquement pour les projets natifs ;
|
||||
- séparer les responsabilités Android des détails JNI, Rust, SDL, Tauri et produit ;
|
||||
- conserver manifests, resources, application identity, configuration locale, signing, packaging et validation chez le bon owner ;
|
||||
- sélectionner Android Lint, tests, package, install et smokes proportionnellement au changement ;
|
||||
- vérifier toute contrainte de distribution évolutive contre une source Android officielle courante avant de la figer dans PGR ;
|
||||
- ne créer un template, skeleton, audit ou contrat de validation supplémentaire que s'il matérialise un contrat réutilisable absent et démontré.
|
||||
|
||||
Elle MUST NOT :
|
||||
|
||||
- modifier ou adopter Games ;
|
||||
- transformer SDL3, `cargo ndk`, les Activities Games ou leur architecture produit en règles Android générales ;
|
||||
- rouvrir Java/Maven/Gradle `0.1.2` sans défaut transversal démontré ;
|
||||
- réexaminer ou créer le skeleton Tauri avant `0.1.4` ;
|
||||
- absorber les contraintes Tauri Android dans `610` sans preuve indépendante ;
|
||||
- démarrer l'adoption Games `0.1.5` ;
|
||||
- créer un owner WASM, serveur Rust, JNI ou deployment par proximité ;
|
||||
- réserver une release au-delà de `0.1.7` sans nouvelle revue d'horizon justifiée.
|
||||
|
||||
## Artefacts candidats
|
||||
|
||||
Owner normatif principal :
|
||||
|
||||
```text
|
||||
docs/rules/610-ANDROID.md
|
||||
```
|
||||
|
||||
Artefacts à décider, non promis par le plan :
|
||||
|
||||
```text
|
||||
docs/validation/006-ANDROID_VALIDATION.md seulement si 400 + 610 ne suffisent pas à éviter une duplication réelle
|
||||
docs/skeletons/... aucun skeleton Android par défaut
|
||||
scripts/audit_*.py aucun audit Android par symétrie
|
||||
templates/android/... aucun template de build sans sujet générique réellement éprouvé
|
||||
```
|
||||
|
||||
Un skeleton Android n'est pas justifié par le seul fait que Games possède un projet Android. Il ne devient candidat que si la révision révèle un ensemble minimal, stable et réutilisable de décisions qu'un projet nouveau ne peut pas simplement obtenir des outils Android officiels et des owners PGR existants.
|
||||
|
||||
## Trajectoire prévisionnelle de `0.1.3`
|
||||
|
||||
### alpha.1 — audit de stable, corpus et plan
|
||||
|
||||
Vérifier `v0.1.2`, son rapport `publish.001`, le corpus Games, ses preuves Android historiques, les owners `520`, `522`, `600`, `610` et la revue d'horizon. Créer le présent plan et la classification initiale sans modifier encore `610-ANDROID.md`.
|
||||
|
||||
### alpha.2 — structure, composition et contrats Android de base
|
||||
|
||||
Réviser `610-ANDROID.md` sur les points démontrés par le corpus : structure Android-only versus multi-plateforme, composition avec Gradle/Java, matrice AGP/Gradle/JDK sans duplication de `522`, responsabilités `compileSdk`/`targetSdk`/`minSdk`, versioning Android, namespaces/application IDs, manifests/resources, configuration locale et signing.
|
||||
|
||||
Les valeurs exactes Games restent des exemples de preuve, pas des defaults PGR.
|
||||
|
||||
### alpha.3 — natif, packaging, distribution et validation
|
||||
|
||||
Réviser les responsabilités conditionnelles NDK/ABI/native packaging, APK/AAB, Android Lint, tests JVM/instrumentés, install/smoke device/AVD et contraintes de distribution applicables.
|
||||
|
||||
Avant toute règle évolutive telle que 16 KB, confronter la preuve Games à la documentation Android officielle courante et rédiger le contrat de manière conditionnelle au canal de distribution et au type d'artefact réellement concernés.
|
||||
|
||||
Ne pas créer d'owner JNI/Rust/SDL. Si un contrat de validation séparé apparaît réellement nécessaire, déclencher un REPLAN avant la beta plutôt que l'ajouter opportunément.
|
||||
|
||||
### beta.1 — réconciliation et décision d'artefacts
|
||||
|
||||
Relire le profil Android révisé contre Games, `520-JAVA.md`, `522-GRADLE.md`, `600-PLATFORMS.md`, `400-VALIDATION.md` et la revue d'horizon.
|
||||
|
||||
Vérifier qu'aucun choix Games n'est devenu un `MUST` général, que les contraintes natives restent conditionnelles, et que le futur réexamen Tauri dispose d'une frontière Android stable sans avoir été commencé.
|
||||
|
||||
Décider explicitement qu'aucun artefact supplémentaire n'est nécessaire si `610` et les owners existants suffisent. Un artefact nouveau qui exigerait du contenu fonctionnel supplémentaire entraîne un REPLAN vers une tranche alpha dédiée.
|
||||
|
||||
### rc.1 — release candidate
|
||||
|
||||
Geler le scope Android, préparer le changelog candidat et le prompt de reprise `0.1.4` sans commencer Tauri. Rejouer les validations PGR de release et vérifier les frontières `0.1.4` / `0.1.5`.
|
||||
|
||||
### rel.1 — promotion stable
|
||||
|
||||
Promouvoir mécaniquement `0.1.3` après RC `PASS` : version stable, roadmap, changelog, README/index et plan historique. Aucun nouveau changement fonctionnel Android ne doit entrer dans la clôture.
|
||||
|
||||
La preuve post-tag reste séparée et doit être produite depuis l'archive du tag `v0.1.3` réellement publiée avant de démarrer `0.1.4`.
|
||||
|
||||
## 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 `009`, des owners `520/522/600/610`, du plan et du scope Git.
|
||||
|
||||
PGR lui-même ne contient aucun projet Android exécutable. Une modification de `610-ANDROID.md` ne doit donc pas simuler un build AGP/Gradle/SDK absent du dépôt PGR.
|
||||
|
||||
Les preuves Games historiques servent à démontrer des responsabilités et des frontières ; elles ne deviennent pas une gate PGR locale et ne doivent pas être présentées comme si les APK/AAB avaient été reconstruits pendant `0.1.3`.
|
||||
|
||||
Lorsqu'une propriété relève d'un build Android réel, les outils officiels restent autoritaires : Gradle/AGP, Android Lint, SDK/NDK, outils de packaging, installation et device/AVD selon le contrat à prouver. Un audit Python read-only ne remplace aucun de ces outils.
|
||||
|
||||
La validation reste proportionnée : pas de `clean` systématique, pas de full matrix ABI/device pour un changement documentaire, pas de signing release pour une tranche qui ne valide pas la distribution signée.
|
||||
|
||||
## Déclencheurs de REPLAN
|
||||
|
||||
Un REPLAN est requis notamment si :
|
||||
|
||||
- la révision montre qu'une responsabilité aujourd'hui dans `610` appartient en réalité à un owner séparé nécessaire immédiatement ;
|
||||
- un contrat de validation Android séparé apporte une valeur concrète que `400 + 610` ne peuvent pas exprimer sans duplication ;
|
||||
- un skeleton Android réellement réutilisable devient nécessaire et peut être démontré sans copier Games ;
|
||||
- une contrainte supposée Android générale dépend en réalité de SDL, Rust, JNI, Tauri ou d'un canal de distribution particulier ;
|
||||
- une exigence Android officielle courante contredit une règle `610` existante ;
|
||||
- la release ne peut pas rester bornée sans absorber le scope Tauri `0.1.4` ou l'adoption Games `0.1.5`.
|
||||
|
||||
Un REPLAN ne sert pas à ajouter des artefacts pour remplir la release ; il corrige le découpage lorsqu'une responsabilité réelle l'exige.
|
||||
|
||||
## Clôture et transition
|
||||
|
||||
La roadmap possède déjà un horizon suffisant jusqu'à `0.1.7`. Aucune nouvelle release n'est réservée par `0.1.3-alpha.1`.
|
||||
|
||||
La prochaine release après publication vérifiée de `0.1.3` reste :
|
||||
|
||||
```text
|
||||
0.1.4 — domaine Tauri : réexamen du DEFER et matérialisation du skeleton contrôlé seulement si les conditions de sortie sont réellement satisfaites
|
||||
```
|
||||
|
||||
L'adoption réelle de Games reste ensuite réservée à `0.1.5`, afin qu'elle puisse comparer son état local avec une stable Android et une stable Tauri réellement publiées.
|
||||
89
history/0.1.3/alpha.1.md
Normal file
89
history/0.1.3/alpha.1.md
Normal file
@@ -0,0 +1,89 @@
|
||||
<!-- file: history/0.1.3/alpha.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.1.3-alpha.1 — audit de stable, corpus et plan Android
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate opérateur de `0.1.3-alpha.1` exécutée le `2026-09-28` est propre. Le plan Android créé depuis la stable `v0.1.2` et le corpus Games autoritaire est cohérent avec les frontières annoncées ; 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.3-alpha.1
|
||||
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md présent
|
||||
deltas/0.1.3/alpha.1.md présent
|
||||
history/0.1.3/alpha.1.md absent pendant la gate
|
||||
README.md version 23
|
||||
docs/000-README.md version 37
|
||||
```
|
||||
|
||||
Les deux index référencent bien le plan actif `009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`.
|
||||
|
||||
## Tests Python
|
||||
|
||||
La suite complète a affiché :
|
||||
|
||||
```text
|
||||
Ran 48 tests in 0.767s
|
||||
|
||||
OK
|
||||
```
|
||||
|
||||
Soit `48/48` tests `PASS`.
|
||||
|
||||
## Audits Markdown
|
||||
|
||||
Les trois audits documentaires sont propres :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (252 file(s))
|
||||
Markdown table audit: clean (11 table(s), 252 file(s))
|
||||
Markdown link audit: clean (316 local link(s), 252 file(s))
|
||||
```
|
||||
|
||||
## Audit structurel `alpha.1`
|
||||
|
||||
Le contrôle structurel de la tranche a affiché :
|
||||
|
||||
```text
|
||||
0.1.3 alpha.1 structural audit: clean (90 prior pairs, Games Android classified, Tauri/adoption boundaries preserved)
|
||||
```
|
||||
|
||||
Il a notamment confirmé :
|
||||
|
||||
- les `90` couples delta/history antérieurs attendus et les sept histories `0.1.2` tous `PASS` ;
|
||||
- `0.1.2` terminé, `0.1.3` à `0.1.7` toujours engagés et aucune réservation `0.1.8` ;
|
||||
- la présence dans le prompt `009` de la baseline Games attendue, de la classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, des questions Android principales et des frontières Tauri `0.1.4` / adoption Games `0.1.5` ;
|
||||
- `610-ANDROID.md` encore en révision interne `3` pendant cette tranche de cadrage ;
|
||||
- les owners `520-JAVA.md`, `522-GRADLE.md` et `600-PLATFORMS.md` aux révisions attendues ;
|
||||
- le plan `009` contenant la trajectoire `alpha.2`, `alpha.3`, `beta.1`, `rc.1`, `rel.1` et les valeurs Games conservées comme preuves locales ;
|
||||
- l'absence de `docs/validation/006-ANDROID_VALIDATION.md` et d'un history `alpha.1` anticipé pendant la gate.
|
||||
|
||||
## Hygiène Git et scope observé
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
|
||||
|
||||
Le scope indexé observé est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.1.3/alpha.1.md
|
||||
M docs/000-README.md
|
||||
A docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
|
||||
```
|
||||
|
||||
Aucun fichier Android normatif n'a été modifié prématurément dans `alpha.1`.
|
||||
|
||||
## Décision
|
||||
|
||||
`0.1.3-alpha.1` est validée `PASS`.
|
||||
|
||||
La tranche suivante reste `0.1.3-alpha.2`, bornée à la structure Android, la composition Gradle/Java, la matrice AGP/Gradle/JDK, les contrats `compileSdk` / `targetSdk` / `minSdk`, le versioning Android, `namespace` / `applicationId`, manifests/resources, configuration locale et signing.
|
||||
|
||||
Les responsabilités NDK/ABI/native packaging, APK/AAB, Android Lint, tests/instrumentation, install/smokes et contraintes de distribution modernes restent réservées à `alpha.3`. Le détail 16 KB reste donc différé jusqu'à la vérification officielle prévue pour cette tranche.
|
||||
Reference in New Issue
Block a user