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

v0.4.8-pre.016-fix003

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-09 15:58:11 +02:00
parent 99fdfba767
commit 28bc774898
6 changed files with 69 additions and 55 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/architecture/ARCHITECTURE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/ARCHITECTURE.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Architecture générale
@@ -66,10 +66,10 @@ Il dépend des contrats de `kb-lib`, des données de `kb-store` et des capacité
### 2.5 Démonstrations et applications
- `kb-pipeline-demo-scenarios` fournit les fixtures et les campagnes automatisées spécifiques à Devnet/Testnet. Ces campagnes peuvent reproduire en parallèle les parcours de démonstration du desktop afin de les valider par des tests sans déplacer les scénarios UI hors de `kb-app-demo-desktop`.
- Le binaire `kb-pipeline-demo-scenarios-cli` a été introduit pour préparer les fixtures SPL Token-2022 utilisées ensuite par les démonstrations d’exécution Devnet ; il ne constitue pas, par défaut, une interface générale de tous les scénarios.
- `kb-app-demo-desktop` est une crate mixte : bibliothèque Tauri et binaire desktop.
- `kb-wallet` fournit actuellement une frontière limitée de wallet temporaire et de signataire. Son périmètre reste incomplet.
- `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`.
## 3. Flux principal de données
@@ -99,11 +99,13 @@ 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 UI spécifiques à Devnet/Testnet restent dans `kb-app-demo-desktop`. Lorsqu’un même parcours doit être validé automatiquement, un scénario équivalent est ajouté en parallèle dans les tests de `kb-pipeline-demo-scenarios` ; cette duplication contrôlée de parcours de validation ne déplace pas le scénario UI.
- 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`.
- 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.
## 5. État de migration
L’architecture bot3 est alignée fonctionnellement sur le périmètre bot2 `0.4.6`. Tout le travail Metaplex Token Metadata réalisé dans bot2 a été migré dans bot3 ; `0.4.7` achève cette surface à partir de cette base migrée complète.
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.