pgr/docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md

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 :

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 :

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 :

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 :

48 / 48 tests PASS

Les audits documentaires donnent :

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 :

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 :

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 :

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 :

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 :

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/ :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

.gradle/
**/build/
local.properties
libs/*.aar
**/src/main/jniLibs/

La baseline ne versionne ni local.properties, ni keystore, ni credentials de signing. Les AAR SDL3 sont également exclus et apportés localement.

Les builds bundleRelease historiques ne nécessitent aucun secret versionné ; sans configuration de signature externe ils produisent des AAB de validation qui ne sont pas présentés comme artefacts directement publiables sur un store.

Cette pratique corrobore la séparation entre configuration partagée, état machine local, outputs générés, dépendances locales non vendorizées et secrets de release.

Packaging APK / AAB et preuves runtime

Les histories 0.3.3 fournissent des preuves opérateur successives :

• APK Debug Snake puis Snake/Reflex construits et inspectés ;
• AAB Release Snake/Reflex produits ;
• contenu natif vérifié sous lib/<abi>/ dans les APK et base/lib/<abi>/ dans les AAB ;
• installation et démarrage sur AVD x86_64 ;
• installation et démarrage sur appareil ARM64 réel ;
• preuve API 21/x86 pour le minimum supporté ;
• preuve Android 15/API 35 x86_64 avec PAGE_SIZE=16384 ;
• répétition large en beta puis RC après stabilisation.

Ces preuves montrent qu'un build natif ou une cross-compilation ne suffit pas à prouver à lui seul le package final ou le comportement runtime.

Contrainte 16 KB observée

Games a vérifié pour ses bibliothèques natives 64 bits arm64-v8a et x86_64 des segments ELF LOAD alignés au moins à 2**14, puis un zipalign -P 16 réussi sur les APK. Un AVD ps16k a fourni une preuve runtime avec getconf PAGE_SIZE=16384.

Cette preuve est importante, mais elle reste liée à un besoin de distribution Android réel et à la présence de bibliothèques natives. 0.1.3 doit vérifier la forme générique et actuelle de cette exigence auprès des sources Android officielles avant d'en faire une règle normative PGR. Elle ne doit pas devenir une gate universelle pour un projet Android sans code natif ou sans canal de distribution concerné.

Classification initiale des décisions Games

La classification initiale guide la réévaluation ; elle n'est pas une adoption de Games.

Observation ou décision	Classification	Traitement prévu
Dépôt multi-plateforme avec zone Android distincte	ADOPT	conserver un contrat conditionnel : racine Android dédiée lorsque l'architecture en a réellement besoin, sans l'imposer à un dépôt Android-only
Composition Android + Gradle + Java seulement lorsqu'applicables	ADOPT	maintenir la composition explicite 600 + 610 + 522 [+ 520]
Matrice AGP / Gradle / JDK explicitement compatible	ADOPT	conserver le principe et vérifier que la contrainte choisie reste la moins restrictive réellement démontrée
Séparation JDK de build / niveau Java	ADOPT	réutiliser les owners 520/522, sans copier les versions Games
Distinction compileSdk / targetSdk / minSdk	ADOPT	conserver trois contrats séparés et justifier leurs changements selon leur responsabilité
VERSION distinct du versionName de produits indépendants	ADOPT	conserver la synchronisation uniquement lorsqu'un même release train la justifie
État local, outputs Gradle et secrets hors Git	ADOPT	consolider local.properties, caches, build outputs et signing au bon owner
ABI déclarées et prouvées lorsqu'il existe du code natif	ADOPT	garder le contrat conditionnel sans liste universelle
APK/AAB, install et smoke sélectionnés selon le risque	ADOPT	intégrer à la validation Android proportionnée, sans full matrix systématique
Chemin exact Android/ de Games	KEEP-LOCAL	preuve d'un layout multi-plateforme valide, pas layout obligatoire de tout dépôt Android
Groovy DSL	KEEP-LOCAL	522-GRADLE.md reste neutre Groovy/Kotlin DSL
Gradle système >= 9.6.0 sans Wrapper	KEEP-LOCAL	choix Games compatible avec 522; ne pas interdire ni imposer le Wrapper
AGP 9.4.0, Gradle 9.7.1, JDK 25.0.4.1, Java 17	KEEP-LOCAL	valeurs de preuve, jamais minima PGR génériques
SDK 36/36/21, NDK r28c, SDL3 3.4.16	KEEP-LOCAL	contraintes Games/framework/produit
Quatre ABI et cibles Rust correspondantes	KEEP-LOCAL	matrice produit/toolchain, pas contrat Android universel
cargo ndk, bridge JNI, extraction SDL3 et staging jniLibs	KEEP-LOCAL	spécialisation Rust/SDL/JNI hors du profil Android général
Modules common / game-*, Activities, labels et assets	KEEP-LOCAL	architecture produit Games
Exemple PGR de layout contenant systématiquement gradlew*	OVERRIDE	réviser l'exemple pour ne pas présenter le Wrapper comme élément structurel obligatoire
Formulation PGR poussant minSdk « aussi bas que raisonnablement supportable »	OVERRIDE	réexaminer vers un choix de compatibilité produit explicitement justifié, sans préférence artificielle vers le minimum le plus bas
Détail normatif 16 KB / page size	DEFER	vérifier les exigences Android/distribution officielles courantes avant normalisation ciblée
Création d'un owner JNI/Rust Android	DEFER	aucun owner nouveau sans besoin générique démontré ; Games reste un corpus spécialisé
Skeleton ou contrat de validation Android dédié	DEFER	décider seulement après révision de 610 et analyse des lacunes restantes
Skeleton Tauri	DEFER	réservé à 0.1.4
Adoption réelle de Games	DEFER	réservée à 0.1.5

Réévaluation initiale de 610-ANDROID.md

Le profil courant contient déjà une part importante des contrats démontrés par Games : structure conditionnelle, matrice AGP/Gradle/JDK, niveaux SDK séparés, version Android, configuration locale, signing, modules, dépendances, ABI conditionnelles, niveaux de tests, validation proportionnée, manifests/resources et artefacts APK/AAB.

0.1.3 ne doit donc pas réécrire ce profil pour produire du volume. La révision doit se concentrer sur les écarts réellement démontrés :

1. rendre les exemples de structure neutres vis-à-vis du choix Wrapper/système déjà possédé par 522-GRADLE.md ;
2. confirmer qu'Android reste neutre quant au langage applicatif et n'active 520-JAVA.md que lorsque Java est réellement présent ;
3. rendre la politique minSdk explicitement orientée contrat produit/compatibilité plutôt que « minimum le plus bas » comme objectif en soi ;
4. clarifier ownership Android versus build tool pour AGP, Gradle, JDK et propriétés locales ;
5. mieux séparer NDK/ABI/package Android des détails JNI/Rust/SDL spécifiques ;
6. intégrer uniquement les contraintes de distribution modernes réellement vérifiées et applicables, notamment 16 KB si les sources officielles courantes le justifient ;
7. déterminer si le profil suffit à exprimer la validation Android ou si un contrat docs/validation/ apporte une réduction réelle de duplication.

Mission de 0.1.3

La release doit produire un profil Android pratiquement éprouvé contre Games tout en restant utilisable par un projet Android qui ne ressemble pas à Games.

Elle MUST :

• conserver Android comme spécialisation de 600-PLATFORMS.md ;
• composer explicitement 522-GRADLE.md et 520-JAVA.md uniquement lorsqu'ils sont réellement applicables ;
• distinguer build tool, SDK Android, compatibilité utilisateur et contraintes de distribution ;
• traiter NDK et ABI uniquement pour les projets natifs ;
• séparer les responsabilités Android des détails JNI, Rust, SDL, Tauri et produit ;
• conserver manifests, resources, application identity, configuration locale, signing, packaging et validation chez le bon owner ;
• sélectionner Android Lint, tests, package, install et smokes proportionnellement au changement ;
• vérifier toute contrainte de distribution évolutive contre une source Android officielle courante avant de la figer dans PGR ;
• ne créer un template, skeleton, audit ou contrat de validation supplémentaire que s'il matérialise un contrat réutilisable absent et démontré.

Elle MUST NOT :

• modifier ou adopter Games ;
• transformer SDL3, cargo ndk, les Activities Games ou leur architecture produit en règles Android générales ;
• rouvrir Java/Maven/Gradle 0.1.2 sans défaut transversal démontré ;
• réexaminer ou créer le skeleton Tauri avant 0.1.4 ;
• absorber les contraintes Tauri Android dans 610 sans preuve indépendante ;
• démarrer l'adoption Games 0.1.5 ;
• créer un owner WASM, serveur Rust, JNI ou deployment par proximité ;
• réserver une release au-delà de 0.1.7 sans nouvelle revue d'horizon justifiée.

Artefacts candidats

Owner normatif principal :

docs/rules/610-ANDROID.md

Artefacts à décider, non promis par le plan :

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 :

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.