# Prompt de démarrage 0.1.3 — réévaluation pratique Android ## Baseline et cible Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`. La baseline attendue au démarrage effectif de `0.1.3` est l'archive source téléchargée depuis le tag Gitea `v0.1.2`, accompagnée du rapport post-tag `pgr-0.1.2-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`. Version cible : `0.1.3`. Première tranche attendue : `0.1.3-alpha.1`. Le corpus principal attendu pour confronter Android à un projet réel est une archive autoritaire récente de `sasedev-games`. Si aucune baseline plus récente n'est explicitement fournie, la baseline de référence déjà auditée reste : ```text 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.2` 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.2.zip téléchargée depuis le tag Gitea v0.1.2 et du rapport post-tag pgr-0.1.2-publish.001-report.md. Lire et exécuter prompts/009-V0_1_3_START_PROMPT.md. Vérifier intégralement la stable PGR, puis réévaluer le profil Android à partir du corpus Games autoritaire avant de préparer 0.1.3-alpha.1, sans absorber le scope Tauri réservé à 0.1.4 ni les décisions produit propres aux jeux/SDL. ``` Ce texte ne doit pas être remis comme preuve de publication avant le `publish.001 PASS` réel. ## Mission Réévaluer pratiquement [`../docs/rules/610-ANDROID.md`](../docs/rules/610-ANDROID.md) à partir du corpus Games réellement fourni, en composant explicitement les owners Java et Gradle stabilisés par `0.1.2`, puis matérialiser uniquement les règles, validations, templates ou skeletons Android génériques dont la valeur réutilisable est démontrée. `alpha.1` MUST commencer par : 1. auditer indépendamment la stable `v0.1.2` et son rapport post-tag lorsqu'il est fourni ; 2. auditer le corpus Games réellement fourni, en particulier sa structure `Android/`, sa matrice AGP/Gradle/JDK, ses SDK/NDK/ABI/JNI, manifests/resources, packaging et preuves opérateur historiques ; 3. relire `610-ANDROID.md`, [`../docs/rules/520-JAVA.md`](../docs/rules/520-JAVA.md), [`../docs/rules/522-GRADLE.md`](../docs/rules/522-GRADLE.md), [`../docs/rules/600-PLATFORMS.md`](../docs/rules/600-PLATFORMS.md) et [`../docs/studies/003-V0_1_0_HORIZON_REVIEW.md`](../docs/studies/003-V0_1_0_HORIZON_REVIEW.md) ; 4. créer le plan `0.1.3` avant toute normalisation importante ; 5. classifier les décisions observées avec `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` plutôt que copier Games dans PGR. ## Questions à instruire La release doit notamment réexaminer : - structure Android dans un dépôt exclusivement Android versus multi-plateforme, sans imposer artificiellement `Android/` lorsque le dépôt n'en a pas besoin ; - composition réelle avec Java et Gradle sans rendre Java obligatoire pour tout projet Android ni réabsorber les owners `520/522` dans `610` ; - matrice Android Gradle Plugin / Gradle / JDK et forme de contrainte la moins restrictive réellement compatible ; - séparation entre `compileSdk`, `targetSdk` et `minSdk`, avec justification produit/compatibilité plutôt que copie des valeurs Games ; - Android SDK, NDK et toolchains natives uniquement lorsqu'elles sont réellement applicables ; - ABI, JNI, bibliothèques natives, packaging et frontières de responsabilité entre Android, langage natif et produit ; - manifests, resources, namespaces/application IDs, variantes et configuration de build ; - signing, secrets, keystores et propriétés locales, avec séparation stricte entre configuration versionnée et état machine sensible ; - outputs/caches Android/Gradle, `local.properties` et autres états locaux à exclure de Git ; - packaging APK/AAB, bundles de release et contrôles réellement nécessaires ; - Android Lint, tests JVM/instrumentés, installation sur device/AVD et smokes, sélectionnés proportionnellement au changement ; - contraintes de distribution modernes telles que l'alignement mémoire/16 KB uniquement lorsqu'elles sont démontrées par une exigence Android réelle et possédées au bon niveau ; - nécessité éventuelle d'un contrat de validation ou skeleton Android, sans en créer un par symétrie si le profil et les outils officiels suffisent. ## Frontières obligatoires `0.1.3` MUST NOT : - migrer Games vers PGR ; - transformer SDL3, la logique des jeux, leurs Activities concrètes ou leur architecture produit en règles Android générales ; - rouvrir Java/Maven/Gradle `0.1.2` sauf défaut transversal réellement démontré ; - réexaminer ou créer le skeleton Tauri, réservé à `0.1.4` ; - absorber les contraintes Android propres à Tauri dans le profil Android général sans preuve indépendante ; - démarrer l'adoption Games `0.1.5` ; - créer un owner WASM, serveur Rust ou deployment/operations par proximité ; - réserver une nouvelle release au-delà de la roadmap engagée sans nouvelle revue d'horizon justifiée. Une contrainte observée uniquement à cause de SDL, d'un moteur de jeu, de Tauri ou d'une chaîne JNI particulière doit rester classifiée comme responsabilité produit/framework/spécialisation lorsqu'elle n'est pas générique à Android. ## Principes - Partir des responsabilités réellement exercées par Games, pas d'un catalogue théorique Android. - Les versions AGP, Gradle, JDK, SDK et NDK du corpus ne deviennent pas des `MUST` PGR sans preuve générique. - Utiliser les outils Android/Gradle officiels lorsqu'une validation porte sur un artefact exécutable réel ; un audit Python read-only ne remplace ni Gradle, ni Android Lint, ni les toolchains SDK/NDK, ni une preuve device lorsque celle-ci est réellement requise. - Ne pas imposer un Wrapper, une ABI, un device/AVD, une variante ou une commande `clean` par cérémonie. - Conserver la distinction `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` afin de préparer l'adoption Games `0.1.5` sans la commencer. - Conserver une frontière nette avec Tauri afin que `0.1.4` puisse réexaminer son propre `DEFER` avec la stable Android alors disponible. ## Workflow Suivre [`../RULES.md`](../RULES.md), [`../docs/rules/210-WORKFLOW.md`](../docs/rules/210-WORKFLOW.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).