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

v0.5.1-pre.009

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-10 11:44:47 +02:00
parent 0e05c660c6
commit bae7f0b9d8
21 changed files with 521 additions and 65 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: 8 -->
<!-- version: 9 -->
# Architecture générale
@@ -69,7 +69,7 @@ Il dépend des contrats de `ks-lib`, des données de `ks-store` et des capacité
- `ks-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 `ks-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 à `ks-pipeline-demo-scenarios`. Le reliquat éventuel de scénarios encore déclarés directement dans le desktop sera audité en `0.5.4`.
- `ks-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`.
- `ks-wallet` fournit actuellement une frontière limitée de wallet temporaire et de signataire. Son namespace `ks-*` est stabilisé depuis `0.5.1` et 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 `ks-program-ids`.
- Les APIs publiques de modèles, décodeurs, exécuteurs et matérialisateurs sont exposées par `ks-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 à `ks-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`.
- Les scénarios réseau réutilisables spécifiques à Devnet/Testnet appartiennent à `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 à `ks-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,6 @@ 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.
`0.5.1` stabilise le domaine Khadhroony Solana sous `ks-*` / `KS_*` et remplace la configuration monolithique par des documents spécialisés composables, avec une frontière backend/public explicitement sanitisée.
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.

6
docs/architecture/CRATE_MAP.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/CRATE_MAP.md -->
<!-- version: 6 -->
<!-- version: 7 -->
# Carte des crates
@@ -8,7 +8,7 @@
| Crate | Type | Responsabilité principale | État documentaire |
|------------------------------|------------------------|--------------------------------------------------------------------------------------|------------------------------------------|
| `ks-core` | bibliothèque | erreurs, résultat et identité de module partagés | README/TODO/USAGE/CHANGELOG présents |
| `ks-config` | bibliothèque | compositions binaires, documents JSON partagés, environnement, validation et profils | migration/restructuration en `0.5.1` |
| `ks-config` | bibliothèque | compositions binaires, documents JSON partagés, environnement, validation et profils | fondation stabilisée depuis `0.5.1` |
| `ks-lib` | bibliothèque | modèles, décodeurs, exécuteurs et matérialisateurs consolidés | README/TODO/USAGE/CHANGELOG présents |
| `ks-logging` | bibliothèque | initialisation du logging et du tracing | README/TODO/USAGE/CHANGELOG présents |
| `ks-program-ids` | bibliothèque | registre des programmes et comptes Solana connus | README/TODO/USAGE/CHANGELOG présents |
@@ -19,7 +19,7 @@
| `ks-wallet` | bibliothèque | wallet temporaire et frontière de signataire | nom `ks-*` actif ; 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 actifs depuis `0.5.1-pre.002`. La migration a renommé 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).
La table décrit les noms physiques stabilisés par `0.5.1`. La migration a renommé 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

8
docs/architecture/PIPELINE_ARCHITECTURE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/PIPELINE_ARCHITECTURE.md -->
<!-- version: 7 -->
<!-- version: 8 -->
# Architecture du pipeline
@@ -48,7 +48,7 @@ Cette crate peut préparer des wallets temporaires, demander des airdrops, crée
Le binaire `ks-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 à `ks-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 `ks-pipeline` vers les scénarios reste interdite et cette règle se conserve après migration vers `ks-pipeline`.
`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 à `ks-pipeline-demo-scenarios`, dont le namespace `ks-*` est stabilisé depuis `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 `ks-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 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.
- La réconciliation finale des scénarios encore dupliqués entre le desktop et `ks-pipeline-demo-scenarios` est planifiée en `0.5.4`.
- 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.

4
docs/architecture/PROJECT_OBJECTIVES.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/PROJECT_OBJECTIVES.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Objectifs du projet Khadhroony Bot3
@@ -69,7 +69,7 @@ Le noyau livré jusqu’à `0.4.8` couvre notamment :
Ne sont pas considérés comme achevés :
- 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 ;
- la réconciliation complète des scénarios réutilisables entre `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 ;

4
docs/architecture/STORAGE_ARCHITECTURE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/STORAGE_ARCHITECTURE.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Architecture du stockage
@@ -59,7 +59,7 @@ 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` 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 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 `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.