0.1.2-rc.1
This commit is contained in:
92
prompts/009-V0_1_3_START_PROMPT.md
Normal file
92
prompts/009-V0_1_3_START_PROMPT.md
Normal file
@@ -0,0 +1,92 @@
|
||||
<!-- file: prompts/009-V0_1_3_START_PROMPT.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# 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).
|
||||
Reference in New Issue
Block a user