Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.1.3

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-28 13:04:53 +02:00
parent a9fba6c5c3
commit fe80dbbb73
8 changed files with 458 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md -->
<!-- version: 5 -->
<!-- version: 6 -->
# Plan 0.1.3 — réévaluation pratique Android
@@ -563,17 +563,19 @@ La gate beta confirme `48/48` tests Python, les trois audits Markdown, la récon
### rc.1 — release candidate
Statut opérateur : **à valider**.
Statut opérateur : **PASS**.
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`.
La gate RC a confirmé les quatre histories antérieurs `PASS`, le profil Android gelé en révision `5`, le changelog candidat, le prompt `010`, les `48/48` tests, les trois audits Markdown et l'hygiène texte/templates. Aucun owner Android/Java/Gradle/Tauri, template, skeleton, validation, étude technique ou script n'a été modifié pendant la RC.
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.
Le prompt `010-V0_1_4_START_PROMPT.md` conserve la frontière de release : le réexamen Tauri démarre en `0.1.4` seulement depuis une stable `v0.1.3` réellement taggée et son rapport post-tag `PASS`; l'adoption Games reste `0.1.5` et l'adoption KSP `0.1.6`.
### 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.
Première clôture stable de `0.1.3`. La promotion est strictement mécanique : `VERSION = 0.1.3`, `ROADMAP.md` marque `0.1.3` terminée, le `CHANGELOG` perd son marqueur `candidate`, README/index décrivent la réévaluation Android comme stable et le présent plan devient historique. Aucun owner Android/Java/Gradle/Tauri, template, skeleton, validation, étude technique ou script n'est modifié.
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`.
Le résultat opérateur de cette tranche appartient à `history/0.1.3/rel.1.md`, créé seulement après exécution de la gate. Si `rel.1` échoue, son history est conservé et un `rel.1.fix.N` corrige uniquement la fermeture ; la première tranche qui établit réellement la stable est incluse dans le commit `0.1.3` avant le tag `v0.1.3`.
La vérification post-tag reste séparée : `pgr-0.1.3-publish.001-report.md` ne peut être produit qu'à partir de l'archive du tag réellement publiée et des preuves Git observées. Le prompt `010` ne devient le point de départ effectif de `0.1.4` qu'après cette preuve post-tag `PASS`.
## Stratégie de validation
@@ -604,6 +606,8 @@ Un REPLAN ne sert pas à ajouter des artefacts pour remplir la release ; il corr
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`.
Le présent document devient le plan historique de la stable `0.1.3`. La publication du tag et sa vérification post-tag restent séparées de cette clôture pré-tag.
La prochaine release après publication vérifiée de `0.1.3` reste :
```text