0.1.3

0.1.3-rc.1
0.1.3-beta.1
2026-09-28 13:04:53 +02:00 · 2026-09-28 13:00:04 +02:00 · 2026-09-28 12:49:31 +02:00 · 2026-09-28 11:32:26 +02:00 · 2026-09-28 10:41:03 +02:00 · 2026-09-28 10:28:40 +02:00
20 changed files with 3062 additions and 57 deletions
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,5 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 15 -->
+<!-- version: 17 -->
 # Changelog Project Governance Rules
@@ -7,6 +7,16 @@ Ce fichier décrit les changements utiles aux utilisateurs ou intégrateurs des
 Les tranches `alpha`, `beta`, `rc`, fixes, validations, audits et détails de développement appartiennent aux plans, deltas et historiques. Ils ne sont pas recopiés ici par défaut.
 ## 0.1.3
 - réévalue le profil Android contre le corpus Games réel tout en conservant Android neutre vis-à-vis du langage applicatif et en composant Java/Gradle uniquement lorsqu'ils sont réellement présents ;
 - clarifie les responsabilités `compileSdk` / `targetSdk` / `minSdk`, l'identité `namespace` / `applicationId`, la configuration locale, le signing et les manifests/resources sans promouvoir les valeurs particulières de Games ;
 - borne NDK, ABI et code natif aux projets réellement concernés, distingue compilation native, packaging et preuve runtime, et conserve les choix Rust/JNI/SDL de Games hors du profil Android générique ;
 - rend Android Lint explicite, sépare tests JVM, tests instrumentés et smokes device/AVD, et distingue APK/AAB des preuves d'installation ou d'exécution ;
 - normalise la compatibilité pages mémoire 16 KB uniquement comme contrainte conditionnelle au code natif, au package et au canal de distribution applicables, sans imposer une version AGP/NDK, un `targetSdk` ou une liste d'ABI universels ;
 - confirme que les owners existants `400 + 600 + 610`, complétés par `520` et `522` lorsqu'ils s'appliquent, suffisent sans créer de skeleton Android, template, audit Python, owner JNI/Rust/SDL ou contrat de validation redondant ;
 - prépare le réexamen Tauri distinct de `0.1.4` sans lever son `DEFER` par anticipation et conserve l'adoption Games comme cible séparée `0.1.5`.
 ## 0.1.2
 - sépare l'ancien profil combiné Java/Maven/Gradle en trois owners indépendants et composables : `520-JAVA`, `521-MAVEN` et `522-GRADLE`, afin qu'un build tool ne devienne pas implicitement applicable à tout projet Java ;
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 22 -->
+<!-- version: 25 -->
 # Project Governance Rules
@@ -11,9 +11,9 @@ 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, avec `0.1.2` d’owners Java, Maven et Gradle séparés et composables, et avec `0.1.3` d’un profil Android réévalué contre Games sans généraliser ses choix locaux. Les contrats SDK, identité, natif/ABI, Lint, tests, packaging et 16 KB sont désormais bornés par leur applicabilité réelle. Tauri reste réservé à `0.1.4` et l’adoption Games à `0.1.5`.
-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`.
+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`. La release `0.1.3` stabilise le profil Android générique : séparation des responsabilités SDK et identité applicative, contraintes natives conditionnelles, Android Lint explicite, niveaux de tests distincts, frontières APK/AAB et compatibilité 16 KB liée au code natif et au canal de distribution, sans imposer les versions ou ABI propres à Games.
 ## Entrées principales
@@ -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 historique de la stable Android `0.1.3`, fondée 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 ;
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 # Roadmap Project Governance Rules
@@ -25,7 +25,7 @@ La revue d'horizon de `0.1.0-beta.1` engage les releases suivantes, chacune avec
 - `(x) 0.1.1` — fondation frontend Web : TypeScript, Vite, Sass/CSS, package/build outputs et validation frontend indépendante ;
 - `(x) 0.1.2` — réévaluation pratique de Java/Maven/Gradle, séparation des owners lorsque leurs applicabilités divergent et matérialisation uniquement des artefacts génériques réellement nécessaires ;
- `( ) 0.1.3` — réévaluation pratique du profil Android existant à partir de Games, sans absorber les décisions propres aux jeux ou à SDL ;
+- `(x) 0.1.3` — réévaluation pratique du profil Android existant à partir de Games, sans absorber les décisions propres aux jeux ou à SDL ;
 - `( ) 0.1.4` — domaine Tauri : réexamen du `DEFER` et matérialisation du skeleton contrôlé seulement si les owners Web issus de `0.1.1` satisfont réellement les conditions de sortie ;
 - `( ) 0.1.5` — adoption réelle de PGR par `sasedev-games` avec mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
 - `( ) 0.1.6` — adoption réelle de PGR par `khadhroony-solana-project`, principalement sur Rust/Cargo + Tauri et sans dépendance aux profils non applicables ;
--- a/2
+++ b/2
@@ -1 +1 @@
-0.1.2
+0.1.3
--- a/deltas/0.1.3/alpha.1.md
+++ b/deltas/0.1.3/alpha.1.md
@@ -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.
--- a/deltas/0.1.3/alpha.2.md
+++ b/deltas/0.1.3/alpha.2.md
@@ -0,0 +1,198 @@
 <!-- file: deltas/0.1.3/alpha.2.md -->
 <!-- version: 1 -->
 # Delta 0.1.3-alpha.2 — contrats Android de base
 ## Baseline
 Ce delta s'applique après :
 ```text
 0.1.3-alpha.1
 + history/0.1.3/alpha.1.md PASS
 + commit/push complet de la tranche alpha.1
 ```
 Il ne doit pas être appliqué avant l'intégration du history `alpha.1`.
 ## Objet
 Réviser le profil Android uniquement sur les contrats de base démontrés par le corpus Games et confirmés par la documentation Android officielle courante : structure Android-only versus multi-plateforme, composition langage/build, matrice AGP/Gradle/JDK, niveaux SDK, identité applicative, versioning, configuration locale et signing.
 Cette tranche ne couvre pas encore NDK/ABI/native packaging, APK/AAB, Android Lint, tests instrumentés, installation/smokes device/AVD ni exigences 16 KB ; ces responsabilités restent réservées à `alpha.3`.
 ## Modifications
 ### Version
 `VERSION` devient :
 ```text
 0.1.3-alpha.2
 ```
 ### Plan Android
 `docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md` passe en révision interne `2` et enregistre :
 - le `PASS` opérateur réel de `alpha.1` ;
 - l'absence de fix avant `alpha.2` ;
 - les sources Android officielles vérifiées le `2026-09-28` ;
 - la confirmation que les valeurs Games AGP `9.4.0`, Gradle `>= 9.6.0` et JDK observé restent des preuves locales et non des minima PGR ;
 - le scope exact de `alpha.2` ;
 - le maintien du détail 16 KB dans `alpha.3`.
 ### Profil Android
 `docs/rules/610-ANDROID.md` passe en révision interne `4`.
 La révision :
 - conserve `Android/` comme convention conditionnelle d'un dépôt multi-plateforme, mais retire `gradlew*` du layout d'exemple afin de ne plus présenter le Wrapper comme structure obligatoire ;
 - rend le profil Android neutre quant au langage applicatif et applique `520-JAVA.md` uniquement lorsque du Java est réellement présent ;
 - distingue le JDK qui exécute Gradle/AGP du niveau Java du code applicatif ;
 - conserve la matrice AGP/Gradle/JDK sans recopier les règles générales possédées par `522-GRADLE.md` ;
 - clarifie `compileSdk`, `targetSdk` et `minSdk` comme trois contrats distincts ;
 - remplace l'objectif implicite « `minSdk` aussi bas que possible » par une décision de compatibilité produit explicitement justifiée ;
 - introduit la séparation explicite entre `namespace` et `applicationId` ;
 - conserve `VERSION`, `versionName` et `versionCode` comme contrats distincts selon le release train réellement possédé ;
 - précise que `local.properties` est réservé à l'environnement local Android/AGP et ne doit pas devenir une source de configuration partagée ou un fourre-tout de propriétés produit ;
 - consolide le traitement des keystores, clés et mots de passe de signing sans recopier l'interdiction générale des secrets ;
 - clarifie que le manifest possède composants/permissions/capabilities tandis que les identités `namespace` / `applicationId` restent dans la configuration Android du module.
 Aucun template, skeleton, audit Python ou contrat de validation Android n'est créé.
 ## Vérification officielle utilisée
 La vérification courante effectuée avant préparation du delta couvre :
 ```text
 Android Gradle plugin 9.4.0 release notes
 Configure your build
 Java versions in Android builds
 Configure the app module
 Sign your app
 ```
 Elle confirme notamment la matrice AGP/Gradle/JDK, la distinction du JDK de build et du niveau Java, les responsabilités `compileSdk` / `targetSdk` / `minSdk`, la séparation `namespace` / `applicationId`, le rôle local de `local.properties` et le caractère secret des clés de signing.
 Elle n'est pas utilisée pour normaliser encore la contrainte 16 KB.
 ## Validation opérateur
 Après application du history `PASS`, commit/push de `alpha.1`, puis application du présent delta :
 ```bash
 test "$(cat VERSION)" = '0.1.3-alpha.2'
 git cat-file -e HEAD:history/0.1.3/alpha.1.md
 test -f history/0.1.3/alpha.1.md
 test -f deltas/0.1.3/alpha.2.md
 test ! -e history/0.1.3/alpha.2.md
 grep -A2 '^## Statut$' history/0.1.3/alpha.1.md | grep -Fx 'PASS'
 grep -Fx '<!-- version: 2 -->' docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 grep -Fx '<!-- version: 4 -->' docs/rules/610-ANDROID.md
 python3 -B -m unittest discover -s tests -v
 python3 -B scripts/audit_markdown_headers.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B scripts/audit_markdown_tables.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B scripts/audit_markdown_links.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B - <<'PYGATE'
 from pathlib import Path
 import re
 history = Path('history/0.1.3/alpha.1.md').read_text(encoding='utf-8')
 assert re.search(r'## Statut\s+PASS\s', history)
 android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
 assert android.startswith('<!-- file: docs/rules/610-ANDROID.md -->\n<!-- version: 4 -->')
 for phrase in (
    'Android ne sélectionne pas à lui seul le langage applicatif du projet.',
    'JDK qui exécute Gradle / AGP',
    'Le choix de `minSdk` MUST être justifié par le contrat produit',
    '## Identité applicative et namespace',
    '`applicationId` identifie l\'application installée et distribuée.',
    '`local.properties` appartient à l\'environnement local du build Android/AGP',
    'release / upload keystore',
    '`AndroidManifest.xml` MUST déclarer uniquement les composants',
 ):
    assert phrase in android, phrase
 structure = android.split('## Structure du projet', 1)[1].split('## Langage applicatif et logique de build', 1)[0]
 assert 'gradlew' not in structure
 assert 'settings.gradle(.kts)' in structure
 assert '<module>/' in structure
 assert 'Java est le langage applicatif Android par défaut du profil PGR' not in android
 assert '`minSdk` SHOULD rester aussi bas que raisonnablement supportable' not in android
 plan = Path('docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
 for phrase in (
    '## Décision après `alpha.1`',
    'La gate opérateur de `alpha.1` est `PASS`',
    '### Vérification Android officielle courante pour `alpha.2`',
    'AGP `9.4.0` requiert actuellement au minimum Gradle `9.6.0` et JDK `17`',
    'La vérification 16 KB n\'est pas absorbée ici',
    '### Scope arrêté pour `alpha.2`',
 ):
    assert phrase in plan, phrase
 assert not Path('docs/validation/006-ANDROID_VALIDATION.md').exists()
 assert not Path('history/0.1.3/alpha.2.md').exists()
 for path in (
    'docs/rules/520-JAVA.md',
    'docs/rules/522-GRADLE.md',
    'docs/rules/600-PLATFORMS.md',
 ):
    assert Path(path).is_file(), path
 print('0.1.3 alpha.2 Android base-contract audit: clean (language/build ownership, SDK contracts, app identity, local config and signing clarified)')
 PYGATE
 git diff --check
 git add VERSION \
    docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
    docs/rules/610-ANDROID.md \
    deltas/0.1.3/alpha.2.md
 git diff --cached --check
 git status --short
 ```
 Le scope indexé attendu avant ajout du history est :
 ```text
 M  VERSION
 A  deltas/0.1.3/alpha.2.md
 M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 M  docs/rules/610-ANDROID.md
 ```
 La revue qualitative doit confirmer que :
 - aucun choix Games n'est devenu une règle Android générale par copie de valeur ;
 - Android n'impose plus Java par défaut et ne confond pas JDK de build avec niveau Java applicatif ;
 - l'exemple structurel ne rend ni Wrapper ni Gradle système obligatoire ;
 - `minSdk` est une décision de compatibilité produit et non un concours vers la valeur la plus basse ;
 - `namespace` et `applicationId` sont distingués sans imposer un schéma de nommage propriétaire ;
 - `local.properties` ne devient pas une configuration partagée et les secrets de signing restent hors Git ;
 - aucun contenu NDK/ABI/16 KB, Tauri ou adoption Games n'a été absorbé prématurément ;
 - aucun artefact supplémentaire n'a été créé uniquement pour remplir la release.
 ## Transition
 ### PASS
 Produire `history/0.1.3/alpha.2.md`, puis préparer `0.1.3-alpha.3` pour les responsabilités conditionnelles NDK/ABI/native packaging, APK/AAB, Android Lint, niveaux de tests, install/smokes device/AVD et contraintes de distribution modernes réellement applicables.
 Avant toute règle 16 KB, vérifier explicitement les exigences Android officielles courantes et borner le contrat au canal de distribution et aux artefacts natifs réellement concernés.
 ### FAIL
 Consigner le diagnostic réel dans `history/0.1.3/alpha.2.md` et rester dans `alpha.2.fix.N` sauf REPLAN justifié. Le fix MUST rester borné aux contrats Android de base et ne doit pas absorber le scope natif/distribution de `alpha.3`, Tauri `0.1.4` ou l'adoption Games `0.1.5`.
--- a/deltas/0.1.3/alpha.3.md
+++ b/deltas/0.1.3/alpha.3.md
@@ -0,0 +1,211 @@
 <!-- file: deltas/0.1.3/alpha.3.md -->
 <!-- version: 1 -->
 # Delta 0.1.3-alpha.3 — natif, packaging, distribution et validation Android
 ## Baseline
 Ce delta s'applique après :
 ```text
 0.1.3-alpha.2
 + history/0.1.3/alpha.2.md PASS
 + commit/push complet de la tranche alpha.2
 ```
 Il ne doit pas être appliqué avant l'intégration du history `alpha.2`.
 ## Objet
 Réviser le profil Android uniquement sur les responsabilités conditionnelles démontrées par Games et confirmées par la documentation Android officielle courante : NDK/ABI/code natif, Android Lint, niveaux de tests, APK/AAB, installation/smokes device/AVD et compatibilité 16 KB lorsque le package ou le canal de distribution l'exigent réellement.
 Cette tranche ne crée aucun owner JNI/Rust/SDL, skeleton Android, audit Python ou contrat `docs/validation/` séparé. Elle ne modifie ni Tauri `0.1.4`, ni Games `0.1.5`.
 ## Modifications
 ### Version
 `VERSION` devient :
 ```text
 0.1.3-alpha.3
 ```
 ### Plan Android
 `docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md` passe en révision interne `3` et enregistre :
 - le `PASS` opérateur réel de `alpha.2` ;
 - l'absence de fix avant `alpha.3` ;
 - les sources Android officielles vérifiées le `2026-09-28` pour native/ABI, Lint, tests, packaging, Google Play et 16 KB ;
 - le caractère évolutif des exigences de canal telles que `targetSdk` et les échéances de publication ;
 - la cohérence de la preuve Games 16 KB sans la transformer en gate PGR locale ;
 - le scope exact de `alpha.3` ;
 - le maintien de la décision finale d'artefacts supplémentaires dans `beta.1`.
 ### Profil Android
 `docs/rules/610-ANDROID.md` passe en révision interne `5`.
 La révision :
 - rend NDK et ABI conditionnels à la présence de bibliothèques natives directes ou transitives ;
 - refuse toute version NDK ou liste d'ABI universelle et distingue compilation native, présence dans le package et preuve runtime ;
 - inclut les SDK/bibliothèques natives précompilés dans le contrat de compatibilité du package final ;
 - garde JNI, Rust, SDL, `cargo ndk` et les choix Games hors du profil Android général ;
 - introduit une section Android Lint qui impose une exécution explicite et ciblée lorsqu'elle est applicable, sans supposer qu'un build ordinaire l'exécute ;
 - précise les frontières JVM unit / instrumented / smoke device-AVD et la sélection proportionnée des matrices ;
 - distingue l'APK installable de l'AAB de distribution et interdit d'utiliser un AAB seul comme preuve runtime ;
 - impose de revalider les politiques évolutives du canal de distribution au moment de la release concernée ;
 - normalise la compatibilité 16 KB uniquement lorsqu'il existe du code natif et qu'elle est requise par la plateforme ou le canal ;
 - demande alors une preuve adaptée sur les bibliothèques 64 bits, le package APK/AAB et, lorsque nécessaire, un environnement runtime 16 KB ;
 - conserve les versions AGP/NDK et les commandes précises comme moyens de preuve/toolchain, non comme minima PGR génériques.
 ## Vérification officielle utilisée
 La vérification courante effectuée avant préparation du delta couvre :
 ```text
 Support 16 KB page sizes
 Android ABIs
 Improve your code with lint checks
 Test from the command line
 Build your app from the command line
 Meet Google Play's target API level requirement
 ```
 Elle confirme notamment, au `2026-09-28` :
 - Google Play demande depuis le `2026-08-31` API `36+` pour les nouvelles applications et mises à jour Android ordinaires, avec des règles distinctes pour certains form factors ; cette valeur reste une politique Play datée, pas un default Android PGR ;
 - les applications Google Play ciblant API `35+` doivent supporter les pages `16 KB` sur appareils 64 bits et la documentation courante annonce le `2027-02-01` comme échéance à partir de laquelle les mises à jour non compatibles ne pourront plus être publiées ;
 - une application sans code natif direct ou transitif n'a pas de réalignement ELF à effectuer ; une application native doit vérifier aussi ses bibliothèques tierces précompilées ;
 - les moyens officiels de preuve couvrent les segments ELF, `zipalign -P 16` pour l'APK, l'alignement déclaré dans l'AAB via `bundletool` et, lorsque pertinent, un test sur environnement 16 KB ;
 - AGP `8.5.1+` et NDK `r28+` facilitent le chemin standard actuel mais ne deviennent pas des minima PGR universels ;
 - Lint doit être lancé explicitement ; les tests locaux JVM et instrumentés ont des environnements et des responsabilités distincts ;
 - un APK est directement installable, tandis qu'un AAB sert à la distribution et n'est pas une preuve runtime par lui-même.
 ## Validation opérateur
 Après application du history `PASS`, commit/push de `alpha.2`, puis application du présent delta :
 ```bash
 test "$(cat VERSION)" = '0.1.3-alpha.3'
 git cat-file -e HEAD:history/0.1.3/alpha.2.md
 test -f history/0.1.3/alpha.2.md
 test -f deltas/0.1.3/alpha.3.md
 test ! -e history/0.1.3/alpha.3.md
 grep -A2 '^## Statut$' history/0.1.3/alpha.2.md | grep -Fx 'PASS'
 grep -Fx '<!-- version: 3 -->' docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 grep -Fx '<!-- version: 5 -->' docs/rules/610-ANDROID.md
 python3 -B -m unittest discover -s tests -v
 python3 -B scripts/audit_markdown_headers.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B scripts/audit_markdown_tables.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B scripts/audit_markdown_links.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B - <<'PYGATE'
 from pathlib import Path
 import re
 history = Path('history/0.1.3/alpha.2.md').read_text(encoding='utf-8')
 assert re.search(r'## Statut\s+PASS\s', history)
 android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
 assert android.startswith('<!-- file: docs/rules/610-ANDROID.md -->\n<!-- version: 5 -->')
 for phrase in (
    '## NDK, ABI et code natif',
    'bibliothèques natives précompilées ou apportées par un SDK',
    'compilation native',
    'packaging',
    'runtime',
    '## Android Lint',
    'PGR MUST NOT supposer qu\'un build Gradle ordinaire exécute Lint automatiquement.',
    'JVM unit',
    'instrumented / integration',
    'smoke device / AVD',
    'Un AAB n\'est pas directement une preuve d\'installation ou d\'exécution sur device.',
    '## Pages mémoire 16 KB et packaging natif',
    'Google Play',
    'API `35` ou supérieur',
    '`zipalign -P 16`',
    '`bundletool`',
 ):
    assert phrase in android, phrase
 assert 'PGR ne fixe ni version NDK ni liste universelle d\'ABI.' in android
 assert 'PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison.' in android
 assert 'targetSdk` minimal' in android
 plan = Path('docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
 for phrase in (
    '## Décision après `alpha.2`',
    'La gate opérateur de `alpha.2` est `PASS`',
    '### Vérification Android officielle courante pour `alpha.3`',
    'depuis le `2026-08-31`',
    'à partir du `2027-02-01`',
    '### Scope arrêté pour `alpha.3`',
    'Aucun owner JNI/Rust/SDL, skeleton Android, audit Python ou contrat `docs/validation/` n\'est créé.',
 ):
    assert phrase in plan, phrase
 assert not Path('docs/validation/006-ANDROID_VALIDATION.md').exists()
 assert not Path('history/0.1.3/alpha.3.md').exists()
 for forbidden in (
    'NDK MUST être r28',
    'MUST supporter arm64-v8a, armeabi-v7a, x86_64 et x86',
    'targetSdk MUST être 36',
 ):
    assert forbidden not in android, forbidden
 print('0.1.3 alpha.3 Android native/distribution audit: clean (conditional native ownership, lint/tests/package boundaries and 16 KB policy verified)')
 PYGATE
 git diff --check
 git add VERSION \
    docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
    docs/rules/610-ANDROID.md \
    deltas/0.1.3/alpha.3.md
 git diff --cached --check
 git status --short
 ```
 Le scope indexé attendu avant ajout du history est :
 ```text
 M  VERSION
 A  deltas/0.1.3/alpha.3.md
 M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 M  docs/rules/610-ANDROID.md
 ```
 La revue qualitative doit confirmer que :
 - aucune valeur Games (NDK `r28c`, quatre ABI, SDL3, Rust/JNI) n'est devenue une règle Android générale ;
 - une application sans code natif n'hérite d'aucune gate NDK/ABI/ELF artificielle ;
 - une dépendance native précompilée est couverte par la même preuve package que le code natif du projet ;
 - Android Lint, tests JVM, tests instrumentés, package, install et smoke restent des preuves distinctes et proportionnées ;
 - un AAB n'est pas traité comme un artefact directement installable ;
 - la règle 16 KB est conditionnelle, fondée sur la politique officielle courante et ne fige ni date ni version d'outil comme default PGR durable ;
 - le profil exige de revalider les politiques de distribution évolutives plutôt que de conserver aveuglément une valeur `targetSdk` datée ;
 - PGR ne prétend pas avoir reconstruit les APK/AAB Games pendant cette tranche documentaire ;
 - aucun contrat Android séparé, skeleton, audit ou owner spécialisé n'a été créé uniquement pour remplir la release ;
 - Tauri `0.1.4` et l'adoption Games `0.1.5` restent hors scope.
 ## Transition
 ### PASS
 Produire `history/0.1.3/alpha.3.md`, puis préparer `0.1.3-beta.1` pour la réconciliation du profil Android révisé contre Games, `520-JAVA.md`, `522-GRADLE.md`, `600-PLATFORMS.md` et `400-VALIDATION.md`.
 La beta doit décider explicitement si `610-ANDROID.md` et les owners existants suffisent. Si un artefact fonctionnel supplémentaire devient réellement nécessaire, déclencher un REPLAN vers une tranche alpha dédiée au lieu de l'ajouter en beta.
 ### FAIL
 Consigner le diagnostic réel dans `history/0.1.3/alpha.3.md` et rester dans `alpha.3.fix.N` sauf REPLAN justifié. Le fix MUST rester borné au natif, packaging, distribution et validation Android et ne doit pas absorber Tauri `0.1.4` ou l'adoption Games `0.1.5`.
--- a/deltas/0.1.3/beta.1.md
+++ b/deltas/0.1.3/beta.1.md
@@ -0,0 +1,266 @@
 <!-- file: deltas/0.1.3/beta.1.md -->
 <!-- version: 1 -->
 # Delta 0.1.3-beta.1 — réconciliation Android et décision finale d'artefacts
 ## Baseline et version
 Baseline attendue : commit opérateur de `0.1.3-alpha.3`, réalisé après application de `history/0.1.3/alpha.3.md` avec statut `PASS`.
 Version avant application :
 ```text
 0.1.3-alpha.3
 ```
 Version après application :
 ```text
 0.1.3-beta.1
 ```
 ## Objet
 Cette tranche exécute la réconciliation prévue après les révisions Android `alpha.2` et `alpha.3`. Elle ne crée aucune nouvelle règle fonctionnelle et ne modifie pas `610-ANDROID.md`.
 La beta vérifie que le profil révisé reste générique face au corpus Games, se compose correctement avec `400-VALIDATION.md`, `520-JAVA.md`, `522-GRADLE.md` et `600-PLATFORMS.md`, puis tranche explicitement la question des artefacts Android supplémentaires.
 ## Scope
 REPLACE :
 ```text
 VERSION
 README.md
 docs/000-README.md
 docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 ```
 ADD :
 ```text
 deltas/0.1.3/beta.1.md
 ```
 DELETE : aucun.
 Aucun `history/0.1.3/beta.1.md` n'est anticipé.
 ## Réconciliation contre les owners PGR
 La revue confirme la composition suivante :
 ```text
 400-VALIDATION.md    sélection et autorité générales des preuves
 520-JAVA.md          Java uniquement lorsqu'il est présent
 522-GRADLE.md        Gradle uniquement lorsqu'il est utilisé
 600-PLATFORMS.md     contrat commun des plateformes
 610-ANDROID.md       spécialisation Android
 ```
 Le profil Android ne recopie donc pas les contrats Java/Gradle généraux et ne transforme pas la présence d'AGP ou d'un JDK de build en applicabilité automatique du profil Java.
 `400-VALIDATION.md` possède déjà la validation proportionnée et les catégories de preuves. `610-ANDROID.md` ajoute uniquement les responsabilités Android nécessaires pour choisir Lint, tests, packaging, installation et smokes selon le risque.
 ## Réconciliation contre Games
 Les choix réutilisables démontrés par Games sont intégrés comme contrats génériques sans reprendre ses valeurs concrètes.
 Restent explicitement locaux à Games :
 ```text
 chemin concret Android/
 Groovy DSL
 Gradle système sans Wrapper
 AGP 9.4.0
 Gradle 9.7.1 / contrainte système >= 9.6.0
 JDK 25.0.4.1
 Java source/target 17
 compileSdk 36 / targetSdk 36 / minSdk 21
 NDK r28c
 arm64-v8a / armeabi-v7a / x86_64 / x86
 cargo ndk / bridge JNI / SDL3 / staging jniLibs
 modules, Activities, labels et assets Games
 ```
 Aucune de ces valeurs n'est promue comme minimum Android PGR.
 Les deux corrections `OVERRIDE` initiales sont résolues : le Wrapper n'est plus présenté comme élément structurel obligatoire et `minSdk` est un contrat produit explicitement justifié.
 Le sujet 16 KB, initialement `DEFER`, a été vérifié pendant `alpha.3` puis normalisé uniquement de manière conditionnelle au code natif, au package et au canal de distribution concerné. Les versions d'outils et échéances observées restent des informations datées, pas des defaults universels.
 ## Décision finale d'artefacts
 Aucun artefact technique supplémentaire n'est justifié pour `0.1.3`.
 Ne sont donc pas créés :
 ```text
 docs/validation/006-ANDROID_VALIDATION.md
 skeleton Android
 template de build Android générique
 audit Python Android
 owner JNI / Rust Android / SDL
 ```
 `400 + 600 + 610`, complétés par `520` et `522` lorsqu'ils sont applicables, couvrent déjà les responsabilités réutilisables démontrées. PGR ne possède en outre aucun build Android exécutable qui fournirait aujourd'hui un sujet légitime pour un skeleton, template ou audit spécialisé.
 Si un nouvel artefact fonctionnel devenait réellement nécessaire, il exigerait un REPLAN vers une tranche alpha dédiée. La beta ne doit pas ajouter opportunément du contenu fonctionnel nouveau.
 ## Documentation durable
 La tranche actualise :
 - le statut racine de la release ;
 - l'index documentaire `0.1.3` ;
 - le plan actif avec le `PASS` réel de `alpha.3`, la résolution des classifications et la décision finale d'artefacts.
 `610-ANDROID.md` reste en révision `5`. `ROADMAP.md`, `CHANGELOG.md`, `RULES.md`, les owners `400/520/522/600`, les skeletons, templates, validations et scripts restent inchangés.
 Tauri demeure strictement réservé à `0.1.4` et l'adoption Games à `0.1.5`.
 ## Validation opérateur
 Après application du history `PASS` de `alpha.3`, commit/push de `alpha.3`, puis application du présent delta :
 ```bash
 test "$(cat VERSION)" = '0.1.3-beta.1'
 git cat-file -e HEAD:history/0.1.3/alpha.3.md
 test -f history/0.1.3/alpha.3.md
 test -f deltas/0.1.3/beta.1.md
 test ! -e history/0.1.3/beta.1.md
 grep -A2 '^## Statut$' history/0.1.3/alpha.3.md | grep -Fx 'PASS'
 grep -Fx '<!-- version: 24 -->' README.md
 grep -Fx '<!-- version: 38 -->' docs/000-README.md
 grep -Fx '<!-- version: 4 -->' docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 grep -Fx '<!-- version: 5 -->' docs/rules/610-ANDROID.md
 grep -Fx '<!-- version: 1 -->' docs/rules/400-VALIDATION.md
 grep -Fx '<!-- version: 4 -->' docs/rules/520-JAVA.md
 grep -Fx '<!-- version: 1 -->' docs/rules/522-GRADLE.md
 grep -Fx '<!-- version: 1 -->' docs/rules/600-PLATFORMS.md
 python3 -B -m unittest discover -s tests -v
 python3 -B scripts/audit_markdown_headers.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B scripts/audit_markdown_tables.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B scripts/audit_markdown_links.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B - <<'PYGATE'
 from pathlib import Path
 import re
 history = Path('history/0.1.3/alpha.3.md').read_text(encoding='utf-8')
 assert re.search(r'## Statut\s+PASS\s', history)
 validation = Path('docs/rules/400-VALIDATION.md').read_text(encoding='utf-8')
 java = Path('docs/rules/520-JAVA.md').read_text(encoding='utf-8')
 gradle = Path('docs/rules/522-GRADLE.md').read_text(encoding='utf-8')
 platforms = Path('docs/rules/600-PLATFORMS.md').read_text(encoding='utf-8')
 android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
 plan = Path('docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
 for phrase in (
    'La validation existe pour fournir une preuve utile proportionnée au changement.',
    'BUILD, PACKAGE et PUBLISH',
    '## Autorité du gate opérateur',
 ):
    assert phrase in validation, phrase
 assert '# Profil Java' in java
 assert '# Profil Gradle' in gradle
 assert '# Règles de profils plateforme' in platforms
 for phrase in (
    'Android ne sélectionne pas à lui seul le langage applicatif du projet.',
    'Le choix de `minSdk` MUST être justifié par le contrat produit',
    'PGR ne fixe ni version NDK ni liste universelle d\'ABI.',
    'PGR MUST NOT supposer qu\'un build Gradle ordinaire exécute Lint automatiquement.',
    'Un AAB n\'est pas directement une preuve d\'installation ou d\'exécution sur device.',
    '## Pages mémoire 16 KB et packaging natif',
    'PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison.',
 ):
    assert phrase in android, phrase
 for forbidden in (
    'targetSdk MUST être 36',
    'minSdk MUST être 21',
    'NDK MUST être r28',
    'MUST supporter arm64-v8a, armeabi-v7a, x86_64 et x86',
    'Gradle MUST être 9.7.1',
    'AGP MUST être 9.4.0',
    'JDK MUST être 25',
 ):
    assert forbidden not in android, forbidden
 for phrase in (
    '## Décision après `alpha.3` et réconciliation `beta.1`',
    'La gate opérateur de `alpha.3` est `PASS`',
    '### Résolution de la classification initiale',
    '### Décision finale d\'artefacts Android',
    'Aucun artefact technique supplémentaire n\'est justifié pour `0.1.3`.',
    'docs/validation/006-ANDROID_VALIDATION.md',
    '### Frontières après réconciliation',
    'Tauri                    0.1.4',
    'adoption Games           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/beta.1.md').exists()
 for forbidden_path in (
    'templates/android',
    'docs/skeletons/004-ANDROID.md',
    'docs/rules/620-JNI.md',
 ):
    assert not Path(forbidden_path).exists(), forbidden_path
 print('0.1.3 beta.1 reconciliation audit: clean (Android profile generic, Games-local choices preserved, existing owners sufficient, no extra artifacts justified)')
 PYGATE
 git diff --check
 git add README.md VERSION \
    docs/000-README.md \
    docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
    deltas/0.1.3/beta.1.md
 git diff --cached --check
 git status --short
 ```
 Le scope indexé attendu avant ajout du history est exactement :
 ```text
 M  README.md
 M  VERSION
 A  deltas/0.1.3/beta.1.md
 M  docs/000-README.md
 M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 ```
 La revue qualitative doit confirmer que :
 - aucun choix local Games n'est devenu une règle Android générale ;
 - les contraintes NDK/ABI/16 KB restent conditionnelles et n'imposent aucune toolchain universelle ;
 - Java et Gradle restent des profils composés uniquement lorsqu'ils sont applicables ;
 - `400 + 600 + 610` expriment déjà la validation Android sans contrat séparé redondant ;
 - aucun skeleton, template, audit ou owner spécialisé n'est ajouté pour satisfaire une structure théorique ;
 - Tauri `0.1.4` n'est pas commencé et l'adoption Games `0.1.5` reste hors scope ;
 - aucun `0.1.8` n'est réservé.
 ## Transition
 ### PASS
 Produire `history/0.1.3/beta.1.md`, puis préparer `0.1.3-rc.1` pour geler le scope Android, préparer le changelog candidat et le prompt de reprise `0.1.4`, puis rejouer le release gate complet sans commencer Tauri.
 ### FAIL
 Consigner le diagnostic réel dans `history/0.1.3/beta.1.md`, puis produire `beta.1.fix.N` ou effectuer un REPLAN uniquement si un défaut d'ownership, de généricité ou de frontière ne peut pas être corrigé localement sans nouvelle matière fonctionnelle.
--- a/deltas/0.1.3/rc.1.md
+++ b/deltas/0.1.3/rc.1.md
@@ -0,0 +1,312 @@
 <!-- file: deltas/0.1.3/rc.1.md -->
 <!-- version: 1 -->
 # Delta 0.1.3-rc.1 — gel du scope Android et gate de release candidate
 ## Baseline et version
 Baseline attendue : commit opérateur de `0.1.3-beta.1`, réalisé après application de `history/0.1.3/beta.1.md` avec statut `PASS`.
 Le hash de ce commit n'est pas anticipé.
 Version avant application :
 ```text
 0.1.3-beta.1
 ```
 Version après application :
 ```text
 0.1.3-rc.1
 ```
 ## Objet et gel
 La RC gèle le scope fonctionnel de `0.1.3` sur :
 - Android comme spécialisation de `600-PLATFORMS.md`, neutre vis-à-vis du langage applicatif et composant Java/Gradle uniquement lorsqu'ils sont réellement applicables ;
 - les responsabilités distinctes de `compileSdk`, `targetSdk` et `minSdk`, avec `minSdk` justifié par le contrat produit plutôt que minimisé cérémoniellement ;
 - `namespace`, `applicationId`, manifests/resources, configuration locale et signing comme responsabilités Android clairement bornées ;
 - NDK, ABI et bibliothèques natives uniquement pour les projets réellement concernés, sans version NDK ni liste d'ABI universelles ;
 - la séparation entre compilation native, packaging et preuve runtime ;
 - Android Lint comme gate explicite, avec tests JVM, tests instrumentés et smokes device/AVD sélectionnés proportionnellement au changement ;
 - la distinction APK/AAB versus preuve d'installation/exécution ;
 - la compatibilité pages mémoire 16 KB comme contrat conditionnel au code natif, au package et au canal de distribution concernés, sans minimum AGP/NDK/SDK universel ;
 - les choix spécifiques Games — versions d'outils, niveaux SDK, quatre ABI, Rust/JNI/SDL, modules et assets — conservés comme décisions locales ;
 - la décision beta qu'aucun skeleton Android, template de build, audit Python, owner JNI/Rust/SDL ni contrat de validation Android séparé n'est justifié ;
 - la frontière suivante : réexamen Tauri `0.1.4`, adoption Games `0.1.5`, adoption KSP `0.1.6`.
 Le changelog reçoit une entrée candidate `0.1.3` orientée utilisateurs. Le prompt `010-V0_1_4_START_PROMPT.md` est préparé pour le réexamen Tauri après publication vérifiée de `v0.1.3`.
 Aucune nouvelle règle fonctionnelle Android n'entre dans cette RC. Les owners, skeletons, templates, validations et scripts sont vérifiés mais non modifiés.
 ## Scope
 REPLACE :
 ```text
 VERSION
 CHANGELOG.md
 docs/000-README.md
 docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 ```
 ADD :
 ```text
 deltas/0.1.3/rc.1.md
 prompts/010-V0_1_4_START_PROMPT.md
 ```
 DELETE : aucun.
 Le history `beta.1` est livré séparément et MUST être appliqué/committé avant ce delta.
 ## Gate opérateur de release candidate
 Après application du history `PASS` de `beta.1`, commit/push de `beta.1`, puis application du présent delta :
 ```bash
 test "$(cat VERSION)" = '0.1.3-rc.1'
 git cat-file -e HEAD:history/0.1.3/beta.1.md
 test -f history/0.1.3/beta.1.md
 test -f deltas/0.1.3/rc.1.md
 test -f prompts/010-V0_1_4_START_PROMPT.md
 test ! -e history/0.1.3/rc.1.md
 grep -A2 '^## Statut$' history/0.1.3/beta.1.md | grep -Fx 'PASS'
 grep -Fx '<!-- version: 16 -->' CHANGELOG.md
 grep -Fx '## 0.1.3 (candidate)' CHANGELOG.md
 grep -Fx '<!-- version: 39 -->' docs/000-README.md
 grep -Fx '<!-- version: 5 -->' docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 grep -Fx '<!-- version: 14 -->' ROADMAP.md
 grep -Fx '<!-- version: 1 -->' prompts/010-V0_1_4_START_PROMPT.md
 grep -Fx '<!-- version: 5 -->' docs/rules/610-ANDROID.md
 grep -Fx '<!-- version: 6 -->' docs/rules/710-TAURI.md
 grep -Fx '<!-- version: 2 -->' docs/studies/002-TAURI_SKELETON_DECISION.md
 grep -Fx '<!-- version: 1 -->' docs/skeletons/003-WEB_FRONTEND.md
 grep -Fx '<!-- version: 1 -->' docs/validation/005-WEB_FRONTEND_VALIDATION.md
 ```
 Contrôle d'intégration de la RC :
 ```bash
 python3 -B - <<'PYGATE'
 from pathlib import Path
 import re
 expected = {
    "alpha.1.md": "PASS",
    "alpha.2.md": "PASS",
    "alpha.3.md": "PASS",
    "beta.1.md": "PASS",
 }
 histories = {path.name for path in Path("history/0.1.3").glob("*.md")}
 assert histories == set(expected), histories
 for name, status in expected.items():
    text = Path("history/0.1.3", name).read_text(encoding="utf-8")
    assert re.search(rf"## Statut\s+{status}\s", text), (name, status)
 deltas = {path.name for path in Path("deltas/0.1.3").glob("*.md")}
 assert deltas == set(expected) | {"rc.1.md"}, deltas
 changelog = Path("CHANGELOG.md").read_text(encoding="utf-8")
 assert "## 0.1.3 (candidate)" in changelog
 section = changelog.split("## 0.1.3 (candidate)", 1)[1].split("## 0.1.2", 1)[0]
 for phrase in (
    "profil Android",
    "compileSdk",
    "targetSdk",
    "minSdk",
    "namespace",
    "applicationId",
    "NDK",
    "Android Lint",
    "tests instrumentés",
    "APK/AAB",
    "16 KB",
    "0.1.4",
    "0.1.5",
 ):
    assert phrase in section, phrase
 for forbidden in (
    "alpha.1",
    "alpha.2",
    "alpha.3",
    "beta.1",
    "rc.1",
 ):
    assert forbidden not in section, forbidden
 android = Path("docs/rules/610-ANDROID.md").read_text(encoding="utf-8")
 for phrase in (
    "Android ne sélectionne pas à lui seul le langage applicatif du projet.",
    "Le choix de `minSdk` MUST être justifié par le contrat produit",
    "PGR ne fixe ni version NDK ni liste universelle d'ABI.",
    "PGR MUST NOT supposer qu'un build Gradle ordinaire exécute Lint automatiquement.",
    "Un AAB n'est pas directement une preuve d'installation ou d'exécution sur device.",
    "## Pages mémoire 16 KB et packaging natif",
    "PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison.",
 ):
    assert phrase in android, phrase
 for forbidden in (
    "targetSdk MUST être 36",
    "minSdk MUST être 21",
    "NDK MUST être r28",
    "MUST supporter arm64-v8a, armeabi-v7a, x86_64 et x86",
    "Gradle MUST être 9.7.1",
    "AGP MUST être 9.4.0",
    "JDK MUST être 25",
 ):
    assert forbidden not in android, forbidden
 plan = Path("docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md").read_text(encoding="utf-8")
 for phrase in (
    "### beta.1 — réconciliation et décision d'artefacts\n\nRelire",
    "Statut opérateur : **PASS**.",
    "### rc.1 — release candidate\n\nStatut opérateur : **à valider**.",
    "prompts/010-V0_1_4_START_PROMPT.md",
    "Aucune nouvelle fonctionnalité normative Android ne doit apparaître en RC.",
 ):
    assert phrase in plan, phrase
 prompt = Path("prompts/010-V0_1_4_START_PROMPT.md").read_text(encoding="utf-8")
 for phrase in (
    "archive source téléchargée depuis le tag Gitea `v0.1.3`",
    "pgr-0.1.3-publish.001-report.md",
    "0.1.4-alpha.1",
    "2a9cabcb9f147a348dcf8d24df8bc6c5029089b6d49feb17bd4a42b4293c329a",
    "ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8",
    "002-TAURI_SKELETON_DECISION.md",
    "710-TAURI.md",
    "003-WEB_FRONTEND",
    "ADOPT / KEEP-LOCAL / OVERRIDE / DEFER",
    "conditions de sortie",
    "créer le skeleton Tauri parce que la roadmap le mentionne",
    "adoption Games `0.1.5`",
    "adoption KSP `0.1.6`",
 ):
    assert phrase in prompt, phrase
 study = Path("docs/studies/002-TAURI_SKELETON_DECISION.md").read_text(encoding="utf-8")
 for phrase in (
    "DEFER",
    "Condition 1 — TypeScript et conventions Web contrôlées",
    "Condition 2 — Vite et ownership des commandes/dev server/build outputs",
    "Condition 3 — Sass/CSS et statut des artefacts générés",
    "Condition 4 — validation frontend indépendante de la validation Tauri",
    "Condition 5 — framework CSS classé comme décision de skeleton/projet",
    "réexamen autorisé            0.1.4",
    "création automatique         interdite",
 ):
    assert phrase in study, phrase
 roadmap = Path("ROADMAP.md").read_text(encoding="utf-8")
 for version in ("0.1.3", "0.1.4", "0.1.5", "0.1.6", "0.1.7"):
    assert f"- `( ) {version}`" in roadmap, version
 assert "- `( ) 0.1.8`" not in roadmap
 assert "skeleton Tauri jusqu'au réexamen 0.1.4" in roadmap
 for forbidden_path in (
    "docs/validation/006-ANDROID_VALIDATION.md",
    "docs/skeletons/004-ANDROID.md",
    "docs/rules/620-JNI.md",
    "docs/skeletons/004-TAURI.md",
 ):
    assert not Path(forbidden_path).exists(), forbidden_path
 index = Path("docs/000-README.md").read_text(encoding="utf-8")
 assert "../prompts/010-V0_1_4_START_PROMPT.md" in index
 print("0.1.3 rc.1 integration audit: clean (4 prior histories, frozen Android profile, candidate changelog and prompt 010 verified)")
 PYGATE
 ```
 Rejouer ensuite les preuves PGR :
 ```bash
 python3 -B -m unittest discover -s tests -v
 python3 -B scripts/audit_markdown_headers.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B scripts/audit_markdown_tables.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B scripts/audit_markdown_links.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 ```
 Vérifier également l'hygiène texte/templates sans simuler une toolchain Android ou Tauri absente du dépôt PGR :
 ```bash
 python3 -B - <<'PYHYGIENE'
 from pathlib import Path
 import json
 import tomllib
 for path in sorted(Path("templates/rust-cargo").rglob("*.toml")):
    tomllib.loads(path.read_text(encoding="utf-8"))
 json.loads(Path("templates/web-typescript/package.json").read_text(encoding="utf-8"))
 json.loads(Path("templates/web-typescript/tsconfig.json").read_text(encoding="utf-8"))
 roots = (
    Path("VERSION"), Path("README.md"), Path("RULES.md"), Path("ROADMAP.md"), Path("CHANGELOG.md"),
    Path("docs"), Path("deltas"), Path("history"), Path("prompts"), Path("templates"),
 )
 files = []
 for root in roots:
    if root.is_file():
        files.append(root)
    elif root.is_dir():
        files.extend(path for path in root.rglob("*") if path.is_file())
 for path in files:
    try:
        data = path.read_bytes()
        text = data.decode("utf-8")
    except UnicodeDecodeError:
        continue
    assert b"\r" not in data, path
    assert text.endswith("\n"), path
    for number, line in enumerate(text.splitlines(), 1):
        assert line == line.rstrip(" \t"), (path, number)
 print("0.1.3 rc.1 text/template hygiene: clean")
 PYHYGIENE
 git diff --check
 git add VERSION CHANGELOG.md docs/000-README.md \
    docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
    deltas/0.1.3/rc.1.md prompts/010-V0_1_4_START_PROMPT.md
 git diff --cached --check
 git status --short
 ```
 Le scope indexé attendu avant ajout du history est exactement :
 ```text
 M  CHANGELOG.md
 M  VERSION
 A  deltas/0.1.3/rc.1.md
 M  docs/000-README.md
 M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 A  prompts/010-V0_1_4_START_PROMPT.md
 ```
 La revue qualitative doit confirmer que :
 - aucune règle fonctionnelle Android nouvelle n'entre en RC ;
 - `610-ANDROID.md` reste en révision `5` et aucun choix Games n'est généralisé ;
 - aucun artefact Android supplémentaire n'est créé ;
 - le changelog candidat décrit la valeur utilisateur de `0.1.3` sans recopier la chronologie alpha/beta/RC ;
 - le prompt `010` exige une future stable `v0.1.3` réellement publiée et son rapport post-tag `PASS` ;
 - le `DEFER` Tauri n'est pas levé par le prompt : `0.1.4` doit le réexaminer objectivement contre les corpus courants ;
 - l'adoption Games `0.1.5` et l'adoption KSP `0.1.6` ne sont pas commencées ;
 - aucune preuve Android/Tauri exécutable n'est simulée dans PGR.
 ## Transition
 ### PASS
 Produire séparément `history/0.1.3/rc.1.md`, puis préparer la promotion mécanique `0.1.3-rel.1` sans rouvrir le scope fonctionnel.
--- a/deltas/0.1.3/rel.1.md
+++ b/deltas/0.1.3/rel.1.md
@@ -0,0 +1,288 @@
 <!-- file: deltas/0.1.3/rel.1.md -->
 <!-- version: 1 -->
 # Delta 0.1.3 rel.1 — promotion stable pré-tag
 ## Baseline et version
 Baseline : `0.1.3-rc.1`, avec `history/0.1.3/rc.1.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
 Version avant application :
 ```text
 0.1.3-rc.1
 ```
 Version après application :
 ```text
 0.1.3
 ```
 `rel.1` identifie la clôture opérationnelle ; il ne fait pas partie de la version SemVer du produit.
 ## Objet
 Promouvoir mécaniquement la RC validée vers la stable `0.1.3` sans rouvrir le scope fonctionnel.
 La tranche finalise uniquement la présentation et les métadonnées de release : version stable, roadmap terminée, changelog sans marqueur `candidate`, README/index en état stable et plan `009` historique. Aucun owner Android/Java/Gradle/Tauri, template, skeleton, validation, étude technique ou script d'audit n'est modifié.
 La validation de cette tranche est **pré-tag**. Le tag `v0.1.3`, son archive source Gitea et le rapport `pgr-0.1.3-publish.001-report.md` ne sont pas déclarés existants par ce delta. Ils suivent uniquement un history `rel.1` `PASS`, le commit stable `0.1.3` et la publication réelle du tag.
 ## Scope
 REPLACE :
 ```text
 VERSION
 README.md
 ROADMAP.md
 CHANGELOG.md
 docs/000-README.md
 docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 ```
 ADD :
 ```text
 deltas/0.1.3/rel.1.md
 ```
 DELETE : aucun.
 Le history `rc.1` est livré séparément. Le history `rel.1` sera produit uniquement après la gate opérateur.
 ## Validation opérateur pré-tag
 Après application sur le commit contenant `history/0.1.3/rc.1.md` :
 ```bash
 test "$(cat VERSION)" = '0.1.3'
 git cat-file -e HEAD:history/0.1.3/rc.1.md
 test -f history/0.1.3/rc.1.md
 test -f deltas/0.1.3/rel.1.md
 test -f prompts/010-V0_1_4_START_PROMPT.md
 test ! -e history/0.1.3/rel.1.md
 grep -A2 '^## Statut$' history/0.1.3/rc.1.md | grep -Fx 'PASS'
 grep -Fx '<!-- version: 25 -->' README.md
 grep -Fx '<!-- version: 15 -->' ROADMAP.md
 grep -Fx '<!-- version: 17 -->' CHANGELOG.md
 grep -Fx '<!-- version: 40 -->' docs/000-README.md
 grep -Fx '<!-- version: 6 -->' docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 grep -F -- '- `(x) 0.1.3`' ROADMAP.md
 grep -Fx '## 0.1.3' CHANGELOG.md
 grep -F 'avec `0.1.3` d’un profil Android réévalué contre Games' README.md
 grep -F 'plan historique de la stable `0.1.3`' docs/000-README.md
 python3 -B - <<'PYGATE'
 from pathlib import Path
 import re
 expected = {
    "alpha.1.md": "PASS",
    "alpha.2.md": "PASS",
    "alpha.3.md": "PASS",
    "beta.1.md": "PASS",
    "rc.1.md": "PASS",
 }
 for name, status in expected.items():
    delta = Path("deltas/0.1.3", name)
    history = Path("history/0.1.3", name)
    assert delta.is_file(), name
    assert history.is_file(), name
    text = history.read_text(encoding="utf-8")
    assert re.search(rf"## Statut\s+{status}\s", text), (name, status)
 pending = {path.name for path in Path("deltas/0.1.3").glob("*.md")} - {
    path.name for path in Path("history/0.1.3").glob("*.md")
 }
 assert pending == {"rel.1.md"}, pending
 roadmap = Path("ROADMAP.md").read_text(encoding="utf-8")
 assert "- `(x) 0.1.3`" in roadmap
 for version in ("0.1.4", "0.1.5", "0.1.6", "0.1.7"):
    assert f"- `( ) {version}`" in roadmap, version
 assert "- `( ) 0.1.8`" not in roadmap
 assert "skeleton Tauri jusqu'au réexamen 0.1.4" in roadmap
 changelog = Path("CHANGELOG.md").read_text(encoding="utf-8")
 assert "## 0.1.3" in changelog.splitlines()
 assert "## 0.1.3 (candidate)" not in changelog
 section = changelog.split("## 0.1.3", 1)[1].split("## 0.1.2", 1)[0]
 for phrase in (
    "profil Android",
    "compileSdk",
    "targetSdk",
    "minSdk",
    "namespace",
    "applicationId",
    "NDK",
    "Android Lint",
    "tests instrumentés",
    "APK/AAB",
    "16 KB",
    "0.1.4",
    "0.1.5",
 ):
    assert phrase in section, phrase
 for forbidden in ("alpha.1", "alpha.2", "alpha.3", "beta.1", "rc.1", "rel.1"):
    assert forbidden not in section, forbidden
 readme = Path("README.md").read_text(encoding="utf-8")
 assert "avec `0.1.3` d’un profil Android réévalué contre Games" in readme
 assert "plan historique de la stable Android `0.1.3`" in readme
 index = Path("docs/000-README.md").read_text(encoding="utf-8")
 assert "plan historique de la stable `0.1.3`" in index
 assert "à exécuter uniquement après publication et vérification post-tag de `v0.1.3`" in index
 plan = Path("docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md").read_text(encoding="utf-8")
 assert "Plan 0.1.3 — réévaluation pratique Android" in plan
 assert "### rc.1 — release candidate\n\nStatut opérateur : **PASS**." in plan
 assert "history/0.1.3/rel.1.md" in plan
 assert "pgr-0.1.3-publish.001-report.md" in plan
 assert "commit `0.1.3` avant le tag `v0.1.3`" in plan
 assert "plan historique de la stable `0.1.3`" in plan
 prompt = Path("prompts/010-V0_1_4_START_PROMPT.md").read_text(encoding="utf-8")
 for phrase in (
    "tag Gitea `v0.1.3`",
    "pgr-0.1.3-publish.001-report.md",
    "0.1.4-alpha.1",
    "002-TAURI_SKELETON_DECISION.md",
    "710-TAURI.md",
    "003-WEB_FRONTEND",
    "ADOPT / KEEP-LOCAL / OVERRIDE / DEFER",
    "adoption Games `0.1.5`",
    "adoption KSP `0.1.6`",
 ):
    assert phrase in prompt, phrase
 for path, version in (
    ("docs/rules/400-VALIDATION.md", 1),
    ("docs/rules/520-JAVA.md", 4),
    ("docs/rules/522-GRADLE.md", 1),
    ("docs/rules/600-PLATFORMS.md", 1),
    ("docs/rules/610-ANDROID.md", 5),
    ("docs/rules/710-TAURI.md", 6),
    ("docs/studies/002-TAURI_SKELETON_DECISION.md", 2),
    ("docs/skeletons/003-WEB_FRONTEND.md", 1),
    ("docs/validation/005-WEB_FRONTEND_VALIDATION.md", 1),
 ):
    lines = Path(path).read_text(encoding="utf-8").splitlines()
    assert lines[1] == f"<!-- version: {version} -->", (path, lines[1])
 android = Path("docs/rules/610-ANDROID.md").read_text(encoding="utf-8")
 for phrase in (
    "Android ne sélectionne pas à lui seul le langage applicatif du projet.",
    "Le choix de `minSdk` MUST être justifié par le contrat produit",
    "PGR ne fixe ni version NDK ni liste universelle d'ABI.",
    "PGR MUST NOT supposer qu'un build Gradle ordinaire exécute Lint automatiquement.",
    "Un AAB n'est pas directement une preuve d'installation ou d'exécution sur device.",
    "## Pages mémoire 16 KB et packaging natif",
    "PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison.",
 ):
    assert phrase in android, phrase
 for forbidden in (
    "targetSdk MUST être 36",
    "minSdk MUST être 21",
    "NDK MUST être r28",
    "MUST supporter arm64-v8a, armeabi-v7a, x86_64 et x86",
    "Gradle MUST être 9.7.1",
    "AGP MUST être 9.4.0",
    "JDK MUST être 25",
 ):
    assert forbidden not in android, forbidden
 for forbidden_path in (
    "docs/validation/006-ANDROID_VALIDATION.md",
    "docs/skeletons/004-ANDROID.md",
    "docs/rules/620-JNI.md",
    "docs/skeletons/004-TAURI.md",
 ):
    assert not Path(forbidden_path).exists(), forbidden_path
 workflow = Path("docs/rules/210-WORKFLOW.md").read_text(encoding="utf-8")
 assert "history rel.1 FAIL / PARTIAL / BLOCKED" in workflow
 assert "premier history rel.N[/fix.M] PASS qui établit réellement la stable" in workflow
 assert "commit X.Y.Z" in workflow
 print("0.1.3 rel.1 stable gate audit: clean (5 prior histories, rel.1 pending, stable Android presentation and post-tag Tauri handoff coherent)")
 PYGATE
 python3 -B -m unittest discover -s tests -v
 python3 -B scripts/audit_markdown_headers.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B scripts/audit_markdown_tables.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B scripts/audit_markdown_links.py \
    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
 python3 -B - <<'PYHYGIENE'
 from pathlib import Path
 import json
 import tomllib
 for path in sorted(Path("templates/rust-cargo").rglob("*.toml")):
    tomllib.loads(path.read_text(encoding="utf-8"))
 json.loads(Path("templates/web-typescript/package.json").read_text(encoding="utf-8"))
 json.loads(Path("templates/web-typescript/tsconfig.json").read_text(encoding="utf-8"))
 roots = (
    Path("VERSION"), Path("README.md"), Path("RULES.md"), Path("ROADMAP.md"), Path("CHANGELOG.md"),
    Path("docs"), Path("deltas"), Path("history"), Path("prompts"), Path("templates"),
 )
 files = []
 for root in roots:
    if root.is_file():
        files.append(root)
    elif root.is_dir():
        files.extend(path for path in root.rglob("*") if path.is_file())
 for path in files:
    try:
        data = path.read_bytes()
        text = data.decode("utf-8")
    except UnicodeDecodeError:
        continue
    assert b"\r" not in data, path
    assert text.endswith("\n"), path
    for number, line in enumerate(text.splitlines(), 1):
        assert line == line.rstrip(" \t"), (path, number)
 print("0.1.3 rel.1 text/template hygiene: clean")
 PYHYGIENE
 git diff --check
 git add VERSION README.md ROADMAP.md CHANGELOG.md docs/000-README.md \
    docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
    deltas/0.1.3/rel.1.md
 git diff --cached --check
 git status --short
 ```
 Le scope attendu avant ajout du history est exactement :
 ```text
 M  CHANGELOG.md
 M  README.md
 M  ROADMAP.md
 M  VERSION
 A  deltas/0.1.3/rel.1.md
 M  docs/000-README.md
 M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 ```
 La RC a déjà reconfirmé le profil Android gelé, les frontières Tauri/Games/KSP, le contrat du prompt `010` et l'absence d'artefacts Android supplémentaires. Comme `rel.1` ne modifie aucun artefact technique, la promotion stable rejoue les tests PGR, les audits documentaires et l'hygiène des templates sans simuler une toolchain Android absente du dépôt.
 ## Revue opérateur complémentaire
 Confirmer que :
 - `0.1.3` est bien présenté comme stable partout où la RC était auparavant candidate ;
 - aucun changement fonctionnel Android n'est entré dans `rel.1` ;
 - `0.1.4` reste le réexamen Tauri, sans création anticipée du skeleton ;
 - `0.1.5` et `0.1.6` restent respectivement les adoptions Games et KSP ;
 - le tag et le rapport post-tag ne sont pas anticipés dans le dépôt pré-tag.
--- a/docs/000-README.md
+++ b/docs/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 36 -->
+<!-- version: 40 -->
 # Documentation PGR
@@ -20,6 +20,16 @@ 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 historique de la stable `0.1.3`, de l'audit Games à la stabilisation du profil Android générique et au handoff Tauri `0.1.4`.
 - [`rules/610-ANDROID.md`](rules/610-ANDROID.md) — owner Android révisé : contrats SDK/identité/signing, natif/ABI, Lint, niveaux de tests, packaging/distribution et 16 KB conditionnel, sans absorber les choix propres à Games.
 - [`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`.
 - [`../prompts/010-V0_1_4_START_PROMPT.md`](../prompts/010-V0_1_4_START_PROMPT.md) — prompt préparé par la RC pour le réexamen Tauri `0.1.4`, à exécuter uniquement après publication et vérification post-tag de `v0.1.3`.
 ## 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.
--- a/docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+++ b/docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
@@ -0,0 +1,617 @@
 <!-- file: docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md -->
 <!-- version: 6 -->
 # 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`                                                                                                                              |
 ## Décision après `alpha.1`
 La gate opérateur de `alpha.1` est `PASS`. Les `48/48` tests Python, les trois audits Markdown, l'audit structurel de la tranche et les contrôles Git sont propres ; aucun `alpha.1.fix.N` n'est requis.
 `alpha.2` peut donc appliquer les décisions déjà classifiées `ADOPT` / `OVERRIDE` pour les contrats Android de base, sans ouvrir le natif, le packaging de distribution ou les smokes réservés à `alpha.3`.
 ### Vérification Android officielle courante pour `alpha.2`
 La documentation Android officielle courante a été vérifiée le `2026-09-28` sur les responsabilités touchées par cette tranche :
 ```text
 https://developer.android.com/build/releases/agp-9-4-0-release-notes
 https://developer.android.com/build
 https://developer.android.com/build/jdks
 https://developer.android.com/build/configure-app-module
 https://developer.android.com/studio/publish/app-signing
 ```
 Cette vérification confirme notamment :
 - AGP possède une matrice de compatibilité explicite avec Gradle et le JDK de build ; AGP `9.4.0` requiert actuellement au minimum Gradle `9.6.0` et JDK `17`, ce qui confirme la cohérence du corpus Games sans transformer ces valeurs en minima PGR ;
 - le JDK qui exécute Gradle/AGP est distinct du niveau de langage ou bytecode du code Java ; cette séparation reste nécessaire même lorsqu'un projet Android ne contient aucun source Java ;
 - `compileSdk`, `targetSdk` et `minSdk` ont des responsabilités distinctes : APIs disponibles à la compilation, comportements/runtime ciblés et plus ancien niveau Android réellement supporté ;
 - `namespace` et `applicationId` sont deux propriétés distinctes ; les garder identiques est le cas courant, mais leur divergence peut être volontaire et doit rester explicite ;
 - `local.properties` est réservé aux propriétés locales de l'environnement Android/AGP et doit rester hors du contrôle de version ; des propriétés locales propres au projet doivent utiliser un mécanisme séparé ;
 - les clés et mots de passe de signing sont des secrets ; le debug keystore généré par les outils reste un état local et ne constitue pas une identité de release à versionner.
 La vérification 16 KB n'est pas absorbée ici : elle reste explicitement réservée à `alpha.3`, avec sa propre confrontation aux exigences de distribution officielles courantes.
 ### Scope arrêté pour `alpha.2`
 La tranche révise uniquement `610-ANDROID.md` pour :
 1. retirer du layout d'exemple toute présentation implicite du Wrapper comme élément obligatoire ;
 2. rendre Android neutre quant au langage applicatif et composer `520-JAVA.md` seulement lorsque du Java est réellement présent ;
 3. séparer clairement JDK de build AGP/Gradle et niveau Java du code ;
 4. reformuler `minSdk` comme contrat produit explicite, sans objectif artificiel de valeur la plus basse ;
 5. expliciter la séparation `namespace` / `applicationId` ;
 6. consolider le rôle de `local.properties`, des propriétés partagées et du signing sans recopier les owners généraux.
 Aucun template, skeleton, audit Python ou contrat `docs/validation/` n'est créé par cette tranche.
 ## Décision après `alpha.2`
 La gate opérateur de `alpha.2` est `PASS`. Les `48/48` tests Python, les trois audits Markdown, l'audit Android de base et les contrôles Git sont propres ; aucun `alpha.2.fix.N` n'est requis.
 `alpha.3` peut donc traiter le natif, le packaging, la distribution et la validation Android sans rouvrir les contrats de base validés en `alpha.2`.
 ### Vérification Android officielle courante pour `alpha.3`
 La documentation Android officielle courante a été vérifiée le `2026-09-28` sur les responsabilités touchées par cette tranche :
 ```text
 https://developer.android.com/guide/practices/page-sizes
 https://developer.android.com/ndk/guides/abis
 https://developer.android.com/studio/write/lint
 https://developer.android.com/studio/test/command-line
 https://developer.android.com/build/building-cmdline
 https://developer.android.com/google/play/requirements/target-sdk
 ```
 Cette vérification confirme notamment :
 - les politiques de distribution sont évolutives : depuis le `2026-08-31`, Google Play demande pour les applications Android ordinaires nouvelles ou mises à jour un `targetSdk` Android 16 / API `36` ou supérieur, mais cette valeur appartient au canal Play courant et ne devient pas un default PGR universel ;
 - Android 15 introduit les devices configurés avec pages mémoire `16 KB` ; une application composée uniquement de code Java/Kotlin est déjà compatible du point de vue de l'alignement natif, tandis que toute bibliothèque native directe ou transitive impose de vérifier le package réellement livré ;
 - pour Google Play, les applications ciblant Android 15 / API `35` ou supérieur doivent supporter les pages `16 KB` sur les appareils 64 bits ; la documentation courante annonce qu'à partir du `2027-02-01`, les mises à jour non compatibles ne pourront plus être publiées ;
 - pour une application native concernée, la preuve officielle couvre les segments ELF des bibliothèques 64 bits, l'alignement ZIP de l'APK et, pour un AAB, la configuration d'alignement du bundle ; les dépendances natives précompilées font partie du même contrat ;
 - AGP `8.5.1+` et NDK `r28+` rendent aujourd'hui le chemin 16 KB standard plus direct, mais PGR n'en déduit pas de minimum global : le projet doit choisir une toolchain compatible avec ses contraintes et prouver l'artefact final ;
 - Android Lint n'est pas exécuté automatiquement par un build ordinaire : lorsqu'il est applicable, il doit être appelé explicitement sur le module/variant pertinent ;
 - les tests JVM locaux et les tests instrumentés constituent des niveaux distincts ; l'instrumentation s'exécute sur device/émulateur et ne remplace pas à elle seule l'installation/smoke d'un package final lorsque le packaging ou le runtime sont dans le scope ;
 - l'APK reste l'artefact installable adapté aux smokes directs, tandis que l'AAB est un artefact de distribution qui entraîne la génération d'APK par le canal ; un AAB seul ne constitue donc pas une preuve runtime.
 La preuve Games `PAGE_SIZE=16384`, `align 2**14` et `zipalign -P 16` est cohérente avec ces exigences actuelles. Elle reste une preuve historique du corpus et n'est pas rejouée dans PGR, qui ne possède aucun build Android exécutable.
 ### Scope arrêté pour `alpha.3`
 La tranche révise uniquement `610-ANDROID.md` pour :
 1. rendre NDK et ABI strictement conditionnels à la présence de code natif et séparer sélection de toolchain, ABI déclarées et preuve du package ;
 2. inclure les bibliothèques natives précompilées ou transitives dans les preuves de compatibilité ;
 3. clarifier le rôle d'Android Lint comme gate explicite et ciblée, non implicite au build ;
 4. préciser la frontière entre tests JVM, tests instrumentés et smokes device/AVD ;
 5. distinguer APK installable et AAB de distribution sans imposer un full packaging à chaque tranche ;
 6. normaliser le contrat 16 KB de manière conditionnelle au code natif et au canal de distribution, avec revalidation obligatoire des politiques évolutives ;
 7. conserver les détails JNI, Rust, SDL3, `cargo ndk`, les quatre ABI Games et les commandes spécifiques Games hors du profil Android général.
 Aucun owner JNI/Rust/SDL, skeleton Android, audit Python ou contrat `docs/validation/` n'est créé. La décision finale sur l'absence d'artefact supplémentaire reste réservée à `beta.1` après réconciliation.
 ## Décision après `alpha.3` et réconciliation `beta.1`
 La gate opérateur de `alpha.3` est `PASS`. Les `48/48` tests Python, les trois audits Markdown, l'audit Android natif/distribution et les contrôles Git sont propres ; aucun `alpha.3.fix.N` n'est requis.
 La réconciliation beta relit le profil Android révisé contre le corpus Games, [`400-VALIDATION.md`](../rules/400-VALIDATION.md), [`520-JAVA.md`](../rules/520-JAVA.md), [`522-GRADLE.md`](../rules/522-GRADLE.md), [`600-PLATFORMS.md`](../rules/600-PLATFORMS.md) et la revue d'horizon. Elle ne rouvre aucun contrat fonctionnel déjà validé en `alpha.2` / `alpha.3`.
 ### Résolution de la classification initiale
 Les décisions `ADOPT` sont couvertes par les owners existants : structure Android conditionnelle, composition de profils, compatibilité AGP/Gradle/JDK, séparation des niveaux SDK, versioning Android, configuration locale/signing, ABI conditionnelles et validation package/runtime proportionnée.
 Les décisions `KEEP-LOCAL` restent locales à Games : chemin concret `Android/`, Groovy DSL, Gradle système sans Wrapper, versions AGP/Gradle/JDK/Java, niveaux SDK, NDK `r28c`, quatre ABI, `cargo ndk`, bridge JNI, SDL3, modules, Activities, labels et assets. Aucune de ces valeurs ou stacks n'est devenue un `MUST` Android général.
 Les deux `OVERRIDE` initiaux sont résolus par `alpha.2` : l'exemple structurel ne présente plus `gradlew*` comme élément obligatoire et `minSdk` est désormais un contrat produit explicitement justifié plutôt qu'une course vers la valeur la plus basse.
 Le `DEFER` 16 KB a été levé en `alpha.3` après vérification des sources Android officielles courantes, sous forme d'un contrat conditionnel au code natif, au package et au canal de distribution ; aucune version d'outil ni échéance datée n'est transformée en default PGR universel.
 Les autres `DEFER` restent bornés : aucun owner JNI/Rust Android n'est justifié, Tauri reste réservé à `0.1.4` et l'adoption Games à `0.1.5`.
 ### Décision finale d'artefacts Android
 Aucun artefact technique supplémentaire n'est justifié pour `0.1.3`.
 Ne sont donc pas ajoutés :
 ```text
 docs/validation/006-ANDROID_VALIDATION.md
 skeleton Android
 template de build Android générique
 audit Python Android
 owner JNI / Rust Android / SDL
 ```
 La raison est positive et vérifiable :
 - `400-VALIDATION.md` possède déjà la sélection proportionnée des preuves, les catégories `LINT`, `TEST`, `PACKAGE` et `SMOKE`, ainsi que l'autorité du gate opérateur ;
 - `600-PLATFORMS.md` possède la composition et la validation spécialisées des plateformes sans rendre chaque smoke obligatoire ;
 - `520-JAVA.md` et `522-GRADLE.md` restent composés uniquement lorsqu'ils sont applicables et évitent de recopier leurs contrats dans Android ;
 - `610-ANDROID.md` possède désormais les responsabilités spécifiques de SDK, identité applicative, signing, NDK/ABI, Android Lint, niveaux de tests, packaging APK/AAB, distribution et 16 KB ;
 - PGR ne contient aucun build Android exécutable qui justifierait aujourd'hui un skeleton, template ou audit spécialisé supplémentaire.
 Créer un artefact seulement pour refléter la structure de Games ou pour dupliquer `400 + 610` augmenterait la maintenance sans apporter de nouvelle preuve. Si un futur corpus démontre une lacune réutilisable, elle devra être traitée dans une tranche qui possède réellement ce scope.
 ### Frontières après réconciliation
 La beta confirme donc :
 ```text
 Android générique        600 + 610
 Gradle si utilisé        + 522
 Java si présent          + 520
 validation générale      400
 JNI / Rust / SDL         hors 610
 Tauri                    0.1.4
 adoption Games           0.1.5
 ```
 La prochaine tranche peut être `rc.1` si la gate opérateur de `beta.1` confirme cette réconciliation. La RC devra geler le scope Android et préparer le prompt de reprise `0.1.4` sans commencer le réexamen Tauri.
 ## 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.
 Statut opérateur : **PASS**.
 La gate beta confirme `48/48` tests Python, les trois audits Markdown, la réconciliation des owners et l'absence d'artefact Android supplémentaire justifié. Aucun fix ni REPLAN n'est requis.
 ### rc.1 — release candidate
 Statut opérateur : **PASS**.
 La gate RC a confirmé les quatre histories antérieurs `PASS`, le profil Android gelé en révision `5`, le changelog candidat, le prompt `010`, les `48/48` tests, les trois audits Markdown et l'hygiène texte/templates. Aucun owner Android/Java/Gradle/Tauri, template, skeleton, validation, étude technique ou script n'a été modifié pendant la RC.
 Le prompt `010-V0_1_4_START_PROMPT.md` conserve la frontière de release : le réexamen Tauri démarre en `0.1.4` seulement depuis une stable `v0.1.3` réellement taggée et son rapport post-tag `PASS`; l'adoption Games reste `0.1.5` et l'adoption KSP `0.1.6`.
 ### rel.1 — promotion stable
 Première clôture stable de `0.1.3`. La promotion est strictement mécanique : `VERSION = 0.1.3`, `ROADMAP.md` marque `0.1.3` terminée, le `CHANGELOG` perd son marqueur `candidate`, README/index décrivent la réévaluation Android comme stable et le présent plan devient historique. Aucun owner Android/Java/Gradle/Tauri, template, skeleton, validation, étude technique ou script n'est modifié.
 Le résultat opérateur de cette tranche appartient à `history/0.1.3/rel.1.md`, créé seulement après exécution de la gate. Si `rel.1` échoue, son history est conservé et un `rel.1.fix.N` corrige uniquement la fermeture ; la première tranche qui établit réellement la stable est incluse dans le commit `0.1.3` avant le tag `v0.1.3`.
 La vérification post-tag reste séparée : `pgr-0.1.3-publish.001-report.md` ne peut être produit qu'à partir de l'archive du tag réellement publiée et des preuves Git observées. Le prompt `010` ne devient le point de départ effectif de `0.1.4` qu'après cette preuve post-tag `PASS`.
 ## Stratégie de validation
 `alpha.1` reste documentaire et structurel : tests Python PGR, audits Markdown, contrôle des couples delta/history, vérification du prompt `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`.
 Le présent document devient le plan historique de la stable `0.1.3`. La publication du tag et sa vérification post-tag restent séparées de cette clôture pré-tag.
 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.
--- a/docs/rules/610-ANDROID.md
+++ b/docs/rules/610-ANDROID.md
@@ -1,5 +1,5 @@
 <!-- file: docs/rules/610-ANDROID.md -->
-<!-- version: 3 -->
+<!-- version: 5 -->
 # Profil Android
@@ -15,7 +15,7 @@ Les profils Rust/JNI et Tauri ne sont pas définis ici. Ils constituent des comp
 ## Structure du projet
-Pour un dépôt exclusivement Android, les conventions Android normales restent prioritaires et la racine du dépôt MAY être directement le projet Gradle.
+Pour un dépôt exclusivement Android, les conventions Android normales restent prioritaires et la racine du dépôt MAY être directement le projet de build Android.
 Dans un dépôt multi-plateforme où une zone Android distincte est nécessaire, PGR SHOULD utiliser la racine :
@@ -33,23 +33,25 @@ project/
 ├── crates/
 ├── Web/
 └── Android/
-    ├── settings.gradle
+    ├── settings.gradle(.kts)
-    ├── build.gradle
+    ├── build.gradle(.kts)
    ├── gradle.properties
-    ├── gradlew
+    └── <module>/
    ├── gradlew.bat
    └── gradle/
 ```
 Cet exemple décrit une frontière de plateforme, pas une liste obligatoire de fichiers Gradle. Wrapper, version catalog, plugins de convention, modules et autres éléments de build restent gouvernés par la composition réellement choisie et par [`522-GRADLE.md`](522-GRADLE.md).
 Les noms et fichiers exacts restent soumis au projet Android réellement utilisé ; PGR ne crée pas de niveau `Android/` artificiel dans un dépôt qui est déjà exclusivement Android.
 ## Langage applicatif et logique de build
-Java est le langage applicatif Android par défaut du profil PGR lorsqu'aucune API, framework ou contrainte réelle n'impose un autre choix.
+Android ne sélectionne pas à lui seul le langage applicatif du projet. Les profils langage s'appliquent uniquement aux langages réellement présents.
-Kotlin MAY être utilisé lorsqu'une API, un framework ou une intégration l'exige réellement.
+Lorsqu'un projet Android contient du Java, [`520-JAVA.md`](520-JAVA.md) possède les règles Java correspondantes. La présence d'AGP, d'un JDK de build ou d'un script Gradle ne suffit pas à rendre le profil Java applicable au code produit.
-Groovy DSL ou Kotlin DSL MAY être utilisés par Gradle comme langage de configuration. Leur présence dans le build ne transforme pas Kotlin ou Groovy en langage applicatif du projet.
+Un autre langage applicatif MAY être utilisé lorsqu'il correspond à la stack réelle du projet. Le profil Android possède uniquement les contraintes imposées par la plateforme et ne transforme pas un choix de langage local en règle Android générale.
 Groovy DSL ou Kotlin DSL MAY être utilisés par Gradle comme langage de configuration conformément à [`522-GRADLE.md`](522-GRADLE.md). Leur présence dans le build ne détermine pas le langage applicatif.
 Les fichiers Gradle SHOULD rester aussi déclaratifs et courts que raisonnablement possible. Une logique de build importante SHOULD être possédée par une abstraction ou un plugin identifiable plutôt que devenir du code produit caché dans un script Gradle.
@@ -57,7 +59,7 @@ Les annotations fonctionnelles Android ou de frameworks restent autorisées lors
 ## Matrice AGP / Gradle / JDK
-Un projet Android MUST exprimer une chaîne de build compatible.
+Un projet Android qui utilise AGP MUST exprimer une chaîne de build compatible.
 La matrice conceptuelle est :
@@ -66,9 +68,11 @@ Android Gradle Plugin
 ↕
 Gradle
 ↕
-JDK LTS
+JDK de build
 ```
 La version AGP retenue peut également contraindre les niveaux Android SDK supportés par la chaîne de build. Cette compatibilité appartient au scope Android ; les règles Gradle générales restent possédées par [`522-GRADLE.md`](522-GRADLE.md).
 PGR MUST NOT imposer globalement une version Gradle, AGP ou JDK uniquement parce qu'elle est utilisée par un autre projet Android.
 La contrainte applicable peut être :
@@ -80,27 +84,47 @@ version exacte / pin
 latest compatible
 ```
-Le projet choisit la forme la moins restrictive qui reste réellement compatible avec sa stack.
+Le projet choisit la forme la moins restrictive qui reste réellement compatible avec sa stack et effectivement vérifiable.
-Le JDK suit le profil Java : dernière LTS compatible par défaut, LTS plus ancienne lorsqu'une contrainte Android ou de framework l'impose, non-LTS uniquement par exception justifiée.
+Le JDK utilisé pour exécuter Gradle/AGP est une contrainte de build Android même lorsqu'aucun code source Java n'existe. Lorsqu'un projet contient du Java, le niveau Java du code source et du bytecode reste un contrat distinct possédé par [`520-JAVA.md`](520-JAVA.md).
-Lorsque le Gradle Wrapper est retenu, ses fichiers requis sont versionnés et sa version doit satisfaire la matrice réelle AGP/Gradle/JDK.
+PGR MUST NOT confondre :
 ```text
 JDK qui exécute Gradle / AGP
 ≠
 niveau Java du code applicatif
 ```
 Le choix Wrapper ou Gradle système, ainsi que la manière de vérifier la contrainte Gradle, restent possédés par [`522-GRADLE.md`](522-GRADLE.md). Une matrice Android plus étroite MAY raffiner cette contrainte dans le seul scope Android.
 ## `compileSdk`, `targetSdk` et `minSdk`
 Ces trois valeurs représentent des contrats différents.
-`compileSdk` définit l'API Android utilisée pour compiler. Il MAY être récent afin de permettre l'usage des APIs et outils actuels.
+`compileSdk` définit le niveau d'API Android disponible lors de la compilation. Il doit être compatible avec la version AGP réellement utilisée et MAY évoluer sans entraîner mécaniquement une hausse de `targetSdk` ou `minSdk`.
-`targetSdk` déclare le niveau de comportement Android pour lequel l'application a été adaptée. Il MUST respecter les exigences applicables au canal de distribution réellement visé.
+`targetSdk` déclare le niveau Android pour lequel l'application a été adaptée et testée du point de vue des comportements de plateforme. Il MUST respecter les exigences applicables au canal de distribution réellement visé.
-`minSdk` définit la plus ancienne version Android que le produit promet de pouvoir installer et exécuter.
+`minSdk` définit le plus ancien niveau d'API Android que le produit choisit réellement de supporter. Il participe notamment à l'éligibilité d'installation sur les appareils plus anciens.
 PGR MUST NOT déduire une hausse de `minSdk` d'une hausse de `compileSdk` ou `targetSdk`.
-`minSdk` SHOULD rester aussi bas que raisonnablement supportable tant que cela ne compromet pas une capacité nécessaire, une dépendance imposée, la sécurité ou une maintenance raisonnable.
+Le choix de `minSdk` MUST être justifié par le contrat produit et ses contraintes réelles : population visée, capacités nécessaires, dépendances, sécurité, coût de maintenance et preuves de compatibilité. PGR ne privilégie ni le niveau le plus bas possible ni une hausse de confort sans justification.
-Une hausse de `minSdk` est un changement de compatibilité utilisateur et MUST être explicitement justifiée.
+Une hausse de `minSdk` retire explicitement des appareils auparavant éligibles ; elle constitue donc un changement de compatibilité utilisateur et MUST être traitée comme tel.
 ## Identité applicative et namespace
 Pour un module application Android, `applicationId` et `namespace` sont deux contrats distincts.
 `applicationId` identifie l'application installée et distribuée. Pour une application déjà publiée, le modifier ne constitue pas un simple renommage de code : il crée une identité applicative différente du point de vue de la plateforme et des canaux de distribution.
 `namespace` possède l'espace de noms utilisé par le code et les ressources générées du module. Il MAY évoluer indépendamment de `applicationId` lorsque le projet a une raison réelle de dissocier identité distribuée et organisation du code.
 PGR SHOULD conserver `namespace` et `applicationId` alignés lorsque cela suffit, mais MUST NOT les confondre ni dériver implicitement l'identité distribuée d'un renommage de namespace. Toute divergence ou modification d'`applicationId` doit être explicite dans la configuration Android concernée.
 Les valeurs concrètes telles que `com.example.product` appartiennent au projet ; PGR n'impose aucun domaine ou préfixe universel.
 ## `VERSION`, `versionName` et `versionCode`
@@ -135,15 +159,15 @@ lorsqu'un projet ou skeleton réel fournit des fichiers à contrôler. Cet audit
 ## Configuration locale
-`local.properties` est un fichier local Android typique et SHOULD rester hors Git lorsqu'il contient des chemins machine tels que l'emplacement du SDK.
+`local.properties` appartient à l'environnement local du build Android/AGP, notamment pour des chemins machine tels que l'emplacement du SDK. Il SHOULD rester hors Git.
-PGR MUST NOT utiliser `local.properties` comme source normative de configuration partagée du projet.
+PGR MUST NOT utiliser `local.properties` comme source normative de configuration partagée ni comme fourre-tout pour des propriétés locales propres au produit. La documentation Android réserve ce fichier aux propriétés locales comprises par la toolchain Android ; une propriété locale spécifique au projet doit utiliser un mécanisme séparé et explicitement possédé.
-Si l'outil ou l'IDE régénère intégralement ce fichier, aucun fichier exemple n'est nécessaire.
+Les propriétés Gradle partagées, portables et non secrètes restent gouvernées par [`522-GRADLE.md`](522-GRADLE.md). Les chemins machine, credentials, secrets et overrides développeur restent locaux, via variables d'environnement, propriétés utilisateur ou fichier explicitement ignoré selon le besoin réel.
-Lorsqu'une propriété locale obligatoire n'est pas automatiquement reproductible, un template MAY être fourni conformément aux règles générales PGR.
+Si l'outil ou l'IDE régénère intégralement un état local, aucun fichier exemple n'est nécessaire. Lorsqu'une valeur locale obligatoire n'est pas automatiquement reproductible, un template MAY être fourni conformément aux règles générales PGR.
-La même politique s'applique aux fichiers locaux analogues tels que `keystore.properties`, `user.properties` ou des variantes `*.local.properties` lorsqu'ils contiennent des valeurs propres à la machine ou à l'utilisateur.
+Un fichier local tel que `keystore.properties` ou une variante `*.local.properties` MAY exister lorsqu'il possède une responsabilité claire, mais il MUST rester hors Git lorsqu'il contient des secrets ou valeurs propres à la machine.
 ## Signing et secrets
@@ -152,7 +176,7 @@ L'interdiction générale de versionner ou distribuer des secrets reste posséd
 Dans le scope Android, les éléments suivants sont notamment des secrets ou artefacts privés soumis à cette interdiction :
 ```text
-release keystore
+release / upload keystore
 private signing key
 passwords
 credentials
@@ -168,7 +192,9 @@ RELEASE_KEY_ALIAS
 mais MUST NOT contenir leurs valeurs privées.
-Le debug keystore généré automatiquement est local.
+Le debug keystore généré par les outils Android est un état local de développement et ne doit pas être promu comme identité de signing de release.
 Les clés de release ou d'upload appartiennent à une frontière de sécurité durable de l'application publiée. Leur stockage, sauvegarde, rotation ou délégation au canal de distribution doit être décidé explicitement par le projet sans introduire la matière secrète dans Git.
 Le signing de release ne doit pas être requis pour une validation ordinaire de développement sauf lorsque la tranche valide précisément la distribution ou la signature finale.
@@ -203,25 +229,44 @@ Une BOM ou un mécanisme officiel de gestion de versions MAY être utilisé lors
 La politique d'un lockfile Android/Gradle, lorsqu'un projet en utilise un, doit être décidée selon le besoin réel de cet écosystème et du projet. Elle n'est pas déduite automatiquement d'un autre profil.
-## ABI et code natif
+## NDK, ABI et code natif
-Un projet Android purement Java peut ne posséder aucune règle ABI spécifique.
+Un projet Android sans bibliothèque native directe ou transitive n'a pas besoin de NDK ni de matrice ABI propre au produit.
-Dès qu'un projet contient du code natif via NDK, C/C++, Rust ou une autre frontière native, les ABI réellement supportées MUST être déclarées explicitement.
+Dès qu'un projet contient du code natif via NDK, C/C++, Rust, un SDK précompilé ou une autre frontière native, la toolchain native réellement nécessaire et les ABI réellement supportées MUST être explicites.
-Exemples possibles :
+PGR ne fixe ni version NDK ni liste universelle d'ABI. La version NDK MAY être épinglée lorsqu'une reproductibilité, une dépendance ou une exigence de packaging le justifie ; elle ne doit pas être copiée depuis un autre projet par défaut.
 Les mécanismes tels que `abiFilters` MAY exprimer la matrice voulue lorsque Gradle/AGP les utilise. La configuration choisie doit refléter le contrat produit et le canal de distribution plutôt qu'une liste maximale par principe.
 Une ABI annoncée comme supportée doit disposer d'une preuve adaptée à la propriété annoncée. Il faut distinguer au minimum :
 ```text
-arm64-v8a
+compilation native
-armeabi-v7a
+→ la bibliothèque est produite pour l'ABI
-x86_64
+
 packaging
 → la bibliothèque et ses dépendances natives sont présentes dans l'artefact Android attendu
 runtime
 → le package pertinent s'installe et exécute le chemin critique sur un environnement représentant l'ABI / API concernée
 ```
-PGR ne fixe pas une liste universelle d'ABI.
+Une cross-compilation native seule ne prouve donc ni l'intégration dans l'APK/AAB, ni le lifecycle Android, ni l'exécution sur device/AVD.
-Une ABI annoncée comme supportée doit disposer d'une preuve adaptée. Une cross-compilation native seule ne prouve pas l'intégration dans l'APK, le lifecycle Android ni l'exécution sur device/AVD.
+Les bibliothèques natives précompilées ou apportées par un SDK font partie du package final et MUST respecter les mêmes contraintes de compatibilité que les bibliothèques produites par le projet.
-Les règles JNI elles-mêmes appartiennent à un profil spécialisé et restent hors de ce document.
+Les règles JNI, Rust, SDL, `cargo ndk` ou toute autre chaîne native spécialisée appartiennent à leurs owners/projets respectifs et restent hors de ce document tant qu'un profil générique séparé n'est pas justifié.
 ## Android Lint
 Android Lint est une analyse statique Android distincte de la compilation et des tests.
 Lorsqu'un changement touche du code, des resources, un manifest, une configuration Android ou une dépendance susceptible d'être analysée par Lint, la gate SHOULD exécuter la tâche Lint du module et du variant pertinents.
 PGR MUST NOT supposer qu'un build Gradle ordinaire exécute Lint automatiquement. Les commandes exactes (`lint`, `lintDebug`, `lintRelease` ou équivalent) appartiennent au projet et à sa stratégie Wrapper/Gradle système.
 Une baseline Lint MAY être versionnée lorsqu'elle sert réellement à isoler la dette existante des nouvelles régressions. Elle ne doit pas servir à masquer silencieusement de nouveaux diagnostics applicables.
 ## Niveaux de tests Android
@@ -229,20 +274,22 @@ PGR distingue au moins trois niveaux de preuve Android lorsqu'ils sont applicabl
 ```text
 JVM unit
-→ logique ne nécessitant pas le runtime Android
+→ logique exécutée sur la JVM hôte sans runtime Android réel
 instrumented / integration
-→ comportement nécessitant le framework Android
+→ test exécuté sur device ou émulateur avec le framework Android
 smoke device / AVD
-→ application ou package réel dans un environnement Android
+→ application ou package réel installé et chemin critique exécuté dans un environnement Android
 ```
-Un test JVM MUST NOT être enregistré comme preuve d'un comportement réel d'`Activity`, de lifecycle ou de device.
+Un test JVM MUST NOT être enregistré comme preuve d'un comportement réel d'`Activity`, de lifecycle, de package ou de device.
-Un test instrumenté ne remplace pas automatiquement un smoke du package final.
+Un test instrumenté prouve le comportement couvert par son runner et son environnement, mais ne remplace pas automatiquement un smoke du package final lorsque la tranche modifie packaging, signing, native libraries, manifest de lancement ou installation.
-Un appareil physique n'est pas obligatoire pour chaque release. Il devient nécessaire lorsqu'une propriété annoncée dépend d'un matériel ou comportement qui ne peut pas être suffisamment prouvé par AVD.
+Les tâches de tests SHOULD être ciblées par module/variant lorsque cela suffit. Une matrice instrumentée ou multi-device large n'est requise que lorsqu'elle couvre un risque réellement modifié ou une phase de release qui l'exige.
 Un appareil physique n'est pas obligatoire pour chaque release. Il devient nécessaire lorsqu'une propriété annoncée dépend d'un matériel, d'une ABI ou d'un comportement qui ne peut pas être suffisamment prouvé par AVD.
 ## Ordre de validation Android
@@ -274,10 +321,12 @@ Les commandes exactes appartiennent à la matrice du projet ou du skeleton qui p
 ## Manifest et ressources
-`AndroidManifest.xml` MUST déclarer uniquement les permissions et capabilities réellement nécessaires.
+`AndroidManifest.xml` MUST déclarer uniquement les composants, permissions et capabilities de plateforme réellement nécessaires au module.
 Une permission sensible ne doit pas être ajoutée « au cas où ». Son introduction constitue un changement significatif qui doit être visible dans le delta et, lorsque pertinent, dans la documentation de release.
 `applicationId` et `namespace` restent possédés par la configuration Android du module ; PGR SHOULD éviter de créer des sources de vérité concurrentes ou des copies divergentes de ces identités dans des fichiers séparés.
 `src/main/res/` reste la source canonique des ressources Android d'un module standard.
 Dans un projet multi-plateforme, des assets réellement partagés MAY vivre dans un owner commun hors d'Android si leur consommation est définie clairement.
@@ -290,20 +339,54 @@ PGR distingue les rôles des principaux artefacts :
 ```text
 APK debug
-→ développement et smokes ordinaires
+→ développement, installation directe et smokes ordinaires
 APK release
 → validation d'un package release installable lorsque nécessaire
 AAB
-→ artefact de distribution lorsque le canal cible l'exige
+→ artefact de distribution lorsque le canal cible l'exige ; le canal génère ensuite les APK servis aux appareils
 ```
-La phase de release et le scope modifié déterminent l'artefact nécessaire.
+La phase de release, le canal de distribution et le scope modifié déterminent l'artefact nécessaire.
-Une alpha documentaire n'a pas besoin d'un package Android réel si aucun projet Android n'est concerné. Une release d'une application Android peut au contraire nécessiter un package ou smoke réel lorsque `versionName`, `versionCode`, signing ou packaging sont modifiés.
+Un AAB n'est pas directement une preuve d'installation ou d'exécution sur device. Lorsqu'une propriété runtime ou de packaging doit être prouvée, la gate doit aussi utiliser un APK approprié ou les APK dérivés du bundle selon le canal et le risque concernés.
-La promotion stable ne doit pas provoquer mécaniquement un full rebuild sans preuve invalidée ; elle doit toutefois revalider le packaging ciblé lorsque les métadonnées qui entrent dans l'artefact ont changé.
+Une alpha documentaire n'a pas besoin d'un package Android réel si aucun projet Android n'est concerné. Une release d'une application Android peut au contraire nécessiter un package ou smoke réel lorsque `versionName`, `versionCode`, signing, manifest, code natif ou packaging sont modifiés.
 La promotion stable ne doit pas provoquer mécaniquement un full rebuild sans preuve invalidée ; elle doit toutefois revalider le packaging ciblé lorsque les métadonnées ou composants qui entrent dans l'artefact ont changé.
 Les exigences telles que le niveau `targetSdk` minimal, le format de publication ou les délais de compatibilité appartiennent au canal de distribution et évoluent indépendamment de PGR. Un projet publié MUST vérifier la politique officielle courante de son canal avant une release concernée ; PGR ne transforme pas une valeur datée de Google Play en default Android universel.
 ## Pages mémoire 16 KB et packaging natif
 Android supporte des appareils configurés avec des pages mémoire de `16 KB`. Cette responsabilité est conditionnelle : un projet sans bibliothèque native directe ou transitive n'a pas de segments ELF à réaligner, même s'il SHOULD tester les comportements importants sur les environnements Android qu'il prétend supporter.
 Lorsqu'une application contient du natif et que la plateforme ou le canal de distribution exige la compatibilité `16 KB`, le package final MUST être compatible. La preuve doit couvrir les bibliothèques natives du projet ainsi que les dépendances natives précompilées réellement embarquées.
 Pour Google Play, la politique officielle courante vérifiée pendant `0.1.3` impose le support `16 KB` sur appareils 64 bits aux applications ciblant Android 15 / API `35` ou supérieur. Cette politique est évolutive : le projet MUST la revalider auprès de la documentation officielle au moment où elle devient une gate de release.
 Une preuve de compatibilité native `16 KB` SHOULD couvrir, selon l'artefact réellement distribué :
 ```text
 ELF 64 bits
 → segments LOAD des bibliothèques embarquées compatibles avec l'alignement 16 KB
 APK
 → alignement ZIP des bibliothèques natives vérifié sur le package final
 AAB
 → configuration d'alignement du bundle vérifiée lorsque ce bundle est l'artefact de distribution
 runtime
 → smoke sur device/AVD 16 KB lorsque le comportement runtime ou la distribution concernée le justifie
 ```
 Les outils Android officiels peuvent notamment contrôler les segments ELF, `zipalign -P 16` pour un APK et l'alignement déclaré par `bundletool` pour un AAB. Ces commandes sont des moyens de preuve, pas des noms de fichiers ou chemins machine à figer dans PGR.
 Une toolchain récente peut fournir cette compatibilité par défaut, mais PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison. La toolchain retenue doit satisfaire la politique courante du canal et toutes les bibliothèques natives précompilées doivent être compatibles elles aussi.
 Un mode de compatibilité de plateforme ou le simple fait que l'application démarre sur un appareil 16 KB ne remplace pas la preuve de conformité du package natif lorsque le canal de distribution l'exige.
 ## Validation et futurs audits PGR
--- a/history/0.1.3/alpha.1.md
+++ b/history/0.1.3/alpha.1.md
@@ -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.
--- a/history/0.1.3/alpha.2.md
+++ b/history/0.1.3/alpha.2.md
@@ -0,0 +1,99 @@
 <!-- file: history/0.1.3/alpha.2.md -->
 <!-- version: 1 -->
 # History 0.1.3-alpha.2 — contrats Android de base
 ## Statut
 PASS
 La gate opérateur de `0.1.3-alpha.2` exécutée le `2026-09-28` est propre. La révision des contrats Android de base est validée sans fix ; `alpha.3` peut traiter le natif, le packaging, la distribution et la validation Android.
 ## Intégration de `alpha.1`
 Avant la gate `alpha.2`, l'opérateur a intégré le history `PASS` de `alpha.1`, puis commit/push la tranche :
 ```text
 commit local observé    eaa9c39 0.1.3-alpha.1
 push origin/master      585b508..eaa9c39
 ```
 Le history `history/0.1.3/alpha.1.md` est donc présent dans `HEAD` avant validation de `alpha.2`.
 ## Contrôles d'identité
 Les contrôles opérateur ont confirmé :
 ```text
 VERSION                                            0.1.3-alpha.2
 history/0.1.3/alpha.1.md                           présent dans HEAD et PASS
 deltas/0.1.3/alpha.2.md                            présent
 history/0.1.3/alpha.2.md                           absent pendant la gate
 docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md version 2
 docs/rules/610-ANDROID.md                          version 4
 ```
 ## Tests Python
 La suite complète a affiché :
 ```text
 Ran 48 tests in 0.717s
 OK
 ```
 Soit `48/48` tests `PASS`.
 ## Audits Markdown
 Les trois audits documentaires sont propres :
 ```text
 Markdown header audit: clean (254 file(s))
 Markdown table audit: clean (11 table(s), 254 file(s))
 Markdown link audit: clean (323 local link(s), 254 file(s))
 ```
 ## Audit Android de base `alpha.2`
 Le contrôle structurel de la tranche a affiché :
 ```text
 0.1.3 alpha.2 Android base-contract audit: clean (language/build ownership, SDK contracts, app identity, local config and signing clarified)
 ```
 Il a notamment confirmé :
 - Android reste neutre quant au langage applicatif et n'active le profil Java que lorsque Java est réellement présent ;
 - le JDK qui exécute Gradle/AGP reste distinct du niveau Java du code ;
 - `compileSdk`, `targetSdk` et `minSdk` sont des contrats séparés, avec `minSdk` justifié par le contrat produit ;
 - `namespace` et `applicationId` sont explicitement distingués ;
 - `local.properties` reste un état local Android/AGP et ne devient pas une source de configuration partagée ;
 - les secrets et artefacts privés de signing restent hors Git ;
 - l'exemple de structure ne rend plus `gradlew*` obligatoire ;
 - aucun contrat `docs/validation/006-ANDROID_VALIDATION.md` ni history `alpha.2` n'a été anticipé pendant la gate ;
 - les owners Java, Gradle et plateformes restent présents et non absorbés par Android.
 ## 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  VERSION
 A  deltas/0.1.3/alpha.2.md
 M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 M  docs/rules/610-ANDROID.md
 ```
 Aucun contenu NDK/ABI/16 KB, Tauri ou adoption Games n'a été absorbé prématurément dans `alpha.2`.
 ## Décision
 `0.1.3-alpha.2` est validée `PASS`.
 La tranche suivante reste `0.1.3-alpha.3`, bornée aux responsabilités conditionnelles NDK/ABI/native packaging, APK/AAB, Android Lint, niveaux de tests, install/smokes device/AVD et contraintes de distribution modernes réellement applicables.
 Toute règle 16 KB doit être fondée sur une vérification Android officielle courante et rester conditionnelle à la présence de code natif, au type d'artefact et au canal de distribution concerné. Aucun owner JNI/Rust/SDL, skeleton Android ou audit spécialisé ne doit être créé par proximité.
--- a/history/0.1.3/alpha.3.md
+++ b/history/0.1.3/alpha.3.md
@@ -0,0 +1,98 @@
 <!-- file: history/0.1.3/alpha.3.md -->
 <!-- version: 1 -->
 # History 0.1.3-alpha.3 — natif, packaging, distribution et validation Android
 ## Statut
 PASS
 La gate opérateur de `0.1.3-alpha.3` exécutée le `2026-09-28` est propre. Les responsabilités Android conditionnelles liées au code natif, aux ABI, à Lint, aux niveaux de tests, au packaging APK/AAB, aux smokes device/AVD et à la compatibilité 16 KB sont validées sans fix.
 ## Intégration de `alpha.2`
 Avant la gate `alpha.3`, l'opérateur a intégré le history `PASS` de `alpha.2`, puis commit/push la tranche :
 ```text
 commit local observé    1223a70 0.1.3-alpha.2
 push origin/master      eaa9c39..1223a70
 ```
 Le history `history/0.1.3/alpha.2.md` est donc présent dans `HEAD` avant validation de `alpha.3`.
 ## Contrôles d'identité
 Les contrôles opérateur ont confirmé :
 ```text
 VERSION                                            0.1.3-alpha.3
 history/0.1.3/alpha.2.md                           présent dans HEAD et PASS
 deltas/0.1.3/alpha.3.md                            présent
 history/0.1.3/alpha.3.md                           absent pendant la gate
 docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md version 3
 docs/rules/610-ANDROID.md                          version 5
 ```
 ## Tests Python
 La suite complète a affiché :
 ```text
 Ran 48 tests in 0.760s
 OK
 ```
 Soit `48/48` tests `PASS`.
 ## Audits Markdown
 Les trois audits documentaires sont propres :
 ```text
 Markdown header audit: clean (256 file(s))
 Markdown table audit: clean (11 table(s), 256 file(s))
 Markdown link audit: clean (323 local link(s), 256 file(s))
 ```
 ## Audit Android natif/distribution `alpha.3`
 Le contrôle structurel de la tranche a affiché :
 ```text
 0.1.3 alpha.3 Android native/distribution audit: clean (conditional native ownership, lint/tests/package boundaries and 16 KB policy verified)
 ```
 Il a notamment confirmé :
 - NDK et ABI restent conditionnels à la présence de bibliothèques natives directes ou transitives ;
 - PGR ne fixe ni version NDK ni liste universelle d'ABI ;
 - compilation native, présence dans le package et preuve runtime restent trois niveaux de preuve distincts ;
 - Android Lint est une gate explicite et ne doit pas être supposé exécuté par un build Gradle ordinaire ;
 - tests JVM, tests instrumentés et smokes device/AVD restent distincts et proportionnés ;
 - un AAB est un artefact de distribution et ne constitue pas à lui seul une preuve d'installation ou d'exécution ;
 - la compatibilité 16 KB est conditionnelle au code natif, au package et au canal de distribution réellement concernés ;
 - aucune version AGP/NDK, valeur `targetSdk`, liste d'ABI ou commande Games n'est devenue un minimum PGR universel ;
 - aucun owner JNI/Rust/SDL, skeleton Android, audit Python ou contrat `docs/validation/` séparé n'a été créé ;
 - Tauri `0.1.4` et l'adoption Games `0.1.5` restent hors scope.
 ## 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  VERSION
 A  deltas/0.1.3/alpha.3.md
 M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 M  docs/rules/610-ANDROID.md
 ```
 ## Décision
 `0.1.3-alpha.3` est validée `PASS`.
 La tranche suivante reste `0.1.3-beta.1`, dédiée à la réconciliation du profil Android révisé contre Games et les owners `400`, `520`, `522` et `600`, ainsi qu'à la décision finale sur les artefacts Android supplémentaires.
 Si `610-ANDROID.md` et les owners existants suffisent, la beta doit consigner explicitement qu'aucun artefact supplémentaire n'est nécessaire. Si une lacune fonctionnelle impose au contraire un nouvel owner, contrat, template, skeleton ou audit, elle doit déclencher un REPLAN vers une tranche alpha dédiée plutôt que l'introduire opportunément en beta.
--- a/history/0.1.3/beta.1.md
+++ b/history/0.1.3/beta.1.md
@@ -0,0 +1,102 @@
 <!-- file: history/0.1.3/beta.1.md -->
 <!-- version: 1 -->
 # History 0.1.3-beta.1 — réconciliation Android et décision finale d'artefacts
 ## Statut
 PASS
 La gate opérateur de `0.1.3-beta.1` exécutée le `2026-09-28` est propre. La réconciliation confirme que le profil Android révisé reste générique, que les choix Games restent locaux et qu'aucun artefact Android supplémentaire n'est justifié avant la release candidate.
 ## Intégration de `alpha.3`
 Avant la gate `beta.1`, l'opérateur a intégré le history `PASS` de `alpha.3`, puis commit/push la tranche :
 ```text
 commit local observé    8cbd686 0.1.3-alpha.3
 push origin/master      1223a70..8cbd686
 ```
 Le history `history/0.1.3/alpha.3.md` est donc présent dans `HEAD` avant validation de `beta.1`.
 ## Contrôles d'identité
 Les contrôles opérateur ont confirmé :
 ```text
 VERSION                                            0.1.3-beta.1
 history/0.1.3/alpha.3.md                           présent dans HEAD et PASS
 deltas/0.1.3/beta.1.md                             présent
 history/0.1.3/beta.1.md                            absent pendant la gate
 README.md                                          version 24
 docs/000-README.md                                 version 38
 docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md version 4
 docs/rules/610-ANDROID.md                          version 5
 docs/rules/400-VALIDATION.md                       version 1
 docs/rules/520-JAVA.md                             version 4
 docs/rules/522-GRADLE.md                           version 1
 docs/rules/600-PLATFORMS.md                        version 1
 ```
 ## Tests Python
 La suite complète a affiché :
 ```text
 Ran 48 tests in 0.696s
 OK
 ```
 Soit `48/48` tests `PASS`.
 ## Audits Markdown
 Les trois audits documentaires sont propres :
 ```text
 Markdown header audit: clean (258 file(s))
 Markdown table audit: clean (11 table(s), 258 file(s))
 Markdown link audit: clean (327 local link(s), 258 file(s))
 ```
 ## Réconciliation Android `beta.1`
 Le contrôle structurel a affiché :
 ```text
 0.1.3 beta.1 reconciliation audit: clean (Android profile generic, Games-local choices preserved, existing owners sufficient, no extra artifacts justified)
 ```
 Il a notamment confirmé :
 - `400-VALIDATION.md`, `520-JAVA.md`, `522-GRADLE.md`, `600-PLATFORMS.md` et `610-ANDROID.md` restent des owners séparés et composables ;
 - Android ne sélectionne pas Java à lui seul et ne recopie pas les responsabilités Gradle générales ;
 - les versions AGP/Gradle/JDK/Java, niveaux SDK, NDK, quatre ABI et la chaîne Rust/JNI/SDL observés dans Games restent des choix locaux ;
 - aucune valeur Games n'est devenue un `MUST` Android général ;
 - les contraintes natives, de packaging et 16 KB restent conditionnelles ;
 - aucun `docs/validation/006-ANDROID_VALIDATION.md`, skeleton Android, template Android, audit Python Android ou owner JNI/Rust/SDL n'est créé ;
 - les frontières `0.1.4` Tauri et `0.1.5` adoption Games restent intactes.
 ## 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/beta.1.md
 M  docs/000-README.md
 M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 ```
 ## Décision
 `0.1.3-beta.1` est validée `PASS`.
 Aucun fix ni REPLAN n'est requis. La tranche suivante est `0.1.3-rc.1` : elle doit geler le scope Android déjà validé, produire le changelog candidat, préparer `prompts/010-V0_1_4_START_PROMPT.md` et rejouer les gates de release sans introduire de nouvelle règle fonctionnelle Android.
 Le prompt `010` doit préparer uniquement le réexamen Tauri `0.1.4` après publication vérifiée de `v0.1.3`. Il ne doit ni lever le `DEFER` Tauri par anticipation, ni commencer l'adoption Games `0.1.5`.
--- a/history/0.1.3/rc.1.md
+++ b/history/0.1.3/rc.1.md
@@ -0,0 +1,127 @@
 <!-- file: history/0.1.3/rc.1.md -->
 <!-- version: 1 -->
 # History 0.1.3-rc.1 — release candidate Android
 ## Statut
 PASS
 La gate opérateur de `0.1.3-rc.1` exécutée le `2026-09-28` a réussi. Elle confirme le gel du profil Android révisé, l'intégrité des histories antérieurs, le changelog candidat, le prompt de reprise `010`, les tests Python, les audits Markdown et l'hygiène texte/templates avant promotion stable.
 ## Baseline opérateur
 La tranche `0.1.3-beta.1` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `rc.1` :
 ```text
 commit       3f3de72
 message      0.1.3-beta.1
 push         origin/master PASS
 ```
 Après application du delta `rc.1`, les contrôles initiaux ont confirmé :
 ```text
 VERSION                                                   0.1.3-rc.1
 history/0.1.3/beta.1.md                                   présent dans HEAD et le workspace
 deltas/0.1.3/rc.1.md                                      présent
 prompts/010-V0_1_4_START_PROMPT.md                        présent
 history/0.1.3/rc.1.md                                     absent pendant la gate
 CHANGELOG.md                                               version 16
 docs/000-README.md                                        version 39
 docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md       version 5
 ROADMAP.md                                                 version 14
 prompts/010-V0_1_4_START_PROMPT.md                        version 1
 docs/rules/610-ANDROID.md                                 version 5
 docs/rules/710-TAURI.md                                   version 6
 docs/studies/002-TAURI_SKELETON_DECISION.md              version 2
 docs/skeletons/003-WEB_FRONTEND.md                        version 1
 docs/validation/005-WEB_FRONTEND_VALIDATION.md            version 1
 ```
 Le history `beta.1` a été retrouvé avec statut `PASS`.
 ## Gate d'intégration RC
 Le contrôle structurel a affiché :
 ```text
 0.1.3 rc.1 integration audit: clean (4 prior histories, frozen Android profile, candidate changelog and prompt 010 verified)
 ```
 Il a vérifié les quatre histories antérieurs avec statut `PASS` :
 ```text
 alpha.1   PASS
 alpha.2   PASS
 alpha.3   PASS
 beta.1    PASS
 ```
 Avant application du présent history, `rc.1.md` est la seule tranche `0.1.3` possédant un delta sans history.
 La gate a également confirmé :
 - le `CHANGELOG` candidat `0.1.3` sans détails de tranches ;
 - le profil Android `610-ANDROID.md` gelé en révision `5` sans généralisation de `targetSdk 36`, `minSdk 21`, NDK r28, quatre ABI, Gradle 9.7.1, AGP 9.4.0 ou JDK 25 ;
 - la composition Android avec les owners génériques sans créer d'owner JNI/Rust/SDL, skeleton Android ou contrat de validation redondant ;
 - la distinction entre SDK, identité applicative, natif/ABI, Lint, niveaux de tests, APK/AAB et contraintes 16 KB conditionnelles ;
 - la roadmap `0.1.3` à `0.1.7` sans réservation de `0.1.8` ;
 - le maintien du `DEFER` Tauri jusqu'au réexamen `0.1.4` ;
 - le prompt `010` ciblant `0.1.4-alpha.1` uniquement depuis une future archive du tag `v0.1.3` et son rapport post-tag réel ;
 - l'absence de création anticipée du skeleton Tauri et le maintien des adoptions Games `0.1.5` et KSP `0.1.6` hors scope.
 ## Tests et audits PGR
 La suite Python globale a exécuté `48` tests, tous réussis :
 ```text
 Ran 48 tests in 0.745s
 OK
 ```
 Les audits documentaires sont propres :
 ```text
 Markdown header audit: clean (261 file(s))
 Markdown table audit: clean (11 table(s), 261 file(s))
 Markdown link audit: clean (337 local link(s), 261 file(s))
 ```
 L'hygiène texte/templates a également réussi :
 ```text
 0.1.3 rc.1 text/template hygiene: clean
 ```
 Les templates TOML Rust/Cargo et JSON Web ont été parsés ; aucun retour chariot, whitespace final ni fichier texte sans newline finale n'a été détecté dans le corpus contrôlé.
 ## Contrôles Git
 `git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
 Le statut indexé transmis avant ajout du présent history est exactement :
 ```text
 M  CHANGELOG.md
 M  VERSION
 A  deltas/0.1.3/rc.1.md
 M  docs/000-README.md
 M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 A  prompts/010-V0_1_4_START_PROMPT.md
 ```
 Le scope correspond exactement à la RC annoncée. Aucun owner Android, Java, Gradle ou Tauri, template, skeleton, validation, étude technique ou script d'audit n'a été modifié pendant la RC.
 ## Décision
 `0.1.3-rc.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
 La transition autorisée est la promotion mécanique pré-tag :
 ```text
 0.1.3-rel.1
 ```
 Cette promotion ne doit pas rouvrir le scope fonctionnel. Elle doit uniquement présenter `0.1.3` comme stable, produire sa propre gate pré-tag et préparer le handoff de publication sans anticiper le rapport post-tag.
--- a/history/0.1.3/rel.1.md
+++ b/history/0.1.3/rel.1.md
@@ -0,0 +1,149 @@
 <!-- file: history/0.1.3/rel.1.md -->
 <!-- version: 1 -->
 # History 0.1.3-rel.1 — promotion stable pré-tag
 ## Statut
 PASS
 La gate opérateur de `0.1.3-rel.1` exécutée le `2026-09-28` a réussi. Elle confirme la promotion mécanique de la release candidate vers la stable `0.1.3`, la cohérence des histories antérieurs, la présentation stable du profil Android, les tests PGR, les audits documentaires et l'hygiène texte/templates avant création du tag.
 ## Baseline opérateur
 La tranche `0.1.3-rc.1` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `rel.1` :
 ```text
 commit       a9fba6c
 message      0.1.3-rc.1
 push         origin/master PASS
 ```
 Après application du delta `rel.1`, les contrôles initiaux ont confirmé :
 ```text
 VERSION                                                   0.1.3
 history/0.1.3/rc.1.md                                     présent dans HEAD et le workspace
 deltas/0.1.3/rel.1.md                                     présent
 prompts/010-V0_1_4_START_PROMPT.md                        présent
 history/0.1.3/rel.1.md                                    absent pendant la gate
 README.md                                                  version 25
 ROADMAP.md                                                 version 15
 CHANGELOG.md                                               version 17
 docs/000-README.md                                        version 40
 docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md        version 6
 ```
 Le history `rc.1` a été retrouvé avec statut `PASS`.
 La présentation stable est établie :
 ```text
 ROADMAP.md     0.1.3 marqué terminé
 CHANGELOG.md   entrée `## 0.1.3` sans suffixe `(candidate)`
 README.md      profil Android réévalué contre Games présenté comme stable
 docs index     plan 009 classé historique
 ```
 ## Gate stable pré-tag
 Le contrôle structurel a affiché :
 ```text
 0.1.3 rel.1 stable gate audit: clean (5 prior histories, rel.1 pending, stable Android presentation and post-tag Tauri handoff coherent)
 ```
 Il a vérifié les cinq histories antérieurs avec statut `PASS` :
 ```text
 alpha.1   PASS
 alpha.2   PASS
 alpha.3   PASS
 beta.1    PASS
 rc.1      PASS
 ```
 Avant application du présent history, `rel.1.md` est la seule tranche `0.1.3` possédant un delta sans history.
 La gate a également confirmé :
 - `0.1.3` terminé dans la roadmap ;
 - `0.1.4` à `0.1.7` engagés sans réservation de `0.1.8` ;
 - le `CHANGELOG` stable sans suffixe `(candidate)` et sans détails de tranches ;
 - le plan `009` classé historique ;
 - le profil Android `610-ANDROID.md` gelé en révision `5` ;
 - l'absence de généralisation de `targetSdk 36`, `minSdk 21`, NDK r28, quatre ABI, Gradle 9.7.1, AGP 9.4.0 ou JDK 25 ;
 - la composition Android avec les owners génériques existants sans création d'owner JNI/Rust/SDL, de skeleton Android ni de contrat de validation redondant ;
 - les contrats Android stabilisés pour SDK, identité applicative, natif/ABI, Android Lint, niveaux de tests, APK/AAB et contraintes 16 KB conditionnelles ;
 - `0.1.4` réservé au réexamen Tauri, sans création anticipée du skeleton ;
 - `0.1.5` et `0.1.6` réservés respectivement aux adoptions Games et KSP ;
 - le prompt `010` préparé pour démarrer `0.1.4` uniquement depuis le tag réel `v0.1.3` et un rapport post-tag `publish.001` `PASS` ;
 - la convention de clôture `rel.N`, puis commit stable `X.Y.Z` avant création du tag.
 ## Validation Android
 Les décisions Android issues du corpus Games ont été réconciliées avant la RC et `rel.1` n'a modifié aucun owner technique.
 La promotion stable n'a donc pas simulé de toolchain Android, Gradle, AGP, JDK ou NDK absente du dépôt PGR. Elle a rejoué les gates réellement possédées par PGR afin de vérifier que la promotion documentaire et les métadonnées de release n'ont invalidé aucune propriété du référentiel.
 Les choix Games qui restent locaux n'ont pas été promus en minima PGR universels et aucun artefact Android supplémentaire n'a été créé pendant la clôture.
 ## Tests et audits PGR
 La suite Python globale a exécuté `48` tests, tous réussis :
 ```text
 Ran 48 tests in 0.735s
 OK
 ```
 Les audits documentaires sont propres :
 ```text
 Markdown header audit: clean (263 file(s))
 Markdown table audit: clean (11 table(s), 263 file(s))
 Markdown link audit: clean (337 local link(s), 263 file(s))
 ```
 L'hygiène texte/templates a également affiché :
 ```text
 0.1.3 rel.1 text/template hygiene: clean
 ```
 Les templates TOML Rust/Cargo et JSON Web ont été parsés avec succès ; aucun retour chariot, whitespace final ni fichier texte sans newline finale n'a été détecté dans le corpus contrôlé.
 ## Contrôles Git
 `git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
 Le statut indexé transmis avant ajout du présent history est exactement :
 ```text
 M  CHANGELOG.md
 M  README.md
 M  ROADMAP.md
 M  VERSION
 A  deltas/0.1.3/rel.1.md
 M  docs/000-README.md
 M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
 ```
 Le scope correspond exactement à la promotion stable annoncée. Aucun owner Android/Java/Gradle/Tauri, template, skeleton, validation, étude technique ou script d'audit n'a été modifié pendant `rel.1`.
 ## Décision
 `0.1.3-rel.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
 Conformément à la convention stable PGR, le présent history doit être inclus dans le commit final nommé exactement :
 ```text
 0.1.3
 ```
 Le commit stable doit être poussé sur `origin/master` avant création du tag annoté `v0.1.3`.
 Le rapport `pgr-0.1.3-publish.001-report.md` ne pourra être produit qu'après réception des preuves post-publication réelles : identité du commit stable, propreté du workspace, objet et cible déréférencée du tag local, références distantes du tag et archive ZIP téléchargée depuis le tag Gitea.
 Le prompt `010-V0_1_4_START_PROMPT.md` ne devient la reprise effective de `0.1.4` qu'après un rapport post-tag `PASS`.
--- a/prompts/010-V0_1_4_START_PROMPT.md
+++ b/prompts/010-V0_1_4_START_PROMPT.md
@@ -0,0 +1,98 @@
 <!-- file: prompts/010-V0_1_4_START_PROMPT.md -->
 <!-- version: 1 -->
 # Prompt de démarrage 0.1.4 — réexamen Tauri et skeleton contrôlé
 ## Baseline et cible
 Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`.
 La baseline attendue au démarrage effectif de `0.1.4` est l'archive source téléchargée depuis le tag Gitea `v0.1.3`, accompagnée du rapport post-tag `pgr-0.1.3-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`.
 Version cible : `0.1.4`. Première tranche attendue : `0.1.4-alpha.1`.
 Les corpus principaux attendus pour réexaminer Tauri sont des archives autoritaires récentes de `khadhroony-solana-project` et `sasedev-games`. Si aucune baseline plus récente n'est explicitement fournie, les dernières baselines Tauri déjà auditées par PGR restent des références de comparaison, sans être présumées représenter l'état courant des projets :
 ```text
 khadhroony-solana-project-v0.3.17.zip  2a9cabcb9f147a348dcf8d24df8bc6c5029089b6d49feb17bd4a42b4293c329a
 games-v0.3.6.zip                       ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
 ```
 Une archive source peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu'elle ne peut contenir.
 ## Reprise manuelle après publication
 Après vérification réelle de l'archive du tag `v0.1.3` et du rapport post-tag `PASS`, la consigne de nouvelle session doit suivre le pattern de [`../docs/templates/003-NEW_SESSION_PROMPT.md`](../docs/templates/003-NEW_SESSION_PROMPT.md) et citer les artefacts réellement obtenus.
 La forme attendue, si les noms et le statut sont confirmés, est :
 ```text
 Partir de l'archive pgr-v0.1.3.zip téléchargée depuis le tag Gitea v0.1.3 et du rapport post-tag pgr-0.1.3-publish.001-report.md. Lire et exécuter prompts/010-V0_1_4_START_PROMPT.md. Vérifier intégralement la stable PGR et les baselines autoritaires fournies de KSP/Games avant de réexaminer le DEFER du skeleton Tauri et de préparer 0.1.4-alpha.1, sans commencer l'adoption Games réservée à 0.1.5 ni l'adoption KSP réservée à 0.1.6.
 ```
 Ce texte ne doit pas être remis comme preuve de publication avant le `publish.001 PASS` réel.
 ## Mission
 Réexaminer objectivement la décision `DEFER` enregistrée dans [`../docs/studies/002-TAURI_SKELETON_DECISION.md`](../docs/studies/002-TAURI_SKELETON_DECISION.md) à partir des corpus Tauri réellement fournis, du profil [`../docs/rules/710-TAURI.md`](../docs/rules/710-TAURI.md), des owners Web stabilisés par `0.1.1`, du profil Android stabilisé par `0.1.3` et des règles de skeletons.
 La release `0.1.4` ne part pas du principe qu'un skeleton Tauri doit être créé. Elle doit confirmer, modifier ou abandonner le candidat historique selon les preuves courantes. Si un skeleton contrôlé est justifié, il doit sélectionner et composer des owners existants plutôt que devenir leur propriétaire implicite.
 `alpha.1` MUST commencer par :
 1. auditer indépendamment la stable `v0.1.3` et son rapport post-tag lorsqu'il est fourni ;
 2. auditer les corpus KSP/Games réellement fournis et inventorier leurs hosts Tauri actuels, sans supposer que les layouts, versions ou plugins historiques sont encore représentatifs ;
 3. relire `710-TAURI.md`, `220-SKELETONS.md`, `510-RUST_CARGO.md`, `003-WEB_FRONTEND.md`, les owners Web `530/540/550/560`, `005-WEB_FRONTEND_VALIDATION.md`, `600-PLATFORMS.md`, `610-ANDROID.md`, l'étude `002-TAURI_SKELETON_DECISION.md` et la revue d'horizon `003` ;
 4. vérifier la documentation Tauri 2 officielle courante pour les points susceptibles d'avoir évolué ;
 5. créer le plan `0.1.4` avant toute matérialisation importante ;
 6. classifier les choix observés avec `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` et décider explicitement si les conditions de sortie du report historique sont réellement satisfaites par le corpus courant.
 ## Questions à instruire
 La release doit notamment réexaminer :
 - pertinence réelle d'un skeleton Tauri organisationnel pour les nouveaux projets contrôlés ;
 - composition avec `001-PROJECT_GOVERNANCE_FOUNDATION`, `002-RUST_CARGO_WORKSPACE` et `003-WEB_FRONTEND` sans duplication normative ;
 - host Cargo direct versus layout `src-tauri/`, en distinguant convention organisationnelle et possibilité supportée par Tauri ;
 - statut de `frontend/`, Vite, TypeScript, Sass et Bootstrap : choix éventuels du skeleton/projet, jamais obligations Tauri implicites ;
 - TS-RS pour les DTO Rust/TypeScript lorsque cette frontière est réellement présente, sans le rendre universel ;
 - ownership de `tauri.conf.json`, `build.rs`, capabilities/permissions, plugins, commandes et hooks frontend ;
 - ajout manuel de plugins versus commandes de commodité telles que `cargo tauri add`, avec revue explicite des modifications générées ;
 - `devUrl`, `frontendDist`, outputs/caches et séparation source/généré ;
 - stratégie de version produit `CANONICAL / MIRROR-EXACT / MIRROR-STABLE` sans churn cérémoniel ;
 - distinction entre preuves Rust, preuves frontend, `tauri dev`, `tauri build` et packaging plateforme ;
 - projets mobiles générés/modifiés par Tauri et composition avec les profils Android/iOS applicables sans absorber leurs responsabilités dans `710` ;
 - nécessité éventuelle de templates techniques ou d'un contrat de validation Tauri supplémentaire, uniquement si un besoin non couvert est démontré ;
 - compatibilité du candidat avec plusieurs package managers et plusieurs choix frontend supportés.
 ## Frontières obligatoires
 `0.1.4` MUST NOT :
 - migrer KSP ou Games vers PGR ;
 - créer le skeleton Tauri parce que la roadmap le mentionne ou parce que les cinq prérequis Web sont désormais couverts ;
 - transformer Vite, TypeScript, Sass, Bootstrap, npm, TS-RS, `frontend/` ou l'absence de `src-tauri/` en obligations universelles du profil Tauri sans preuve correspondante ;
 - rouvrir Android `0.1.3` sauf défaut transversal réellement démontré ;
 - démarrer l'adoption Games `0.1.5` ou l'adoption KSP `0.1.6` ;
 - intégrer WASM au host Tauri par défaut ;
 - créer un owner serveur Rust, deployment/operations ou iOS par proximité ;
 - réserver une nouvelle release au-delà de la roadmap engagée sans revue d'horizon justifiée.
 Les personnalisations produit, plugins concrets, fenêtres, CSP, ports, targets de bundle, icônes, ABI et autres valeurs spécifiques aux corpus restent locales sauf invariant réutilisable démontré.
 ## Principes
 - Le skeleton doit composer des owners ; il ne remplace pas un owner manquant.
 - Les conditions de sortie historiques autorisent un réexamen, pas une création automatique.
 - Partir des hosts Tauri réellement présents dans les corpus courants et comparer leurs convergences/divergences.
 - Vérifier les capacités officielles courantes de Tauri 2 avant de figer une convention organisationnelle.
 - Maintenir une séparation claire entre host Rust, frontend Web, intégration Tauri et plateformes mobiles.
 - Utiliser les toolchains propriétaires des preuves : Cargo/Rust pour Rust, toolchain frontend pour le Web, CLI Tauri pour l'orchestration Tauri et outils plateforme pour les artefacts mobiles.
 - Ne pas exiger un `tauri build` complet lorsqu'une modification ne touche pas l'intégration ou le packaging ; inversement, ne pas assimiler un `cargo check` ou un build frontend isolé à une preuve Tauri complète lorsque la propriété dépend des hooks/capabilities/bundling.
 - Conserver `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` afin de préparer les futures adoptions `0.1.5` et `0.1.6` sans les commencer.
 ## Workflow
 Suivre [`../RULES.md`](../RULES.md), [`../docs/rules/210-WORKFLOW.md`](../docs/rules/210-WORKFLOW.md), [`../docs/rules/220-SKELETONS.md`](../docs/rules/220-SKELETONS.md), [`../docs/rules/230-ADOPTION.md`](../docs/rules/230-ADOPTION.md) et [`../docs/rules/400-VALIDATION.md`](../docs/rules/400-VALIDATION.md).
 La séquence reste : delta → gate opérateur → history constaté → application du history → commit/push → delta suivant. Les commandes de handoff sont remises automatiquement conformément à [`../docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`](../docs/templates/006-OPERATOR_COMMAND_HANDOFF.md).
Author	SHA1	Message	Date
SinuS Von SifriduS	fe80dbbb73	0.1.3	2026-09-28 13:04:53 +02:00
SinuS Von SifriduS	a9fba6c5c3	0.1.3-rc.1	2026-09-28 13:00:04 +02:00
SinuS Von SifriduS	3f3de726c2	0.1.3-beta.1	2026-09-28 12:49:31 +02:00
SinuS Von SifriduS	8cbd686f47	0.1.3-alpha.3	2026-09-28 11:32:26 +02:00
SinuS Von SifriduS	1223a705c0	0.1.3-alpha.2	2026-09-28 10:41:03 +02:00
SinuS Von SifriduS	eaa9c399be	0.1.3-alpha.1	2026-09-28 10:28:40 +02:00