v0.1.0-pre.069+

docs/rules/CRATE_DOCUMENTATION_RULES.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/CRATE_DOCUMENTATION_RULES.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Règles documentaires des crates
 
@@ -16,7 +16,7 @@ USAGE.md
 CHANGELOG.md
 ```
 
-Les variantes `001.README.md`, `USAGES.md` ou tout autre nom concurrent sont interdites dans la documentation active.
+La variante `USAGES.md` et tout autre nom concurrent de `USAGE.md` sont interdits dans la documentation active. Un fichier `001.README.md` est autorisé comme index lexical dans un répertoire contenant un grand nombre de fichiers, par exemple `idls/`, afin d’apparaître au début d’un listing. Il ne remplace jamais le `README.md` obligatoire à la racine d’une crate.
 
 Ces fichiers doivent être écrits pour l’architecture actuelle de `khadhroony-bot3`. Les documents de `olddocs/archivekbot2/` sont des sources historiques : leur contenu peut être étudié, vérifié, réinterprété et adapté, mais ne doit jamais être déplacé, copié automatiquement ou rendu normatif sans réécriture explicite.
 
@@ -130,7 +130,7 @@ Le TODO maintient uniquement les travaux futurs confirmés propres à la crate.
 
 ### 5.2 Organisation
 
-Le fichier est organisé en tâches et, lorsque nécessaire, en sous-tâches. Les sections sont choisies selon le travail réellement recensé : version cible, fonctionnalité, dette technique, tests, validation réseau, documentation, migration ou dépendance externe.
+Le fichier est organisé en tâches et, lorsque nécessaire, en sous-tâches. Les sections sont choisies selon le travail réellement recensé : version cible, fonctionnalité, dette technique, tests, validation réseau, documentation, migration ou dépendance externe. Une tâche peut aussi porter un préfixe explicite lorsque cela améliore sa lecture, par exemple `Dette technique -`, `Test -`, `Documentation -`, `Validation Devnet -` ou `Dépendance externe -`.
 
 Chaque entrée doit :
 
@@ -175,16 +175,11 @@ Le changelog de crate retrace chronologiquement les changements effectivement in
 
 Il ne contient ni section `Non publié`, ni tâches futures, ni roadmap, ni liste de limitations sans changement associé.
 
-### 6.2 Base historique minimale
+### 6.2 Numérotation
 
-Chaque changelog de crate doit contenir au minimum une section `0.1.0` décrivant :
+Le changelog suit les versions réellement attribuées au workspace ou à la crate ; il ne crée ni n’impose une version. Une section n’est ajoutée que lorsqu’une release, une prerelease ou, exceptionnellement, un correctif significatif a effectivement affecté la crate.
 
-- la migration depuis les composants correspondants de `khadhroony-bot2` ;
+Lorsqu’une version de migration doit être retracée, son entrée décrit les responsabilités venues de `khadhroony-bot2`, les consolidations ou renommages, les nouvelles règles applicables et les validations réellement exécutées pendant cette version. Le numéro utilisé est celui de la livraison concernée, pas une valeur minimale imposée par la documentation.
-- les consolidations, renommages ou suppressions de frontières de crates intervenues dans bot3 ;
-- l’adoption des nouvelles règles Rust et Khadhroony applicables ;
-- les validations réellement exécutées pendant cette version.
-
-Les prereleases et correctifs ultérieurs sont ajoutés au moment où leurs changements sont intégrés à la crate.
 
 ### 6.3 Catégories
 
@@ -199,17 +194,17 @@ Utiliser uniquement les catégories pertinentes parmi :
 - Validation ;
 - Documentation.
 
-Ne pas créer de section vide. Une limitation n’est mentionnée que si elle résulte directement du changement décrit dans l’entrée considérée ; les travaux nécessaires à sa suppression appartiennent au TODO.
+Ne pas créer de section vide. Une limitation connue peut être intégrée au texte explicatif d’un changement lorsqu’elle est nécessaire pour comprendre sa portée. Elle ne constitue pas une catégorie autonome du changelog. Les travaux nécessaires à sa suppression appartiennent au TODO.
 
-### 6.4 Versions et corrections
+### 6.4 Versions, prereleases et correctifs
 
-Le changelog distingue clairement :
+Le changelog général du workspace ne liste que les versions fonctionnelles `X.Y.Z`.
 
-- versions fonctionnelles ;
+Le changelog d’une crate peut détailler les versions `X.Y.Z`, les prereleases `X.Y.Z-pre.abc` et, lorsqu’un correctif publié est suffisamment important pour mériter une trace autonome, les correctifs `X.Y.Z-pre.abc-fix-def`.
-- prereleases ;
-- correctifs `fix`.
 
-Une modification fonctionnelle ou documentaire de la crate impose une entrée sous l’identifiant exact de la livraison qui l’intègre. Les informations pertinentes de `delta.md` concernant la crate sont reprises et reformulées dans son changelog.
+Les corrections mineures d’une prerelease ou d’une release ne créent pas automatiquement une section dédiée : elles sont repliées dans l’entrée de la version ou prerelease concernée. Un correctif reçoit une section propre seulement lorsqu’il modifie substantiellement ce qui a déjà été livré ou commité et qu’une explication séparée améliore la traçabilité.
+
+Les informations pertinentes de `delta.md` concernant la crate sont reprises et reformulées dans son changelog selon cette granularité.
 
 ### 6.5 Provenance bot2
 
@@ -243,11 +238,13 @@ Les IDL archivées ou maintenues dans le workspace servent de références de co
 
 L’inventaire et la classification des IDL sont des travaux documentaires actifs dès maintenant, notamment parce que bot3 a déjà subi un renommage massif des IDL. Ils ne sont pas reportés à l’implémentation future du décodeur Anchor.
 
+Un inventaire actif des programmes Solana et des IDL disponibles doit être reconstruit pour bot3. Il indique notamment les Program IDs connus, la présence ou l’absence d’une IDL récupérable, et la provenance de celle-ci. Une IDL peut provenir de Solscan, de l’explorateur Solana, d’un dépôt Git officiel ou d’une autre source vérifiée.
+
 Pour chaque IDL ajoutée, documenter lorsque possible :
 
 - protocole et programme ;
 - Program ID ;
-- source ;
+- source exacte ;
 - version, tag ou commit ;
 - nom de fichier normalisé ;
 - surface actuelle ou future qui l’utilise ;
@@ -257,27 +254,7 @@ Pour chaque IDL ajoutée, documenter lorsque possible :
 
 Les rapports bot2 sont des preuves historiques. Les documents bot3 doivent synthétiser leurs conclusions utiles et les confronter à l’architecture actuelle, sans les déplacer depuis `olddocs/archivekbot2/` ni les recopier intégralement.
 
-## 8. Statuts particuliers connus
+## 8. Processus de création des documents de crate
-
-### 8.1 Registre ElGamal
-
-La documentation doit distinguer les niveaux suivants :
-
-- implémentation du registre dans `kb-lib` ;
-- éventuelle intégration dans `kb-pipeline` et `kb-pipeline-demo-scenarios`, à vérifier précisément ;
-- présentation non fonctionnelle dans `kb-app-demo-desktop` ;
-- absence de validation réelle Devnet ;
-- déploiement Devnet/Mainnet non tenu pour acquis et à vérifier avant toute affirmation.
-
-Le registre ElGamal reste mis de côté tant que son déploiement, ses prérequis de preuve et son intégration applicative ne sont pas établis.
-
-### 8.2 Metaplex Token Metadata
-
-La migration bot2 vers bot3 a commencé en cours de développement de `0.4.7`.
-
-Le décodeur Metaplex Token Metadata déjà réalisé dans bot2 a été migré dans bot3. La documentation ne doit donc ni reporter le décodeur comme entièrement futur, ni considérer toute la surface `0.4.7` comme achevée. Les exécuteurs, matérialisateurs, préflights, validations et autres éléments doivent être décrits selon leur état réel.
-
-## 9. Processus de création des documents de crate
 
 Pour chaque crate :
 

docs/templates/CRATE_CHANGELOG_TEMPLATE.md

@@ -1,26 +1,28 @@
 <!-- file: docs/templates/CRATE_CHANGELOG_TEMPLATE.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Modèle de changelog de crate
 
 # Changelog de `<nom-de-crate>`
 
-## `<version-ou-prerelease-fix>`
+## `<version-ou-prerelease>`
 
-### Ajouté / Modifié / Corrigé / Supprimé / Validation / Documentation
+### `<catégorie pertinente>`
 
-- Décrire uniquement les changements effectivement intégrés par cette livraison.
+- Décrire uniquement les changements effectivement intégrés pendant cette version ou prerelease.
+- Reprendre les informations pertinentes des deltas concernant cette crate, sans transformer chaque correction mineure en section autonome.
 
-## 0.1.0
+## `<correctif-significatif-si-nécessaire>`
 
-### Migré
+Créer cette section uniquement lorsqu’un correctif modifie substantiellement une livraison déjà publiée ou commitée et mérite une explication séparée. Sinon, replier la correction dans l’entrée de la version ou prerelease concernée.
 
-- Migration depuis les composants correspondants de `khadhroony-bot2` vers l’architecture consolidée de `khadhroony-bot3`.
+Catégories possibles, uniquement lorsqu’elles contiennent des changements réels :
 
-### Modifié
+- Ajouté ;
-
+- Modifié ;
-- Adoption des règles Rust et Khadhroony applicables à bot3.
+- Corrigé ;
-
+- Supprimé ;
-### Validation
+- Migré ;
-
+- Compatibilité ;
-- Indiquer uniquement les validations réellement exécutées et pertinentes pour cette crate.
+- Validation ;
+- Documentation.

docs/templates/CRATE_TODO_TEMPLATE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/templates/CRATE_TODO_TEMPLATE.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Modèle de TODO de crate
 
@@ -7,8 +7,19 @@
 
 ## `<version, fonctionnalité ou lot>`
 
-- [ ] action vérifiable à réaliser ;
+- [ ] `<catégorie facultative> -` action vérifiable à réaliser ;
-- [ ] sous-tâche ordonnée si nécessaire ;
+  - [ ] sous-tâche ordonnée si nécessaire ;
-- [ ] validation ou documentation à produire pour clôturer le lot.
+  - [ ] critère de clôture, validation ou documentation nécessaire.
+
+Préfixes possibles lorsqu’ils améliorent la lecture :
+
+- `Fonctionnalité -` ;
+- `Dette technique -` ;
+- `Test -` ;
+- `Validation Devnet -` ;
+- `Validation Mainnet -` ;
+- `Documentation -` ;
+- `Migration -` ;
+- `Dépendance externe -`.
 
 > Supprimer chaque tâche terminée. Ne conserver ni section vide, ni constat sans action. Ne reprendre une idée de `docs/IDEA_REMINDERS.md` qu’après confirmation, attribution à cette crate et reformulation en tâche vérifiable.

docs/templates/CRATE_USAGE_TEMPLATE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/templates/CRATE_USAGE_TEMPLATE.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Modèle de guide d’utilisation de crate
 
@@ -41,8 +41,12 @@ Supprimer cette section si aucun binaire public n’existe.
 
 ## Contraintes et limites durables
 
+## Tests de référence
+
+Lister uniquement les tests unitaires ou d’intégration qui constituent des exemples particulièrement instructifs de l’utilisation réelle de la crate, de ses invariants ou de ses parcours Devnet/Mainnet. Ne pas produire un catalogue exhaustif de tous les tests.
+
 ## Références
 
-Lier les tests, exemples, fixtures et matrices canoniques sans les dupliquer.
+Lier les autres exemples, fixtures et matrices canoniques sans les dupliquer.
 
 > Ne pas répéter ici une limite temporaire déjà planifiée dans `TODO.md`. Les exemples Rust doivent respecter les règles du workspace.

kb-config/CHANGELOG.md

@@ -1,27 +1,19 @@
 <!-- file: kb-config/CHANGELOG.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # CHANGELOG — kb-config
 
-## 0.1.0-pre.069-fix-001
-
-### Corrigé
-
-- suppression de la section `Non publié`, incompatible avec le rôle chronologique du changelog ;
-- retrait des limitations et travaux futurs, désormais maintenus dans `TODO.md` ou `USAGE.md` selon leur nature ;
-- clarification de la séparation entre historique de prerelease et objectifs futurs.
-
-### Documentation
-
-- réécriture de `TODO.md` sous forme de tâches uniquement ;
-- correction des exemples de `USAGE.md` afin de ne pas utiliser l’opérateur `?`.
-
 ## 0.1.0-pre.069
 
 ### Documentation
 
 - création de `TODO.md`, `USAGE.md` et du changelog détaillé ;
-- réécriture du README selon l’architecture bot3.
+- réécriture du README selon l’architecture bot3 ;
+- suppression de la section `Non publié`, incompatible avec le rôle chronologique du changelog ;
+- retrait des limitations et travaux futurs, désormais maintenus dans `TODO.md` ou `USAGE.md` selon leur nature ;
+- clarification de la séparation entre historique de prerelease et objectifs futurs ;
+- réécriture de `TODO.md` sous forme de tâches uniquement ;
+- correction des exemples de `USAGE.md` afin de ne pas utiliser l’opérateur `?`.
 
 ## 0.1.0
 

kb-lib/CHANGELOG.md

@@ -1,26 +1,18 @@
 <!-- file: kb-lib/CHANGELOG.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # CHANGELOG — kb-lib
 
-## 0.1.0-pre.069-fix-001
-
-### Corrigé
-
-- suppression de la section `Non publié`, incompatible avec le rôle chronologique du changelog ;
-- retrait des limitations et travaux futurs du changelog ;
-- correction de la frontière entre historique, TODO et limites durables d’utilisation.
-
-### Documentation
-
-- réécriture de `TODO.md` sous forme de tâches uniquement ;
-- correction des exemples de `USAGE.md` afin de ne pas utiliser l’opérateur `?`.
-
 ## 0.1.0-pre.069
 
 ### Documentation
 
-- ajout de `README.md`, `TODO.md`, `USAGE.md` et du présent changelog selon les normes bot3.
+- ajout de `README.md`, `TODO.md`, `USAGE.md` et du présent changelog selon les normes bot3 ;
+- suppression de la section `Non publié`, incompatible avec le rôle chronologique du changelog ;
+- retrait des limitations et travaux futurs du changelog ;
+- correction de la frontière entre historique, TODO et limites durables d’utilisation ;
+- réécriture de `TODO.md` sous forme de tâches uniquement ;
+- correction des exemples de `USAGE.md` afin de ne pas utiliser l’opérateur `?`.
 
 ## 0.1.0
 

kb-logging/CHANGELOG.md

@@ -1,26 +1,18 @@
 <!-- file: kb-logging/CHANGELOG.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # CHANGELOG — kb-logging
 
-## 0.1.0-pre.069-fix-001
-
-### Corrigé
-
-- suppression de la section `Non publié`, incompatible avec le rôle chronologique du changelog ;
-- retrait des travaux futurs du changelog.
-
-### Documentation
-
-- réécriture de `TODO.md` sous forme de tâches uniquement ;
-- correction de `USAGE.md` pour ne conserver que les contraintes runtime durables.
-
 ## 0.1.0-pre.069
 
 ### Documentation
 
 - création de `TODO.md`, `USAGE.md` et du changelog détaillé ;
-- réécriture du README selon la séparation bot3 entre configuration et runtime logging.
+- réécriture du README selon la séparation bot3 entre configuration et runtime logging ;
+- suppression de la section `Non publié`, incompatible avec le rôle chronologique du changelog ;
+- retrait des travaux futurs du changelog ;
+- réécriture de `TODO.md` sous forme de tâches uniquement ;
+- correction de `USAGE.md` pour ne conserver que les contraintes runtime durables.
 
 ## 0.1.0
 

kb-store/CHANGELOG.md

@@ -1,26 +1,18 @@
 <!-- file: kb-store/CHANGELOG.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # CHANGELOG — kb-store
 
-## 0.1.0-pre.069-fix-001
-
-### Corrigé
-
-- suppression de la section `Non publié`, incompatible avec le rôle chronologique du changelog ;
-- retrait des constats sans action du TODO et des travaux futurs du changelog.
-
-### Documentation
-
-- réécriture de `TODO.md` sous forme de tâches uniquement ;
-- correction des exemples de `USAGE.md` afin de ne pas utiliser l’opérateur `?`.
-
 ## 0.1.0-pre.069
 
 ### Documentation
 
 - création de `TODO.md`, `USAGE.md` et du changelog détaillé ;
-- réécriture du README autour des contrats consolidés et de `PostgresStore`.
+- réécriture du README autour des contrats consolidés et de `PostgresStore` ;
+- suppression de la section `Non publié`, incompatible avec le rôle chronologique du changelog ;
+- retrait des constats sans action du TODO et des travaux futurs du changelog ;
+- réécriture de `TODO.md` sous forme de tâches uniquement ;
+- correction des exemples de `USAGE.md` afin de ne pas utiliser l’opérateur `?`.
 
 ## 0.1.0