v0.1.0-pre.074
This commit is contained in:
22
olddocs/archivekbot3/001.README.md
Normal file
22
olddocs/archivekbot3/001.README.md
Normal file
@@ -0,0 +1,22 @@
|
||||
<!-- file: olddocs/archivekbot3/001.README.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Archive documentaire de khadhroony-bot3
|
||||
|
||||
Ce répertoire conserve les documents bot3 remplacés, temporaires ou liés à une phase historique terminée.
|
||||
|
||||
## Statut
|
||||
|
||||
Les documents archivés :
|
||||
|
||||
- ne sont plus normatifs ;
|
||||
- ne doivent pas être utilisés seuls pour décrire l’état actuel du workspace ;
|
||||
- restent disponibles pour la traçabilité des décisions et de la migration ;
|
||||
- conservent autant que possible leur nom et leur contenu d’origine.
|
||||
|
||||
## Arborescence
|
||||
|
||||
- `docs/` : audits, plans et rapports bot3 remplacés ;
|
||||
- `prompts/` : prompts utilisés pendant la migration architecturale.
|
||||
|
||||
La documentation active reste sous `docs/`. Le point d’entrée normatif reste `RULES.md`.
|
||||
284
olddocs/archivekbot3/docs/DOCUMENTATION_REFACTOR_AUDIT.md
Normal file
284
olddocs/archivekbot3/docs/DOCUMENTATION_REFACTOR_AUDIT.md
Normal file
@@ -0,0 +1,284 @@
|
||||
<!-- file: docs/DOCUMENTATION_REFACTOR_AUDIT.md -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Audit de refonte documentaire
|
||||
|
||||
## 1. Objet
|
||||
|
||||
Cet audit établit l’état documentaire de `khadhroony-bot3` à partir de la base `v0.1.0-pre.062`, en comparaison avec l’archive complète fournie de `khadhroony-bot2 v0.4.7-pre.035-tofix07`.
|
||||
|
||||
Il précède toute refonte massive, tout déplacement des règles secondaires et tout réalignement du versionnement vers `0.4.6+`. Il ne constitue pas un nouvel audit technique des surfaces Solana déjà validées.
|
||||
|
||||
## 2. Sources inspectées
|
||||
|
||||
### 2.1 Racine bot3
|
||||
|
||||
Les fichiers suivants existent à la racine :
|
||||
|
||||
- `README.md` ;
|
||||
- `CHANGELOG.md` ;
|
||||
- `ROADMAP.md` ;
|
||||
- `RULES.md` ;
|
||||
- `docs/rules/RULES_GENERAL.md` ;
|
||||
- `docs/rules/RULES_RUST.md` ;
|
||||
- `docs/rules/RULES_SPECIFIC_KHADHROONY.md` ;
|
||||
- `KHADHROONY_BOT3_MIGRATION_CLOSURE_TODO.md`.
|
||||
|
||||
### 2.2 Documentation active bot3
|
||||
|
||||
Le répertoire `docs/` contient sept documents :
|
||||
|
||||
| Document | Statut initial | Classe proposée |
|
||||
|---------------------------------------|---------------------------------------------------------|----------------------------------------------|
|
||||
| `DEVNET_EXECUTION_GUIDE.md` | actif, volumineux, utilisé pour la validation opérateur | `docs/validation/` ou `docs/guides/` |
|
||||
| `PRE_062_DEVNET_VALIDATION_REPORT.md` | rapport de validation daté | `docs/validation/` |
|
||||
| `OPERATION_NAMING_CONVENTION.md` | normatif | `docs/architecture/` ou `docs/rules/` |
|
||||
| `IDL_AUDIT.md` | audit de migration | `docs/audits/` ou archive bot3 après reprise |
|
||||
| `IDL_TO_KB_LIB_NOMENCLATURE.md` | document de correspondance encore utile | `docs/migrations/` |
|
||||
| `MISSING_PROGRAM_IDLS.md` | état ciblé pouvant évoluer | `docs/audits/` ou `docs/protocols/` |
|
||||
| `IDEA_REMINDERS.md` | liste de rappels non normative | `docs/decisions/` ou TODO généraux ciblés |
|
||||
|
||||
Il n’existe pas encore de `docs/README.md` servant d’index.
|
||||
|
||||
### 2.3 Prompts bot3
|
||||
|
||||
Deux prompts sont présents :
|
||||
|
||||
- `prompts/KHADHROONY_BOT3_MIGRATION_CONTINUATION_PROMPT_REORDERED.md` ;
|
||||
- `prompts/khadhroony-bot3_next-session_after-v0.1.0-pre.062.md`.
|
||||
|
||||
Le premier est un prompt de migration très détaillé et historiquement utile, mais il ne doit pas rester le modèle normatif des futures sessions. Le second correspond au prompt de reprise courant et doit être conservé comme source jusqu’à la production du modèle bot3 et à l’archivage contrôlé des prompts antérieurs.
|
||||
|
||||
### 2.4 Documentation et prompts bot2
|
||||
|
||||
L’archive bot2 fournit :
|
||||
|
||||
- 61 fichiers sous `docs/`, comprenant architecture, stockage, pipeline, transports, exécution, matrices SPL/Core, audits de fermeture et validation `0.4.6` ;
|
||||
- 27 fichiers sous `prompts/`, dont un modèle de session, un index et les prompts historiques jusqu’à `0.4.7` Metaplex Token Metadata ;
|
||||
- un `CHANGELOG.md` structuré de `0.0.1` à `0.4.6` ;
|
||||
- un `ROADMAP.md` contenant l’historique détaillé, les prereleases et les validations opérateur.
|
||||
|
||||
Ces documents sont une source historique et technique. Ils ne sont pas normatifs pour bot3 tant qu’ils n’ont pas été adaptés à sa nouvelle architecture.
|
||||
|
||||
## 3. État de `olddocs/`
|
||||
|
||||
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 crée deux archives séparées :
|
||||
|
||||
```text
|
||||
olddocs/archivekbot2/
|
||||
olddocs/archivekbot3/
|
||||
```
|
||||
|
||||
`olddocs/archivekbot2/` doit reproduire l’arborescence documentaire utile de bot2, et pas uniquement son ancien répertoire `docs/`. La structure attendue comprend notamment :
|
||||
|
||||
```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
|
||||
|
||||
Le workspace déclare 11 crates :
|
||||
|
||||
- `kb-core` ;
|
||||
- `kb-config` ;
|
||||
- `kb-lib` ;
|
||||
- `kb-logging` ;
|
||||
- `kb-program-ids` ;
|
||||
- `kb-pipeline` ;
|
||||
- `kb-pipeline-demo-scenarios` ;
|
||||
- `kb-onchain-transport` ;
|
||||
- `kb-store` ;
|
||||
- `kb-wallet` ;
|
||||
- `kb-app-demo-desktop`.
|
||||
|
||||
État actuel :
|
||||
|
||||
| Crate | README | TODO | USAGE | CHANGELOG |
|
||||
|------------------------------|--------:|-------:|-------:|----------:|
|
||||
| `kb-app-demo-desktop` | absent | absent | absent | absent |
|
||||
| `kb-config` | présent | absent | absent | absent |
|
||||
| `kb-core` | présent | absent | absent | absent |
|
||||
| `kb-lib` | présent | absent | absent | absent |
|
||||
| `kb-logging` | présent | absent | absent | absent |
|
||||
| `kb-onchain-transport` | absent | absent | absent | absent |
|
||||
| `kb-pipeline` | absent | absent | absent | absent |
|
||||
| `kb-pipeline-demo-scenarios` | présent | absent | absent | absent |
|
||||
| `kb-program-ids` | présent | absent | absent | absent |
|
||||
| `kb-store` | présent | absent | absent | absent |
|
||||
| `kb-wallet` | présent | absent | absent | absent |
|
||||
|
||||
Aucune crate ne satisfait donc le contrat complet `README.md`, `TODO.md`, `USAGE.md`, `CHANGELOG.md`.
|
||||
|
||||
La contradiction `USAGES.md` contre `USAGE.md` est résolue en faveur de `USAGE.md`. `001.README.md` reste autorisé uniquement comme index lexical de répertoire très fourni, notamment sous `idls/`, et ne remplace jamais le `README.md` obligatoire d’une crate.
|
||||
|
||||
### 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
|
||||
|
||||
### 5.1 `README.md`
|
||||
|
||||
Le README racine doit être réécrit comme point d’entrée de bot3 : objectif, architecture consolidée, crates, démarrage, validations et liens documentaires. Il ne doit pas reprendre le journal détaillé de migration.
|
||||
|
||||
### 5.2 `CHANGELOG.md`
|
||||
|
||||
Le changelog bot3 actuel est centré sur les prereleases `0.1.0-pre.*`. Il doit être reconstruit sans perdre cette traçabilité, puis enrichi par l’historique pertinent de bot2 de `0.0.1` à `0.4.6` et par une section explicite de transition bot2 vers bot3.
|
||||
|
||||
Le changelog bot2 ne doit pas être supprimé de la source historique avant reprise complète. Sa copie archivée constituera la référence de contrôle.
|
||||
|
||||
### 5.3 `ROADMAP.md`
|
||||
|
||||
Le roadmap bot3 actuel est encore largement une checklist de migration et de prereleases. Le roadmap bot2 contient lui aussi un historique détaillé et des prereleases. Aucun des deux ne satisfait le nouveau contrat général.
|
||||
|
||||
Le futur `ROADMAP.md` doit être reconstruit par versions mineures et grands lots, sans prerelease ni correctif `fix`, avec dépendances, critères de sortie et liens vers les TODO/changelogs des crates.
|
||||
|
||||
### 5.4 `KHADHROONY_BOT3_MIGRATION_CLOSURE_TODO.md`
|
||||
|
||||
Ce document conserve une forte valeur de traçabilité, mais il ne doit pas rester un document actif permanent après clôture de la migration. Il doit alimenter l’audit d’alignement `0.4.6`, les TODO ciblés et la section de transition du changelog, puis être archivé sous `olddocs/archivekbot3/`.
|
||||
|
||||
## 6. Règles et références à corriger
|
||||
|
||||
Le déplacement des règles secondaires vers `docs/rules/` ne doit pas être effectué dans le premier delta.
|
||||
|
||||
Références actives identifiées :
|
||||
|
||||
- `RULES.md` lie directement les trois fichiers secondaires à la racine ;
|
||||
- les scripts, prompts et documents actifs doivent employer les chemins `docs/rules/...` ;
|
||||
- `docs/rules/RULES_SPECIFIC_KHADHROONY.md` lie `docs/rules/RULES_GENERAL.md` et `docs/rules/RULES_RUST.md` par chemins relatifs racine ;
|
||||
- `scripts/audit_khadhroony_workspace_rules.py` vérifie explicitement les quatre chemins racine à deux endroits ;
|
||||
- les deux prompts bot3 citent les chemins racine ;
|
||||
- `KHADHROONY_BOT3_MIGRATION_CLOSURE_TODO.md` décrit l’organisation actuelle.
|
||||
|
||||
Avant déplacement, il faudra :
|
||||
|
||||
1. modifier `RULES.md` pour pointer vers `docs/rules/` ;
|
||||
2. corriger les liens relatifs internes aux règles ;
|
||||
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 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
|
||||
|
||||
### 7.1 Modèles bot2 à reprendre
|
||||
|
||||
Les meilleurs modèles structurels sont :
|
||||
|
||||
- `prompts/001_version_session_template.md` pour le squelette minimal ;
|
||||
- `prompts/020_v0_4_1_native_solana_programs.md` pour les sources de vérité, le phasage et les critères de sortie ;
|
||||
- `prompts/022_v0_4_3_spl_memo.md` à `026_v0_4_7_metaplex_token_metadata.md` pour la structure numérotée, les frontières, matrices, validations et livraisons.
|
||||
|
||||
### 7.2 Informations bot3 à conserver
|
||||
|
||||
Le futur modèle bot3 doit préserver :
|
||||
|
||||
- l’architecture consolidée autour de `kb-lib`, `kb-store`, `kb-pipeline`, `kb-onchain-transport` et des crates de démonstration ;
|
||||
- les décisions de nommage des crates et binaires ;
|
||||
- les règles Tauri et TS-RS ;
|
||||
- l’état Git et la base d’archive de départ ;
|
||||
- les validations réellement exécutées ;
|
||||
- le statut explicite des surfaces reportées, notamment ElGamal ;
|
||||
- les conventions de delta sans SHA-256 ;
|
||||
- les fichiers normatifs et documents d’architecture à lire.
|
||||
|
||||
### 7.3 Traitement proposé
|
||||
|
||||
Les prompts bot3 existants restent temporairement en place. Après création d’un modèle bot3 et d’un index :
|
||||
|
||||
- le prompt de reprise `pre.062` sera archivé comme preuve de transition ;
|
||||
- le prompt de migration réordonné sera archivé après extraction des décisions encore utiles ;
|
||||
- les futurs prompts actifs seront courts, versionnés par mission et séparés des archives historiques.
|
||||
|
||||
## 8. Classement documentaire proposé
|
||||
|
||||
Arborescence cible à valider progressivement :
|
||||
|
||||
```text
|
||||
docs/
|
||||
├── README.md
|
||||
├── architecture/
|
||||
├── audits/
|
||||
├── decisions/
|
||||
├── generated/
|
||||
├── guides/
|
||||
├── migrations/
|
||||
├── protocols/
|
||||
├── rules/
|
||||
└── validation/
|
||||
```
|
||||
|
||||
Principes de classement :
|
||||
|
||||
- `architecture/` : contrats transversaux et conventions structurelles ;
|
||||
- `audits/` : audits actifs servant une décision non encore clôturée ;
|
||||
- `decisions/` : décisions d’architecture ou de périmètre durables ;
|
||||
- `generated/` : index ou artefacts régénérables explicitement suivis ;
|
||||
- `guides/` : procédures d’utilisation et d’exploitation ;
|
||||
- `migrations/` : correspondances bot2/bot3 et rapports de migration actifs ;
|
||||
- `protocols/` : documents techniques par programme ou famille Solana ;
|
||||
- `rules/` : règles normatives secondaires ;
|
||||
- `validation/` : guides, campagnes et rapports de validation.
|
||||
|
||||
Les déplacements ne doivent commencer qu’après création de `docs/README.md` et correction planifiée de toutes les références.
|
||||
|
||||
## 9. Écarts et contradictions déjà démontrés
|
||||
|
||||
Les écarts suivants sont établis sans nouvel audit fonctionnel des protocoles :
|
||||
|
||||
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`, 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 ;
|
||||
8. prompts bot3 non encore reconstruits depuis les modèles bot2 ;
|
||||
9. statut documentaire de `kb-wallet` insuffisant au regard de son état d’ébauche ;
|
||||
10. absence de l’audit ciblé `docs/V0_4_6_ALIGNMENT_AUDIT.md`.
|
||||
|
||||
## 10. Ambiguïtés bloquantes
|
||||
|
||||
Aucune ambiguïté ne bloque la première livraison d’audit.
|
||||
|
||||
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 ;
|
||||
- convention de nommage des prompts bot3 actifs et archivés ;
|
||||
- niveau de détail historique conservé dans le changelog général par rapport aux changelogs de crates.
|
||||
|
||||
## 11. Conclusion
|
||||
|
||||
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.
|
||||
400
olddocs/archivekbot3/docs/DOCUMENTATION_REFACTOR_PLAN.md
Normal file
400
olddocs/archivekbot3/docs/DOCUMENTATION_REFACTOR_PLAN.md
Normal file
@@ -0,0 +1,400 @@
|
||||
<!-- file: docs/DOCUMENTATION_REFACTOR_PLAN.md -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Plan de refonte documentaire
|
||||
|
||||
## 1. Objectif
|
||||
|
||||
Ce plan transforme progressivement la documentation de `khadhroony-bot3 v0.1.0-pre.062` sans mélanger audit, déplacements, réécriture historique, documentation par crate et décision de réalignement vers `0.4.6`.
|
||||
|
||||
Aucune version Cargo ne doit être modifiée avant la conclusion de `docs/V0_4_6_ALIGNMENT_AUDIT.md`.
|
||||
|
||||
## 2. Principes d’exécution
|
||||
|
||||
- livrer des deltas courts et thématiques ;
|
||||
- ne pas créer en masse des documents vides ;
|
||||
- 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 ;
|
||||
- conserver séparément les archives bot2 et bot3 ;
|
||||
- ne pas rouvrir les audits techniques Solana déjà validés sans écart concret ;
|
||||
- exécuter uniquement les validations réellement nécessaires au delta.
|
||||
|
||||
## 3. Contrat documentaire à inscrire dans les règles
|
||||
|
||||
Chaque crate du workspace doit posséder les quatre fichiers suivants :
|
||||
|
||||
```text
|
||||
README.md
|
||||
TODO.md
|
||||
USAGE.md
|
||||
CHANGELOG.md
|
||||
```
|
||||
|
||||
### 3.1 `README.md`
|
||||
|
||||
Contenu minimal :
|
||||
|
||||
- objectif et périmètre ;
|
||||
- responsabilités et exclusions ;
|
||||
- fonctionnalités principales ;
|
||||
- principales APIs ou façades ;
|
||||
- relations avec les autres crates ;
|
||||
- liens vers `USAGE.md`, `TODO.md`, `CHANGELOG.md` et l’architecture pertinente.
|
||||
|
||||
Le README ne contient pas le journal détaillé des versions.
|
||||
|
||||
### 3.2 `TODO.md`
|
||||
|
||||
Sections minimales :
|
||||
|
||||
- fonctionnalités manquantes ;
|
||||
- dette technique ;
|
||||
- tests manquants ;
|
||||
- validations Devnet/Mainnet manquantes ;
|
||||
- documentation manquante ;
|
||||
- dépendances externes ;
|
||||
- éléments reportés ;
|
||||
- hors périmètre.
|
||||
|
||||
Les sections sans élément doivent indiquer explicitement qu’aucun élément n’est actuellement recensé, plutôt que rester vides.
|
||||
|
||||
### 3.3 `USAGE.md`
|
||||
|
||||
Contenu minimal :
|
||||
|
||||
- objectif ;
|
||||
- prérequis ;
|
||||
- configuration ;
|
||||
- APIs publiques significatives ;
|
||||
- description des types importants ;
|
||||
- erreurs et invariants ;
|
||||
- exemples réalistes ou compilables ;
|
||||
- au moins un exemple par API publique significative ;
|
||||
- limites connues ;
|
||||
- liens vers tests, fixtures et matrices.
|
||||
|
||||
Une API n’est documentée qu’après vérification dans le code et les exports publics.
|
||||
|
||||
### 3.4 `CHANGELOG.md`
|
||||
|
||||
Le changelog de crate distingue :
|
||||
|
||||
- non publié ;
|
||||
- releases ;
|
||||
- prereleases ;
|
||||
- correctifs `fix` ;
|
||||
- ajouts ;
|
||||
- modifications ;
|
||||
- corrections ;
|
||||
- suppressions ;
|
||||
- migrations ;
|
||||
- compatibilité ;
|
||||
- validations ;
|
||||
- limitations connues.
|
||||
|
||||
Il est mis à jour pour tout changement fonctionnel de la crate. Les changements purement documentaires peuvent être regroupés dans une entrée documentaire explicite.
|
||||
|
||||
## 4. Arborescence cible
|
||||
|
||||
```text
|
||||
docs/
|
||||
├── README.md
|
||||
├── architecture/
|
||||
├── audits/
|
||||
├── decisions/
|
||||
├── generated/
|
||||
├── guides/
|
||||
├── migrations/
|
||||
├── protocols/
|
||||
├── rules/
|
||||
└── validation/
|
||||
|
||||
olddocs/
|
||||
├── archivekbot2/
|
||||
│ ├── README.md
|
||||
│ ├── CHANGELOG.md
|
||||
│ ├── ROADMAP.md
|
||||
│ ├── RULES.md
|
||||
│ ├── docs/
|
||||
│ ├── prompts/
|
||||
│ └── <anciennes-crates>/...
|
||||
└── archivekbot3/
|
||||
```
|
||||
|
||||
Le premier déplacement structurel devra inclure un tableau de correspondance ancien chemin vers nouveau chemin dans `docs/README.md` ou dans un rapport de migration dédié.
|
||||
|
||||
## 5. Séquence de deltas
|
||||
|
||||
### Delta 1 — audit et plan
|
||||
|
||||
Fichiers ajoutés :
|
||||
|
||||
- `docs/DOCUMENTATION_REFACTOR_AUDIT.md` ;
|
||||
- `docs/DOCUMENTATION_REFACTOR_PLAN.md`.
|
||||
|
||||
Aucun déplacement et aucune réécriture massive.
|
||||
|
||||
Validations :
|
||||
|
||||
```bash
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
```
|
||||
|
||||
### Delta 2 — archives et index documentaire
|
||||
|
||||
Travail :
|
||||
|
||||
1. créer `olddocs/archivekbot2/` ;
|
||||
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 (`v0.1.0-pre.065`)
|
||||
|
||||
Travail :
|
||||
|
||||
1. corriger `docs/rules/RULES_GENERAL.md` pour imposer les quatre fichiers exacts par crate ;
|
||||
2. interdire `USAGES.md`, retenir définitivement `USAGE.md` et encadrer l’exception `001.README.md` pour les index lexicaux ;
|
||||
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 secondaires restent temporairement à la racine dans ce delta.
|
||||
|
||||
### Delta 4 — déplacement des règles secondaires
|
||||
|
||||
Travail :
|
||||
|
||||
1. créer `docs/rules/` ;
|
||||
2. déplacer `docs/rules/RULES_GENERAL.md`, `docs/rules/RULES_RUST.md` et `docs/rules/RULES_SPECIFIC_KHADHROONY.md` ;
|
||||
3. mettre à jour `RULES.md` ;
|
||||
4. corriger les liens internes ;
|
||||
5. adapter `scripts/audit_khadhroony_workspace_rules.py` ;
|
||||
6. corriger les références dans prompts, README et documents d’onboarding ;
|
||||
7. vérifier qu’aucune référence active aux anciens chemins ne subsiste.
|
||||
|
||||
Validations obligatoires :
|
||||
|
||||
```bash
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
```
|
||||
|
||||
### Delta 5 — documentation générale bot3 (`v0.1.0-pre.067`)
|
||||
|
||||
Travail :
|
||||
|
||||
1. remplacer le README racine obsolète par une présentation stable ;
|
||||
2. créer les objectifs et l’architecture générale ;
|
||||
3. créer la carte des 11 crates ;
|
||||
4. documenter les architectures pipeline et stockage ;
|
||||
5. créer une matrice de responsabilités par surface sans dupliquer les matrices contractuelles ;
|
||||
6. mettre à jour `docs/README.md`.
|
||||
|
||||
Ces documents sont réécrits pour bot3 à partir du workspace actuel et des sources historiques vérifiées.
|
||||
|
||||
### Delta 6 — changelog général de transition
|
||||
|
||||
Travail :
|
||||
|
||||
1. préserver une copie historique du changelog bot2 ;
|
||||
2. reconstruire le changelog bot3 ;
|
||||
3. reprendre l’historique fonctionnel pertinent de `0.0.1` à `0.4.6` ;
|
||||
4. ajouter la transition bot2 vers bot3 ;
|
||||
5. documenter consolidation, renommages et validations `0.1.0-pre.*` ;
|
||||
6. conserver les limites, notamment ElGamal non validé Devnet ;
|
||||
7. distinguer clairement version fonctionnelle et prereleases de migration.
|
||||
|
||||
Le changelog ne doit pas affirmer que bot3 est déjà officiellement `0.4.6`.
|
||||
|
||||
### Delta 7 — roadmap général
|
||||
|
||||
Reconstruire `ROADMAP.md` selon les séries suivantes :
|
||||
|
||||
- `0.4.6` : fermeture de l’alignement et écarts résiduels ;
|
||||
- `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 ;
|
||||
- `0.8.x` : Raydium ;
|
||||
- `0.9.x` : Pump ;
|
||||
- `0.10.x` : Orca ;
|
||||
- `0.11.x` : Jupiter ;
|
||||
- `0.12.x` : OKX et autres routers ;
|
||||
- `0.13.x` : transports temps réel ;
|
||||
- `0.14.x` : trading, workers et orchestration ;
|
||||
- `0.15.x+` : extensions futures.
|
||||
|
||||
Le roadmap ne contient ni prereleases, ni correctifs `fix`, ni journal détaillé du passé.
|
||||
|
||||
### Delta 8 — documentation des crates fondamentales
|
||||
|
||||
Ordre proposé :
|
||||
|
||||
1. `kb-core` ;
|
||||
2. `kb-config` ;
|
||||
3. `kb-logging` ;
|
||||
4. `kb-program-ids` ;
|
||||
5. `kb-store`.
|
||||
|
||||
Pour chaque crate : auditer les exports publics, tests, erreurs, exemples existants et dépendances avant de rédiger les quatre fichiers.
|
||||
|
||||
### Delta 9 — documentation du noyau fonctionnel
|
||||
|
||||
Ordre proposé :
|
||||
|
||||
1. `kb-lib` ;
|
||||
2. `kb-pipeline` ;
|
||||
3. `kb-onchain-transport`.
|
||||
|
||||
`kb-lib` devra être traité par sections cohérentes et liens vers les matrices, sans transformer son README en catalogue exhaustif de toutes les fonctions.
|
||||
|
||||
### Delta 10 — démonstrations et wallet
|
||||
|
||||
Ordre proposé :
|
||||
|
||||
1. `kb-pipeline-demo-scenarios` ;
|
||||
2. `kb-app-demo-desktop` ;
|
||||
3. `kb-wallet`.
|
||||
|
||||
Les TODO doivent expliciter :
|
||||
|
||||
- l’autonomie incomplète éventuelle des scénarios ;
|
||||
- les contraintes de validation Tauri ;
|
||||
- le statut d’ébauche de `kb-wallet` et son périmètre `0.5.x`.
|
||||
|
||||
### Delta 11 — réorganisation des documents actifs
|
||||
|
||||
Travail :
|
||||
|
||||
- déplacer les guides et rapports Devnet ;
|
||||
- classer les documents IDL ;
|
||||
- classer la convention de nommage ;
|
||||
- ventiler `IDEA_REMINDERS.md` dans les TODO ou décisions ;
|
||||
- mettre à jour toutes les références ;
|
||||
- archiver sous `olddocs/archivekbot3/` les audits et plans remplacés qui conservent une valeur historique.
|
||||
|
||||
Aucun déplacement ne doit laisser de lien cassé.
|
||||
|
||||
### Delta 12 — refonte des prompts
|
||||
|
||||
Travail :
|
||||
|
||||
1. copier ou référencer les prompts bot2 historiques dans l’archive appropriée sans les rendre normatifs ;
|
||||
2. créer `prompts/README.md` ;
|
||||
3. créer un modèle bot3 contenant mission, base validée, périmètre, hors périmètre, règles, architecture, fichiers à lire, tests, critères de clôture, livraison, limites, décisions reportées et état Git ;
|
||||
4. migrer les informations bot3 utiles ;
|
||||
5. archiver les deux prompts de migration actuels lorsque leurs informations ont été reprises.
|
||||
|
||||
### Delta 13 — audit d’alignement `0.4.6`
|
||||
|
||||
Créer :
|
||||
|
||||
```text
|
||||
docs/V0_4_6_ALIGNMENT_AUDIT.md
|
||||
```
|
||||
|
||||
L’audit synthétise, sans réauditer intégralement les protocoles :
|
||||
|
||||
- composants migrés ;
|
||||
- renommages ;
|
||||
- consolidations ;
|
||||
- versions Cargo ;
|
||||
- noms de crates et binaires ;
|
||||
- exports ;
|
||||
- tests ;
|
||||
- validations Devnet ;
|
||||
- ElGamal ;
|
||||
- transports ;
|
||||
- documentation par crate ;
|
||||
- prompts et archives ;
|
||||
- `kb-wallet` ;
|
||||
- futur split de `kb-config` ;
|
||||
- autonomie de `kb-pipeline-demo-scenarios` ;
|
||||
- écarts résiduels.
|
||||
|
||||
Conclusion obligatoire :
|
||||
|
||||
```text
|
||||
READY_FOR_0_4_6
|
||||
READY_WITH_DOCUMENTED_EXCEPTIONS
|
||||
NOT_READY_FOR_0_4_6
|
||||
```
|
||||
|
||||
### Delta 13 — décision de versionnement
|
||||
|
||||
Seulement après validation du delta 12 :
|
||||
|
||||
- décider du passage officiel à `0.4.6` ;
|
||||
- modifier les versions Cargo si la conclusion le permet ;
|
||||
- mettre à jour changelogs, documentation et prompt de session ;
|
||||
- exécuter les validations workspace imposées pour les modifications de code ou de structure.
|
||||
|
||||
## 6. Matrice de validation
|
||||
|
||||
### Documentation pure
|
||||
|
||||
```bash
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
```
|
||||
|
||||
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
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
```
|
||||
|
||||
Ajouter les tests des crates modifiées.
|
||||
|
||||
### Frontend desktop
|
||||
|
||||
La validation frontend ne doit jamais utiliser `npm --prefix kb-app-demo-desktop run build`.
|
||||
|
||||
La validation runtime se fait par :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
## 7. Risques contrôlés
|
||||
|
||||
| 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
|
||||
|
||||
Valider le présent audit et le séquençage des deltas avant :
|
||||
|
||||
- la copie de l’archive bot2 dans `olddocs/` ;
|
||||
- le déplacement des règles ;
|
||||
- la reconstruction du changelog et du roadmap ;
|
||||
- la création des documents par crate ;
|
||||
- la modification des versions Cargo.
|
||||
@@ -0,0 +1,88 @@
|
||||
<!-- file: docs/audits/CRATE_TODO_VERSION_ALIGNMENT_AUDIT.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Audit d’alignement des TODO par crate
|
||||
|
||||
## Objectif
|
||||
|
||||
Classer les tâches restantes des onze crates selon leur rapport à l’alignement fonctionnel de `khadhroony-bot3` sur `khadhroony-bot2 0.4.6`, à la reprise de l’objectif `0.4.7` et aux versions ultérieures.
|
||||
|
||||
Cet audit ne constitue pas encore `V0_4_6_ALIGNMENT_AUDIT.md`. Il prépare cet audit en supprimant les ambiguïtés de calendrier dans les TODO.
|
||||
|
||||
## Règles de classement
|
||||
|
||||
### Bloquant avant `0.4.6`
|
||||
|
||||
Une tâche appartient à cette catégorie lorsqu’elle doit démontrer ou rétablir une capacité attendue de bot2 `0.4.6`, ou lorsqu’elle est nécessaire à la clôture documentaire de la migration.
|
||||
|
||||
### Entre `0.4.6` et `0.4.7`
|
||||
|
||||
Cette catégorie contient les travaux nécessaires pour reprendre et achever l’objectif Metaplex Token Metadata interrompu dans bot2.
|
||||
|
||||
### Version ultérieure
|
||||
|
||||
Cette catégorie contient les travaux explicitement planifiés après `0.4.7`, notamment `0.5.x`, `0.6.x`, `0.9.x` et `0.13.x`.
|
||||
|
||||
### Report conditionnel
|
||||
|
||||
Une tâche dépendante d’un déploiement, d’une preuve ou d’une source externe non confirmée n’est pas un blocant de version tant que cette dépendance n’est pas établie.
|
||||
|
||||
## Blocants identifiés avant `0.4.6`
|
||||
|
||||
### `kb-app-demo-desktop`
|
||||
|
||||
- synchronisation complète Tauri/TS-RS ;
|
||||
- couverture explicite des cycles de fenêtres ;
|
||||
- maintien de la session WebSocket après fermeture de `demo_ws` ;
|
||||
- restauration de l’état WebSocket lors de la réouverture.
|
||||
|
||||
Ces points sont des preuves de migration attendues, même lorsque leur comportement paraît déjà implicitement couvert.
|
||||
|
||||
### `kb-pipeline`
|
||||
|
||||
- traitement des écarts concrets révélés par l’audit final ;
|
||||
- guide transversal replay, extraction Core et matérialisation.
|
||||
|
||||
### `kb-onchain-transport`
|
||||
|
||||
- guide transversal RPC, backfill et WebSocket.
|
||||
|
||||
### `kb-store`
|
||||
|
||||
- guide transversal PostgreSQL et contrats de stockage.
|
||||
|
||||
## Travaux entre `0.4.6` et `0.4.7`
|
||||
|
||||
- exécuteur Metaplex Token Metadata dans `kb-lib` ;
|
||||
- vérification et complément de la matérialisation migrée ;
|
||||
- intégration replay et orchestration dans `kb-pipeline` ;
|
||||
- scénarios et validations dans `kb-pipeline-demo-scenarios` ;
|
||||
- panneaux applicatifs dans `kb-app-demo-desktop`.
|
||||
|
||||
## Exceptions documentées
|
||||
|
||||
### Registre ElGamal
|
||||
|
||||
Le registre reste implémenté dans certaines couches, mais sa validation réseau dépend :
|
||||
|
||||
- de la confirmation de son déploiement ;
|
||||
- d’une preuve `PubkeyValidity` ;
|
||||
- d’un compte `Proof Context State` valide.
|
||||
|
||||
Ces tâches restent conditionnelles et ne bloquent pas l’alignement `0.4.6`, à condition que la documentation ne déclare jamais une validation réseau inexistante.
|
||||
|
||||
### `kb-wallet`
|
||||
|
||||
Les capacités avancées sont affectées à `0.5.x`. Le wallet temporaire migré suffit au périmètre historique attendu avant l’alignement.
|
||||
|
||||
### Configuration et logging
|
||||
|
||||
Le split de configuration appartient à `0.5.x` et ne bloque pas `0.4.6`.
|
||||
|
||||
### Transports avancés
|
||||
|
||||
Helius étendu, LaserStream, Yellowstone et la résilience streaming appartiennent à `0.13.x`.
|
||||
|
||||
## Résultat
|
||||
|
||||
Les TODO sont désormais classés par version ou dépendance. Le classement ne prouve pas encore que les blocants `0.4.6` sont satisfaits ; il définit les vérifications à exécuter dans les correctifs de `pre.072` et dans `V0_4_6_ALIGNMENT_AUDIT.md`.
|
||||
@@ -0,0 +1,812 @@
|
||||
# Prompt de reprise — clôture migration `khadhroony-bot3`
|
||||
|
||||
## 1. Mission
|
||||
|
||||
Poursuivre et clôturer la migration de `khadhroony-bot2` vers `khadhroony-bot3`.
|
||||
|
||||
Objectif fonctionnel intermédiaire :
|
||||
|
||||
- revenir d’abord à un niveau de couverture équivalent à `0.4.6` de Bot2 ;
|
||||
- terminer ensuite le travail Metaplex Token Metadata commencé mais non achevé dans `0.4.7` de Bot2 ;
|
||||
- seulement après cela, finaliser Clippy/Tauri, la documentation et le passage de Bot3 à `0.4.7`.
|
||||
|
||||
Ne pas déclarer la migration terminée avant validation complète des critères de clôture.
|
||||
|
||||
---
|
||||
|
||||
## 2. Revalidation initiale obligatoire des règles
|
||||
|
||||
Avant toute modification de code :
|
||||
|
||||
1. relire intégralement :
|
||||
- `RULES.md`
|
||||
- `docs/rules/RULES_GENERAL.md`
|
||||
- `docs/rules/RULES_RUST.md`
|
||||
- `docs/rules/RULES_SPECIFIC_KHADHROONY.md`
|
||||
- `README.md`
|
||||
- `ROADMAP.md`
|
||||
- `CHANGELOG.md`
|
||||
- le présent prompt ;
|
||||
2. comparer les règles Bot2 encore applicables avec les règles Bot3 ;
|
||||
3. vérifier qu’aucune règle de migration récente n’est absente ou contradictoire ;
|
||||
4. vérifier en particulier :
|
||||
- conventions de noms ;
|
||||
- façades `kb-lib` et `kb-store` ;
|
||||
- ordre des imports et réexports ;
|
||||
- interdiction de `unsafe`, `unwrap`, `expect`, `panic`, `anyhow`, `thiserror` ;
|
||||
- règles Tauri ;
|
||||
- conventions TS-RS ;
|
||||
- conventions de logging ;
|
||||
- règles d’archives delta ;
|
||||
- politique de versionnement ;
|
||||
5. corriger les documents de règles avant le code si une divergence est détectée ;
|
||||
6. lancer immédiatement :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
```
|
||||
|
||||
L’objectif est d’éviter de refaire plusieurs fois les mêmes corrections structurelles plus tard.
|
||||
|
||||
---
|
||||
|
||||
## 3. Architecture consolidée
|
||||
|
||||
Crates principales :
|
||||
|
||||
```text
|
||||
kb-config
|
||||
kb-core
|
||||
kb-lib
|
||||
kb-logging
|
||||
kb-onchain-transport
|
||||
kb-pipeline
|
||||
kb-pipeline-demo-scenarios
|
||||
kb-program-ids
|
||||
kb-store
|
||||
kb-wallet
|
||||
kb-app-demo-desktop
|
||||
```
|
||||
|
||||
Règles :
|
||||
|
||||
- `kb-store` remplace `kb_store_core` et `kb_store_pg`.
|
||||
- Modèles, décodeurs, matérialiseurs et exécuteurs sont sous `kb-lib`.
|
||||
- Les modules Rust Token-2022 utilisent `token2022`, jamais `token_2022`.
|
||||
- Les variables externes historiques comme `TOKEN_2022_*` peuvent rester si elles constituent un contrat opératoire.
|
||||
- Les fenêtres dynamiques vont dans `capabilities/default.json` et `vite.config.ts`.
|
||||
- Elles ne vont pas dans `tauri.conf.json`, sauf `splash` et `main`.
|
||||
- Toutes les fenêtres doivent avoir la permission de logging/tracing.
|
||||
- Livrer des ZIP delta, sans `Cargo.lock` ni SHA256.
|
||||
- Les correctifs utilisent `delta-fix-XXX`, avec reprise à `fix-001` pour chaque prerelease.
|
||||
|
||||
---
|
||||
|
||||
## 4. État déjà atteint
|
||||
|
||||
Fenêtres migrées / non testées completement :
|
||||
|
||||
- splash ;
|
||||
- main ;
|
||||
- configuration ;
|
||||
- HTTP JSON-RPC ;
|
||||
- WebSocket ;
|
||||
- backfill HTTP ;
|
||||
- SQL diagnostics ;
|
||||
- PostgreSQL raw ;
|
||||
- PostgreSQL core ;
|
||||
- SQL replay candidates ;
|
||||
- extraction core ;
|
||||
- decode replay / matérialisation ;
|
||||
- exécution Solana Core ;
|
||||
- exécution SPL ;
|
||||
- SPL ATA ;
|
||||
- SPL Token classique ;
|
||||
- SPL Token-2022.
|
||||
|
||||
Dépendances déjà présentes :
|
||||
|
||||
```text
|
||||
kb-lib
|
||||
kb-program-ids
|
||||
kb-pipeline-demo-scenarios
|
||||
kb-store
|
||||
kb-wallet
|
||||
```
|
||||
|
||||
Le `.env` est désormais chargé par `kb-config`.
|
||||
|
||||
Ordre de résolution attendu :
|
||||
|
||||
1. environnement du processus ;
|
||||
2. fichier indiqué par `KB_ENV_FILE` ;
|
||||
3. sinon `.env` à la racine du workspace ;
|
||||
4. fallback `${VARIABLE:-valeur}` ;
|
||||
5. absence non fatale pour les services optionnels jusqu’à leur utilisation.
|
||||
|
||||
`HELIUS_API_KEY` fonctionne depuis `.env`.
|
||||
|
||||
Décodeur Metaplex enregistré sous :
|
||||
|
||||
```text
|
||||
metadata_metaplex_token_metadata
|
||||
```
|
||||
|
||||
Program ID :
|
||||
|
||||
```text
|
||||
metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s
|
||||
```
|
||||
|
||||
L’IDL Metaplex Token Metadata est déjà présent dans `idl`. Ne pas le retélécharger.
|
||||
|
||||
---
|
||||
|
||||
## 5. Contrôles rapides et prise en main du code
|
||||
|
||||
### 5.1 Audit TS-RS
|
||||
|
||||
Auditer uniquement les `.rs` :
|
||||
|
||||
```bash
|
||||
find kb-config kb-lib kb-app-demo-desktop -type f -name '*.rs' -print0 |
|
||||
xargs -0 grep -n 'export_to'
|
||||
```
|
||||
|
||||
Chemins attendus :
|
||||
|
||||
```text
|
||||
../frontend/ts/bindings/kb_config/...
|
||||
../frontend/ts/bindings/kb_lib/...
|
||||
../frontend/ts/bindings/kb_app_demo_desktop/...
|
||||
```
|
||||
|
||||
Supprimer les chemins historiques :
|
||||
|
||||
```text
|
||||
kb_executor_*
|
||||
kb_decoder_*
|
||||
kb_materializer_*
|
||||
kb_model
|
||||
kb_store_pg
|
||||
kb_store_core
|
||||
kb_lib_executor_*
|
||||
kb_executor_spl_token_2022
|
||||
```
|
||||
|
||||
Vérifier que les tests TS-RS régénèrent les fichiers attendus.
|
||||
|
||||
### 5.2 Audit des anciens chemins Bot2
|
||||
|
||||
```bash
|
||||
find kb-app-demo-desktop -type f -name '*.rs' -print0 |
|
||||
xargs -0 grep -nE 'kb_store_pg|kb_store_core|kb_model|kb_decoder_|kb_materializer_|kb_executor_|token_2022'
|
||||
```
|
||||
|
||||
Toute occurrence doit être justifiée ou supprimée.
|
||||
|
||||
### 5.3 Audit rapide HTML Copier/Effacer
|
||||
|
||||
```bash
|
||||
find kb-app-demo-desktop/frontend -type f -name '*.html' -print0 |
|
||||
xargs -0 grep -nE 'Copier|Effacer'
|
||||
```
|
||||
|
||||
Vérifier :
|
||||
|
||||
- exactement un bouton Copier ;
|
||||
- exactement un bouton Effacer ;
|
||||
- aucun doublon entre HTML statique et helper TypeScript ;
|
||||
- journaux globaux hors accordéon.
|
||||
|
||||
### 5.4 Menu principal
|
||||
|
||||
Ordre attendu :
|
||||
|
||||
1. Configuration
|
||||
2. Transport et collecte
|
||||
3. Pipeline
|
||||
4. SQL
|
||||
5. Exécution
|
||||
|
||||
Vérifier labels, séparateurs, entrées mortes et fenêtres oubliées.
|
||||
|
||||
---
|
||||
|
||||
## 6. Corrections UI rapides
|
||||
|
||||
### `demo_http`
|
||||
|
||||
Le bloc `Résultat` ne doit pas utiliser `@andypf/json-viewer`.
|
||||
|
||||
À faire :
|
||||
|
||||
- remettre un `<textarea readonly>` ;
|
||||
- hauteur fixe ;
|
||||
- scroll interne ;
|
||||
- exactement un bouton Copier ;
|
||||
- exactement un bouton Effacer ;
|
||||
- l’effacement doit vider aussi le buffer TypeScript.
|
||||
|
||||
### `demo_ws`
|
||||
|
||||
Le bloc `Messages` doit être un affichage texte/log.
|
||||
|
||||
À faire :
|
||||
|
||||
- utiliser un `<textarea>` ou composant log ;
|
||||
- hauteur fixe et scroll interne ;
|
||||
- exactement une paire Copier/Effacer ;
|
||||
- conserver les messages si la fenêtre est fermée puis rouverte tant que la session reste active.
|
||||
|
||||
### Journaux généraux
|
||||
|
||||
Vérifier au minimum :
|
||||
|
||||
- Backfill HTTP ;
|
||||
- Extraction core ;
|
||||
- Exécution Solana Core ;
|
||||
- Exécution SPL ;
|
||||
- Decode replay ;
|
||||
- HTTP ;
|
||||
- WebSocket.
|
||||
|
||||
Règle générale :
|
||||
|
||||
- paramètres dans les accordéons ;
|
||||
- journaux et résultats globaux sous les accordéons ;
|
||||
- hauteur fixe ;
|
||||
- scroll interne ;
|
||||
- boutons toujours accessibles.
|
||||
|
||||
### JSON viewers
|
||||
|
||||
- `@andypf/json-viewer` uniquement pour du JSON structuré ;
|
||||
- `<textarea>` pour texte brut, logs, messages, sorties non JSON et diagnostics concaténés ;
|
||||
- hauteur fixe et scroll interne pour tous les viewers JSON.
|
||||
|
||||
### Fenêtres SQL
|
||||
|
||||
Sauf Replay Candidates :
|
||||
|
||||
- contenu sur toute la largeur ;
|
||||
- pas de split en deux colonnes ;
|
||||
- table sur toute la largeur ;
|
||||
- éviter le scroll horizontal global ;
|
||||
- wrapper responsive uniquement autour de la table ;
|
||||
- vérifier les balises HTML ;
|
||||
- vérifier boutons, tabs et liens.
|
||||
|
||||
---
|
||||
|
||||
|
||||
### État `pre.060` des outils de replay
|
||||
|
||||
- plafond temporaire des listes SQL : `100000`;
|
||||
- vraie pagination SQL/IPC reportée mais obligatoire avant les volumes massifs;
|
||||
- export CSV ancré sur `<workspace>/data/exports_csv`;
|
||||
- Program ID de Decode replay libre avec autocomplétion issue de `kb-program-ids`.
|
||||
|
||||
## 7. `.env` et configuration
|
||||
|
||||
`kb-config` doit rester seul responsable de :
|
||||
|
||||
- recherche du `.env` ;
|
||||
- chargement sans écraser l’environnement du processus ;
|
||||
- `${VAR}` ;
|
||||
- `${VAR:-fallback}` ;
|
||||
- diagnostics sans secrets ;
|
||||
- tests ;
|
||||
- documentation publique.
|
||||
|
||||
Les crates métier ne doivent pas charger `.env`.
|
||||
|
||||
`kb-pipeline-demo-scenarios` peut appeler un point d’initialisation commun, mais ne doit pas dépendre directement de `dotenvy`.
|
||||
|
||||
Backlog futur :
|
||||
|
||||
- étudier la résolution du chemin/URL de base de données côté `kb-store`.
|
||||
|
||||
---
|
||||
|
||||
## 8. Logging
|
||||
|
||||
La console doit rester active pour :
|
||||
|
||||
- `local_devnet` ;
|
||||
- `mainnet_research` ;
|
||||
- `mainnet`.
|
||||
|
||||
Supprimer les routes Bot2 obsolètes.
|
||||
|
||||
Cibles consolidées attendues :
|
||||
|
||||
```text
|
||||
kb-lib.decoder.*
|
||||
kb-lib.executor.*
|
||||
kb-lib.materializer.*
|
||||
kb-store
|
||||
kb-config
|
||||
kb-logging
|
||||
kb-onchain-transport
|
||||
kb-pipeline
|
||||
kb-wallet
|
||||
kb-app-demo-desktop
|
||||
```
|
||||
|
||||
Ne pas recréer les anciens dossiers de crates supprimées.
|
||||
|
||||
Backlog non bloquant :
|
||||
|
||||
- séparer ultérieurement les logs `kb-store` entre `core` et `postgres`.
|
||||
|
||||
---
|
||||
|
||||
## 9. Options SPL et variables Token-2022
|
||||
|
||||
Auditer :
|
||||
|
||||
```text
|
||||
kb-app-demo-desktop/frontend/demo_execution_spl.html
|
||||
kb-app-demo-desktop/src/tauri.rs
|
||||
```
|
||||
|
||||
Vérifier que chaque option HTML correspond à un scénario réellement supporté.
|
||||
|
||||
Éliminer les valeurs internes `token_2022` au profit de `token2022`, sauf contrat externe explicite.
|
||||
|
||||
Pour chaque variable `TOKEN_2022_*`, décider :
|
||||
|
||||
- compatibilité externe à conserver ;
|
||||
- déplacement éventuel vers configuration ;
|
||||
- remplacement futur par structure typée ;
|
||||
- usage limité aux scénarios de démonstration.
|
||||
|
||||
Documenter la décision.
|
||||
|
||||
---
|
||||
|
||||
|
||||
### État validé après `0.1.0-pre.058`
|
||||
|
||||
- `cargo test -p kb-app-demo-desktop` : 115 tests réussis ;
|
||||
- `cargo check --workspace` : réussi ;
|
||||
- audit Rust : propre ;
|
||||
- fenêtres Configuration, HTTP, WebSocket, Backfill et SQL validées visuellement ;
|
||||
- persistance WebSocket, limitation UI et encodage Base64 automatique validés ;
|
||||
- `autoInitializeSchema` reste volontairement à `false` pour `mainnet_research` ;
|
||||
- le câblage statique de System transfer, Memo, SPL Token, ATA et Token-2022 vers `kb-pipeline-demo-scenarios` est confirmé ;
|
||||
- `execute_devnet_spl_token_lifecycle` reste à raccorder ou à documenter comme scénario non exposé.
|
||||
|
||||
### Tranche Tauri en cours
|
||||
|
||||
- les ouvertures de fenêtres doivent utiliser un helper privé commun strictement Tauri ;
|
||||
- les commandes Extraction core doivent déléguer à `demo_core_extraction.rs` ;
|
||||
- poursuivre ensuite avec Decode replay, Backfill, SQL replay et Exécution ;
|
||||
- les helpers de `tauri.rs` sont autorisés uniquement pour l’adaptation Tauri mutualisée et ne portent aucune logique métier.
|
||||
|
||||
## 10. WebSocket
|
||||
|
||||
Comportement obligatoire :
|
||||
|
||||
- aucun pool WebSocket au démarrage ;
|
||||
- création paresseuse au premier accès à `demo_ws` ;
|
||||
- pool conservé dans `AppState` ;
|
||||
- session conservée si la fenêtre est fermée ;
|
||||
- état récupéré à la réouverture ;
|
||||
- fermeture seulement par :
|
||||
- commande explicite ;
|
||||
- timeout ;
|
||||
- arrêt global de l’application.
|
||||
|
||||
La fermeture de `demo_ws` ne doit pas appeler la déconnexion globale.
|
||||
|
||||
---
|
||||
|
||||
## 11. Initialisation PostgreSQL au lancement
|
||||
|
||||
L’initialisation PostgreSQL doit être faite au lancement de `kb-app-demo-desktop`, comme dans Bot2.
|
||||
|
||||
Ordre attendu :
|
||||
|
||||
1. environnement ;
|
||||
2. configuration ;
|
||||
3. logging ;
|
||||
4. pool HTTP ;
|
||||
5. connexion PostgreSQL ;
|
||||
6. vérification/initialisation du schéma ;
|
||||
7. rapport des tables ;
|
||||
8. ouverture de `main` ;
|
||||
9. destruction du splash.
|
||||
|
||||
Fonctions existantes à raccorder :
|
||||
|
||||
```text
|
||||
initialize_postgres_schema_for_startup
|
||||
emit_sql_startup_table_report
|
||||
emit_sql_startup_error
|
||||
emit_sql_startup_splash
|
||||
```
|
||||
|
||||
### Splashscreen
|
||||
|
||||
Problème observé : seuls les messages du haut sont visibles.
|
||||
|
||||
À corriger :
|
||||
|
||||
- zone de messages scrollable ;
|
||||
- hauteur adaptée ;
|
||||
- dernier message visible ;
|
||||
- progression lisible ;
|
||||
- ne pas afficher d’initialisation WebSocket ;
|
||||
- afficher :
|
||||
- connexion PostgreSQL ;
|
||||
- schéma vérifié ou initialisé ;
|
||||
- nombre de tables ;
|
||||
- tables manquantes éventuelles ;
|
||||
- statut final.
|
||||
|
||||
---
|
||||
|
||||
## 12. PostgreSQL — purge des données dérivées
|
||||
|
||||
Objectif : conserver uniquement les données raw, puis tout reconstruire par replay.
|
||||
|
||||
Ne pas supprimer :
|
||||
|
||||
- transactions raw ;
|
||||
- signatures raw ;
|
||||
- payloads RPC raw ;
|
||||
- données nécessaires à l’extraction et au replay.
|
||||
|
||||
Purger les tables dérivées liées notamment à :
|
||||
|
||||
- core extraction ;
|
||||
- decoded events ;
|
||||
- observations ;
|
||||
- coverage ;
|
||||
- diagnostics ;
|
||||
- replay state dérivé ;
|
||||
- annotations ;
|
||||
- materialized events ;
|
||||
- token accounts ;
|
||||
- lifecycle ;
|
||||
- admin ;
|
||||
- fees ;
|
||||
- risk ;
|
||||
- compliance ;
|
||||
- staking ;
|
||||
- autres projections générées.
|
||||
|
||||
Avant purge :
|
||||
|
||||
1. inventorier les tables via `kb-store` ;
|
||||
2. distinguer précisément raw et dérivé ;
|
||||
3. préparer un script SQL versionné et idempotent ;
|
||||
4. documenter les tables conservées ;
|
||||
5. exécuter dans une transaction ;
|
||||
6. prévoir des vérifications avant/après ;
|
||||
7. ne rien supprimer si le périmètre est ambigu.
|
||||
|
||||
Après purge :
|
||||
|
||||
1. extraction core ;
|
||||
2. replay de tous les décodeurs ;
|
||||
3. matérialisation ;
|
||||
4. validation des compteurs ;
|
||||
5. validation des erreurs ;
|
||||
6. contrôle de reconstruction des tables.
|
||||
|
||||
---
|
||||
|
||||
## 13. Retour au niveau fonctionnel `0.4.6`
|
||||
|
||||
Avant de poursuivre Metaplex, valider que Bot3 couvre correctement tout ce qui était fonctionnel dans Bot2 `0.4.6` :
|
||||
|
||||
- Solana Core ;
|
||||
- SPL Memo ;
|
||||
- SPL Token classique ;
|
||||
- SPL ATA ;
|
||||
- SPL Token-2022 ;
|
||||
- ElGamal Registry ;
|
||||
- backfill ;
|
||||
- extraction core ;
|
||||
- replay ;
|
||||
- matérialisation ;
|
||||
- exécution supportée ;
|
||||
- validations devnet déjà existantes ;
|
||||
- transport HTTP et WebSocket ;
|
||||
- PostgreSQL ;
|
||||
- logging ;
|
||||
- configuration.
|
||||
|
||||
Cette étape doit être explicitement considérée comme un jalon de migration.
|
||||
|
||||
---
|
||||
|
||||
## 14. Inventaire des IDL
|
||||
|
||||
Créer :
|
||||
|
||||
```text
|
||||
docs/IDL_SOURCES.md
|
||||
```
|
||||
|
||||
Pour chaque IDL :
|
||||
|
||||
- protocole ;
|
||||
- program ID ;
|
||||
- lien officiel ;
|
||||
- version ou commit ;
|
||||
- chemin local ;
|
||||
- statut ;
|
||||
- usage ;
|
||||
- notes de compatibilité.
|
||||
|
||||
Ne pas inventer d’IDL lorsqu’il n’en existe pas.
|
||||
|
||||
L’IDL Metaplex Token Metadata existe déjà localement : le référencer, ne pas le retélécharger.
|
||||
|
||||
---
|
||||
|
||||
## 15. Metaplex Token Metadata — décodage
|
||||
|
||||
Ce bloc vient après le retour au niveau fonctionnel `0.4.6`.
|
||||
|
||||
Des échecs réels ont été observés après backfill Metaplex.
|
||||
|
||||
Cas signalés :
|
||||
|
||||
- `create_metadata_account_v3` ;
|
||||
- `transfer`.
|
||||
|
||||
Cause probable : attentes incorrectes sur les flags signer/writable des metas.
|
||||
|
||||
Travail :
|
||||
|
||||
1. extraire toutes les erreurs Metaplex ;
|
||||
2. regrouper par instruction ;
|
||||
3. comparer runtime, IDL local, builders et interface officielle ;
|
||||
4. corriger la matrice de comptes ;
|
||||
5. distinguer instructions valides, transactions échouées, payloads tronqués, variantes inconnues, comptes optionnels et legacy ;
|
||||
6. ajouter des tests depuis les transactions réelles ;
|
||||
7. relancer le replay ;
|
||||
8. obtenir zéro faux échec de metas.
|
||||
|
||||
---
|
||||
|
||||
## 16. Exécuteur Metaplex et démos devnet
|
||||
|
||||
Le passage à `0.4.7` exige que l’exécuteur Metaplex Token Metadata soit terminé.
|
||||
|
||||
À compléter :
|
||||
|
||||
- intents typés ;
|
||||
- builders ;
|
||||
- comptes ordonnés ;
|
||||
- signers ;
|
||||
- writable flags ;
|
||||
- variantes supportées ;
|
||||
- politiques de sécurité ;
|
||||
- simulation-first ;
|
||||
- estimation des coûts ;
|
||||
- validation post-exécution ;
|
||||
- tests unitaires ;
|
||||
- comparaison avec builders officiels ;
|
||||
- matrice de couverture.
|
||||
|
||||
Ajouter des scénarios devnet bornés dans `kb-app-demo-desktop` et/ou `kb-pipeline-demo-scenarios`.
|
||||
|
||||
Ils doivent :
|
||||
|
||||
- utiliser uniquement un profil devnet explicite ;
|
||||
- ne jamais exécuter par défaut sur mainnet ;
|
||||
- simuler avant envoi ;
|
||||
- afficher le plan ;
|
||||
- afficher les signers ;
|
||||
- afficher le résultat ;
|
||||
- effectuer un replay post-exécution ;
|
||||
- vérifier décodage et matérialisation ;
|
||||
- afficher les diagnostics.
|
||||
|
||||
---
|
||||
|
||||
## 17. Clippy et Tauri
|
||||
|
||||
Les erreurs `clippy::question_mark_used` issues des macros async Tauri sont à traiter après tout le fonctionnel, y compris Metaplex.
|
||||
|
||||
Ne pas bloquer le débogage dessus.
|
||||
|
||||
À la fin :
|
||||
|
||||
1. solution locale cohérente ;
|
||||
2. éviter un `allow` global ;
|
||||
3. documenter la contradiction macro/règle ;
|
||||
4. obtenir un Clippy propre ou un écart précisément borné.
|
||||
|
||||
---
|
||||
|
||||
## 18. Refonte documentaire après migration
|
||||
|
||||
Ne pas commencer la refonte complète avant validation fonctionnelle, y compris Metaplex.
|
||||
|
||||
### Versionnement
|
||||
|
||||
Passer à :
|
||||
|
||||
```text
|
||||
0.4.7
|
||||
```
|
||||
|
||||
uniquement si :
|
||||
|
||||
- niveau fonctionnel `0.4.6` restauré et validé ;
|
||||
- migration validée ;
|
||||
- bugs majeurs corrigés ;
|
||||
- exécuteur Metaplex terminé ;
|
||||
- démos devnet Metaplex présentes ;
|
||||
- replay et matérialisation validés ;
|
||||
- documentation refondue.
|
||||
|
||||
### README
|
||||
|
||||
Les README doivent devenir génériques.
|
||||
|
||||
Ils ne doivent pas :
|
||||
|
||||
- servir de changelog ;
|
||||
- contenir des numéros de version ;
|
||||
- raconter Bot2 → Bot3 ;
|
||||
- décrire les prereleases.
|
||||
|
||||
Ils doivent présenter :
|
||||
|
||||
- objectif ;
|
||||
- rôle architectural ;
|
||||
- dépendances ;
|
||||
- aperçu minimal ;
|
||||
- liens vers la documentation détaillée.
|
||||
|
||||
### `USAGE.md`
|
||||
|
||||
Créer un `USAGE.md` pour chaque crate publique.
|
||||
|
||||
Contenu :
|
||||
|
||||
- APIs publiques ;
|
||||
- types ;
|
||||
- traits ;
|
||||
- fonctions ;
|
||||
- builders ;
|
||||
- exemples ;
|
||||
- invariants ;
|
||||
- erreurs ;
|
||||
- limites ;
|
||||
- intégrations.
|
||||
|
||||
### Roadmap par crate
|
||||
|
||||
Ajouter un roadmap par crate seulement si utile.
|
||||
|
||||
### Continuité du projet
|
||||
|
||||
Après refonte, on ne doit presque plus sentir la transition Bot2 → Bot3.
|
||||
|
||||
Seule une courte note historique éventuelle est acceptable.
|
||||
|
||||
---
|
||||
|
||||
## 19. Commandes de validation
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
|
||||
cargo check -p kb-config
|
||||
cargo test -p kb-config
|
||||
|
||||
cargo check -p kb-pipeline-demo-scenarios
|
||||
cargo test -p kb-pipeline-demo-scenarios
|
||||
|
||||
cargo check -p kb-store
|
||||
cargo test -p kb-store
|
||||
|
||||
cargo check -p kb-lib
|
||||
cargo test -p kb-lib
|
||||
|
||||
cargo check -p kb-app-demo-desktop
|
||||
cargo test -p kb-app-demo-desktop
|
||||
|
||||
cargo check --workspace
|
||||
cargo test --workspace
|
||||
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
```
|
||||
|
||||
Runtime :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
Clippy en dernier :
|
||||
|
||||
```bash
|
||||
cargo clippy --all-targets
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 20. Critères de clôture
|
||||
|
||||
- [ ] règles relues et revalidées ;
|
||||
- [ ] toutes les crates compilent ;
|
||||
- [ ] tous les tests workspace passent ;
|
||||
- [ ] audit Rust propre ;
|
||||
- [ ] aucun chemin Bot2 supprimé ;
|
||||
- [ ] audit TS-RS propre ;
|
||||
- [ ] toutes les fenêtres fonctionnent ;
|
||||
- [ ] WebSocket persistant après fermeture de `demo_ws` ;
|
||||
- [ ] `.env` chargé par `kb-config` avec priorité correcte ;
|
||||
- [ ] Helius réellement validé ;
|
||||
- [ ] PostgreSQL initialisé au démarrage ;
|
||||
- [ ] splash PostgreSQL lisible ;
|
||||
- [ ] données dérivées purgées ;
|
||||
- [ ] données dérivées reconstruites par replay ;
|
||||
- [ ] niveau fonctionnel `0.4.6` restauré ;
|
||||
- [ ] bons composants pour JSON et texte ;
|
||||
- [ ] aucun bouton Copier/Effacer dupliqué ;
|
||||
- [ ] journaux généraux hors accordéon ;
|
||||
- [ ] fenêtres SQL correctement dimensionnées ;
|
||||
- [ ] routes de logs obsolètes supprimées ;
|
||||
- [ ] console active ;
|
||||
- [ ] inventaire IDL documenté ;
|
||||
- [ ] aucun faux échec Metaplex sur les metas ;
|
||||
- [ ] exécuteur Metaplex terminé ;
|
||||
- [ ] démos devnet Metaplex validées ;
|
||||
- [ ] Clippy/Tauri finalisés ;
|
||||
- [ ] refonte documentaire terminée ;
|
||||
- [ ] `USAGE.md` présent pour chaque crate publique ;
|
||||
- [ ] passage à `0.4.7` justifié.
|
||||
|
||||
---
|
||||
|
||||
## 21. Mode de travail
|
||||
|
||||
- Commencer chaque session par la relecture des règles.
|
||||
- Traiter d’abord les contrôles rapides.
|
||||
- Conserver un ordre logique de dépendances.
|
||||
- Revenir au niveau fonctionnel `0.4.6` avant de terminer Metaplex.
|
||||
- Traiter Metaplex avant Clippy/Tauri et la documentation.
|
||||
- Travailler par deltas courts.
|
||||
- Ne jamais réintroduire les anciennes crates Bot2.
|
||||
- Vérifier les APIs réelles avant de porter du code.
|
||||
- Utiliser `kb-store` et `kb-lib`.
|
||||
- Corriger immédiatement les erreurs locales remontées.
|
||||
- Ne pas masquer les erreurs métier par des `allow`.
|
||||
- Maintenir `delta.md`, changelog et documentation de session.
|
||||
- Fournir une archive delta à chaque tranche.
|
||||
- Utiliser `delta-fix-XXX` pour les correctifs.
|
||||
- Ne pas livrer d’archive complète sauf demande explicite.
|
||||
|
||||
|
||||
## État ajouté par `pre.061`
|
||||
|
||||
- La reconstruction propre a extrait 4 574 transactions raw sur 4 574 puis dispatché 11 880 instructions.
|
||||
- Les 76 faux échecs Loader provenaient de transactions déjà échouées avec payloads réellement courts ou comptes insuffisants. Ils doivent devenir des observations `Decoded` non engagées `malformed_loader_instruction`; les quatre tags Loader v4 u32 inconnus restent `Unsupported`.
|
||||
- Les six faux échecs Metaplex provenaient d'une comparaison exacte des flags globaux de transaction avec les metas attendues de l'instruction CPI. La validation exige désormais uniquement les privilèges requis et accepte les privilèges supplémentaires.
|
||||
- Ne pas commencer Pump.fun, Raydium, Meteora, Jupiter, autres AMM ou launchpads avant clôture de Solana Core, SPL, Metaplex et Anchor.
|
||||
- Relancer après application un replay forcé limité aux 82 entrées en échec, puis le replay complet si le résultat est propre.
|
||||
|
||||
|
||||
## Validation `v0.1.0-pre.061` et correctif attendu
|
||||
|
||||
- Replay ciblé après `pre.061` : 123 entrées, 123 terminées, 0 échec.
|
||||
- Metaplex : 6/6 décodées (`create_metadata_account_v3` x5, `transfer` x1).
|
||||
- Loader : 84 décodées et 4 tags Loader v4 inconnus conservés `Unsupported`, 0 échec.
|
||||
- `kb-store` : 84 tests réussis.
|
||||
- `kb-app-demo-desktop` : 116 tests réussis après appels explicites `ProgramIdEntry::code()` et `program_id()`.
|
||||
- `cargo check --workspace` et `cargo clippy --all-targets` réussissent.
|
||||
- Le test Metaplex `collection_size_variants_reject_truncated_wire_invalid_flags_and_suffixes` doit tester l'absence d'un privilège requis, et non un privilège supplémentaire désormais accepté pour les CPI.
|
||||
- L'audit RUST021 exige un rustdoc adjacent au réexport `DemoDecodeReplayProgramOption`.
|
||||
- La première correction de cette prerelease doit être nommée `khadhroony-bot3_v0.1.0-pre.061-delta-fix-001.zip`.
|
||||
@@ -0,0 +1,631 @@
|
||||
<!-- file: prompts/khadhroony-bot3_next-session_after-v0.1.0-pre.062.md -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# khadhroony-bot3 — Reprise après `v0.1.0-pre.062`
|
||||
|
||||
## 1. Mission
|
||||
|
||||
Reprendre `khadhroony-bot3` après la clôture de `v0.1.0-pre.062`.
|
||||
|
||||
Le suffixe local éventuellement utilisé pour distinguer plusieurs commits successifs après les derniers correctifs ne constitue pas une version fonctionnelle distincte pour la nouvelle session.
|
||||
|
||||
La nouvelle session doit recevoir :
|
||||
|
||||
- ce prompt ;
|
||||
- la dernière archive complète de `khadhroony-bot2` ;
|
||||
- la dernière archive complète de `khadhroony-bot3`.
|
||||
|
||||
La migration de `khadhroony-bot2` vers `khadhroony-bot3` est largement réalisée jusqu’à un périmètre proche de `khadhroony-bot2 v0.4.6`.
|
||||
|
||||
La session doit commencer par une refonte structurée de la documentation, puis établir la liste précise des écarts restant à traiter avant d’aligner officiellement le versionnement de `khadhroony-bot3` sur `0.4.6+`.
|
||||
|
||||
Ne pas reprendre immédiatement le développement de nouvelles surfaces Solana avant d’avoir :
|
||||
|
||||
1. remis en ordre la documentation générale ;
|
||||
2. repris le CHANGELOG historique ;
|
||||
3. reconstruit le ROADMAP ;
|
||||
4. défini les règles documentaires par crate ;
|
||||
5. repris les prompts de `khadhroony-bot2` comme modèles ;
|
||||
6. produit une liste ciblée des écarts restant réellement à traiter avant le passage officiel à `0.4.6`.
|
||||
|
||||
Il ne faut pas refaire un audit complet de Solana Core, SPL Memo, SPL Token, SPL ATA, Token-2022 et des autres surfaces déjà auditées et validées pendant la migration, sauf si un écart concret ou une contradiction documentaire est découvert.
|
||||
|
||||
---
|
||||
|
||||
## 2. Base validée
|
||||
|
||||
### 2.1 Révision de départ
|
||||
|
||||
La base de travail est :
|
||||
|
||||
```text
|
||||
khadhroony-bot3 v0.1.0-pre.062
|
||||
```
|
||||
|
||||
Le workspace a été validé avec :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test -p kb-pipeline-demo-scenarios
|
||||
cargo test -p kb-app-demo-desktop
|
||||
```
|
||||
|
||||
Résultats connus :
|
||||
|
||||
```text
|
||||
kb-pipeline-demo-scenarios:
|
||||
- 39 tests de bibliothèque passés
|
||||
- 1 test de binaire passé
|
||||
|
||||
kb-app-demo-desktop:
|
||||
- 117 tests passés
|
||||
```
|
||||
|
||||
Audits :
|
||||
|
||||
```text
|
||||
General Rust rule audit: clean
|
||||
Rust export completeness audit: 0 candidate(s)
|
||||
Khadhroony workspace rule audit: clean
|
||||
```
|
||||
|
||||
### 2.2 Validation Devnet réalisée
|
||||
|
||||
Validé sur Solana Devnet :
|
||||
|
||||
- Solana Core System Transfer ;
|
||||
- SPL Memo v4 ;
|
||||
- SPL Associated Token Account classique ;
|
||||
- SPL Associated Token Account Token-2022 ;
|
||||
- SPL Token classique `TransferChecked` ;
|
||||
- Token-2022 :
|
||||
- `MintToChecked`
|
||||
- `TransferChecked`
|
||||
- `ApproveChecked`
|
||||
- `Revoke`
|
||||
- `BurnChecked`
|
||||
- `FreezeAccount`
|
||||
- `ThawAccount`
|
||||
- `CloseAccount`
|
||||
|
||||
Pour Token-2022, la validation a couvert préflight, simulation exacte, confirmation opérateur, envoi, confirmation, insertion canonique, extraction Core, replay, matérialisation, idempotence et confirmation CLI finalisée.
|
||||
|
||||
Le registre ElGamal reste :
|
||||
|
||||
```text
|
||||
implémenté mais non validé sur Devnet
|
||||
```
|
||||
|
||||
Motifs du report :
|
||||
|
||||
- absence de générateur complet de contexte de preuve `PubkeyValidity` ;
|
||||
- panneau Registry de `kb-app-demo-desktop` non raccordé à un handler fonctionnel ;
|
||||
- aucun compte `Proof Context State` valide préparé pour la campagne.
|
||||
|
||||
Ne pas déclarer le registre ElGamal validé.
|
||||
|
||||
---
|
||||
|
||||
## 3. Contraintes générales
|
||||
|
||||
### 3.1 Conservation de la base
|
||||
|
||||
- Ne pas réinitialiser le workspace.
|
||||
- Ne pas supprimer les migrations, décodeurs, exécuteurs, matérialisateurs ou tests existants sans preuve qu’ils sont obsolètes.
|
||||
- Ne pas revenir à l’architecture de `khadhroony-bot2`.
|
||||
- Ne pas renommer les crates ou APIs sans audit de toutes leurs utilisations.
|
||||
|
||||
### 3.2 Validation frontend
|
||||
|
||||
Ne jamais utiliser :
|
||||
|
||||
```bash
|
||||
npm --prefix kb-app-demo-desktop run build
|
||||
```
|
||||
|
||||
La validation frontend desktop doit se faire uniquement par :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
### 3.3 Livraisons
|
||||
|
||||
Les corrections doivent être livrées sous forme de deltas ZIP, sans SHA-256.
|
||||
|
||||
Chaque delta doit contenir `delta.md` avec :
|
||||
|
||||
- problème traité ;
|
||||
- fichiers modifiés ;
|
||||
- décisions prises ;
|
||||
- validations demandées ;
|
||||
- limites éventuelles.
|
||||
|
||||
Ne pas inclure `target/`, `node_modules/`, keypairs, fixtures privées, fichiers temporaires, bases de données ou preuves de `/tmp`.
|
||||
|
||||
---
|
||||
|
||||
## 4. Audit documentaire ciblé
|
||||
|
||||
Inventorier :
|
||||
|
||||
```text
|
||||
README.md
|
||||
CHANGELOG.md
|
||||
ROADMAP.md
|
||||
RULES.md
|
||||
docs/rules/RULES_GENERAL.md
|
||||
docs/rules/RULES_RUST.md
|
||||
docs/rules/RULES_SPECIFIC_KHADHROONY.md
|
||||
KHADHROONY_BOT3_MIGRATION_CLOSURE_TODO.md
|
||||
docs/
|
||||
olddocs/
|
||||
prompts/
|
||||
```
|
||||
|
||||
Inspecter aussi, pour chaque crate :
|
||||
|
||||
```text
|
||||
README.md
|
||||
TODO.md
|
||||
USAGE.md
|
||||
CHANGELOG.md
|
||||
```
|
||||
|
||||
Dans ce prompt, le terme « module » désigne une crate. Les obligations documentaires ne s’appliquent pas à chaque sous-module Rust interne ni à chaque fichier source.
|
||||
|
||||
Ne pas créer immédiatement des fichiers vides. Produire d’abord :
|
||||
|
||||
```text
|
||||
docs/DOCUMENTATION_REFACTOR_AUDIT.md
|
||||
docs/DOCUMENTATION_REFACTOR_PLAN.md
|
||||
```
|
||||
|
||||
L’audit doit couvrir documents existants, absents, obsolètes, doublons, contradictions, documents bot2, documents liés à `0.1.0-pre.*`, éléments à conserver, fusionner, déplacer ou réécrire.
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Archivage documentaire
|
||||
|
||||
Le répertoire `olddocs/` actuellement présent dans `khadhroony-bot3` sera supprimé avant la prochaine session.
|
||||
|
||||
La source documentaire historique à reprendre sera :
|
||||
|
||||
```text
|
||||
khadhroony-bot2/docs/
|
||||
```
|
||||
|
||||
Ces fichiers doivent être copiés ou déplacés dans :
|
||||
|
||||
```text
|
||||
khadhroony-bot3/olddocs/archivekbot2/
|
||||
```
|
||||
|
||||
`olddocs/archivekbot2/` constitue l’archive historique de la documentation bot2. Elle doit rester intacte autant que possible, ne doit pas devenir normative pour bot3 et ne doit pas être supprimée après reprise.
|
||||
|
||||
Les documents temporaires, audits intermédiaires, anciens plans, rapports remplacés et autres fichiers bot3 qui ne sont plus nécessaires dans la documentation active doivent être déplacés dans une archive distincte :
|
||||
|
||||
```text
|
||||
khadhroony-bot3/olddocs/archivekbot3/
|
||||
```
|
||||
|
||||
Règles :
|
||||
|
||||
- ne pas mélanger les archives bot2 et bot3 ;
|
||||
- conserver dans `docs/` uniquement les documents actifs, normatifs ou encore utilisés ;
|
||||
- lorsqu’un document temporaire de bot3 n’est plus nécessaire, mettre à jour ses références puis le déplacer dans `olddocs/archivekbot3/` ;
|
||||
- ne pas supprimer un document ayant une valeur historique, décisionnelle ou de traçabilité avant son archivage ;
|
||||
- conserver le nom d’origine ou ajouter un préfixe de date/version en cas de collision ;
|
||||
- documenter tout reclassement significatif.
|
||||
|
||||
## 5. Contrat documentaire par crate
|
||||
|
||||
Chaque crate doit disposer de :
|
||||
|
||||
```text
|
||||
README.md
|
||||
TODO.md
|
||||
USAGE.md
|
||||
CHANGELOG.md
|
||||
```
|
||||
|
||||
### 5.1 README.md
|
||||
|
||||
Le README explique l’objectif, le périmètre, les responsabilités, les principales APIs ou fonctionnalités, les relations avec les autres crates et les liens vers `USAGE.md`, `TODO.md`, `CHANGELOG.md` et les documents d’architecture pertinents.
|
||||
|
||||
Il ne sert pas de journal de versions.
|
||||
|
||||
### 5.2 TODO.md
|
||||
|
||||
Le TODO distingue :
|
||||
|
||||
- fonctionnalités manquantes ;
|
||||
- dette technique ;
|
||||
- tests manquants ;
|
||||
- validations Devnet/Mainnet manquantes ;
|
||||
- documentation manquante ;
|
||||
- dépendances externes ;
|
||||
- éléments reportés ;
|
||||
- hors périmètre.
|
||||
|
||||
Il ne sert pas de changelog.
|
||||
|
||||
### 5.3 USAGE.md
|
||||
|
||||
Le fichier contient :
|
||||
|
||||
- objectif ;
|
||||
- prérequis ;
|
||||
- configuration ;
|
||||
- APIs publiques exposées ;
|
||||
- description de chaque API publique significative ;
|
||||
- types importants ;
|
||||
- erreurs et invariants ;
|
||||
- exemples réalistes ou compilables ;
|
||||
- au moins un exemple par API publique significative ;
|
||||
- limites connues ;
|
||||
- liens vers tests et matrices.
|
||||
|
||||
Ne pas inventer d’API.
|
||||
|
||||
### 5.4 CHANGELOG.md
|
||||
|
||||
Chaque changement fonctionnel d’une crate met à jour son changelog.
|
||||
|
||||
Distinguer releases, prereleases, correctifs `fix` et non publié. Indiquer ajouts, modifications, corrections, suppressions, migrations, compatibilité, validation et limitations connues.
|
||||
|
||||
---
|
||||
|
||||
## 6. ROADMAP général
|
||||
|
||||
Le ROADMAP général ne doit contenir ni prereleases, ni correctifs `fix`, ni journal détaillé du passé.
|
||||
|
||||
Il doit contenir les objectifs par version mineure, grands lots, dépendances, critères de sortie et liens vers les TODO/CHANGELOG des crates concernées.
|
||||
|
||||
---
|
||||
|
||||
## 7. Déplacement des règles
|
||||
|
||||
Conserver à la racine uniquement :
|
||||
|
||||
```text
|
||||
RULES.md
|
||||
```
|
||||
|
||||
Étudier le déplacement vers :
|
||||
|
||||
```text
|
||||
docs/rules/RULES_GENERAL.md
|
||||
docs/rules/RULES_RUST.md
|
||||
docs/rules/RULES_SPECIFIC_KHADHROONY.md
|
||||
```
|
||||
|
||||
Avant déplacement, rechercher et corriger toutes les références dans scripts, prompts, README et documents d’onboarding. Les audits doivent rester fonctionnels.
|
||||
|
||||
---
|
||||
|
||||
## 8. CHANGELOG général
|
||||
|
||||
Le nouveau `CHANGELOG.md` doit reprendre l’historique pertinent de `khadhroony-bot2`.
|
||||
|
||||
Les règles de changelog de bot2 doivent être reprises et adaptées à bot3.
|
||||
|
||||
Ajouter une section de transition expliquant :
|
||||
|
||||
- migration bot2 vers bot3 ;
|
||||
- changement d’architecture ;
|
||||
- consolidation et renommage des crates ;
|
||||
- migration vers `kb-lib` ;
|
||||
- migration de `kb-store`, `kb-pipeline`, transports et desktop ;
|
||||
- validations réalisées pendant `0.1.0-pre.*` ;
|
||||
- décision de réaligner le versionnement sur `0.4.6+`.
|
||||
|
||||
Ne pas supprimer l’ancien changelog bot2 avant reprise complète de ses informations utiles.
|
||||
|
||||
---
|
||||
|
||||
## 9. Nouvelle trajectoire du ROADMAP
|
||||
|
||||
### 9.1 Version `0.4.6`
|
||||
|
||||
Objectifs :
|
||||
|
||||
- formaliser l’équivalence déjà largement atteinte avec bot2 `v0.4.6` ;
|
||||
- documenter les écarts résiduels ;
|
||||
- valider les renommages et la nouvelle architecture ;
|
||||
- fermer la migration structurelle principale ;
|
||||
- préparer le réalignement officiel des versions.
|
||||
|
||||
Ne pas refaire l’audit complet des surfaces déjà auditées. Produire une synthèse fondée sur les rapports, tests, matrices, validations Devnet et écarts connus.
|
||||
|
||||
### 9.2 Version `0.4.7`
|
||||
|
||||
Dernière version de `0.4.x`.
|
||||
|
||||
Objectifs :
|
||||
|
||||
- terminer Metaplex Token Metadata ;
|
||||
- finaliser les éléments résiduels du noyau historique ;
|
||||
- achever décodeurs, exécuteurs, matérialisateurs, préflights et validations nécessaires ;
|
||||
- préparer les démonstrations complétées en `0.5.x`.
|
||||
|
||||
Metaplex Token Metadata reste distinct des metadata Token-2022, de Metaplex Core et des autres programmes Metaplex.
|
||||
|
||||
### 9.3 Série `0.5.x`
|
||||
|
||||
Objectifs :
|
||||
|
||||
- scinder `kb-config` en deux fichiers, ou trois si nécessaire ;
|
||||
- alléger la configuration générale ;
|
||||
- extraire les blocs dupliqués entre profils, notamment le logging, dans une configuration dédiée ;
|
||||
- renforcer `kb-pipeline-demo-scenarios` pour fonctionner hors `kb-app-demo-desktop` ;
|
||||
- améliorer le CLI et les fixtures ;
|
||||
- compléter réellement `kb-wallet`.
|
||||
|
||||
`kb-wallet` n’est qu’une ébauche. Prévoir notamment : import/export, plusieurs wallets, changement de mot de passe, chiffrement/déchiffrement, verrouillage, sélection du wallet actif, sauvegarde/restauration, politiques de sécurité et intégration aux profils/signers.
|
||||
|
||||
### 9.4 Série `0.6.x`
|
||||
|
||||
Objectifs :
|
||||
|
||||
- implémenter le décodeur générique Anchor nécessaire aux futurs protocoles Anchor ;
|
||||
- ajouter le reste des programmes SPL ;
|
||||
- ajouter le reste des programmes Metaplex ;
|
||||
- intégrer les conventions Anchor aux décodeurs, exécuteurs et matérialisateurs.
|
||||
|
||||
Les IDL archivées ne doivent pas être chargées dynamiquement ni utilisées directement par le code de production. Elles servent uniquement de références pour concevoir manuellement décodeurs, exécuteurs, matérialisateurs, matrices et tests.
|
||||
|
||||
Le décodeur Anchor est une infrastructure de décodage des conventions Anchor, pas un moteur générique exécutant arbitrairement les IDL archivées.
|
||||
|
||||
### 9.5 Série `0.7.x` — Meteora
|
||||
|
||||
1. AMM Meteora : DLMM, DAMM v1, DAMM v2 et autres AMM non launchpad ;
|
||||
2. launchpad DBC ;
|
||||
3. vaults Meteora ;
|
||||
4. autres programmes Meteora.
|
||||
|
||||
### 9.6 Série `0.8.x` — Raydium
|
||||
|
||||
1. AMM/swaps : v4, v3, v2, CPMM, CLMM, stable swap ;
|
||||
2. LaunchLab ;
|
||||
3. Raydium Lock ;
|
||||
4. autres programmes Raydium.
|
||||
|
||||
### 9.7 Série `0.9.x` — Pump
|
||||
|
||||
1. Pump AMM ;
|
||||
2. Pump.fun ;
|
||||
3. Pump Fees ;
|
||||
4. autres programmes Pump à identifier.
|
||||
|
||||
Auditer :
|
||||
|
||||
```text
|
||||
MAyhSmzXzV1pTf7LsNkrNwkWKTo4ougAJ1PPg47MD4e
|
||||
```
|
||||
|
||||
Solscan l’indique comme « Pump Mayhem Program ». Vérifier sa nature et son appartenance avant classement.
|
||||
|
||||
Vérifier aussi si `pumpup_ai` appartient à la famille Pump ou constitue un protocole distinct.
|
||||
|
||||
### 9.8 Série `0.10.x` — Orca
|
||||
|
||||
1. Whirlpool ;
|
||||
2. Orca v1 ;
|
||||
3. Orca v2 ;
|
||||
4. Wavebreak ;
|
||||
5. autres programmes Orca.
|
||||
|
||||
### 9.9 Série `0.11.x` — Jupiter
|
||||
|
||||
Routers, agrégateurs, DCA, ordres, perpetuals, lockers et autres programmes Jupiter.
|
||||
|
||||
### 9.10 Série `0.12.x` — OKX et autres routers
|
||||
|
||||
Routers OKX, autres programmes OKX, autres routers/agrégateurs hors Jupiter et surfaces associées.
|
||||
|
||||
### 9.11 Série `0.13.x` — transports temps réel
|
||||
|
||||
- extension WebSocket Helius dans `kb-onchain-transport` ;
|
||||
- amélioration de LaserStream si pertinente ;
|
||||
- Yellowstone gRPC ;
|
||||
- autres transports streaming ;
|
||||
- reprise, continuité, backpressure, reconnexion et métriques.
|
||||
|
||||
Consulter `olddocs/` pour retrouver le listing historique des Program IDs Solana et déterminer à quels programmes ils correspondent. Le listing doit être vérifié, classé et repris dans une nouvelle documentation bot3 sans modifier ni supprimer l’archive originale.
|
||||
|
||||
### 9.12 Série `0.14.x`
|
||||
|
||||
Application de trading, workers, orchestration, automatisation, stratégies, exécution contrôlée, sécurité opérationnelle et séparation UI/workers/services.
|
||||
|
||||
### 9.13 Série `0.15.x+`
|
||||
|
||||
Suite des décodeurs, exécuteurs, matérialisateurs, protocoles, transports, optimisations, observabilité, opérations historiques, outils d’administration et extensions futures.
|
||||
|
||||
---
|
||||
|
||||
## 10. Refonte de `docs/` et rôle de `olddocs/`
|
||||
|
||||
Le répertoire `docs/` doit être audité puis réorganisé.
|
||||
|
||||
`olddocs/` ne doit pas disparaître. Il constitue l’archive permanente de la documentation écrite pour `khadhroony-bot2` et sert de source pour produire de nouveaux documents adaptés à bot3.
|
||||
|
||||
Ne pas déplacer ni supprimer les documents de `olddocs/` au motif qu’ils ont été repris.
|
||||
|
||||
Créer un index `docs/README.md`.
|
||||
|
||||
Une arborescence possible, à valider par l’audit :
|
||||
|
||||
```text
|
||||
docs/
|
||||
├── architecture/
|
||||
├── guides/
|
||||
├── validation/
|
||||
├── migrations/
|
||||
├── protocols/
|
||||
├── rules/
|
||||
├── decisions/
|
||||
├── audits/
|
||||
└── generated/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 11. Refonte des prompts
|
||||
|
||||
Reprendre les prompts bot2 comme modèles pour les futurs prompts bot3.
|
||||
|
||||
Les prompts actuels bot3 ne doivent pas être conservés par défaut.
|
||||
|
||||
Avant remplacement : inventorier bot2 et bot3, reprendre les informations spécifiques à bot3, créer un modèle bot3, migrer les informations utiles puis archiver ou supprimer les prompts devenus inutiles.
|
||||
|
||||
Les futurs prompts doivent contenir mission, base validée, périmètre, hors périmètre, règles, architecture, fichiers à lire, tests, critères de clôture, conventions de livraison, limites connues, décisions reportées et état Git de départ.
|
||||
|
||||
---
|
||||
|
||||
## 12. Audit ciblé avant renommage en `0.4.6`
|
||||
|
||||
Créer :
|
||||
|
||||
```text
|
||||
docs/V0_4_6_ALIGNMENT_AUDIT.md
|
||||
```
|
||||
|
||||
Cet audit ne doit pas refaire tous les audits techniques déjà réalisés.
|
||||
|
||||
Il doit synthétiser :
|
||||
|
||||
- composants migrés ;
|
||||
- renommages terminés ;
|
||||
- crates consolidées ;
|
||||
- tests existants ;
|
||||
- validations Devnet ;
|
||||
- écarts résiduels ;
|
||||
- dette documentaire ;
|
||||
- fonctionnalités reportées ;
|
||||
- composants à compléter.
|
||||
|
||||
Vérifier notamment : versions Cargo, noms de crates/binaires, exports, documentation par crate, statut de `kb-wallet`, futur split de `kb-config`, autonomie de `kb-pipeline-demo-scenarios`, statut ElGamal, transports, prompts, docs et `olddocs/`.
|
||||
|
||||
Conclure par :
|
||||
|
||||
```text
|
||||
READY_FOR_0_4_6
|
||||
READY_WITH_DOCUMENTED_EXCEPTIONS
|
||||
NOT_READY_FOR_0_4_6
|
||||
```
|
||||
|
||||
Ne pas changer les versions Cargo avant cette conclusion.
|
||||
|
||||
---
|
||||
|
||||
## 13. Ordre de travail
|
||||
|
||||
1. lire les règles ;
|
||||
2. lire changelog et roadmap bot2 ;
|
||||
3. lire les prompts bot2 ;
|
||||
4. inventorier la documentation bot3 ;
|
||||
5. inventorier `olddocs/` sans le modifier ;
|
||||
6. produire l’audit et le plan documentaires ;
|
||||
7. proposer l’arborescence ;
|
||||
8. mettre à jour les règles documentaires ;
|
||||
9. déplacer les RULES secondaires après correction des références ;
|
||||
10. reconstruire CHANGELOG et ROADMAP généraux ;
|
||||
11. appliquer progressivement README/TODO/USAGE/CHANGELOG à chaque crate ;
|
||||
12. reconstruire les prompts ;
|
||||
13. produire l’audit d’alignement `0.4.6` ;
|
||||
14. dresser la liste finale des écarts ;
|
||||
15. décider du passage à `0.4.6`.
|
||||
|
||||
Ne pas refaire tous les documents en une seule modification incontrôlable.
|
||||
|
||||
---
|
||||
|
||||
## 14. Première livraison attendue
|
||||
|
||||
La première livraison doit contenir :
|
||||
|
||||
1. inventaire documentaire ;
|
||||
2. analyse de `olddocs/` ;
|
||||
3. analyse des prompts bot2 et bot3 ;
|
||||
4. proposition d’arborescence ;
|
||||
5. règles README/TODO/USAGE/CHANGELOG par crate ;
|
||||
6. références à corriger avant déplacement des RULES ;
|
||||
7. plan de migration par deltas ;
|
||||
8. ambiguïtés réellement bloquantes.
|
||||
|
||||
Créer au minimum :
|
||||
|
||||
```text
|
||||
docs/DOCUMENTATION_REFACTOR_AUDIT.md
|
||||
docs/DOCUMENTATION_REFACTOR_PLAN.md
|
||||
```
|
||||
|
||||
Ne pas modifier massivement les fichiers avant validation de ce plan.
|
||||
|
||||
---
|
||||
|
||||
## 15. Validations obligatoires
|
||||
|
||||
Après chaque delta de code ou de structure :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
```
|
||||
|
||||
Exécuter aussi les tests des crates modifiées.
|
||||
|
||||
Pour les changements documentaires purs :
|
||||
|
||||
```bash
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
git diff --check
|
||||
```
|
||||
|
||||
Ne pas déclarer une validation réussie si elle n’a pas été exécutée.
|
||||
|
||||
---
|
||||
|
||||
## 16. Décisions acquises
|
||||
|
||||
- `kb-app-demo-desktop` reste une crate/package mixte bibliothèque et binaire.
|
||||
- La bibliothèque de `kb-pipeline-demo-scenarios` garde le nom `kb_pipeline_demo_scenarios`.
|
||||
- Son binaire s’appelle `kb-pipeline-demo-scenarios-cli`.
|
||||
- `autobins = false` empêche une cible implicite conflictuelle.
|
||||
- Memo v1 et v3 restent non exécutables.
|
||||
- Memo v4 est exécutable.
|
||||
- ElGamal reste non validé Devnet.
|
||||
- Chaque crate doit posséder `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md`.
|
||||
- Les README ne servent pas de changelog.
|
||||
- Le ROADMAP général ne contient ni prereleases ni correctifs.
|
||||
- Le versionnement sera réaligné sur `0.4.6+` après audit ciblé.
|
||||
- `0.4.7` sera la dernière version `0.4.x`.
|
||||
- `olddocs/` reste une archive permanente bot2.
|
||||
- Les IDL servent de références et ne sont pas exploitées dynamiquement par le code de production.
|
||||
|
||||
---
|
||||
|
||||
## 17. Réponse attendue au démarrage
|
||||
|
||||
Commencer par :
|
||||
|
||||
1. résumer la mission ;
|
||||
2. lire les fichiers normatifs ;
|
||||
3. inventorier documents et prompts ;
|
||||
4. proposer le premier delta d’audit ;
|
||||
5. signaler uniquement les ambiguïtés réellement bloquantes.
|
||||
|
||||
Ne pas commencer par coder de nouveaux protocoles.
|
||||
|
||||
Ne pas modifier les versions Cargo avant l’audit d’alignement.
|
||||
|
||||
Ne pas prétendre que bot3 est déjà officiellement en `0.4.6`.
|
||||
|
||||
L’objectif initial est de rendre cette décision démontrable, traçable et documentée.
|
||||
Reference in New Issue
Block a user