v0.1.1-rel.001

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 9 -->
+<!-- version: 10 -->
 
 # Documentation KSP
 
@@ -52,7 +52,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 première release fonctionnelle est conservé dans [`plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md`](plans/003-V0_1_1_CORE_FOUNDATION_PLAN.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).
 
 `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: 5 -->
+<!-- version: 6 -->
 
 # Plans KSP
 
@@ -11,7 +11,7 @@ Un plan décrit le périmètre, les décisions déjà acquises, les questions ou
 
 - [`001-V0_0_3_PLAN.md`](001-V0_0_3_PLAN.md) — plan historique de la phase fondatrice `0.0.3`, clôturée ;
 - [`002-FUNCTIONAL_RELEASE_SEQUENCE.md`](002-FUNCTIONAL_RELEASE_SEQUENCE.md) — séquence active de référence des premières releases fonctionnelles ;
-- [`003-V0_1_1_CORE_FOUNDATION_PLAN.md`](003-V0_1_1_CORE_FOUNDATION_PLAN.md) — plan détaillé de `0.1.1`, établi par `0.1.1-pre.001` et consolidé jusqu'à sa tranche de clôture.
+- [`003-V0_1_1_CORE_FOUNDATION_PLAN.md`](003-V0_1_1_CORE_FOUNDATION_PLAN.md) — plan historique clôturé de la release stable `0.1.1`, établi par `0.1.1-pre.001` puis consolidé jusqu'à `0.1.1-rel.001`.
 
 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: 3 -->
+<!-- version: 4 -->
 
 # Séquence des releases fonctionnelles KSP
 
@@ -95,7 +95,7 @@ pre.003              Pubkey + Program IDs
 pre.003-fix.001      politique Cargo workspace + corrections Clippy
 pre.004              intégration Core + audits
 pre.005              validation finale/docs/cleanup/prompt 0.1.2
-rel.001               publication stable après validation de pre.005
+rel.001               publication stable validée de 0.1.1
 ```
 
 ## `0.1.2` — Logging foundation
@@ -336,7 +336,7 @@ Son prompt historique d'ouverture reste :
 prompts/001-V0_1_1_START_PROMPT.md
 ```
 
-À la clôture de `0.1.1-pre.005`, la surface Core est prête pour validation puis publication stable via `0.1.1-rel.001`. Après le tag `v0.1.1`, la release suivante s'ouvre avec :
+`0.1.1-rel.001` publie la surface Core stable après validation complète de `pre.005`. Le commit de release reçoit le tag `v0.1.1`. La release suivante s'ouvre avec :
 
 ```text
 0.1.2 — Logging foundation

docs/plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md

@@ -1,13 +1,13 @@
 <!-- file: docs/plans/003-V0_1_1_CORE_FOUNDATION_PLAN.md -->
-<!-- version: 9 -->
+<!-- version: 10 -->
 
 # Plan KSP 0.1.1 — Core foundation
 
 ## Statut
 
-Plan de travail de `0.1.1`, établi par `0.1.1-pre.001` puis consolidé jusqu'à la tranche de clôture `0.1.1-pre.005`.
+Plan historique clôturé de `0.1.1`, établi par `0.1.1-pre.001`, consolidé jusqu'à `0.1.1-pre.005` puis fermé par `0.1.1-rel.001`.
 
-La surface fonctionnelle Core prévue par ce plan est désormais implémentée et validée jusqu'à `pre.004`. `pre.005` finalise la documentation, le prompt `0.1.2` et la préparation de publication ; la version stable `0.1.1` reste à publier par un delta `rel.001` après validation de cette dernière prerelease.
+La surface fonctionnelle Core prévue par ce plan est implémentée et validée. Le delta `rel.001` publie `workspace.package.version = "0.1.1"`; son commit doit recevoir le tag stable `v0.1.1` avant ouverture de `0.1.2`.
 
 ## Base auditée
 
@@ -648,14 +648,30 @@ La tranche ne change ni le contrat Error, ni la taxonomie, ni l'inventaire des 1
 
 ### `0.1.1-pre.005` — clôture
 
-Résultat de clôture préparé :
+Résultat de clôture validé :
 
 - aucune nouvelle primitive Core et aucune nouvelle feature `solana-pubkey` ne sont ajoutées ;
 - les documents de référence de `0.1.1` sont réalignés avec la surface effectivement livrée ;
 - aucun `README.md`/`USAGE.md` spécifique à la crate n'est ajouté : la rustdoc crate-level et les tests publics couvrent suffisamment la petite surface actuelle ;
 - aucun changelog général n'existe dans la base actuelle, donc aucun fichier de changelog artificiel n'est créé uniquement pour cette release ;
 - le prompt final `prompts/002-V0_1_2_START_PROMPT.md` est créé pour ouvrir Logging après publication stable de `0.1.1` ;
-- la publication stable reste volontairement séparée dans un futur delta `0.1.1-rel.001`, conformément au workflow de versionnement.
+- la publication stable est réalisée séparément par `0.1.1-rel.001`, conformément au workflow de versionnement.
+
+### `0.1.1-rel.001` — publication stable
+
+La publication stable :
+
+- passe `workspace.package.version` de `0.1.1-pre.5` à `0.1.1` ;
+- enregistre les validations finales de `pre.005` exécutées avec succès par le user le 2026-08-14 ;
+- confirme 14 tests unitaires et 3 tests d'intégration publics réussis ;
+- confirme Clippy sans warning communiqué ;
+- confirme `solana-pubkey 4.3.0` comme unique dépendance externe directe de `ksp-core-lib` ;
+- confirme l'absence de doublons dans `cargo tree -d` ;
+- confirme que le graphe de features ne justifie aucune feature optionnelle `solana-pubkey` supplémentaire ;
+- marque `0.1.1` comme réalisée dans le roadmap et conserve le présent plan comme historique clôturé ;
+- prépare le commit de release puis le tag stable `v0.1.1`.
+
+Aucun contrat public, Program ID, dépendance ou feature n'est modifié par `rel.001`.
 
 Un `pre.NNN-fix.NNN` corrige la tranche correspondante sans réécrire son historique.