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

0.4.7-pre.001

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-01 22:52:30 +02:00
parent ae85852648
commit aa3f58db30
6 changed files with 650 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/architecture/ARCHITECTURE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/ARCHITECTURE.md -->
<!-- version: 2 -->
<!-- version: 4 -->
# Architecture générale
@@ -66,7 +66,8 @@ 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 une bibliothèque réutilisable et le binaire `kb-pipeline-demo-scenarios-cli`.
- `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.
@@ -98,10 +99,11 @@ 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éutilisables doivent migrer vers `kb-pipeline-demo-scenarios` plutôt que rester enfouis dans l’UI.
- 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.
- 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`. Les travaux Metaplex Token Metadata partiellement migrés sont repris séparément dans `0.4.7`.
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.

14
docs/architecture/PIPELINE_ARCHITECTURE.md
View File

@@ -1,11 +1,11 @@
<!-- file: docs/architecture/PIPELINE_ARCHITECTURE.md -->
<!-- version: 1 -->
<!-- version: 3 -->
# Architecture du pipeline
## 1. Responsabilité
`kb-pipeline` coordonne des opérations qui traversent plusieurs crates sans devenir propriétaire de leurs implémentations : transport, stockage, contrats de décodage, matérialisation et exécution.
`kb-pipeline` coordonne des opérations généralistes qui traversent plusieurs crates sans devenir propriétaire de leurs implémentations : transport, stockage, contrats de décodage, matérialisation et exécution. Il ne dépend d’aucun scénario, wallet ou actif propre à un réseau de démonstration.
## 2. Familles de traitements
@@ -42,7 +42,13 @@ kb-wallet -> signataires lorsque requis
## 4. Scénarios de démonstration
`kb-pipeline-demo-scenarios` doit contenir les scénarios réutilisables hors UI. `kb-app-demo-desktop` adapte leurs requêtes, progrès et résultats en payloads Tauri. Une dépendance à l’application desktop dans le sens inverse serait incorrecte.
`kb-pipeline-demo-scenarios` contient les fixtures, aides de campagne et tests automatisés spécifiques à Devnet ou Testnet. Ses tests peuvent reproduire les mêmes parcours fonctionnels que les démonstrations UI afin de fournir une validation automatisée parallèle, sans retirer ni déplacer les scénarios Devnet/Testnet de `kb-app-demo-desktop`.
Cette crate peut préparer des wallets temporaires, demander des airdrops, créer des mints ou comptes de test, enchaîner plusieurs opérations et réunir les preuves d’une campagne réseau. Ces responsabilités spécifiques aux validations réseau ne doivent pas remonter dans `kb-pipeline`.
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, états et parcours UI de démonstration Devnet/Testnet. Les tests parallèles de `kb-pipeline-demo-scenarios` vérifient des parcours équivalents à partir des APIs généralistes ; ils ne remplacent pas les démonstrations desktop. La dépendance inverse de `kb-pipeline` vers les scénarios reste interdite.
## 5. Contrats de preuve
@@ -51,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.
- Certains scénarios restent à rendre pleinement autonomes hors desktop.
- La couverture automatisée parallèle des scénarios desktop reste à étendre progressivement dans `kb-pipeline-demo-scenarios`, notamment pendant la série `0.5.x`.
- La documentation détaillée des APIs publiques du pipeline sera produite dans `kb-pipeline/USAGE.md` après inventaire des exports.

22
docs/architecture/SURFACE_CRATE_MATRIX.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/SURFACE_CRATE_MATRIX.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Matrice des responsabilités par surface
@@ -13,15 +13,15 @@
## 2. Matrice
| Surface | `kb-lib` | `kb-pipeline` | `kb-store` | `kb-onchain-transport` | scénarios | desktop |
|-------------------------|-----------------------------------------|---------------------------------------------|------------------------|------------------------|-----------------------------------|----------------------------------------------|
| Solana Core | décodeurs, exécuteurs, matérialisateurs | extraction, replay, exécution | persistance | RPC | validations Devnet | panneaux fonctionnels |
| SPL Memo | décodage v1/v3/v4, exécution v4 | replay et exécution v4 | persistance | RPC | scénario Memo v4 | panneau Memo v4 |
| SPL Token classique | contrats et implémentations | stateful, préflight, orchestration | persistance | RPC | scénarios Devnet | panneaux fonctionnels |
| SPL ATA | contrats et implémentations | état et orchestration | persistance | RPC | scénarios classique/Token-2022 | panneaux fonctionnels |
| Token-2022 | contrats et implémentations | corrélation, preuves, préflight, validation | persistance | RPC | scénarios Devnet | panneaux fonctionnels |
| Registre ElGamal | implémentation partielle confirmée | traitement stateful à vérifier par API | persistance selon flux | acquisition de comptes | pas de validation réelle déclarée | présentation non raccordée fonctionnellement |
| Metaplex Token Metadata | décodeur partiellement migré | à compléter selon besoins | à compléter | acquisition standard | à créer/compléter | à créer/compléter |
| Surface | `kb-lib` | `kb-pipeline` | `kb-store` | `kb-onchain-transport` | scénarios | desktop |
|-------------------------|-------------------------------------------------------------------------------------------|---------------------------------------------|--------------------------------------------------------|------------------------|--------------------------------------------|----------------------------------------------|
| Solana Core | décodeurs, exécuteurs, matérialisateurs | extraction, replay, exécution | persistance | RPC | validations Devnet | panneaux fonctionnels |
| SPL Memo | décodage v1/v3/v4, exécution v4 | replay et exécution v4 | persistance | RPC | scénario Memo v4 | panneau Memo v4 |
| SPL Token classique | contrats et implémentations | stateful, préflight, orchestration | persistance | RPC | scénarios Devnet | panneaux fonctionnels |
| SPL ATA | contrats et implémentations | état et orchestration | persistance | RPC | scénarios classique/Token-2022 | panneaux fonctionnels |
| Token-2022 | contrats et implémentations | corrélation, preuves, préflight, validation | persistance | RPC | scénarios Devnet | panneaux fonctionnels |
| Registre ElGamal | implémentation partielle confirmée | traitement stateful à vérifier par API | persistance selon flux | acquisition de comptes | pas de validation réelle déclarée | présentation non raccordée fonctionnellement |
| Metaplex Token Metadata | décodeurs de comptes/instructions et matérialisation migrés ; exécuteur réservé à achever | pipeline généraliste Metaplex à achever | persistance générique présente ; projections à auditer | acquisition standard | scénarios Devnet/Testnet à créer/compléter | adaptateurs et panneaux à créer/compléter |
## 3. Interprétation
@@ -32,4 +32,4 @@ Cette matrice décrit les responsabilités observées au niveau architectural. E
- Memo v1 et v3 restent non exécutables.
- Memo v4 est exécutable.
- Le registre ElGamal ne doit pas être présenté comme validé Devnet/Mainnet.
- Metaplex Token Metadata appartient au travail `0.4.7` commencé avant la migration et seulement partiellement repris dans bot3.
- Tout le travail Metaplex Token Metadata réalisé dans bot2 a été migré dans bot3. `0.4.7` doit achever la surface sans présenter cette migration comme partielle.