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 :

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 et citer les artefacts réellement obtenus.

La forme attendue, si les noms et le statut sont confirmés, est :

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

auditer indépendamment la stable v0.1.2 et son rapport post-tag lorsqu'il est fourni ;
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 ;
relire 610-ANDROID.md, ../docs/rules/520-JAVA.md, ../docs/rules/522-GRADLE.md, ../docs/rules/600-PLATFORMS.md et ../docs/studies/003-V0_1_0_HORIZON_REVIEW.md ;
créer le plan 0.1.3 avant toute normalisation importante ;
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, ../docs/rules/210-WORKFLOW.md, ../docs/rules/230-ADOPTION.md et ../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.

7.1 KiB Raw Blame History