v0.1.0-pre.064-065
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/DOCUMENTATION_REFACTOR_AUDIT.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Audit de refonte documentaire
|
||||
|
||||
@@ -62,18 +62,32 @@ Ces documents sont une source historique et technique. Ils ne sont pas normatifs
|
||||
|
||||
## 3. État de `olddocs/`
|
||||
|
||||
Le répertoire `olddocs/` n’existe pas dans l’archive bot3 fournie. Il n’y a donc aucun contenu bot3 à préserver sous ce chemin dans cette base précise.
|
||||
L’absence de `olddocs/` dans l’archive bot3 fournie est volontaire : conserver une copie partielle de bot2 dans chaque archive complète bot3 aurait dupliqué la source historique alors que l’archive complète bot2 est fournie au démarrage de la session documentaire. Ce point n’est donc pas un défaut de la base `pre.062`.
|
||||
|
||||
La reconstruction devra créer deux archives séparées :
|
||||
La reconstruction crée deux archives séparées :
|
||||
|
||||
```text
|
||||
olddocs/archivekbot2/
|
||||
olddocs/archivekbot3/
|
||||
```
|
||||
|
||||
La totalité de `khadhroony-bot2/docs/` devra être copiée dans `olddocs/archivekbot2/` sans réécriture de fond. L’archive source fournie ne doit évidemment pas être modifiée. Les documents bot3 devenus temporaires ou remplacés seront déplacés ultérieurement vers `olddocs/archivekbot3/`, après correction de leurs références.
|
||||
`olddocs/archivekbot2/` doit reproduire l’arborescence documentaire utile de bot2, et pas uniquement son ancien répertoire `docs/`. La structure attendue comprend notamment :
|
||||
|
||||
Le choix opérationnel retenu pour la suite doit être une copie depuis l’archive bot2, et non un déplacement destructif.
|
||||
```text
|
||||
olddocs/archivekbot2/README.md
|
||||
olddocs/archivekbot2/CHANGELOG.md
|
||||
olddocs/archivekbot2/ROADMAP.md
|
||||
olddocs/archivekbot2/RULES.md
|
||||
olddocs/archivekbot2/docs/...
|
||||
olddocs/archivekbot2/prompts/...
|
||||
olddocs/archivekbot2/<ancienne-crate>/README.md
|
||||
olddocs/archivekbot2/<ancienne-crate>/CHANGELOG.md
|
||||
olddocs/archivekbot2/<ancienne-crate>/<autres-documents>.md|json
|
||||
```
|
||||
|
||||
Cette archive est reconstruite depuis l’archive complète bot2 fournie, en conservant les chemins relatifs et sans modifier les fichiers historiques. Les documents bot3 devenus temporaires ou remplacés seront déplacés ultérieurement vers `olddocs/archivekbot3/`, après correction de leurs références.
|
||||
|
||||
Le choix opérationnel est une copie documentaire depuis l’archive bot2, et non un déplacement destructif ni une copie complète du code bot2.
|
||||
|
||||
## 4. Contrat documentaire des crates
|
||||
|
||||
@@ -109,7 +123,15 @@ Le workspace déclare 11 crates :
|
||||
|
||||
Aucune crate ne satisfait donc le contrat complet `README.md`, `TODO.md`, `USAGE.md`, `CHANGELOG.md`.
|
||||
|
||||
Une contradiction normative existe dans `RULES_GENERAL.md` : le fichier exige encore un `README.md` ou `001.README.md` et, à terme, un `USAGES.md`. Cette formulation doit être remplacée par le contrat acquis utilisant exactement `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md`.
|
||||
Une contradiction normative existe dans `RULES_GENERAL.md` : le fichier exige encore un `README.md` ou `001.README.md` et, à terme, un `USAGES.md`. La convention retenue est `USAGE.md`, nom singulier couramment utilisé pour un guide d’utilisation. La règle doit imposer exactement `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md`.
|
||||
|
||||
### 4.4 Frontière de l’archive documentaire
|
||||
|
||||
La première sélection fondée sur toutes les extensions Markdown et JSON était trop large. La sélection doit désormais reposer sur la fonction documentaire autonome du fichier.
|
||||
|
||||
Sont notamment exclus les configurations de build et d’exécution Tauri/npm/TypeScript, les capabilities, les fixtures RPC et les fichiers internes sous `kb_store_core/src/` ou `kb_store_pg/src/`.
|
||||
|
||||
Restent conservés les matrices documentaires, les IDL archivées, `config/example.config.json` et `config/schema.config.json`, conformément à [`decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md`](decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md).
|
||||
|
||||
## 5. Évaluation des documents racine
|
||||
|
||||
@@ -153,7 +175,7 @@ Avant déplacement, il faudra :
|
||||
3. adapter les chemins attendus par `scripts/audit_khadhroony_workspace_rules.py` ;
|
||||
4. vérifier le lanceur `scripts/audit_rust_workspace_rules.py` ;
|
||||
5. corriger README, prompts, documents d’onboarding et checklist de migration ;
|
||||
6. exécuter l’audit et `git diff --check` avant livraison.
|
||||
6. exécuter l’audit workspace et les validations adaptées aux fichiers modifiés avant livraison. Les commandes Git restent sous la responsabilité de l’opérateur et ne font pas partie des validations demandées à la session.
|
||||
|
||||
## 7. Analyse des prompts
|
||||
|
||||
@@ -222,10 +244,10 @@ Les déplacements ne doivent commencer qu’après création de `docs/README.md`
|
||||
|
||||
Les écarts suivants sont établis sans nouvel audit fonctionnel des protocoles :
|
||||
|
||||
1. absence de `olddocs/` dans la base bot3 fournie ;
|
||||
1. absence volontaire de `olddocs/` dans la base bot3 fournie, à reconstruire depuis l’archive complète bot2 ;
|
||||
2. absence de `docs/README.md` ;
|
||||
3. contrat documentaire incomplet pour les 11 crates ;
|
||||
4. contradiction `USAGES.md` contre `USAGE.md` ;
|
||||
4. contradiction `USAGES.md` contre `USAGE.md`, résolue en faveur de `USAGE.md` ;
|
||||
5. règles secondaires encore liées à la racine par le code d’audit et les prompts ;
|
||||
6. changelog bot3 ne reprenant pas encore l’historique bot2 ;
|
||||
7. roadmap général encore mélangé à la checklist de migration et aux prereleases ;
|
||||
@@ -237,7 +259,7 @@ Les écarts suivants sont établis sans nouvel audit fonctionnel des protocoles
|
||||
|
||||
Aucune ambiguïté ne bloque la première livraison d’audit.
|
||||
|
||||
Les choix suivants doivent être validés avant les deltas de déplacement, mais peuvent être traités par propositions réversibles :
|
||||
Les choix suivants restent à trancher avant les deltas de déplacement, mais ne bloquent pas l’archivage documentaire ni la correction des règles :
|
||||
|
||||
- emplacement final de `OPERATION_NAMING_CONVENTION.md` entre `architecture/` et `rules/` ;
|
||||
- maintien temporaire ou archivage immédiat de `IDEA_REMINDERS.md` après ventilation dans les TODO ;
|
||||
@@ -249,3 +271,14 @@ Les choix suivants doivent être validés avant les deltas de déplacement, mais
|
||||
La base technique peut servir à la refonte documentaire, mais elle n’est pas encore démontrée comme officiellement alignée sur `0.4.6`.
|
||||
|
||||
La prochaine étape contrôlée est l’application du plan décrit dans `docs/DOCUMENTATION_REFACTOR_PLAN.md`, par deltas séparés, avant la création de `docs/V0_4_6_ALIGNMENT_AUDIT.md` et avant toute modification des versions Cargo.
|
||||
|
||||
## 12. Précisions acquises après le premier audit
|
||||
|
||||
- L’absence initiale de `olddocs/` dans bot3 était volontaire ; l’archive bot2 fournie séparément évitait une duplication pendant la migration.
|
||||
- Les documents actifs ne seront jamais déplacés ni générés automatiquement depuis `olddocs/archivekbot2/`. Chaque document bot3 sera créé après lecture et adaptation des sources pertinentes.
|
||||
- Les matrices de contrats actives sont déjà centralisées sous `test-fixtures/contract-matrices/` et ne doivent pas être recopiées dans `docs/`.
|
||||
- Le registre ElGamal est implémenté dans `kb-lib`; son intégration pipeline reste à vérifier précisément, son panneau desktop n’est qu’une présentation et son déploiement Devnet/Mainnet ne doit pas être supposé.
|
||||
- La migration bot3 a commencé en cours de `0.4.7` après réalisation du décodeur Metaplex Token Metadata dans bot2 ; ce décodeur existe déjà dans bot3, tandis que le reste de la surface doit être évalué.
|
||||
- La classification des IDL est un besoin actif immédiat à cause du renommage massif déjà effectué. Elle n’est pas reportée à `0.6.x`; seules les infrastructures Anchor supplémentaires relèvent de cette série.
|
||||
- Chaque changelog de crate devra contenir au minimum une section `0.1.0` retraçant sa migration depuis bot2, sa consolidation dans bot3 et l’adoption des nouvelles normes Rust et Khadhroony.
|
||||
- Les TODO pourront intégrer des idées de `docs/IDEA_REMINDERS.md` uniquement après confirmation, attribution, vérification et réordonnancement.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/DOCUMENTATION_REFACTOR_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Plan de refonte documentaire
|
||||
|
||||
@@ -13,7 +13,10 @@ Aucune version Cargo ne doit être modifiée avant la conclusion de `docs/V0_4_6
|
||||
|
||||
- livrer des deltas courts et thématiques ;
|
||||
- ne pas créer en masse des documents vides ;
|
||||
- documenter une crate à partir de ses APIs et tests réels ;
|
||||
- documenter une crate à partir de ses APIs publiques, binaires, tests et configurations réels ;
|
||||
- ne jamais déplacer ni migrer automatiquement un document depuis `olddocs/archivekbot2/` ;
|
||||
- créer des documents bot3 nouveaux après lecture, sélection, vérification et adaptation des sources historiques ;
|
||||
- référencer les matrices canoniques de `test-fixtures/contract-matrices/` sans les dupliquer ;
|
||||
- ne pas inventer d’API ou de validation ;
|
||||
- archiver avant de retirer un document ayant une valeur historique ;
|
||||
- corriger toutes les références avant chaque déplacement ;
|
||||
@@ -113,6 +116,13 @@ docs/
|
||||
|
||||
olddocs/
|
||||
├── archivekbot2/
|
||||
│ ├── README.md
|
||||
│ ├── CHANGELOG.md
|
||||
│ ├── ROADMAP.md
|
||||
│ ├── RULES.md
|
||||
│ ├── docs/
|
||||
│ ├── prompts/
|
||||
│ └── <anciennes-crates>/...
|
||||
└── archivekbot3/
|
||||
```
|
||||
|
||||
@@ -133,7 +143,6 @@ Validations :
|
||||
|
||||
```bash
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
git diff --check
|
||||
```
|
||||
|
||||
### Delta 2 — archives et index documentaire
|
||||
@@ -141,25 +150,32 @@ git diff --check
|
||||
Travail :
|
||||
|
||||
1. créer `olddocs/archivekbot2/` ;
|
||||
2. y copier intégralement `khadhroony-bot2/docs/` ;
|
||||
3. créer `olddocs/archivekbot3/` ;
|
||||
4. créer `docs/README.md` ;
|
||||
5. créer l’arborescence utile sans fichiers factices ;
|
||||
6. documenter la provenance, la non-normativité et l’intégrité logique de l’archive bot2.
|
||||
2. y reconstruire le miroir documentaire de bot2 en conservant les chemins relatifs : documents racine, `docs/`, `prompts/` et documents des anciennes crates ;
|
||||
3. inclure les fichiers présentant une fonction documentaire démontrée, conformément à la politique de sélection, sans copier le code, les artefacts de build ou les données privées ;
|
||||
4. appliquer [`decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md`](decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md) pour distinguer matrices, schémas, exemples et IDL documentaires des fixtures et configurations d’exécution ;
|
||||
4. créer `olddocs/archivekbot3/` ;
|
||||
5. créer `docs/README.md` ;
|
||||
6. créer l’arborescence utile sans fichiers factices ;
|
||||
7. documenter la provenance, la non-normativité et l’intégrité logique de l’archive bot2.
|
||||
|
||||
Aucun document bot3 actif ne doit encore être supprimé.
|
||||
|
||||
### Delta 3 — règles documentaires
|
||||
### Delta 3 — règles documentaires (`v0.1.0-pre.065`)
|
||||
|
||||
Travail :
|
||||
|
||||
1. corriger `RULES_GENERAL.md` pour imposer les quatre fichiers exacts par crate ;
|
||||
2. supprimer les variantes obsolètes `001.README.md` et `USAGES.md` ;
|
||||
3. définir la frontière entre README, TODO, USAGE, CHANGELOG général et changelogs de crates ;
|
||||
4. préciser le rôle de `docs/`, `olddocs/archivekbot2/` et `olddocs/archivekbot3/` ;
|
||||
5. définir les règles de prompts et d’archivage documentaire.
|
||||
2. supprimer les variantes obsolètes `001.README.md` et `USAGES.md`, et retenir définitivement `USAGE.md` ;
|
||||
3. créer `docs/rules/CRATE_DOCUMENTATION_RULES.md` ;
|
||||
4. définir la frontière entre README, TODO, USAGE, CHANGELOG général et changelogs de crates ;
|
||||
5. imposer que `USAGE.md` documente uniquement les APIs publiques réellement accessibles ;
|
||||
6. imposer dans chaque changelog de crate une base `0.1.0` décrivant la migration bot2, la consolidation bot3 et les nouvelles normes ;
|
||||
7. définir la reprise contrôlée des idées confirmées de `docs/IDEA_REMINDERS.md` dans les TODO ;
|
||||
8. interdire toute duplication des matrices canoniques de `test-fixtures/contract-matrices/` ;
|
||||
9. préciser les statuts Metaplex Token Metadata, ElGamal et IDL ;
|
||||
10. fournir quatre modèles documentaires non génératifs.
|
||||
|
||||
Les règles restent temporairement à la racine dans ce delta.
|
||||
Les règles secondaires restent temporairement à la racine dans ce delta.
|
||||
|
||||
### Delta 4 — déplacement des règles secondaires
|
||||
|
||||
@@ -177,7 +193,6 @@ Validations obligatoires :
|
||||
|
||||
```bash
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
git diff --check
|
||||
```
|
||||
|
||||
### Delta 5 — changelog général de transition
|
||||
@@ -199,7 +214,7 @@ Le changelog ne doit pas affirmer que bot3 est déjà officiellement `0.4.6`.
|
||||
Reconstruire `ROADMAP.md` selon les séries suivantes :
|
||||
|
||||
- `0.4.6` : fermeture de l’alignement et écarts résiduels ;
|
||||
- `0.4.7` : Metaplex Token Metadata et clôture `0.4.x` ;
|
||||
- `0.4.7` : poursuite de Metaplex Token Metadata déjà partiellement migré, puis clôture `0.4.x` ;
|
||||
- `0.5.x` : configuration, scénarios autonomes, CLI, fixtures et wallet ;
|
||||
- `0.6.x` : infrastructure Anchor, reste SPL et Metaplex ;
|
||||
- `0.7.x` : Meteora ;
|
||||
@@ -323,9 +338,10 @@ Seulement après validation du delta 12 :
|
||||
|
||||
```bash
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
git diff --check
|
||||
```
|
||||
|
||||
Les opérations Git et leurs contrôles sont réalisés séparément par l’opérateur et ne doivent pas être répétés dans les validations demandées à la session.
|
||||
|
||||
### Code, scripts d’audit ou structure utilisée par le code
|
||||
|
||||
```bash
|
||||
@@ -349,16 +365,16 @@ cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
|
||||
## 7. Risques contrôlés
|
||||
|
||||
| Risque | Mesure |
|
||||
|----------------------------------------------------|--------------------------------------------------------------|
|
||||
| perte d’historique bot2 | copie intégrale dans `olddocs/archivekbot2/` avant reprise |
|
||||
| règles introuvables après déplacement | correction préalable des scripts et références, delta dédié |
|
||||
| documentation d’API inventée | lecture des exports et tests avant rédaction |
|
||||
| changelog général trop détaillé | déléguer le détail fonctionnel aux changelogs de crates |
|
||||
| roadmap redevenant une checklist | interdire prereleases et correctifs dans le roadmap général |
|
||||
| confusion entre migration et version fonctionnelle | section de transition explicite et audit d’alignement séparé |
|
||||
| fausse validation ElGamal | conserver le statut non validé Devnet |
|
||||
| modification massive difficile à relire | un thème documentaire par delta |
|
||||
| Risque | Mesure |
|
||||
|----------------------------------------------------|-----------------------------------------------------------------------------|
|
||||
| perte d’historique bot2 | miroir documentaire hiérarchique dans `olddocs/archivekbot2/` avant reprise |
|
||||
| règles introuvables après déplacement | correction préalable des scripts et références, delta dédié |
|
||||
| documentation d’API inventée | lecture des exports et tests avant rédaction |
|
||||
| changelog général trop détaillé | déléguer le détail fonctionnel aux changelogs de crates |
|
||||
| roadmap redevenant une checklist | interdire prereleases et correctifs dans le roadmap général |
|
||||
| confusion entre migration et version fonctionnelle | section de transition explicite et audit d’alignement séparé |
|
||||
| fausse validation ElGamal | conserver le statut non validé Devnet |
|
||||
| modification massive difficile à relire | un thème documentaire par delta |
|
||||
|
||||
## 8. Première décision attendue
|
||||
|
||||
|
||||
112
docs/README.md
Normal file
112
docs/README.md
Normal file
@@ -0,0 +1,112 @@
|
||||
<!-- file: docs/README.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Documentation de `khadhroony-bot3`
|
||||
|
||||
## 1. Rôle
|
||||
|
||||
Ce répertoire contient la documentation active, normative ou encore utilisée de `khadhroony-bot3`.
|
||||
|
||||
La documentation historique de `khadhroony-bot2` et les documents bot3 remplacés sont conservés séparément sous `olddocs/`. Un document archivé peut servir de source historique, mais il n’est pas normatif pour l’architecture bot3 actuelle.
|
||||
|
||||
## 2. Documents de pilotage actifs
|
||||
|
||||
| Document | Rôle |
|
||||
|----------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|
|
||||
| [`DOCUMENTATION_REFACTOR_AUDIT.md`](DOCUMENTATION_REFACTOR_AUDIT.md) | inventaire et écarts documentaires de la base `v0.1.0-pre.062` |
|
||||
| [`DOCUMENTATION_REFACTOR_PLAN.md`](DOCUMENTATION_REFACTOR_PLAN.md) | séquence contrôlée de reconstruction documentaire et d’alignement `0.4.6` |
|
||||
| [`decisions/WINCODE_COMPATIBILITY_POLICY.md`](decisions/WINCODE_COMPATIBILITY_POLICY.md) | justification durable de la contrainte `wincode 0.5.x` et du contrôle du lockfile |
|
||||
| [`decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md`](decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md) | critères normatifs de conservation et d’exclusion dans les archives documentaires |
|
||||
|
||||
## 3. Documents existants à reclasser
|
||||
|
||||
Les documents suivants restent temporairement à leur chemin actuel jusqu’au delta de réorganisation :
|
||||
|
||||
- `DEVNET_EXECUTION_GUIDE.md` ;
|
||||
- `PRE_062_DEVNET_VALIDATION_REPORT.md` ;
|
||||
- `OPERATION_NAMING_CONVENTION.md` ;
|
||||
- `IDL_AUDIT.md` ;
|
||||
- `IDL_TO_KB_LIB_NOMENCLATURE.md` ;
|
||||
- `MISSING_PROGRAM_IDLS.md` ;
|
||||
- `IDEA_REMINDERS.md`.
|
||||
|
||||
Leur présence à la racine de `docs/` est transitoire. Ils ne doivent pas être déplacés avant correction de leurs références.
|
||||
|
||||
## 4. Arborescence cible
|
||||
|
||||
```text
|
||||
docs/
|
||||
├── README.md
|
||||
├── architecture/
|
||||
├── audits/
|
||||
├── decisions/
|
||||
├── generated/
|
||||
├── guides/
|
||||
├── migrations/
|
||||
├── protocols/
|
||||
├── rules/
|
||||
└── validation/
|
||||
```
|
||||
|
||||
Les répertoires sont créés lorsqu’un document réel doit y être classé. Aucun fichier factice n’est requis.
|
||||
|
||||
## 5. Archives historiques
|
||||
|
||||
### 5.1 Archive bot2
|
||||
|
||||
```text
|
||||
olddocs/archivekbot2/
|
||||
```
|
||||
|
||||
Cette archive reproduit les chemins relatifs des fichiers sélectionnés selon leur fonction documentaire dans l’archive complète bot2 fournie pour la session. La sélection ne dépend pas de l’extension et suit [`decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md`](decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md). Elle comprend notamment :
|
||||
|
||||
- les documents racine historiques ;
|
||||
- `docs/` ;
|
||||
- `prompts/` ;
|
||||
- les README, changelogs et autres documents des anciennes crates ;
|
||||
- les matrices, schémas, exemples de configuration et IDL ayant une valeur documentaire démontrée.
|
||||
|
||||
Les fichiers sont conservés sans adaptation de fond. Les liens relatifs peuvent viser l’ancienne arborescence bot2 et ne garantissent pas une navigation fonctionnelle depuis bot3.
|
||||
|
||||
### 5.2 Archive bot3
|
||||
|
||||
```text
|
||||
olddocs/archivekbot3/
|
||||
```
|
||||
|
||||
Cette archive recevra progressivement les audits, plans, prompts et documents bot3 remplacés qui conservent une valeur historique, décisionnelle ou de traçabilité.
|
||||
|
||||
## 6. Contrat documentaire des crates
|
||||
|
||||
Chaque crate doit finalement posséder exactement :
|
||||
|
||||
```text
|
||||
README.md
|
||||
TODO.md
|
||||
USAGE.md
|
||||
CHANGELOG.md
|
||||
```
|
||||
|
||||
`USAGE.md` est la convention retenue. La variante `USAGES.md` est obsolète.
|
||||
|
||||
Le contenu attendu de chaque fichier est défini par [`rules/CRATE_DOCUMENTATION_RULES.md`](rules/CRATE_DOCUMENTATION_RULES.md). Les modèles de `docs/templates/` servent uniquement d’aide à la rédaction.
|
||||
|
||||
## 7. Règles de consultation
|
||||
|
||||
Ordre recommandé :
|
||||
|
||||
1. `RULES.md` à la racine du workspace ;
|
||||
2. les règles secondaires à leur emplacement normatif courant ;
|
||||
3. le présent index ;
|
||||
4. les documents d’architecture ou de validation liés à la tâche ;
|
||||
5. `olddocs/` uniquement pour l’historique ou la reprise contrôlée d’informations.
|
||||
|
||||
## Règles et modèles documentaires
|
||||
|
||||
- [`rules/CRATE_DOCUMENTATION_RULES.md`](rules/CRATE_DOCUMENTATION_RULES.md) : contrat normatif des quatre documents de chaque crate ;
|
||||
- [`templates/CRATE_README_TEMPLATE.md`](templates/CRATE_README_TEMPLATE.md) ;
|
||||
- [`templates/CRATE_TODO_TEMPLATE.md`](templates/CRATE_TODO_TEMPLATE.md) ;
|
||||
- [`templates/CRATE_USAGE_TEMPLATE.md`](templates/CRATE_USAGE_TEMPLATE.md) ;
|
||||
- [`templates/CRATE_CHANGELOG_TEMPLATE.md`](templates/CRATE_CHANGELOG_TEMPLATE.md).
|
||||
|
||||
Les modèles ne doivent jamais être remplis mécaniquement : la rédaction exige la lecture du code, des exports publics, des tests et des sources historiques pertinentes.
|
||||
70
docs/decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md
Normal file
70
docs/decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md
Normal file
@@ -0,0 +1,70 @@
|
||||
<!-- file: docs/decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Politique de sélection des archives documentaires
|
||||
|
||||
## 1. Objet
|
||||
|
||||
Cette politique définit les fichiers historiques qui peuvent être copiés depuis l’archive complète de `khadhroony-bot2` vers `olddocs/archivekbot2/`.
|
||||
|
||||
La sélection repose sur la fonction documentaire du fichier, et non sur son extension ni uniquement sur son emplacement.
|
||||
|
||||
## 2. Principe général
|
||||
|
||||
`olddocs/archivekbot2/` est une archive documentaire historique et non une copie partielle du workspace exécutable.
|
||||
|
||||
L’archive complète de bot2 reste la référence pour le code source, les fixtures, les configurations d’exécution et les artefacts nécessaires à la compilation ou aux tests.
|
||||
|
||||
## 3. Fichiers à conserver
|
||||
|
||||
Les catégories suivantes peuvent être conservées lorsqu’elles présentent une valeur historique, normative, architecturale ou décisionnelle :
|
||||
|
||||
- documents Markdown racine, sous `docs/`, sous `prompts/` et dans les anciennes crates ;
|
||||
- changelogs, roadmaps, règles, audits, plans, rapports, guides et décisions ;
|
||||
- matrices JSON décrivant une couverture, un contrat, une validation ou un inventaire ;
|
||||
- IDL archivées servant de références pour la conception manuelle des futurs décodeurs, exécuteurs, matérialisateurs, matrices et tests ;
|
||||
- schémas publics décrivant formellement un contrat de configuration ;
|
||||
- exemples de configuration destinés aux utilisateurs ou aux opérateurs ;
|
||||
- autres fichiers non exécutables dont la valeur documentaire est explicitement démontrée.
|
||||
|
||||
## 4. Fichiers à exclure
|
||||
|
||||
Les catégories suivantes ne doivent pas être copiées dans l’archive documentaire :
|
||||
|
||||
- code source et fichiers internes placés sous `src/`, même lorsqu’ils utilisent une extension documentaire, sauf décision explicite motivée ;
|
||||
- fixtures de tests, snapshots et réponses RPC enregistrées ;
|
||||
- manifests et configurations nécessaires au build ou au lancement de l’ancienne application ;
|
||||
- fichiers Tauri, npm, TypeScript et capabilities servant à l’exécution ;
|
||||
- bases de données, clés, preuves, données privées et fichiers temporaires ;
|
||||
- artefacts générés ou reconstructibles sans valeur documentaire autonome.
|
||||
|
||||
## 5. Cas explicitement conservés
|
||||
|
||||
Les fichiers suivants sont conservés car leur fonction est documentaire :
|
||||
|
||||
```text
|
||||
config/example.config.json
|
||||
config/schema.config.json
|
||||
docs/*_MATRIX.json
|
||||
idls/*.json
|
||||
```
|
||||
|
||||
`example.config.json` illustre la configuration utilisateur historique complète. `schema.config.json` formalise le contrat de cette configuration. Les matrices documentent les périmètres techniques et les validations. Les IDL sont des références archivées et ne sont pas chargées dynamiquement par le code de production.
|
||||
|
||||
## 6. Cas explicitement exclus
|
||||
|
||||
Les fichiers suivants sont exclus car ils relèvent de l’exécution ou des tests :
|
||||
|
||||
```text
|
||||
kb_app_demo/capabilities/default.json
|
||||
kb_app_demo/package.json
|
||||
kb_app_demo/tauri.conf.json
|
||||
kb_app_demo/tsconfig.json
|
||||
kb_rpc/tests/fixtures/*.json
|
||||
kb_store_core/src/**
|
||||
kb_store_pg/src/**
|
||||
```
|
||||
|
||||
## 7. Évolution de l’archive
|
||||
|
||||
Tout ajout futur à `olddocs/archivekbot2/` doit être évalué avec cette politique. En cas d’ambiguïté, le fichier n’est pas copié tant que sa valeur documentaire autonome n’est pas démontrée.
|
||||
62
docs/decisions/WINCODE_COMPATIBILITY_POLICY.md
Normal file
62
docs/decisions/WINCODE_COMPATIBILITY_POLICY.md
Normal file
@@ -0,0 +1,62 @@
|
||||
<!-- file: docs/decisions/WINCODE_COMPATIBILITY_POLICY.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Politique de compatibilité `wincode`
|
||||
|
||||
## 1. Objet
|
||||
|
||||
Ce document explique pourquoi le workspace `khadhroony-bot3` contraint actuellement `wincode` à la famille `0.5.x` et pourquoi le contrôle du `Cargo.lock` local existe.
|
||||
|
||||
Cette contrainte est un garde-fou de compatibilité de dépendances. Elle ne constitue pas un écart fonctionnel à réexaminer dans chaque prompt ou chaque livraison documentaire.
|
||||
|
||||
## 2. Incident à l’origine de la règle
|
||||
|
||||
Pendant la migration vers bot3, l’apparition de `wincode 0.6.0` dans la résolution de dépendances a créé une incompatibilité avec des crates Solana ou interfaces encore fondées sur les traits de `wincode 0.5.x`.
|
||||
|
||||
Les familles `wincode 0.5` et `wincode 0.6` ne sont pas interchangeables au niveau de leurs traits et types. Une résolution transitive non maîtrisée peut donc produire des erreurs de compilation même lorsque les noms des APIs paraissent identiques.
|
||||
|
||||
## 3. Décision actuelle
|
||||
|
||||
Tant que les interfaces Solana consommées par le workspace utilisent la famille `0.5.x` :
|
||||
|
||||
```text
|
||||
wincode = "^0.5"
|
||||
```
|
||||
|
||||
La résolution locale attendue est :
|
||||
|
||||
```text
|
||||
wincode 0.5.5
|
||||
solana-wincode-varint 1.0.0
|
||||
```
|
||||
|
||||
Le script `scripts/audit_khadhroony_workspace_rules.py` vérifie :
|
||||
|
||||
1. la contrainte `^0.5` dans le catalogue de dépendances workspace ;
|
||||
2. la présence du `Cargo.lock` local ;
|
||||
3. l’absence d’une seconde famille `wincode` incompatible ;
|
||||
4. les versions résolues attendues.
|
||||
|
||||
## 4. Rôle du `Cargo.lock`
|
||||
|
||||
Le `Cargo.lock` est nécessaire à ce contrôle parce que `Cargo.toml` décrit une plage de versions, tandis que le lockfile démontre la résolution réellement utilisée par le workspace.
|
||||
|
||||
Les archives de livraison peuvent ne pas contenir ce fichier selon leur convention d’empaquetage. Dans ce cas :
|
||||
|
||||
- l’absence du lockfile dans l’archive n’est pas un défaut fonctionnel du projet ;
|
||||
- le contrôle complet doit être exécuté dans le workspace local réel avec son `Cargo.lock` ;
|
||||
- la livraison ne doit pas répéter cette limite comme un nouvel écart documentaire à chaque session ;
|
||||
- le lockfile peut être fourni ponctuellement à la session lorsqu’une exécution de l’audit est nécessaire.
|
||||
|
||||
## 5. Évolution future
|
||||
|
||||
Le passage à `wincode 0.6+` ne doit pas être effectué par simple mise à jour de version. Il exige :
|
||||
|
||||
- l’inventaire des crates directes et transitives utilisant `wincode` ;
|
||||
- la vérification des versions d’interfaces Solana compatibles ;
|
||||
- l’absence de familles de traits concurrentes ;
|
||||
- la compilation de l’ensemble du workspace ;
|
||||
- les tests des décodeurs et parseurs concernés ;
|
||||
- la mise à jour de la règle et du script d’audit dans le même changement.
|
||||
|
||||
Jusqu’à cette migration explicitement validée, `wincode 0.5.5` reste la résolution normative du workspace.
|
||||
299
docs/rules/CRATE_DOCUMENTATION_RULES.md
Normal file
299
docs/rules/CRATE_DOCUMENTATION_RULES.md
Normal file
@@ -0,0 +1,299 @@
|
||||
<!-- file: docs/rules/CRATE_DOCUMENTATION_RULES.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Règles documentaires des crates
|
||||
|
||||
## 1. Objet
|
||||
|
||||
Ce document définit le contrat documentaire normatif applicable à chaque crate membre du workspace `khadhroony-bot3`.
|
||||
|
||||
Chaque crate doit posséder exactement les quatre fichiers suivants à sa racine :
|
||||
|
||||
```text
|
||||
README.md
|
||||
TODO.md
|
||||
USAGE.md
|
||||
CHANGELOG.md
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
## 2. Principes communs
|
||||
|
||||
Pour chaque document de crate :
|
||||
|
||||
- décrire uniquement des éléments vérifiés dans le code, les exports publics, les tests, les configurations actives ou les décisions acquises ;
|
||||
- ne pas inventer d’API, de fonctionnalité, de validation ou de compatibilité ;
|
||||
- distinguer clairement l’existant, le partiellement implémenté, le reporté et le hors périmètre ;
|
||||
- employer les noms actuels des crates, modules publics, binaires et types ;
|
||||
- ajouter des liens relatifs valides vers les autres documents de la crate et vers la documentation transversale pertinente ;
|
||||
- ne pas recopier une matrice, une fixture ou un rapport déjà maintenu à son emplacement canonique ;
|
||||
- préférer un lien vers `test-fixtures/contract-matrices/`, les tests ou un document transversal plutôt qu’une duplication ;
|
||||
- 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.
|
||||
|
||||
## 3. `README.md`
|
||||
|
||||
### 3.1 Rôle
|
||||
|
||||
Le README présente la crate à un lecteur qui doit comprendre rapidement sa place dans le workspace.
|
||||
|
||||
### 3.2 Contenu obligatoire
|
||||
|
||||
Le README contient au minimum :
|
||||
|
||||
1. objectif ;
|
||||
2. périmètre fonctionnel ;
|
||||
3. responsabilités ;
|
||||
4. éléments explicitement hors périmètre ;
|
||||
5. principales fonctionnalités déjà disponibles ;
|
||||
6. principales façades ou catégories d’API publiques, sans catalogue exhaustif ;
|
||||
7. relations avec les autres crates ;
|
||||
8. binaires fournis, le cas échéant ;
|
||||
9. statut de maturité et limites importantes ;
|
||||
10. liens vers `USAGE.md`, `TODO.md`, `CHANGELOG.md` et les documents d’architecture pertinents.
|
||||
|
||||
### 3.3 Interdictions
|
||||
|
||||
Le README ne doit pas :
|
||||
|
||||
- servir de journal chronologique ;
|
||||
- contenir une liste détaillée de toutes les prereleases ou corrections `fix` ;
|
||||
- annoncer comme disponible une fonctionnalité seulement prévue ;
|
||||
- recopier intégralement les APIs publiques ;
|
||||
- recopier les matrices de contrats présentes dans `test-fixtures/contract-matrices/` ;
|
||||
- reprendre sans adaptation un README de bot2.
|
||||
|
||||
## 4. `USAGE.md`
|
||||
|
||||
### 4.1 Rôle
|
||||
|
||||
`USAGE.md` documente l’utilisation réelle de la crate depuis l’extérieur de celle-ci.
|
||||
|
||||
### 4.2 Frontière des APIs documentées
|
||||
|
||||
Le guide documente uniquement les APIs publiques exposées aux consommateurs de la crate :
|
||||
|
||||
- éléments `pub` effectivement accessibles depuis la racine publique ou un chemin public stable ;
|
||||
- traits publics destinés à être implémentés ou appelés par d’autres crates ;
|
||||
- fonctions, constructeurs, méthodes, types, constantes et façades publiques significatives ;
|
||||
- commandes, événements, DTO ou contrats IPC publics d’une application ou d’une crate mixte ;
|
||||
- arguments et comportement des binaires publics.
|
||||
|
||||
Il ne documente pas comme APIs d’utilisation :
|
||||
|
||||
- les éléments `pub(crate)` ;
|
||||
- les sous-modules internes non réexportés ;
|
||||
- les helpers de test ;
|
||||
- les détails privés d’implémentation ;
|
||||
- une dépendance simplement utilisée en interne ;
|
||||
- une API historique bot2 qui n’existe plus dans bot3.
|
||||
|
||||
Une réexportation publique doit être vérifiée jusqu’à son chemin d’accès consommateur. La seule présence du mot-clé `pub` dans un fichier interne ne suffit pas.
|
||||
|
||||
### 4.3 Contenu obligatoire
|
||||
|
||||
`USAGE.md` contient au minimum :
|
||||
|
||||
1. objectif du guide ;
|
||||
2. prérequis ;
|
||||
3. dépendance Cargo et features utiles, lorsqu’applicable ;
|
||||
4. configuration nécessaire ;
|
||||
5. vue d’ensemble de la surface publique ;
|
||||
6. description des APIs publiques significatives ;
|
||||
7. types publics importants et invariants ;
|
||||
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 ;
|
||||
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.
|
||||
|
||||
### 4.4 Crates sans API bibliothèque publique
|
||||
|
||||
Une crate principalement binaire ou interne conserve un `USAGE.md`. Le document décrit alors ses commandes, entrées, sorties, configuration, contrats d’intégration et limites, sans inventer une API Rust publique.
|
||||
|
||||
## 5. `TODO.md`
|
||||
|
||||
### 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.
|
||||
|
||||
### 5.2 Sections obligatoires
|
||||
|
||||
Le fichier distingue au minimum :
|
||||
|
||||
- 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 préciser, lorsque connu :
|
||||
|
||||
- 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.
|
||||
|
||||
### 5.3 Relation avec `docs/IDEA_REMINDERS.md`
|
||||
|
||||
Les idées de `docs/IDEA_REMINDERS.md` ne sont pas copiées automatiquement dans les TODO de crates.
|
||||
|
||||
Une idée peut être intégrée au TODO d’une crate uniquement après :
|
||||
|
||||
1. confirmation qu’elle est toujours souhaitée ;
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
### 5.4 Interdictions
|
||||
|
||||
Le TODO ne doit pas :
|
||||
|
||||
- répéter les travaux déjà terminés ;
|
||||
- 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é.
|
||||
|
||||
## 6. `CHANGELOG.md`
|
||||
|
||||
### 6.1 Rôle
|
||||
|
||||
Le changelog de crate retrace l’évolution fonctionnelle, structurelle et contractuelle de cette crate.
|
||||
|
||||
### 6.2 Base historique minimale
|
||||
|
||||
Chaque changelog de crate doit contenir au minimum :
|
||||
|
||||
- une section `Non publié` ;
|
||||
- une section `0.1.0` décrivant 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.
|
||||
|
||||
La section `0.1.0` peut regrouper les prereleases de migration lorsque leur détail exhaustif n’apporte pas de valeur. Les prereleases ou correctifs importants peuvent être conservés lorsqu’ils expliquent une rupture, une correction notable ou une validation structurante.
|
||||
|
||||
### 6.3 Catégories
|
||||
|
||||
Utiliser uniquement les catégories pertinentes parmi :
|
||||
|
||||
- Ajouté ;
|
||||
- Modifié ;
|
||||
- Corrigé ;
|
||||
- Supprimé ;
|
||||
- Migré ;
|
||||
- Compatibilité ;
|
||||
- Validation ;
|
||||
- Limitations connues ;
|
||||
- Documentation.
|
||||
|
||||
Ne pas créer des sections vides.
|
||||
|
||||
### 6.4 Versions et corrections
|
||||
|
||||
Le changelog distingue clairement :
|
||||
|
||||
- version publiée ;
|
||||
- prerelease ;
|
||||
- correctif `fix` ;
|
||||
- changement non publié.
|
||||
|
||||
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`.
|
||||
|
||||
### 6.5 Provenance bot2
|
||||
|
||||
La reprise historique depuis bot2 doit être synthétique et traçable. Elle s’appuie sur les changelogs, README, rapports et code historiques, mais est réécrite pour refléter la responsabilité actuelle de la crate bot3.
|
||||
|
||||
Il est interdit de copier un changelog d’ancienne crate sans analyser :
|
||||
|
||||
- la destination de ses responsabilités dans bot3 ;
|
||||
- les APIs supprimées ou consolidées ;
|
||||
- les changements de noms ;
|
||||
- les nouvelles contraintes ;
|
||||
- les validations réellement conservées.
|
||||
|
||||
## 7. Matrices, fixtures, IDL et rapports
|
||||
|
||||
### 7.1 Matrices de contrats
|
||||
|
||||
Les matrices actives maintenues sous :
|
||||
|
||||
```text
|
||||
test-fixtures/contract-matrices/
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
### 7.2 IDL
|
||||
|
||||
Les IDL archivées ou maintenues dans le workspace servent de références de conception et d’audit. Elles ne sont pas chargées dynamiquement par le code de production.
|
||||
|
||||
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.
|
||||
|
||||
Pour chaque IDL ajoutée, documenter lorsque possible :
|
||||
|
||||
- protocole et programme ;
|
||||
- Program ID ;
|
||||
- source ;
|
||||
- version, tag ou commit ;
|
||||
- nom de fichier normalisé ;
|
||||
- surface actuelle ou future qui l’utilise ;
|
||||
- statut de vérification.
|
||||
|
||||
### 7.3 Rapports historiques
|
||||
|
||||
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.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 :
|
||||
|
||||
1. lire son `Cargo.toml`, ses features et ses cibles ;
|
||||
2. inventorier les exports accessibles depuis la racine publique ;
|
||||
3. identifier les binaires et commandes ;
|
||||
4. lire les tests et exemples ;
|
||||
5. rechercher les anciennes responsabilités bot2 correspondantes ;
|
||||
6. confronter les idées confirmées et le ROADMAP ;
|
||||
7. rédiger les quatre documents ;
|
||||
8. vérifier les liens et exemples ;
|
||||
9. exécuter les audits documentaires prescrits ;
|
||||
10. exécuter les tests de la crate uniquement si le travail révèle ou corrige une incohérence de code.
|
||||
|
||||
La création des documents ne doit jamais être une génération mécanique fondée seulement sur les noms de fichiers ou les anciens documents.
|
||||
30
docs/templates/CRATE_CHANGELOG_TEMPLATE.md
vendored
Normal file
30
docs/templates/CRATE_CHANGELOG_TEMPLATE.md
vendored
Normal file
@@ -0,0 +1,30 @@
|
||||
<!-- file: docs/templates/CRATE_CHANGELOG_TEMPLATE.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Modèle de changelog de crate
|
||||
|
||||
# Changelog de `<nom-de-crate>`
|
||||
|
||||
## Non publié
|
||||
|
||||
### Documentation
|
||||
|
||||
- Création ou mise à jour de la documentation de crate.
|
||||
|
||||
## 0.1.0
|
||||
|
||||
### Migré
|
||||
|
||||
- Migration depuis les composants correspondants de `khadhroony-bot2` vers l’architecture consolidée de `khadhroony-bot3`.
|
||||
|
||||
### Modifié
|
||||
|
||||
- Adoption des règles Rust et Khadhroony applicables à bot3.
|
||||
|
||||
### 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.
|
||||
36
docs/templates/CRATE_README_TEMPLATE.md
vendored
Normal file
36
docs/templates/CRATE_README_TEMPLATE.md
vendored
Normal file
@@ -0,0 +1,36 @@
|
||||
<!-- file: docs/templates/CRATE_README_TEMPLATE.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Modèle de README de crate
|
||||
|
||||
> Ce modèle est une aide de rédaction. Supprimer les instructions et sections non applicables après analyse réelle de la crate.
|
||||
|
||||
# `<nom-de-crate>`
|
||||
|
||||
## Objectif
|
||||
|
||||
## Périmètre
|
||||
|
||||
## Responsabilités
|
||||
|
||||
## Hors périmètre
|
||||
|
||||
## Fonctionnalités disponibles
|
||||
|
||||
## Surface publique principale
|
||||
|
||||
Présenter les catégories d’API ou façades sans recopier `USAGE.md`.
|
||||
|
||||
## Binaire(s)
|
||||
|
||||
Supprimer cette section si la crate ne fournit aucun binaire.
|
||||
|
||||
## Relations avec le workspace
|
||||
|
||||
## Statut et limites
|
||||
|
||||
## Documentation
|
||||
|
||||
- [Guide d’utilisation](USAGE.md)
|
||||
- [Travaux restant à réaliser](TODO.md)
|
||||
- [Historique des changements](CHANGELOG.md)
|
||||
24
docs/templates/CRATE_TODO_TEMPLATE.md
vendored
Normal file
24
docs/templates/CRATE_TODO_TEMPLATE.md
vendored
Normal file
@@ -0,0 +1,24 @@
|
||||
<!-- file: docs/templates/CRATE_TODO_TEMPLATE.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Modèle de TODO de crate
|
||||
|
||||
# Travaux restant pour `<nom-de-crate>`
|
||||
|
||||
## 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
|
||||
|
||||
> Ne reprendre une idée de `docs/IDEA_REMINDERS.md` qu’après confirmation, attribution à cette crate et reformulation en tâche vérifiable.
|
||||
46
docs/templates/CRATE_USAGE_TEMPLATE.md
vendored
Normal file
46
docs/templates/CRATE_USAGE_TEMPLATE.md
vendored
Normal file
@@ -0,0 +1,46 @@
|
||||
<!-- file: docs/templates/CRATE_USAGE_TEMPLATE.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Modèle de guide d’utilisation de crate
|
||||
|
||||
> Documenter uniquement la surface publique réellement accessible aux consommateurs.
|
||||
|
||||
# Utilisation de `<nom-de-crate>`
|
||||
|
||||
## Objectif
|
||||
|
||||
## Prérequis
|
||||
|
||||
## Dépendance et features
|
||||
|
||||
## Configuration
|
||||
|
||||
## Vue d’ensemble de l’API publique
|
||||
|
||||
## APIs publiques significatives
|
||||
|
||||
Pour chaque API ou groupe cohérent :
|
||||
|
||||
- chemin public ;
|
||||
- rôle ;
|
||||
- paramètres ou types associés ;
|
||||
- valeur retournée ;
|
||||
- erreurs ;
|
||||
- invariants ;
|
||||
- exemple.
|
||||
|
||||
## Types publics importants
|
||||
|
||||
## Erreurs et invariants
|
||||
|
||||
## Exemples
|
||||
|
||||
## Utilisation du binaire
|
||||
|
||||
Supprimer cette section si aucun binaire public n’existe.
|
||||
|
||||
## Limites connues
|
||||
|
||||
## Références
|
||||
|
||||
Lier les tests, exemples, fixtures et matrices canoniques sans les dupliquer.
|
||||
Reference in New Issue
Block a user