v0.2.0-rel.001

docs/plans/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/000-README.md -->
-<!-- version: 27 -->
+<!-- version: 28 -->
 
 # Plans KSP
 
@@ -15,7 +15,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
 - [`004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](004-V0_1_2_LOGGING_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.2`, établi par `0.1.2-pre.001` puis consolidé jusqu'à `0.1.2-rel.001`.
 - [`005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](005-V0_1_3_CONFIG_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.3 — Configuration foundation`, établi par `0.1.3-pre.001`, exécuté jusqu'à `pre.015` puis publié par `0.1.3-rel.001`.
 - [`006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](006-V0_1_4_CONFIG_DESKTOP_PLAN.md) — plan historique clôturé de la release stable `0.1.4 — ksp-app-config-desk`, établi par `0.1.4-pre.001` puis consolidé jusqu'à `0.1.4-rel.001`.
-- [`007-V0_2_0_SERIES_PLANNING.md`](007-V0_2_0_SERIES_PLANNING.md) — plan actif de `0.2.0`, ouvert par `pre.001`, consolidé par `pre.002` puis finalisé/audité par `pre.003` avec l'ordre `0.2.1+`, la stratégie RAW/CORE/DECODE/SPECIALIZED, les vertical slices Program, les fiches de release et le prompt finalisé `0.2.1`.
+- [`007-V0_2_0_SERIES_PLANNING.md`](007-V0_2_0_SERIES_PLANNING.md) — plan historique clôturé de la release stable `0.2.0`, ouvert par `pre.001`, consolidé par `pre.002`, audité par `pre.003` puis publié par `rel.001`; il fixe l'ordre `0.2.1+`, la stratégie RAW/CORE/DECODE/SPECIALIZED, les vertical slices Program et le prompt `0.2.1`.
 
 Le `pre.001` de chaque release fonctionnelle peut introduire son propre plan détaillé lorsque la release s'ouvre.
 

docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
-<!-- version: 28 -->
+<!-- version: 29 -->
 
 # Séquence des releases fonctionnelles KSP
 
@@ -351,7 +351,7 @@ Par défaut :
 
 # Série `0.2.x` — accès Solana, Wallet et contrats initiaux
 
-`0.2.0` reste la release de cadrage. `0.2.0-pre.002` a fixé le début de la séquence fonctionnelle suivante et `0.2.0-pre.003` en réalise l'audit final de cohérence avant publication stable :
+`0.2.0` est publiée stable par `0.2.0-rel.001`. `pre.002` a fixé le début de la séquence fonctionnelle suivante et `pre.003` en a réalisé l'audit final de cohérence :
 
 ```text
 0.2.1  on-chain transport HTTP foundation
@@ -538,7 +538,7 @@ Chaque release concrète doit pouvoir être ouverte et clôturée dans une seule
 
 Les releases `0.1.1` à `0.1.4` sont stables et leurs plans/prompts restent historiques.
 
-# Ouverture de `0.2.0`
+# Clôture stable de `0.2.0` et ouverture de `0.2.1`
 
 `0.2.0` a été ouverte par :
 
@@ -552,4 +552,4 @@ prompts/005-V0_2_0_START_PROMPT.md
 prompts/006-V0_2_1_START_PROMPT.md
 ```
 
-Le prompt `0.2.1` est finalisé côté contenu par `0.2.0-pre.003`; il ne devient applicable qu'après publication stable de `v0.2.0`.
+`0.2.0-rel.001` publie ce cadrage sous la version stable `0.2.0`. Après validation du commit de release et création du tag `v0.2.0`, le prompt `0.2.1` devient le point d'entrée actif de la série.

docs/plans/007-V0_2_0_SERIES_PLANNING.md

@@ -1,8 +1,10 @@
 <!-- file: docs/plans/007-V0_2_0_SERIES_PLANNING.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Plan `0.2.0` — audit bot3 et planification de la série `0.2.x`
 
+> **Statut : plan historique clôturé par `0.2.0-rel.001`.** La première release fonctionnelle suivante est `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation`, ouverte avec `prompts/006-V0_2_1_START_PROMPT.md`.
+
 ## 1. Statut et objectif
 
 `0.2.0` est une release intermédiaire de transition, d'audit et de planification. Elle ne livre pas directement une nouvelle capacité Solana complète ; elle transforme l'expérience de `khadhroony-bot3` en une trajectoire KSP cohérente, bornée et compatible avec les règles stabilisées en `0.1.x`.
@@ -698,15 +700,15 @@ Il est volontairement prématuré de figer maintenant chaque numéro jusqu'aux D
 
 Aucune `pre.004` n'est prévue. Elle ne serait créée que si la validation de `pre.003` révélait un nouveau défaut ou une omission substantielle qui ne peut pas être honnêtement corrigée dans `rel.001`.
 
-Après validation de `pre.003`, `0.2.0-rel.001` doit rester une publication de cadrage :
+`0.2.0-rel.001` publie le cadrage sans nouvelle décision architecturale :
 
-- passer `workspace.package.version` à `0.2.0` ;
-- marquer `0.2.0` stable dans ROADMAP/indices/plans ;
-- ajouter l'entrée stable `0.2.0` au `CHANGELOG.md` ;
-- créer `deltas/0.2.0/rel.001.md` ;
-- exécuter les validations globales de clôture disponibles ;
-- commit `v0.2.0-rel.001`, puis tag stable Git `v0.2.0` ;
-- ne modifier le prompt `0.2.1` que si une validation de clôture révèle un écart réel.
+- `workspace.package.version = 0.2.0` ;
+- `0.2.0` est marqué stable dans ROADMAP/indices/plans ;
+- `CHANGELOG.md` reçoit l'entrée stable `0.2.0` ;
+- `deltas/0.2.0/rel.001.md` enregistre la publication ;
+- les validations finales de `pre.003` communiquées par le user sont reportées dans la matrice de clôture ;
+- le commit attendu est `v0.2.0-rel.001`, puis le tag stable Git `v0.2.0` ;
+- le prompt `0.2.1` reste inchangé et devient le prochain point d'entrée après le tag stable.
 
 La matrice de clôture durable est `docs/validation/002-V0_2_0_SERIES_PLANNING.md`.