v0.1.0-pre.069

docs/README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/README.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Documentation active de Khadhroony Bot3
 
@@ -81,3 +81,12 @@ CHANGELOG.md
 ```
 
 Leur création commencera après stabilisation des documents transversaux, par lots de crates. `USAGE.md` documentera les APIs publiques réelles et pourra signaler les tests particulièrement instructifs.
+
+## Documentation des crates
+
+Le premier lot documenté comprend :
+
+- [`kb-lib`](../kb-lib/README.md) ;
+- [`kb-store`](../kb-store/README.md) ;
+- [`kb-config`](../kb-config/README.md) ;
+- [`kb-logging`](../kb-logging/README.md).

docs/rules/CRATE_DOCUMENTATION_RULES.md

@@ -16,7 +16,7 @@ USAGE.md
 CHANGELOG.md
 ```
 
-`USAGES.md` et les autres noms concurrents sont interdits. `001.README.md` reste autorisé comme index de répertoire lorsque le tri lexical au début d’un répertoire très fourni est utile, par exemple sous `idls/`; il ne remplace jamais le `README.md` obligatoire à la racine d’une crate.
+Les variantes `001.README.md`, `USAGES.md` ou tout autre nom concurrent sont interdites dans la documentation active.
 
 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.
 
@@ -34,7 +34,7 @@ Pour chaque document de crate :
 - conserver les détails historiques dans les changelogs et archives, non dans le README ou le guide d’utilisation ;
 - mettre à jour le numéro de version documentaire placé dans l’en-tête du fichier lorsqu’un changement substantiel est effectué.
 
-Les sections obligatoires ne doivent pas être laissées vides. Lorsqu’aucun élément n’est recensé, l’indiquer explicitement.
+Les documents ne doivent pas contenir de sections vides ni de constats sans action. Une section sans contenu utile est omise.
 
 ## 3. `README.md`
 
@@ -109,12 +109,14 @@ Une réexportation publique doit être vérifiée jusqu’à son chemin d’acc
 8. erreurs publiques et conditions d’échec ;
 9. exemples réalistes, préférablement compilables ;
 10. utilisation des binaires ou commandes, lorsqu’applicable ;
-11. limites connues ;
+11. contraintes et limites durables de l’API actuelle ;
 12. liens vers les tests, exemples, fixtures et matrices canoniques.
 
-Chaque API publique significative doit disposer d’au moins un exemple ou être couverte par un exemple de scénario explicitement identifié. Les APIs triviales ou regroupées peuvent partager un exemple lorsqu’il démontre réellement leur usage.
+Les travaux planifiés pour supprimer une limite temporaire appartiennent au TODO et ne sont pas répétés dans `USAGE.md`.
 
-Les tests unitaires peuvent être documentés lorsqu’ils illustrent un contrat public, un invariant, un format canonique ou une régression importante. `USAGE.md` doit alors les référencer et expliquer ce qu’ils démontrent, sans transformer les helpers internes en API publique.
+Les exemples Rust doivent respecter les règles du workspace, y compris les conventions de propagation d’erreurs.
+
+Chaque API publique significative doit disposer d’au moins un exemple ou être couverte par un exemple de scénario explicitement identifié. Les APIs triviales ou regroupées peuvent partager un exemple lorsqu’il démontre réellement leur usage.
 
 ### 4.4 Crates sans API bibliothèque publique
 
@@ -124,28 +126,20 @@ Une crate principalement binaire ou interne conserve un `USAGE.md`. Le document
 
 ### 5.1 Rôle
 
-Le TODO maintient l’état futur propre à la crate. Il ne sert ni de roadmap général ni de changelog.
+Le TODO maintient uniquement les travaux futurs confirmés propres à la crate. Il ne sert ni de roadmap général, ni de changelog, ni de fiche descriptive.
 
-### 5.2 Sections obligatoires
+### 5.2 Organisation
 
-Le fichier distingue au minimum :
+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.
 
-- fonctionnalités manquantes ;
-- dette technique ;
-- tests manquants ;
-- validations Devnet/Mainnet manquantes ;
-- documentation manquante ;
-- dépendances ou contraintes externes ;
-- éléments confirmés mais reportés ;
-- hors périmètre.
+Chaque entrée doit :
 
-Chaque entrée doit préciser, lorsque connu :
+- commencer par une action à réaliser ;
+- être vérifiable et supprimable une fois terminée ;
+- préciser sa version cible, sa priorité, sa dépendance ou son critère de clôture lorsque cette information est connue ;
+- rester dans le TODO uniquement tant qu’elle n’est pas achevée.
 
-- son statut ;
-- sa priorité ou son ordre relatif ;
-- sa dépendance ;
-- son critère de clôture ;
-- la version ou série cible si elle est déjà décidée.
+Une contrainte externe ne figure dans le TODO que si elle bloque ou conditionne une tâche explicite. Une absence de validation Devnet/Mainnet n’est mentionnée que lorsqu’une validation réseau doit réellement être exécutée pour cette crate.
 
 ### 5.3 Relation avec `docs/IDEA_REMINDERS.md`
 
@@ -157,38 +151,40 @@ Une idée peut être intégrée au TODO d’une crate uniquement après :
 2. identification de la crate réellement responsable ;
 3. vérification qu’elle n’est pas déjà implémentée ou remplacée ;
 4. reformulation en tâche vérifiable ;
-5. classement dans la bonne section et selon un ordre cohérent ;
-6. ajout des dépendances et limites connues.
+5. classement selon un ordre cohérent ;
+6. ajout de ses dépendances ou critères de clôture.
 
-Une idée encore exploratoire reste dans `docs/IDEA_REMINDERS.md` ou dans un document de décision ; elle ne doit pas être présentée comme engagement de crate.
+Une idée encore exploratoire reste dans `docs/IDEA_REMINDERS.md` ou dans un document de décision.
 
 ### 5.4 Interdictions
 
 Le TODO ne doit pas :
 
-- conserver ou répéter les travaux déjà terminés ;
+- conserver une tâche terminée ;
+- contenir des phrases telles que « aucune tâche », « aucune validation » ou « hors périmètre » ;
+- décrire le comportement actuel de la crate ;
 - contenir l’historique des corrections ;
 - recopier le ROADMAP général ;
-- transformer une hypothèse en obligation ;
-- masquer une fonctionnalité partiellement implémentée sous un statut binaire terminé/non terminé.
+- transformer une hypothèse en obligation.
 
 ## 6. `CHANGELOG.md`
 
 ### 6.1 Rôle
 
-Le changelog de crate retrace l’évolution fonctionnelle, structurelle et contractuelle de cette crate.
+Le changelog de crate retrace chronologiquement les changements effectivement intégrés à cette crate. Il conserve le détail des releases, prereleases et correctifs `fix` qui l’ont affectée.
+
+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
 
-Chaque changelog de crate doit contenir au minimum :
+Chaque changelog de crate doit contenir au minimum une section `0.1.0` décrivant :
 
-- une section `Non publié` ;
-- une section `0.1.0` décrivant la migration depuis les composants correspondants de `khadhroony-bot2` ;
+- la migration depuis les composants correspondants de `khadhroony-bot2` ;
 - 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 et les limitations encore connues.
+- les validations réellement exécutées pendant cette version.
 
-La section `0.1.0` synthétise la migration initiale. À partir de cette base, le changelog de crate conserve le détail des prereleases et correctifs `fix` qui ont touché la crate, afin de reprendre durablement les informations pertinentes de chaque `delta.md`.
+Les prereleases et correctifs ultérieurs sont ajoutés au moment où leurs changements sont intégrés à la crate.
 
 ### 6.3 Catégories
 
@@ -201,23 +197,19 @@ Utiliser uniquement les catégories pertinentes parmi :
 - Migré ;
 - Compatibilité ;
 - Validation ;
-- Limitations connues ;
 - Documentation.
 
-Ne pas créer des sections vides.
+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.
 
 ### 6.4 Versions et corrections
 
-Le changelog de crate distingue clairement :
+Le changelog distingue clairement :
 
-- version publiée ;
-- prerelease ;
-- correctif `fix` ;
-- changement non publié.
+- versions fonctionnelles ;
+- prereleases ;
+- correctifs `fix`.
 
-Le changelog général suit une granularité différente : il décrit les changements entre versions fonctionnelles, par exemple de `0.4.6` à `0.4.7`, sans détailler les prereleases ni les correctifs `fix`. Les détails de livraison restent dans les changelogs des crates concernées.
-
-Une modification fonctionnelle de la crate impose une mise à jour de son changelog. Une modification documentaire pure peut être regroupée sous `Non publié / Documentation`.
+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.
 
 ### 6.5 Provenance bot2
 
@@ -241,7 +233,7 @@ Les matrices actives maintenues sous :
 test-fixtures/contract-matrices/
 ```
 
-restent les références canoniques. Elles servent à la fois de contrats documentaires et de fixtures exécutées par des tests unitaires ou d’intégration. Elles ne doivent pas être dupliquées dans `docs/`.
+restent les références canoniques. Elles ne doivent pas être dupliquées dans `docs/`.
 
 Les documents de crate et de protocole doivent les référencer par lien et expliquer leur rôle, leur portée et leur statut de validation.
 

docs/templates/CRATE_CHANGELOG_TEMPLATE.md

@@ -5,11 +5,11 @@
 
 # Changelog de `<nom-de-crate>`
 
-## Non publié
+## `<version-ou-prerelease-fix>`
 
-### Documentation
+### Ajouté / Modifié / Corrigé / Supprimé / Validation / Documentation
 
-- Création ou mise à jour de la documentation de crate.
+- Décrire uniquement les changements effectivement intégrés par cette livraison.
 
 ## 0.1.0
 
@@ -24,11 +24,3 @@
 ### Validation
 
 - Indiquer uniquement les validations réellement exécutées et pertinentes pour cette crate.
-
-### Limitations connues
-
-- Indiquer les fonctionnalités partielles, non raccordées ou non validées.
-
-## Historique détaillé des livraisons
-
-Ajouter les prereleases et correctifs `fix` ayant réellement modifié cette crate, en reprenant les informations pertinentes des `delta.md`.

docs/templates/CRATE_TODO_TEMPLATE.md

@@ -3,24 +3,12 @@
 
 # Modèle de TODO de crate
 
-# Travaux restant pour `<nom-de-crate>`
+# TODO — `<nom-de-crate>`
 
-## Fonctionnalités manquantes
+## `<version, fonctionnalité ou lot>`
 
-## Dette technique
+- [ ] action vérifiable à réaliser ;
+- [ ] sous-tâche ordonnée si nécessaire ;
+- [ ] validation ou documentation à produire pour clôturer le lot.
 
-## Tests manquants
-
-## Validations Devnet/Mainnet manquantes
-
-## Documentation manquante
-
-## Dépendances ou contraintes externes
-
-## Éléments confirmés mais reportés
-
-## Hors périmètre
-
-> Ne reprendre une idée de `docs/IDEA_REMINDERS.md` qu’après confirmation, attribution à cette crate et reformulation en tâche vérifiable.
-
-> Supprimer toute tâche dès que sa réalisation est confirmée et la reporter dans le changelog de la crate.
+> 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

@@ -39,12 +39,10 @@ Pour chaque API ou groupe cohérent :
 
 Supprimer cette section si aucun binaire public n’existe.
 
-## Tests de référence
-
-Documenter les tests unitaires particulièrement instructifs qui démontrent un contrat public, un invariant, un format canonique ou une non-régression.
-
-## Limites connues
+## Contraintes et limites durables
 
 ## Références
 
 Lier les tests, 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.