0.1.3

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 39 -->
+<!-- version: 40 -->
 
 # Documentation PGR
 
@@ -22,7 +22,7 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
 
 ## Points d'entrée de 0.1.3
 
-- [`plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan actif de la réévaluation Android ; `beta.1` est `PASS` et `rc.1` gèle le scope avant promotion stable.
+- [`plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.3`, de l'audit Games à la stabilisation du profil Android générique et au handoff Tauri `0.1.4`.
 - [`rules/610-ANDROID.md`](rules/610-ANDROID.md) — owner Android révisé : contrats SDK/identité/signing, natif/ABI, Lint, niveaux de tests, packaging/distribution et 16 KB conditionnel, sans absorber les choix propres à Games.
 - [`rules/520-JAVA.md`](rules/520-JAVA.md) et [`rules/522-GRADLE.md`](rules/522-GRADLE.md) — owners composés uniquement lorsqu'un projet Android contient réellement du Java ou utilise Gradle.
 - [`rules/600-PLATFORMS.md`](rules/600-PLATFORMS.md) et [`rules/400-VALIDATION.md`](rules/400-VALIDATION.md) — contrats généraux de plateforme et de preuve auxquels la spécialisation Android doit rester conforme.

docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md

@@ -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