Sasedev/khadhroony-bot3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.5.0-pre.004

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-09 18:36:58 +02:00
parent a61c9ea05e
commit 7dddab6d37
19 changed files with 793 additions and 131 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/architecture/ARCHITECTURE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/ARCHITECTURE.md -->
<!-- version: 5 -->
<!-- version: 6 -->
# Architecture générale
@@ -69,7 +69,7 @@ Il dépend des contrats de `kb-lib`, des données de `kb-store` et des capacité
- `kb-pipeline-demo-scenarios` fournit les fixtures et campagnes réseau réutilisables spécifiques aux validations Devnet/Testnet. Les scénarios réutilisables doivent être appelables sans dépendre du desktop.
- Le binaire `kb-pipeline-demo-scenarios-cli` reste un outil ciblé ; son existence n’impose pas d’exposer chaque scénario par un CLI.
- `kb-app-demo-desktop` est une crate mixte : bibliothèque Tauri et binaire desktop. Les commandes et projections UI y restent, tandis que la logique de scénario réutilisable doit être déléguée à `kb-pipeline-demo-scenarios`. Le reliquat éventuel de scénarios encore déclarés directement dans le desktop sera audité en `0.5.4`.
- `kb-wallet` fournit actuellement une frontière limitée de wallet temporaire et de signataire. Sa restructuration est planifiée en `0.5.2`.
- `kb-wallet` fournit actuellement une frontière limitée de wallet temporaire et de signataire. Elle devient `ks-wallet` en `0.5.1`, puis sa restructuration fonctionnelle est planifiée en `0.5.2`.
## 3. Flux principal de données
@@ -99,7 +99,7 @@ L’exécution suit un flux séparé : intention typée, construction, préfligh
- Les IDs canoniques ne doivent pas être dispersés lorsqu’ils appartiennent au registre de `kb-program-ids`.
- Les APIs publiques de modèles, décodeurs, exécuteurs et matérialisateurs sont exposées par `kb-lib`.
- Les commandes Tauri et payloads frontend spécifiques restent dans `kb-app-demo-desktop`.
- Les scénarios réseau réutilisables spécifiques à Devnet/Testnet appartiennent à `kb-pipeline-demo-scenarios`. `kb-app-demo-desktop` doit se limiter à l’adaptation Tauri, aux payloads UI, à la présentation et à l’appel de ces scénarios ; les doublons résiduels seront réconciliés en `0.5.4`.
- Les scénarios réseau réutilisables spécifiques à Devnet/Testnet appartiennent à `kb-pipeline-demo-scenarios`, future `ks-pipeline-demo-scenarios`. `kb-app-demo-desktop` doit se limiter à l’adaptation Tauri, aux payloads UI, à la présentation et à l’appel de ces scénarios ; les doublons résiduels seront réconciliés en `0.5.4`.
- Toute primitive ou orchestration réellement généraliste, indépendante de l’UI et d’une campagne de démonstration précise, appartient à `kb-pipeline` ou à la crate métier propriétaire.
- Les fixtures contractuelles communes restent sous `test-fixtures/contract-matrices/` lorsqu’elles sont consommées par plusieurs tests.
- Les archives documentaires ne participent ni au build ni aux décisions normatives.
@@ -108,4 +108,4 @@ L’exécution suit un flux séparé : intention typée, construction, préfligh
La migration bot2 vers bot3 est close pour le périmètre fonctionnel repris jusqu’à `0.4.7`. La version `0.4.8` complète ensuite la fondation Metadata on-chain en distinguant Solana Program Metadata, Token-2022 Token Metadata et Metaplex Token Metadata, avec leurs décodeurs, matérialisateurs, exécuteurs lorsque applicables, orchestration stateful, scénarios réutilisables et intégration desktop.
La série `0.5.x` ne vise pas à étendre immédiatement la couverture protocolaire : elle stabilise d’abord `kb-config`, `kb-wallet`, `kb-store` et les frontières de scénarios afin d’éviter de devoir casser ces fondations après l’arrivée des protocoles trading. `0.6.x` introduira ensuite le décodeur Anchor générique avant la séquence Meteora/Raydium/Pump/Orca/Jupiter.
La série `0.5.x` ne vise pas à étendre immédiatement la couverture protocolaire : elle migre d’abord les bibliothèques vers `ks-*`, puis stabilise `ks-config`, `ks-wallet`, `ks-store` et les frontières de scénarios afin d’éviter de devoir casser ces fondations après l’arrivée des protocoles trading. `0.6.x` introduira ensuite le décodeur Anchor générique avant la séquence Meteora/Raydium/Pump/Orca/Jupiter.

12
docs/architecture/CRATE_MAP.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/CRATE_MAP.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Carte des crates
@@ -8,17 +8,19 @@
| Crate | Type | Responsabilité principale | État documentaire |
|------------------------------|------------------------|--------------------------------------------------------------------|------------------------------------------|
| `kb-core` | bibliothèque | erreurs, résultat et identité de module partagés | README/TODO/USAGE/CHANGELOG présents |
| `kb-config` | bibliothèque | configuration JSON, environnement, validation et profils | documentée ; restructuration en `0.5.1` |
| `kb-config` | bibliothèque | configuration JSON, environnement, validation et profils | migration/restructuration en `0.5.1` |
| `kb-lib` | bibliothèque | modèles, décodeurs, exécuteurs et matérialisateurs consolidés | README/TODO/USAGE/CHANGELOG présents |
| `kb-logging` | bibliothèque | initialisation du logging et du tracing | README/TODO/USAGE/CHANGELOG présents |
| `kb-program-ids` | bibliothèque | registre des programmes et comptes Solana connus | README/TODO/USAGE/CHANGELOG présents |
| `kb-pipeline` | bibliothèque | backfill, extraction, replay, stateful, préflight et orchestration | README/TODO/USAGE/CHANGELOG présents |
| `kb-pipeline-demo-scenarios` | bibliothèque + binaire | scénarios Devnet réutilisables et CLI | documentée ; réconciliation en `0.5.4` |
| `kb-pipeline-demo-scenarios` | bibliothèque + binaire | scénarios Devnet réutilisables et CLI | renommage `0.5.1`, audit `0.5.4` |
| `kb-onchain-transport` | bibliothèque | transports RPC HTTP/WebSocket et pools d’endpoints | README/TODO/USAGE/CHANGELOG présents |
| `kb-store` | bibliothèque | contrats de stockage et adaptateur PostgreSQL | documentée ; audit structurel en `0.5.3` |
| `kb-wallet` | bibliothèque | wallet temporaire et frontière de signataire | documentée ; restructuration en `0.5.2` |
| `kb-store` | bibliothèque | contrats de stockage et adaptateur PostgreSQL | renommage `0.5.1`, normalisation `0.5.3` |
| `kb-wallet` | bibliothèque | wallet temporaire et frontière de signataire | renommage `0.5.1`, refonte `0.5.2` |
| `kb-app-demo-desktop` | bibliothèque + binaire | application de démonstration Tauri | documentée ; réconciliation en `0.5.4` |
La table décrit les noms physiques du workspace `0.5.0`. La migration `0.5.1` renomme les dix crates généralistes en `ks-core`, `ks-config`, `ks-lib`, `ks-logging`, `ks-program-ids`, `ks-pipeline`, `ks-pipeline-demo-scenarios`, `ks-onchain-transport`, `ks-store` et `ks-wallet`. `kb-app-demo-desktop` conserve son nom parce qu’il appartient au domaine applicatif Bot. Voir [`../decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md`](../decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md).
## 2. Consolidations principales depuis bot2
La migration a regroupé de nombreuses anciennes crates dans des frontières plus larges :

8
docs/architecture/PIPELINE_ARCHITECTURE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/PIPELINE_ARCHITECTURE.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Architecture du pipeline
@@ -48,7 +48,7 @@ Cette crate peut préparer des wallets temporaires, demander des airdrops, crée
Le binaire `kb-pipeline-demo-scenarios-cli` est actuellement un outil ciblé de préparation des fixtures SPL Token-2022 réutilisées par les démonstrations Devnet. Son existence ne signifie pas que chaque scénario doit être exposé par un CLI ni que le desktop doit consommer ses scénarios.
`kb-app-demo-desktop` conserve ses commandes Tauri, états, payloads et parcours de présentation Devnet/Testnet. La logique réutilisable de préparation et d’exécution de campagne appartient à `kb-pipeline-demo-scenarios`. `0.5.4` auditera les scénarios encore déclarés directement dans le desktop et déplacera ceux qui sont réutilisables. La dépendance inverse de `kb-pipeline` vers les scénarios reste interdite.
`kb-app-demo-desktop` conserve ses commandes Tauri, états, payloads et parcours de présentation Devnet/Testnet. La logique réutilisable de préparation et d’exécution de campagne appartient à `kb-pipeline-demo-scenarios`, renommée `ks-pipeline-demo-scenarios` en `0.5.1`. `0.5.4` auditera les scénarios encore déclarés directement dans le desktop et déplacera ceux qui sont réutilisables. La dépendance inverse de `kb-pipeline` vers les scénarios reste interdite et cette règle se conserve après migration vers `ks-pipeline`.
## 5. Contrats de preuve
@@ -57,5 +57,5 @@ Les tests unitaires, tests d’intégration et matrices de `test-fixtures/contra
## 6. Limites connues
- Le registre ElGamal n’est pas déclaré validé sur Devnet ou Mainnet.
- La réconciliation finale des scénarios encore dupliqués entre desktop et `kb-pipeline-demo-scenarios` est planifiée en `0.5.4`.
- Les futurs protocoles doivent conserver cette frontière : orchestration généraliste dans `kb-pipeline`, scénarios réseau réutilisables dans `kb-pipeline-demo-scenarios`, adaptation UI/Tauri dans le desktop.
- La réconciliation finale des scénarios encore dupliqués entre desktop et la future `ks-pipeline-demo-scenarios` est planifiée en `0.5.4`.
- Après `0.5.1`, les futurs protocoles doivent conserver cette frontière : orchestration généraliste dans `ks-pipeline`, scénarios réseau réutilisables dans `ks-pipeline-demo-scenarios`, adaptation UI/Tauri dans le desktop.

8
docs/architecture/PROJECT_OBJECTIVES.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/PROJECT_OBJECTIVES.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Objectifs du projet Khadhroony Bot3
@@ -9,6 +9,8 @@
Il succède à `khadhroony-bot2` en conservant les contrats fonctionnels validés tout en réduisant fortement le nombre de crates et en clarifiant les frontières entre modèles, traitements, stockage, transports, démonstrations et applications.
La fondation `0.5.x` distingue désormais deux domaines : `khadhroony-solana` pour les bibliothèques généralistes Solana et `khadhroony-bot` pour les applications spécifiques au futur robot de trading. Le portefeuille plus large `khadhroony-project` pourra contenir d'autres projets de trading ou de crypto, y compris des projets non Solana et non crypto.
## 2. Objectifs structurants
Le projet vise à :
@@ -66,8 +68,8 @@ Le noyau livré jusqu’à `0.4.8` couvre notamment :
Ne sont pas considérés comme achevés :
- la restructuration des fondations `kb-config`, `kb-wallet` et `kb-store`, planifiée en `0.5.x` ;
- la réconciliation complète des scénarios réutilisables entre `kb-pipeline-demo-scenarios` et le desktop ;
- la migration des bibliothèques généralistes vers `ks-*` et les restructurations de `ks-config`, `ks-wallet` et `ks-store`, planifiées en `0.5.x` ;
- la réconciliation complète des scénarios réutilisables entre la future `ks-pipeline-demo-scenarios` et le desktop ;
- le décodeur Anchor générique planifié en `0.6.x` ;
- les protocoles trading prioritaires Meteora, Raydium, Pump, Orca et Jupiter ;
- la couverture généraliste différée des autres Program IDs Solana, qui reste un objectif du projet après la séquence trading prioritaire ;

6
docs/architecture/STORAGE_ARCHITECTURE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/STORAGE_ARCHITECTURE.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Architecture du stockage
@@ -59,7 +59,9 @@ Les noms de tables, contrats de replay et APIs publiques sont documentés dans `
- erreurs explicites ;
- séparation entre données brutes, résultats de décodage et matérialisations.
La série `0.5.3` réauditera cette fondation avant l’arrivée des protocoles trading. Cet audit doit notamment distinguer les timestamps observés sur la blockchain des timestamps d’insertion et de mise à jour locaux, normaliser la structure interne de `kb-store`, vérifier les champs et index manquants et préparer les futures matérialisations trading, routing et multi-pools sans casser les contrats de replay existants.
La série `0.5.3` normalisera cette fondation avant l’arrivée des protocoles trading. Elle doit notamment distinguer `slot`, `block_time` et les timestamps d’acquisition/persistance, normaliser la structure interne de la future `ks-store`, vérifier les champs et index manquants et préparer les futures matérialisations trading, routing et multi-pools sans perdre les contrats de provenance et d’idempotence.
La même migration remplace le préfixe historique des tables Solana `kb_sol_*` par `k_sol_*`. La base peut encore être reconstruite ou migrée proprement avant `0.6.x`, il n’est donc pas nécessaire de conserver indéfiniment l’ancien préfixe. Le préfixe `kb_*` est réservé aux éventuelles tables dont la responsabilité appartient réellement au domaine applicatif Bot, pas aux faits Solana simplement consommés par le bot.
## 5. Données de test