# 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//` dans les APK et `base/lib//` 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. ## Réévaluation initiale de `610-ANDROID.md` Le profil courant contient déjà une part importante des contrats démontrés par Games : structure conditionnelle, matrice AGP/Gradle/JDK, niveaux SDK séparés, version Android, configuration locale, signing, modules, dépendances, ABI conditionnelles, niveaux de tests, validation proportionnée, manifests/resources et artefacts APK/AAB. `0.1.3` ne doit donc pas réécrire ce profil pour produire du volume. La révision doit se concentrer sur les écarts réellement démontrés : 1. rendre les exemples de structure neutres vis-à-vis du choix Wrapper/système déjà possédé par `522-GRADLE.md` ; 2. confirmer qu'Android reste neutre quant au langage applicatif et n'active `520-JAVA.md` que lorsque Java est réellement présent ; 3. rendre la politique `minSdk` explicitement orientée contrat produit/compatibilité plutôt que « minimum le plus bas » comme objectif en soi ; 4. clarifier ownership Android versus build tool pour AGP, Gradle, JDK et propriétés locales ; 5. mieux séparer NDK/ABI/package Android des détails JNI/Rust/SDL spécifiques ; 6. intégrer uniquement les contraintes de distribution modernes réellement vérifiées et applicables, notamment 16 KB si les sources officielles courantes le justifient ; 7. déterminer si le profil suffit à exprimer la validation Android ou si un contrat `docs/validation/` apporte une réduction réelle de duplication. ## Mission de `0.1.3` La release doit produire un profil Android pratiquement éprouvé contre Games tout en restant utilisable par un projet Android qui ne ressemble pas à Games. Elle MUST : - conserver Android comme spécialisation de `600-PLATFORMS.md` ; - composer explicitement `522-GRADLE.md` et `520-JAVA.md` uniquement lorsqu'ils sont réellement applicables ; - distinguer build tool, SDK Android, compatibilité utilisateur et contraintes de distribution ; - traiter NDK et ABI uniquement pour les projets natifs ; - séparer les responsabilités Android des détails JNI, Rust, SDL, Tauri et produit ; - conserver manifests, resources, application identity, configuration locale, signing, packaging et validation chez le bon owner ; - sélectionner Android Lint, tests, package, install et smokes proportionnellement au changement ; - vérifier toute contrainte de distribution évolutive contre une source Android officielle courante avant de la figer dans PGR ; - ne créer un template, skeleton, audit ou contrat de validation supplémentaire que s'il matérialise un contrat réutilisable absent et démontré. Elle MUST NOT : - modifier ou adopter Games ; - transformer SDL3, `cargo ndk`, les Activities Games ou leur architecture produit en règles Android générales ; - rouvrir Java/Maven/Gradle `0.1.2` sans défaut transversal démontré ; - réexaminer ou créer le skeleton Tauri avant `0.1.4` ; - absorber les contraintes Tauri Android dans `610` sans preuve indépendante ; - démarrer l'adoption Games `0.1.5` ; - créer un owner WASM, serveur Rust, JNI ou deployment par proximité ; - réserver une release au-delà de `0.1.7` sans nouvelle revue d'horizon justifiée. ## Artefacts candidats Owner normatif principal : ```text docs/rules/610-ANDROID.md ``` Artefacts à décider, non promis par le plan : ```text docs/validation/006-ANDROID_VALIDATION.md seulement si 400 + 610 ne suffisent pas à éviter une duplication réelle docs/skeletons/... aucun skeleton Android par défaut scripts/audit_*.py aucun audit Android par symétrie templates/android/... aucun template de build sans sujet générique réellement éprouvé ``` Un skeleton Android n'est pas justifié par le seul fait que Games possède un projet Android. Il ne devient candidat que si la révision révèle un ensemble minimal, stable et réutilisable de décisions qu'un projet nouveau ne peut pas simplement obtenir des outils Android officiels et des owners PGR existants. ## Trajectoire prévisionnelle de `0.1.3` ### alpha.1 — audit de stable, corpus et plan Vérifier `v0.1.2`, son rapport `publish.001`, le corpus Games, ses preuves Android historiques, les owners `520`, `522`, `600`, `610` et la revue d'horizon. Créer le présent plan et la classification initiale sans modifier encore `610-ANDROID.md`. ### alpha.2 — structure, composition et contrats Android de base Réviser `610-ANDROID.md` sur les points démontrés par le corpus : structure Android-only versus multi-plateforme, composition avec Gradle/Java, matrice AGP/Gradle/JDK sans duplication de `522`, responsabilités `compileSdk`/`targetSdk`/`minSdk`, versioning Android, namespaces/application IDs, manifests/resources, configuration locale et signing. Les valeurs exactes Games restent des exemples de preuve, pas des defaults PGR. ### alpha.3 — natif, packaging, distribution et validation Réviser les responsabilités conditionnelles NDK/ABI/native packaging, APK/AAB, Android Lint, tests JVM/instrumentés, install/smoke device/AVD et contraintes de distribution applicables. Avant toute règle évolutive telle que 16 KB, confronter la preuve Games à la documentation Android officielle courante et rédiger le contrat de manière conditionnelle au canal de distribution et au type d'artefact réellement concernés. Ne pas créer d'owner JNI/Rust/SDL. Si un contrat de validation séparé apparaît réellement nécessaire, déclencher un REPLAN avant la beta plutôt que l'ajouter opportunément. ### beta.1 — réconciliation et décision d'artefacts Relire le profil Android révisé contre Games, `520-JAVA.md`, `522-GRADLE.md`, `600-PLATFORMS.md`, `400-VALIDATION.md` et la revue d'horizon. Vérifier qu'aucun choix Games n'est devenu un `MUST` général, que les contraintes natives restent conditionnelles, et que le futur réexamen Tauri dispose d'une frontière Android stable sans avoir été commencé. Décider explicitement qu'aucun artefact supplémentaire n'est nécessaire si `610` et les owners existants suffisent. Un artefact nouveau qui exigerait du contenu fonctionnel supplémentaire entraîne un REPLAN vers une tranche alpha dédiée. ### rc.1 — release candidate Geler le scope Android, préparer le changelog candidat et le prompt de reprise `0.1.4` sans commencer Tauri. Rejouer les validations PGR de release et vérifier les frontières `0.1.4` / `0.1.5`. ### rel.1 — promotion stable Promouvoir mécaniquement `0.1.3` après RC `PASS` : version stable, roadmap, changelog, README/index et plan historique. Aucun nouveau changement fonctionnel Android ne doit entrer dans la clôture. La preuve post-tag reste séparée et doit être produite depuis l'archive du tag `v0.1.3` réellement publiée avant de démarrer `0.1.4`. ## Stratégie de validation `alpha.1` reste documentaire et structurel : tests Python PGR, audits Markdown, contrôle des couples delta/history, vérification du prompt `009`, des owners `520/522/600/610`, du plan et du scope Git. PGR lui-même ne contient aucun projet Android exécutable. Une modification de `610-ANDROID.md` ne doit donc pas simuler un build AGP/Gradle/SDK absent du dépôt PGR. Les preuves Games historiques servent à démontrer des responsabilités et des frontières ; elles ne deviennent pas une gate PGR locale et ne doivent pas être présentées comme si les APK/AAB avaient été reconstruits pendant `0.1.3`. Lorsqu'une propriété relève d'un build Android réel, les outils officiels restent autoritaires : Gradle/AGP, Android Lint, SDK/NDK, outils de packaging, installation et device/AVD selon le contrat à prouver. Un audit Python read-only ne remplace aucun de ces outils. La validation reste proportionnée : pas de `clean` systématique, pas de full matrix ABI/device pour un changement documentaire, pas de signing release pour une tranche qui ne valide pas la distribution signée. ## Déclencheurs de REPLAN Un REPLAN est requis notamment si : - la révision montre qu'une responsabilité aujourd'hui dans `610` appartient en réalité à un owner séparé nécessaire immédiatement ; - un contrat de validation Android séparé apporte une valeur concrète que `400 + 610` ne peuvent pas exprimer sans duplication ; - un skeleton Android réellement réutilisable devient nécessaire et peut être démontré sans copier Games ; - une contrainte supposée Android générale dépend en réalité de SDL, Rust, JNI, Tauri ou d'un canal de distribution particulier ; - une exigence Android officielle courante contredit une règle `610` existante ; - la release ne peut pas rester bornée sans absorber le scope Tauri `0.1.4` ou l'adoption Games `0.1.5`. Un REPLAN ne sert pas à ajouter des artefacts pour remplir la release ; il corrige le découpage lorsqu'une responsabilité réelle l'exige. ## Clôture et transition La roadmap possède déjà un horizon suffisant jusqu'à `0.1.7`. Aucune nouvelle release n'est réservée par `0.1.3-alpha.1`. La prochaine release après publication vérifiée de `0.1.3` reste : ```text 0.1.4 — domaine Tauri : réexamen du DEFER et matérialisation du skeleton contrôlé seulement si les conditions de sortie sont réellement satisfaites ``` L'adoption réelle de Games reste ensuite réservée à `0.1.5`, afin qu'elle puisse comparer son état local avec une stable Android et une stable Tauri réellement publiées.