Files

SinuS Von SifriduS a9fba6c5c3 0.1.3-rc.1

2026-09-28 13:00:04 +02:00

40 KiB

Raw Blame History

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`

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 :

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 :

retirer du layout d'exemple toute présentation implicite du Wrapper comme élément obligatoire ;
rendre Android neutre quant au langage applicatif et composer 520-JAVA.md seulement lorsque du Java est réellement présent ;
séparer clairement JDK de build AGP/Gradle et niveau Java du code ;
reformuler minSdk comme contrat produit explicite, sans objectif artificiel de valeur la plus basse ;
expliciter la séparation namespace / applicationId ;
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 :

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 :

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 ;
inclure les bibliothèques natives précompilées ou transitives dans les preuves de compatibilité ;
clarifier le rôle d'Android Lint comme gate explicite et ciblée, non implicite au build ;
préciser la frontière entre tests JVM, tests instrumentés et smokes device/AVD ;
distinguer APK installable et AAB de distribution sans imposer un full packaging à chaque tranche ;
normaliser le contrat 16 KB de manière conditionnelle au code natif et au canal de distribution, avec revalidation obligatoire des politiques évolutives ;
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, 520-JAVA.md, 522-GRADLE.md, 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 :

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 :

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 :

rendre les exemples de structure neutres vis-à-vis du choix Wrapper/système déjà possédé par 522-GRADLE.md ;
confirmer qu'Android reste neutre quant au langage applicatif et n'active 520-JAVA.md que lorsque Java est réellement présent ;
rendre la politique minSdk explicitement orientée contrat produit/compatibilité plutôt que « minimum le plus bas » comme objectif en soi ;
clarifier ownership Android versus build tool pour AGP, Gradle, JDK et propriétés locales ;
mieux séparer NDK/ABI/package Android des détails JNI/Rust/SDL spécifiques ;
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 ;
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.

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 : à valider.

Geler le scope Android, préparer le changelog candidat et prompts/010-V0_1_4_START_PROMPT.md sans commencer Tauri. Rejouer les validations PGR de release et vérifier les frontières 0.1.4 / 0.1.5.

Aucune nouvelle fonctionnalité normative Android ne doit apparaître en RC. Le profil 610-ANDROID.md reste en révision 5; la RC ne fait qu'établir la présentation candidate, le handoff vers 0.1.4 et les preuves de cohérence de release.

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.

40 KiB Raw Blame History