v0.2.0-rel.001

CHANGELOG.md

@@ -1,10 +1,14 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Changelog KSP
 
 Ce changelog résume uniquement les releases KSP considérées comme stables, dans l'ordre chronologique décroissant. Les détails de chaque livraison restent dans `deltas/`.
 
+## 0.2.0 — Audit bot3 et planification de la série `0.2.x` — 2026-08-17
+
+`0.2.0` stabilise le cadrage de la prochaine phase fonctionnelle de KSP après audit de `khadhroony-bot3`. La release fixe l'ordre `0.2.1+` autour du transport HTTP Solana, du Wallet `.kspwallet`, de Wallet Desk, des transports WebSocket/LaserStream/Yellowstone, du transport off-chain de prix, de `ksp-interface-lib` et de `ksp-program-api`; elle impose la couverture exhaustive des surfaces Transport documentées avec warnings KSP pour les opérations deprecated/obsolete encore fonctionnelles et unstable/experimental. Elle stabilise également la progression durable `RAW -> CORE -> DECODE -> SPECIALIZED`, RAW/CORE sans décodage Program, puis des vertical slices complets par groupe à partir de DECODE, avec priorité Solana Core, SPL token/trading, metadata token, Anchor, Meteora/Raydium/Pump/Orca, routing et Market Desk progressive. Le prompt `prompts/006-V0_2_1_START_PROMPT.md` ouvre `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation` avec un gate de sizing imposant qu'une release concrète reste clôturable dans une seule session.
+
 ## 0.1.4 — Config Desk — 2026-08-17
 
 `0.1.4` stabilise `ksp-app-config-desk` comme première application desktop/Tauri spécialisée et modèle de référence des futures applications KSP. La release valide de bout en bout les contrats de `ksp-config-lib` et le lifecycle de `ksp-logging-lib` : shell splash/main, inventaire et diagnostics des documents Config, profils et provenance sûre, management `.env` avec shadowing et reveal Secret privilégié, éditeur Logging typé multi-profils/multi-sinks, persistence atomique, hot reload transactionnel, rollback, sélection runtime explicite, génération observable, fichiers de logs distincts par lancement, bridge frontend vers la façade KSP et panneau Test Logging pour démontrer le routing niveau/target/domain. Elle ajoute également les audits desktop/ownership/sécurité, un registre extensible `file_id -> éditeur spécialisé`, une baseline Logging de release `info`/`warn`, et prépare `0.2.0` comme release intermédiaire d’audit de `khadhroony-bot3` et de planification du reste de `0.2.x`.

Cargo.toml

@@ -1,12 +1,12 @@
 # file: Cargo.toml
-# version: 94
+# version: 95
 
 [workspace]
 resolver = "3"
 members = ["crates/ksp-app-config-desk", "crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-logging-lib"]
 
 [workspace.package]
-version = "0.2.0-pre.3"
+version = "0.2.0"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project"

ROADMAP.md

@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 23 -->
+<!-- version: 24 -->
 
 # Roadmap KSP
 
@@ -39,10 +39,11 @@ Le roadmap décrit les objectifs à atteindre et les grandes étapes prévues. U
 
 ### Cadrage
 
-- [/] `0.2.0` — Auditer bot3, fixer l'ordre de `0.2.x`, actualiser l'architecture et préparer `0.2.1`.
+- [X] `0.2.0` — Audit bot3, ordre de `0.2.x`, architecture durable et prompt `0.2.1` stabilisés par `0.2.0-rel.001`.
 - [X] `0.2.0-pre.001` — Méthode d'audit, cartographie initiale et matrice provisoire.
 - [X] `0.2.0-pre.002` — Fixer l'ordre fonctionnel, la discipline de sizing, le pipeline RAW/CORE/DECODE/SPECIALIZED et préparer le prompt `0.2.1`.
-- [/] `0.2.0-pre.003` — Audit de cohérence final : corriger les règles résiduelles supersédées, compléter les fiches `0.2.1+`, préserver les TODO bot3 utiles et finaliser le prompt `0.2.1`.
+- [X] `0.2.0-pre.003` — Audit de cohérence final : règles résiduelles supersédées corrigées, fiches `0.2.1+` complétées, TODO bot3 utiles préservés et prompt `0.2.1` finalisé.
+- [X] `0.2.0-rel.001` — Publication stable du cadrage `0.2.x`; prochaine release : `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation`.
 
 ### Releases fonctionnelles décidées/pressenties
 

deltas/0.2.0/rel.001.md

@@ -0,0 +1,118 @@
+<!-- file: deltas/0.2.0/rel.001.md -->
+<!-- version: 1 -->
+
+# Delta `0.2.0-rel.001` — publication stable du cadrage `0.2.x`
+
+## Base validée
+
+La base requise est le commit :
+
+```text
+e721464a7c2cbf4c564757061a2a44dd7913facb
+v0.2.0-pre.003
+```
+
+Le user a communiqué le 2026-08-17 les validations suivantes avec succès :
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --workspace --all-targets
+cargo test --workspace
+git diff --check
+git status --short
+```
+
+`cargo test --workspace` exécute 241 tests avec succès ; le probe diagnostic d'overhead de `ksp-logging-lib` reste volontairement ignoré. `git diff --check` et `git status --short` ne produisent aucune sortie après le commit `pre.003`.
+
+## Objet
+
+Publier sous version stable le cadrage `0.2.0` déjà audité et validé, sans ajouter de capacité N2 ni modifier les décisions architecturales finalisées en `pre.003`.
+
+## Changements
+
+- `workspace.package.version` passe de `0.2.0-pre.3` à `0.2.0` ;
+- `CHANGELOG.md` reçoit l'entrée stable `0.2.0` ;
+- `ROADMAP.md` marque `0.2.0` et `0.2.0-pre.003` réalisés et enregistre `rel.001` ;
+- l'index documentaire marque `007-V0_2_0_SERIES_PLANNING.md` comme plan historique clôturé ;
+- la séquence fonctionnelle enregistre `0.2.0` stable et `0.2.1` comme prochaine release ;
+- le plan `007` enregistre sa clôture par `rel.001` ;
+- la matrice `docs/validation/002-V0_2_0_SERIES_PLANNING.md` enregistre les preuves opérateur finales de `pre.003` ;
+- le prompt `prompts/006-V0_2_1_START_PROMPT.md` reste inchangé et devient le point d'entrée de la prochaine release après création du tag stable.
+
+## Surface stable publiée
+
+`0.2.0` stabilise notamment :
+
+- l'ordre fonctionnel de `0.2.1+` : HTTP Solana -> Wallet -> Wallet Desk -> WebSocket standard -> Helius LaserStream WebSocket -> Yellowstone gRPC standard -> off-chain prix -> app prix -> Interface -> Program API ;
+- `ksp-onchain-transport-lib` indépendant de `ksp-config-lib`, Store et Program, avec settings publics propres au transport et adapter Config -> Transport ;
+- la règle de couverture exhaustive des méthodes/opérations documentées pour chaque surface Transport ciblée ;
+- la conservation des méthodes deprecated/obsolete encore fonctionnelles avec warning KSP, et le warning KSP des méthodes unstable/experimental ;
+- la progression durable `RAW -> CORE -> DECODE -> SPECIALIZED` ;
+- RAW et CORE sans decoder Program, complétés horizontalement avec persistence/replay/jobs/workers/apps selon besoin ;
+- à partir de DECODE, des vertical slices groupe par groupe : wire -> decode -> materialize -> specialized -> prepare -> policy -> execute -> scenario Devnet ;
+- l'intégration des composants satellites dans leur groupe protocolaire, par exemple Meteora vaults avec Meteora et Pump fees avec Pump ;
+- la priorité Solana Core -> SPL token/trading -> metadata token -> Anchor -> Meteora/Raydium/Pump/Orca -> Market Desk V1 -> Jupiter/OKX -> Market Desk V2 -> trading-adjacent -> décodage généraliste ;
+- le gate de sizing : une prerelease vise environ 15–20 minutes et une release concrète doit rester clôturable dans une seule session de chat, sinon elle est redécoupée avant l'implémentation lourde.
+
+## Hors périmètre
+
+`0.2.0-rel.001` ne modifie pas :
+
+- les crates Rust hors signal de version workspace ;
+- `ksp-app-config-desk` runtime/frontend ;
+- les versions `package.json` / `tauri.conf.json` de Config Desk ;
+- les dépendances Cargo ;
+- les contrats publics existants ;
+- la configuration runtime ;
+- le prompt `0.2.1` finalisé par `pre.003`.
+
+Aucune nouvelle fonctionnalité N2 n'est introduite.
+
+## Version technique
+
+```text
+workspace.package.version = "0.2.0"
+```
+
+## Validation de `rel.001`
+
+Le delta modifie `Cargo.toml` et de la documentation, sans fichier Rust ni frontend/Tauri. Avant publication/tag, exécuter :
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --workspace --all-targets
+cargo test --workspace
+git diff --check
+git status --short
+```
+
+Aucun `cargo tauri build` n'est requis : la version Tauri de `ksp-app-config-desk` reste `0.1.4` et aucun fichier de l'application n'est modifié par cette publication.
+
+## Commit et tag
+
+Après validation de `rel.001` :
+
+```text
+commit : v0.2.0-rel.001
+tag    : v0.2.0
+```
+
+Seul le tag stable `v0.2.0` est attendu.
+
+## Suite
+
+Après création du tag `v0.2.0`, ouvrir :
+
+```text
+0.2.1-pre.001
+```
+
+avec :
+
+```text
+prompts/006-V0_2_1_START_PROMPT.md
+```
+
+`0.2.1` commence par audit de la documentation Solana HTTP actuelle, audit du transport bot3, matrice exhaustive des méthodes et gate de sizing avant toute implémentation fonctionnelle lourde.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 19 -->
+<!-- version: 20 -->
 
 # Documentation KSP
 
@@ -60,7 +60,7 @@ D'autres sous-répertoires seront ajoutés uniquement lorsque leur rôle aura é
 
 ## Documents de planification
 
-Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.4 — ksp-app-config-desk` est conservé comme historique clôturé dans [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md), avec sa matrice finale [`validation/001-V0_1_4_CONFIG_DESKTOP.md`](validation/001-V0_1_4_CONFIG_DESKTOP.md). Son prompt d'ouverture historique reste [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md). La session active est `0.2.0`, ouverte par [`../prompts/005-V0_2_0_START_PROMPT.md`](../prompts/005-V0_2_0_START_PROMPT.md). Son plan directeur d'audit et de découpage de série est [`plans/007-V0_2_0_SERIES_PLANNING.md`](plans/007-V0_2_0_SERIES_PLANNING.md), créé par `0.2.0-pre.001`, restructuré par `0.2.0-pre.002` puis audité/finalisé par `0.2.0-pre.003` autour de la séquence Transport HTTP -> Wallet -> transports live -> off-chain -> Interface/Program et de l'architecture RAW -> CORE -> DECODE -> SPECIALIZED. Sa matrice de clôture est [`validation/002-V0_2_0_SERIES_PLANNING.md`](validation/002-V0_2_0_SERIES_PLANNING.md). Le prompt préparatoire de la première release fonctionnelle est [`../prompts/006-V0_2_1_START_PROMPT.md`](../prompts/006-V0_2_1_START_PROMPT.md).
+Le plan historique de la phase fondatrice clôturée est conservé dans [`plans/001-V0_0_3_PLAN.md`](plans/001-V0_0_3_PLAN.md). La séquence active des premières releases fonctionnelles est définie dans [`plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md`](plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md). Le plan détaillé de la release stable `0.1.1` est conservé comme historique clôturé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.2` est conservé comme historique clôturé dans [`plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md`](plans/004-V0_1_2_LOGGING_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.3 — Configuration foundation` est conservé comme historique clôturé dans [`plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md`](plans/005-V0_1_3_CONFIG_FOUNDATION_PLAN.md). Le plan détaillé de la release stable `0.1.4 — ksp-app-config-desk` est conservé comme historique clôturé dans [`plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md`](plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md), avec sa matrice finale [`validation/001-V0_1_4_CONFIG_DESKTOP.md`](validation/001-V0_1_4_CONFIG_DESKTOP.md). Son prompt d'ouverture historique reste [`../prompts/004-V0_1_4_START_PROMPT.md`](../prompts/004-V0_1_4_START_PROMPT.md). La release stable `0.2.0` clôt l'audit de bot3 et le découpage de la série. Son plan directeur est conservé comme historique clôturé dans [`plans/007-V0_2_0_SERIES_PLANNING.md`](plans/007-V0_2_0_SERIES_PLANNING.md), avec sa matrice finale [`validation/002-V0_2_0_SERIES_PLANNING.md`](validation/002-V0_2_0_SERIES_PLANNING.md). La prochaine release fonctionnelle est `0.2.1 — ksp-onchain-transport-lib / HTTP Solana foundation`, à ouvrir avec [`../prompts/006-V0_2_1_START_PROMPT.md`](../prompts/006-V0_2_1_START_PROMPT.md).
 
 `IDEAS.md` conserve les pistes et questions qui ne sont pas encore des engagements du roadmap ni des décisions architecturales.
 

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` ;
+- `workspace.package.version = 0.2.0` ;
-- marquer `0.2.0` stable dans ROADMAP/indices/plans ;
+- `0.2.0` est marqué stable dans ROADMAP/indices/plans ;
-- ajouter l'entrée stable `0.2.0` au `CHANGELOG.md` ;
+- `CHANGELOG.md` reçoit l'entrée stable `0.2.0` ;
-- créer `deltas/0.2.0/rel.001.md` ;
+- `deltas/0.2.0/rel.001.md` enregistre la publication ;
-- exécuter les validations globales de clôture disponibles ;
+- les validations finales de `pre.003` communiquées par le user sont reportées dans la matrice de clôture ;
-- commit `v0.2.0-rel.001`, puis tag stable Git `v0.2.0` ;
+- le commit attendu est `v0.2.0-rel.001`, puis le 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.
+- 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`.
 

docs/validation/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/000-README.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Validations KSP
 
@@ -10,4 +10,4 @@ Les deltas restent l’historique autoritatif des livraisons ; une matrice de va
 Documents :
 
 - [`001-V0_1_4_CONFIG_DESKTOP.md`](001-V0_1_4_CONFIG_DESKTOP.md) — matrice finale de `0.1.4 — ksp-app-config-desk`.
-- [`002-V0_2_0_SERIES_PLANNING.md`](002-V0_2_0_SERIES_PLANNING.md) — audit final de cohérence et matrice de clôture documentaire de `0.2.0`.
+- [`002-V0_2_0_SERIES_PLANNING.md`](002-V0_2_0_SERIES_PLANNING.md) — matrice finale de la release stable `0.2.0`, avec audit de cohérence et preuves opérateur de `pre.003`.

docs/validation/002-V0_2_0_SERIES_PLANNING.md

@@ -1,11 +1,11 @@
 <!-- file: docs/validation/002-V0_2_0_SERIES_PLANNING.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Validation `0.2.0` — audit bot3 et planification de la série `0.2.x`
 
 ## Objet
 
-Cette matrice synthétise l'audit final de `0.2.0` et vérifie que le cadrage demandé par `prompts/005-V0_2_0_START_PROMPT.md` est suffisamment complet avant publication stable.
+Cette matrice synthétise l'audit final de `0.2.0`, les preuves opérateur de `pre.003` et la clôture publiée par `0.2.0-rel.001` conformément au cadrage demandé par `prompts/005-V0_2_0_START_PROMPT.md`.
 
 Elle ne remplace ni `docs/plans/007-V0_2_0_SERIES_PLANNING.md` ni les deltas `0.2.0`.
 
@@ -148,25 +148,49 @@ deltas/0.1.4/pre.016-fix.002.md
 
 qui ne possède pas les deux commentaires d'en-tête `file/version` utilisés par la convention actuelle. Ce fichier appartient à l'historique publié `0.1.4` et n'est **pas réécrit silencieusement** dans `0.2.0-pre.003`, conformément à la règle d'immutabilité pratique des deltas livrés. Cette anomalie ne modifie aucune règle/architecture active et ne bloque pas `0.2.0`.
 
-## Statut de clôture
+## Preuves opérateur finales de `pre.003`
 
-Après application et validation de `0.2.0-pre.003`, aucun développement N2 n'est attendu dans `0.2.0`.
+Le user a communiqué le 2026-08-17, sur le commit :
-
-La publication `0.2.0-rel.001` peut être préparée si les validations locales ne révèlent pas d'écart supplémentaire.
-
-Le `rel.001` doit essentiellement :
 
 ```text
-workspace.package.version -> 0.2.0
+e721464a7c2cbf4c564757061a2a44dd7913facb
-ROADMAP / plans / indices -> 0.2.0 stable
+v0.2.0-pre.003
-CHANGELOG.md -> entrée stable 0.2.0
-deltas/0.2.0/rel.001.md
-validations globales finales
-commit v0.2.0-rel.001
-tag Git v0.2.0
 ```
 
-Le prompt à utiliser ensuite est :
+les validations suivantes avec succès :
+
+```bash
+cargo fmt --all
+cargo check --workspace
+cargo clippy --workspace --all-targets
+cargo test --workspace
+git diff --check
+git status --short
+```
+
+Résultats synthétiques :
+
+- `cargo check --workspace` : succès ;
+- `cargo clippy --workspace --all-targets` : succès sans warning communiqué ;
+- `cargo test --workspace` : **241 tests réussis**, aucun échec ; le probe diagnostic d'overhead de `ksp-logging-lib` reste volontairement `ignored` ;
+- `git diff --check` : aucune sortie ;
+- `git status --short` : aucune sortie, working tree propre ;
+- `git log -1 --oneline --decorate` confirme `e721464 (HEAD -> master, origin/master) v0.2.0-pre.003`.
+
+Aucun écart supplémentaire n'a été révélé par cette validation. Aucune `pre.004` n'est donc requise.
+
+## Statut de clôture
+
+`0.2.0-rel.001` publie le cadrage sous `workspace.package.version = "0.2.0"` sans développement N2 ni nouvelle décision architecturale.
+
+Après validation du delta stable, les identifiants Git attendus sont :
+
+```text
+commit : v0.2.0-rel.001
+tag    : v0.2.0
+```
+
+La release suivante s'ouvre avec :
 
 ```text
 prompts/006-V0_2_1_START_PROMPT.md