khadhroony-bot3/prompts/khadhroony-bot3_next-session_after-v0.1.0-pre.062.md

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 :

khadhroony-bot3 v0.1.0-pre.062

Le workspace a été validé avec :

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 :

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 :

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 :

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 :

npm --prefix kb-app-demo-desktop run build

La validation frontend desktop doit se faire uniquement par :

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 :

README.md
CHANGELOG.md
ROADMAP.md
RULES.md
RULES_GENERAL.md
RULES_RUST.md
RULES_SPECIFIC_KHADHROONY.md
KHADHROONY_BOT3_MIGRATION_CLOSURE_TODO.md
docs/
olddocs/
prompts/

Inspecter aussi, pour chaque crate :

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 :

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 :

khadhroony-bot2/docs/

Ces fichiers doivent être copiés ou déplacés dans :

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 :

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 :

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 :

RULES.md

Étudier le déplacement vers :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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.