0.1.3-alpha.2

docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Plan 0.1.3 — réévaluation pratique Android
 
@@ -323,6 +323,48 @@ La classification initiale guide la réévaluation ; elle n'est pas une adoption
 | 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.
+
 ## 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.