0.5.1-pre.002
This commit is contained in:
@@ -1,11 +1,11 @@
|
||||
<!-- file: docs/DEVNET_EXECUTION_GUIDE.md -->
|
||||
<!-- version: 24 -->
|
||||
<!-- version: 25 -->
|
||||
|
||||
# Guide d’exécution Devnet
|
||||
|
||||
## 1. Objet et ordre de validation
|
||||
|
||||
Ce guide décrit la campagne Devnet de `kb-app-demo-desktop` et `kb-pipeline-demo-scenarios`. Après une modification de nomenclature persistée ou une recréation de la base Devnet, reprendre les scénarios depuis le début dans l’ordre suivant :
|
||||
Ce guide décrit la campagne Devnet de `kb-app-demo-desktop` et `ks-pipeline-demo-scenarios`. Après une modification de nomenclature persistée ou une recréation de la base Devnet, reprendre les scénarios depuis le début dans l’ordre suivant :
|
||||
|
||||
1. préparation commune et base PostgreSQL propre ;
|
||||
2. Solana Core — System Transfer ;
|
||||
@@ -241,7 +241,7 @@ La création du compte destination par CLI est acceptable ici : `S03A` et `S03B`
|
||||
Le workspace fournit une commande idempotente qui prépare les comptes publics requis par les huit scénarios Token-2022 :
|
||||
|
||||
```bash
|
||||
cargo run -p kb-pipeline-demo-scenarios --bin kb-pipeline-demo-scenarios-cli -- prepare-token-2022-fixture --rpc-url "$KB_DEVNET_RPC_URL" --wallet "$KB_DEVNET_WALLET" --wallet-dir "$PWD/wallets/temporary/local_devnet" --decimals 9 | tee "$KB_DEVNET_VALIDATION_DIR/50-spl-token-2022-fixture-preparation.json"
|
||||
cargo run -p ks-pipeline-demo-scenarios --bin ks-pipeline-demo-scenarios-cli -- prepare-token-2022-fixture --rpc-url "$KB_DEVNET_RPC_URL" --wallet "$KB_DEVNET_WALLET" --wallet-dir "$PWD/wallets/temporary/local_devnet" --decimals 9 | tee "$KB_DEVNET_VALIDATION_DIR/50-spl-token-2022-fixture-preparation.json"
|
||||
```
|
||||
|
||||
Lorsque `--rpc-url` et `--wallet` sont omis, la commande utilise respectivement `KB_DEVNET_RPC_URL` et `KB_DEVNET_WALLET`. Lorsque `--wallet-dir` est omis, elle utilise le répertoire parent du wallet.
|
||||
@@ -623,7 +623,7 @@ export KB_DEVNET_SCENARIO="50-spl-token-2022"
|
||||
5. Cliquer **Charger la fixture Token-2022**.
|
||||
6. Vérifier que le message indique le chemin de `fixture.env` et le Program ID Token-2022.
|
||||
|
||||
Le bouton lit le `fixture.env` produit par `kb-pipeline-demo-scenarios` et remplit automatiquement :
|
||||
Le bouton lit le `fixture.env` produit par `ks-pipeline-demo-scenarios` et remplit automatiquement :
|
||||
|
||||
- compte source ou cible ;
|
||||
- mint ;
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/IDEA_REMINDERS.md -->
|
||||
<!-- version: 8 -->
|
||||
<!-- version: 9 -->
|
||||
|
||||
# Rappels d’idées
|
||||
|
||||
@@ -24,7 +24,7 @@ La décision normative et son calendrier sont dans [`decisions/KHADHROONY_SOLANA
|
||||
|
||||
- autocomplétion Token et Pool lorsque des tables de référence fiables existeront ;
|
||||
- pagination SQL/IPC côté serveur avant l’exploitation de volumes massifs ;
|
||||
- résolution configurable du chemin de base de `kb-store` ;
|
||||
- résolution configurable du chemin de base de `ks-store` ;
|
||||
- sélection indépendante du profil de logging ;
|
||||
|
||||
## Pipeline et PostgreSQL
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
<!-- file: docs/IDL_TO_KB_LIB_NOMENCLATURE.md -->
|
||||
<!-- version: 7 -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# Correspondance IDL ↔ `kb-lib`
|
||||
# Correspondance IDL ↔ `ks-lib`
|
||||
|
||||
Ce tableau constitue la cible de classification pour les futurs décodeurs et exécuteurs.
|
||||
Il ne signifie pas que tous les modules proposés sont déjà implémentés.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/MISSING_PROGRAM_IDLS.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Programmes ou IDL manquants
|
||||
|
||||
@@ -7,7 +7,7 @@ Cette liste distingue l'absence d'un fichier dans `idls_v3` de l'absence d'une I
|
||||
|
||||
## Surfaces Bot3 déjà implémentées sans IDL correspondante dans l'archive
|
||||
|
||||
| Classification `kb-lib` | Program ID | Situation |
|
||||
| Classification `ks-lib` | Program ID | Situation |
|
||||
|--------------------------------|------------------------------------------------|-------------------------------------------------|
|
||||
| `spl/memo/v1` | `Memo1UhkJRfHyvLMcVucJwxXeuD728EqVDDwQDxFMNo` | aucune IDL correspondante dans `idls_v2` |
|
||||
| `spl/memo/v4` | `Memo4c2pN8afCj432Lb7RMVKi9PbQnnW7ewFFaV3oAH` | aucune IDL correspondante dans `idls_v2` |
|
||||
@@ -19,4 +19,4 @@ Cette liste distingue l'absence d'un fichier dans `idls_v3` de l'absence d'une I
|
||||
- Le fichier Memo présent correspond à `MemoSq4...`, donc à la génération v3 dans la nomenclature Bot3.
|
||||
- L'absence d'IDL ne signifie pas l'absence de source normative : les crates d'interface officielles,
|
||||
le code runtime et les matrices wire restent utilisables.
|
||||
- La liste devra être recalculée après chaque ajout de programme à `kb-program-ids`.
|
||||
- La liste devra être recalculée après chaque ajout de programme à `ks-program-ids`.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/OPERATION_NAMING_CONVENTION.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Convention canonique des identités runtime et des codes d’opération
|
||||
|
||||
@@ -41,7 +41,7 @@ metadata_metaplex_token_metadata.create_metadata_account_v3
|
||||
|
||||
## 2.1 Frontière avec les codes de registre
|
||||
|
||||
La notation par points s’applique aux identités runtime, processeurs, surfaces, opérations et événements persistés. Elle ne s’applique pas aux codes techniques du registre `kb-program-ids`, qui restent des identifiants Rust/registre en `lower_snake_case` afin de préserver leur ordre lexical, leur compatibilité et leur rôle de clé interne.
|
||||
La notation par points s’applique aux identités runtime, processeurs, surfaces, opérations et événements persistés. Elle ne s’applique pas aux codes techniques du registre `ks-program-ids`, qui restent des identifiants Rust/registre en `lower_snake_case` afin de préserver leur ordre lexical, leur compatibilité et leur rôle de clé interne.
|
||||
|
||||
Exemples de codes de registre :
|
||||
|
||||
@@ -267,7 +267,7 @@ Une surface `decode_only` peut avoir `operationCode` et `executorName` à `null`
|
||||
Avant de fusionner une nouvelle opération :
|
||||
|
||||
1. choisir son domaine et sa famille ;
|
||||
2. identifier le Program ID canonique dans `kb-program-ids` ;
|
||||
2. identifier le Program ID canonique dans `ks-program-ids` ;
|
||||
3. définir `processor_name` et `surface_code` ;
|
||||
4. définir séparément `operation_code` et `event_code` ;
|
||||
5. ajouter les constantes Rust ;
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/README.md -->
|
||||
<!-- version: 31 -->
|
||||
<!-- version: 32 -->
|
||||
|
||||
# Documentation active de Khadhroony Bot3
|
||||
|
||||
@@ -70,16 +70,16 @@ Elles peuvent être chargées directement par les tests unitaires ou d’intégr
|
||||
|
||||
Les onze crates possèdent `README.md`, `TODO.md`, `USAGE.md` et `CHANGELOG.md` :
|
||||
|
||||
- [`kb-core`](../kb-core/README.md) ;
|
||||
- [`kb-config`](../kb-config/README.md) ;
|
||||
- [`kb-lib`](../kb-lib/README.md) ;
|
||||
- [`kb-logging`](../kb-logging/README.md) ;
|
||||
- [`kb-program-ids`](../kb-program-ids/README.md) ;
|
||||
- [`kb-pipeline`](../kb-pipeline/README.md) ;
|
||||
- [`kb-pipeline-demo-scenarios`](../kb-pipeline-demo-scenarios/README.md) ;
|
||||
- [`kb-onchain-transport`](../kb-onchain-transport/README.md) ;
|
||||
- [`kb-store`](../kb-store/README.md) ;
|
||||
- [`kb-wallet`](../kb-wallet/README.md) ;
|
||||
- [`ks-core`](../ks-core/README.md) ;
|
||||
- [`ks-config`](../ks-config/README.md) ;
|
||||
- [`ks-lib`](../ks-lib/README.md) ;
|
||||
- [`ks-logging`](../ks-logging/README.md) ;
|
||||
- [`ks-program-ids`](../ks-program-ids/README.md) ;
|
||||
- [`ks-pipeline`](../ks-pipeline/README.md) ;
|
||||
- [`ks-pipeline-demo-scenarios`](../ks-pipeline-demo-scenarios/README.md) ;
|
||||
- [`ks-onchain-transport`](../ks-onchain-transport/README.md) ;
|
||||
- [`ks-store`](../ks-store/README.md) ;
|
||||
- [`ks-wallet`](../ks-wallet/README.md) ;
|
||||
- [`kb-app-demo-desktop`](../kb-app-demo-desktop/README.md).
|
||||
|
||||
## 8. Guides
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/ARCHITECTURE.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# Architecture générale
|
||||
|
||||
@@ -12,7 +12,7 @@ configuration ─────┐
|
||||
logging ───────────┼──────────────┐
|
||||
program IDs ───────┘ │
|
||||
v
|
||||
transport -> store -> pipeline -> kb-lib
|
||||
transport -> store -> pipeline -> ks-lib
|
||||
│ │
|
||||
v v
|
||||
demo scenarios wallet/signers
|
||||
@@ -28,32 +28,32 @@ Cette représentation indique les relations dominantes. Elle ne remplace pas le
|
||||
|
||||
### 2.1 Fondations
|
||||
|
||||
- `kb-core` fournit les erreurs et identités transversales minimales.
|
||||
- `kb-config` charge, résout et valide la configuration.
|
||||
- `kb-logging` initialise le logging et le tracing.
|
||||
- `kb-program-ids` centralise les identifiants de programmes et comptes connus.
|
||||
- `ks-core` fournit les erreurs et identités transversales minimales.
|
||||
- `ks-config` charge, résout et valide la configuration.
|
||||
- `ks-logging` initialise le logging et le tracing.
|
||||
- `ks-program-ids` centralise les identifiants de programmes et comptes connus.
|
||||
|
||||
### 2.2 Noyau métier
|
||||
|
||||
`kb-lib` contient quatre familles principales :
|
||||
`ks-lib` contient quatre familles principales :
|
||||
|
||||
- modèles et contrats partagés ;
|
||||
- décodeurs ;
|
||||
- exécuteurs ;
|
||||
- matérialisateurs.
|
||||
|
||||
La façade publique est constituée par les réexports de `kb-lib/src/lib.rs`. Les modules internes conservent leurs frontières et leurs conventions de nommage.
|
||||
La façade publique est constituée par les réexports de `ks-lib/src/lib.rs`. Les modules internes conservent leurs frontières et leurs conventions de nommage.
|
||||
|
||||
### 2.3 Acquisition et stockage
|
||||
|
||||
- `kb-onchain-transport` fournit les clients HTTP/WebSocket, pools, rôles d’endpoints, méthodes RPC standard et contrats liés à l’exécution RPC.
|
||||
- `kb-store` regroupe les contrats store-neutral et l’implémentation PostgreSQL.
|
||||
- `ks-onchain-transport` fournit les clients HTTP/WebSocket, pools, rôles d’endpoints, méthodes RPC standard et contrats liés à l’exécution RPC.
|
||||
- `ks-store` regroupe les contrats store-neutral et l’implémentation PostgreSQL.
|
||||
|
||||
Les transports n’effectuent pas la matérialisation métier. Le stockage ne décide pas quelle surface protocolaire doit être décodée.
|
||||
|
||||
### 2.4 Orchestration
|
||||
|
||||
`kb-pipeline` orchestre :
|
||||
`ks-pipeline` orchestre :
|
||||
|
||||
- backfill ;
|
||||
- extraction Core ;
|
||||
@@ -62,14 +62,14 @@ Les transports n’effectuent pas la matérialisation métier. Le stockage ne d
|
||||
- corrélation stateful ;
|
||||
- préflight et orchestration d’exécution pour les surfaces prises en charge.
|
||||
|
||||
Il dépend des contrats de `kb-lib`, des données de `kb-store` et des capacités de `kb-onchain-transport` sans absorber leurs responsabilités.
|
||||
Il dépend des contrats de `ks-lib`, des données de `ks-store` et des capacités de `ks-onchain-transport` sans absorber leurs responsabilités.
|
||||
|
||||
### 2.5 Démonstrations et applications
|
||||
|
||||
- `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. Elle devient `ks-wallet` en `0.5.1`, puis sa restructuration fonctionnelle est planifiée en `0.5.2`.
|
||||
- `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`.
|
||||
|
||||
## 3. Flux principal de données
|
||||
|
||||
@@ -77,18 +77,18 @@ Il dépend des contrats de `kb-lib`, des données de `kb-store` et des capacité
|
||||
Solana RPC / WebSocket
|
||||
│
|
||||
v
|
||||
kb-onchain-transport
|
||||
ks-onchain-transport
|
||||
│
|
||||
v
|
||||
kb-store (données brutes/canoniques)
|
||||
ks-store (données brutes/canoniques)
|
||||
│
|
||||
v
|
||||
kb-pipeline
|
||||
ks-pipeline
|
||||
│
|
||||
├── extraction Core
|
||||
├── sélection des décodeurs
|
||||
├── décodage via kb-lib
|
||||
├── matérialisation via kb-lib
|
||||
├── décodage via ks-lib
|
||||
├── matérialisation via ks-lib
|
||||
└── stockage des résultats
|
||||
```
|
||||
|
||||
@@ -96,11 +96,11 @@ L’exécution suit un flux séparé : intention typée, construction, préfligh
|
||||
|
||||
## 4. Frontières obligatoires
|
||||
|
||||
- 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 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 à `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 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`.
|
||||
- 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.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/CRATE_MAP.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Carte des crates
|
||||
|
||||
@@ -7,16 +7,16 @@
|
||||
|
||||
| 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 | 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 | 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 | 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` |
|
||||
| `ks-core` | bibliothèque | erreurs, résultat et identité de module partagés | README/TODO/USAGE/CHANGELOG présents |
|
||||
| `ks-config` | bibliothèque | configuration JSON, environnement, validation et profils | migration/restructuration en `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 |
|
||||
| `ks-pipeline` | bibliothèque | backfill, extraction, replay, stateful, préflight et orchestration | README/TODO/USAGE/CHANGELOG présents |
|
||||
| `ks-pipeline-demo-scenarios` | bibliothèque + binaire | scénarios Devnet réutilisables et CLI | renommage `0.5.1`, audit `0.5.4` |
|
||||
| `ks-onchain-transport` | bibliothèque | transports RPC HTTP/WebSocket et pools d’endpoints | README/TODO/USAGE/CHANGELOG présents |
|
||||
| `ks-store` | bibliothèque | contrats de stockage et adaptateur PostgreSQL | renommage `0.5.1`, normalisation `0.5.3` |
|
||||
| `ks-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).
|
||||
@@ -25,21 +25,21 @@ La table décrit les noms physiques du workspace `0.5.0`. La migration `0.5.1` r
|
||||
|
||||
La migration a regroupé de nombreuses anciennes crates dans des frontières plus larges :
|
||||
|
||||
- les modèles et APIs de décodage, matérialisation et exécution ont rejoint `kb-lib` ;
|
||||
- les implémentations de stockage core et PostgreSQL ont rejoint `kb-store` ;
|
||||
- les responsabilités de pipeline ont été réunies dans `kb-pipeline` ;
|
||||
- les transports Solana sont réunis dans `kb-onchain-transport` ;
|
||||
- les modèles et APIs de décodage, matérialisation et exécution ont rejoint `ks-lib` ;
|
||||
- les implémentations de stockage core et PostgreSQL ont rejoint `ks-store` ;
|
||||
- les responsabilités de pipeline ont été réunies dans `ks-pipeline` ;
|
||||
- les transports Solana sont réunis dans `ks-onchain-transport` ;
|
||||
- l’application et sa bibliothèque sont réunies dans `kb-app-demo-desktop` ;
|
||||
- les scénarios réutilisables ont été extraits dans `kb-pipeline-demo-scenarios`.
|
||||
- les scénarios réutilisables ont été extraits dans `ks-pipeline-demo-scenarios`.
|
||||
|
||||
Cette carte n’est pas une table de compatibilité exhaustive des anciennes crates. Les correspondances historiques détaillées seront synthétisées dans la documentation de migration et l’audit d’alignement.
|
||||
|
||||
## 3. Crates mixtes
|
||||
|
||||
### 3.1 `kb-pipeline-demo-scenarios`
|
||||
### 3.1 `ks-pipeline-demo-scenarios`
|
||||
|
||||
- bibliothèque Rust : `kb_pipeline_demo_scenarios` ;
|
||||
- binaire : `kb-pipeline-demo-scenarios-cli` ;
|
||||
- bibliothèque Rust : `ks_pipeline_demo_scenarios` ;
|
||||
- binaire : `ks-pipeline-demo-scenarios-cli` ;
|
||||
- `autobins = false` évite une cible implicite concurrente.
|
||||
|
||||
### 3.2 `kb-app-demo-desktop`
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
<!-- file: docs/architecture/PIPELINE_ARCHITECTURE.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# Architecture du pipeline
|
||||
|
||||
## 1. Responsabilité
|
||||
|
||||
`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.
|
||||
`ks-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
|
||||
|
||||
@@ -19,7 +19,7 @@ L’extraction Core transforme les transactions stockées en représentations d
|
||||
|
||||
### 2.3 Replay de décodage
|
||||
|
||||
Le replay sélectionne des candidats, applique les décodeurs compatibles de `kb-lib`, conserve diagnostics et preuves, puis déclenche les matérialisateurs demandés. La reprise doit préserver l’idempotence et les frontières de campagne.
|
||||
Le replay sélectionne des candidats, applique les décodeurs compatibles de `ks-lib`, conserve diagnostics et preuves, puis déclenche les matérialisateurs demandés. La reprise doit préserver l’idempotence et les frontières de campagne.
|
||||
|
||||
### 2.4 Traitements stateful
|
||||
|
||||
@@ -27,28 +27,28 @@ Les modules stateful corrèlent instructions, comptes, états précédents et r
|
||||
|
||||
### 2.5 Préflight et exécution
|
||||
|
||||
Le pipeline assemble les contrôles préalables, plans préparés, signataires, preuves, simulation et validation postérieure. Les exécuteurs restent définis dans `kb-lib` ; le pipeline orchestre leur utilisation.
|
||||
Le pipeline assemble les contrôles préalables, plans préparés, signataires, preuves, simulation et validation postérieure. Les exécuteurs restent définis dans `ks-lib` ; le pipeline orchestre leur utilisation.
|
||||
|
||||
## 3. Dépendances fonctionnelles
|
||||
|
||||
```text
|
||||
kb-onchain-transport -> acquisition et appels RPC
|
||||
kb-store -> lecture/écriture canonique et replay
|
||||
kb-lib -> contrats et implémentations métier
|
||||
kb-config -> profils et paramètres opérationnels
|
||||
kb-logging -> observabilité
|
||||
kb-wallet -> signataires lorsque requis
|
||||
ks-onchain-transport -> acquisition et appels RPC
|
||||
ks-store -> lecture/écriture canonique et replay
|
||||
ks-lib -> contrats et implémentations métier
|
||||
ks-config -> profils et paramètres opérationnels
|
||||
ks-logging -> observabilité
|
||||
ks-wallet -> signataires lorsque requis
|
||||
```
|
||||
|
||||
## 4. Scénarios de démonstration
|
||||
|
||||
`kb-pipeline-demo-scenarios` contient les fixtures, aides de campagne et scénarios réutilisables spécifiques à Devnet ou Testnet. Le desktop doit appeler ces scénarios lorsqu’ils existent plutôt que maintenir une seconde implémentation métier du même parcours.
|
||||
`ks-pipeline-demo-scenarios` contient les fixtures, aides de campagne et scénarios réutilisables spécifiques à Devnet ou Testnet. Le desktop doit appeler ces scénarios lorsqu’ils existent plutôt que maintenir une seconde implémentation métier du même parcours.
|
||||
|
||||
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`.
|
||||
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 `ks-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.
|
||||
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 à `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`.
|
||||
`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`.
|
||||
|
||||
## 5. Contrats de preuve
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/PROJECT_OBJECTIVES.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Objectifs du projet Khadhroony Bot3
|
||||
|
||||
@@ -29,7 +29,7 @@ Le projet vise à :
|
||||
|
||||
### 3.1 Consolidation contrôlée
|
||||
|
||||
La consolidation ne signifie pas l’effacement des frontières métier. `kb-lib` regroupe les modèles, décodeurs, exécuteurs et matérialisateurs dans des modules dédiés. `kb-store`, `kb-pipeline` et `kb-onchain-transport` restent des crates séparées parce qu’ils représentent des responsabilités opérationnelles différentes.
|
||||
La consolidation ne signifie pas l’effacement des frontières métier. `ks-lib` regroupe les modèles, décodeurs, exécuteurs et matérialisateurs dans des modules dédiés. `ks-store`, `ks-pipeline` et `ks-onchain-transport` restent des crates séparées parce qu’ils représentent des responsabilités opérationnelles différentes.
|
||||
|
||||
### 3.2 Contrats explicites
|
||||
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
<!-- file: docs/architecture/STORAGE_ARCHITECTURE.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Architecture du stockage
|
||||
|
||||
## 1. Responsabilité de `kb-store`
|
||||
## 1. Responsabilité de `ks-store`
|
||||
|
||||
`kb-store` réunit :
|
||||
`ks-store` réunit :
|
||||
|
||||
- les contrats store-neutral ;
|
||||
- les DTO et entités persistées ;
|
||||
@@ -34,7 +34,7 @@ Le module PostgreSQL possède :
|
||||
|
||||
### 2.3 Modèles partagés
|
||||
|
||||
Les modèles métier communs restent dans `kb-lib` lorsqu’ils dépassent la seule persistance. `kb-store` ne doit pas créer une seconde définition concurrente d’un contrat partagé.
|
||||
Les modèles métier communs restent dans `ks-lib` lorsqu’ils dépassent la seule persistance. `ks-store` ne doit pas créer une seconde définition concurrente d’un contrat partagé.
|
||||
|
||||
## 3. Catégories de données
|
||||
|
||||
@@ -47,7 +47,7 @@ Le stockage couvre plusieurs niveaux :
|
||||
- états de campagne et candidats de replay ;
|
||||
- informations opérationnelles et de santé.
|
||||
|
||||
Les noms de tables, contrats de replay et APIs publiques sont documentés dans `kb-store/USAGE.md` à partir des exports et migrations actuels.
|
||||
Les noms de tables, contrats de replay et APIs publiques sont documentés dans `ks-store/USAGE.md` à partir des exports et migrations actuels.
|
||||
|
||||
## 4. Propriétés attendues
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/SURFACE_CRATE_MATRIX.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Matrice des responsabilités par surface
|
||||
|
||||
@@ -13,7 +13,7 @@
|
||||
|
||||
## 2. Matrice
|
||||
|
||||
| Surface | `kb-lib` | `kb-pipeline` | `kb-store` | `kb-onchain-transport` | `kb-pipeline-demo-scenarios` | `kb-app-demo-desktop` |
|
||||
| Surface | `ks-lib` | `ks-pipeline` | `ks-store` | `ks-onchain-transport` | `ks-pipeline-demo-scenarios` | `kb-app-demo-desktop` |
|
||||
|---------------------------|--------------------------------------------------------------------------------|------------------------------------------------------|-----------------------|-------------------------------|--------------------------------------------------------|-----------------------------------------------------|
|
||||
| Solana Core | décodeurs, exécuteurs et matérialisateurs | extraction, replay, stateful et exécution | persistance générique | RPC HTTP/WS | validations Devnet | panneaux fonctionnels |
|
||||
| SPL Memo | décodage v1/v3/v4 ; exécution v4 | replay et exécution v4 | persistance générique | RPC | scénario Memo v4 | panneau Memo v4 |
|
||||
@@ -29,7 +29,7 @@
|
||||
|
||||
Cette matrice décrit les responsabilités observées au niveau architectural. Elle ne déclare pas une couverture exhaustive de chaque instruction ou compte. La couverture détaillée reste démontrée par le code, les tests, les matrices sous `test-fixtures/contract-matrices/` et les rapports de validation actifs ou archivés.
|
||||
|
||||
La persistance des surfaces Metadata repose sur les contrats génériques de decode/materialization de `kb-store`. Leur séparation métier est portée notamment par les identités de processeur, les familles matérialisées, les clés de sortie et les payloads versionnés ; `0.4.8` n’introduit donc pas de schéma PostgreSQL spécialisé par protocole Metadata.
|
||||
La persistance des surfaces Metadata repose sur les contrats génériques de decode/materialization de `ks-store`. Leur séparation métier est portée notamment par les identités de processeur, les familles matérialisées, les clés de sortie et les payloads versionnés ; `0.4.8` n’introduit donc pas de schéma PostgreSQL spécialisé par protocole Metadata.
|
||||
|
||||
## 4. Statuts sensibles
|
||||
|
||||
@@ -38,4 +38,4 @@ La persistance des surfaces Metadata repose sur les contrats génériques de dec
|
||||
- Solana Program Metadata est couvert par neuf opérations stables, toutes validées sur Devnet.
|
||||
- Token-2022 Token Metadata est couvert par cinq opérations d’interface, toutes validées sur Devnet.
|
||||
- Metaplex Token Metadata est clos pour la matrice courante de `0.4.8` avec 15 opérations `confirmed`, 5 `unavailable` et 0 `not_run` ; les opérations indisponibles ne doivent pas être promues sans nouvelle preuve réseau.
|
||||
- La priorité trading des versions suivantes n’altère pas la vocation généraliste de `kb-lib` : les autres Program IDs restent dans le périmètre de couverture et peuvent être différés selon leur priorité de développement.
|
||||
- La priorité trading des versions suivantes n’altère pas la vocation généraliste de `ks-lib` : les autres Program IDs restent dans le périmètre de couverture et peuvent être différés selon leur priorité de développement.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/decisions/DOCUMENT_ARCHIVE_SELECTION_POLICY.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Politique de sélection des archives documentaires
|
||||
|
||||
@@ -61,8 +61,8 @@ kb_app_demo/package.json
|
||||
kb_app_demo/tauri.conf.json
|
||||
kb_app_demo/tsconfig.json
|
||||
kb_rpc/tests/fixtures/*.json
|
||||
kb_store_core/src/**
|
||||
kb_store_pg/src/**
|
||||
ks_store_core/src/**
|
||||
ks_store_pg/src/**
|
||||
```
|
||||
|
||||
## 7. Évolution de l’archive
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Politique de namespace Khadhroony Solana
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
|
||||
Cette décision est adoptée pendant la clôture de `0.5.0` et devient la cible normative des migrations de fondation `0.5.1` à `0.5.3`.
|
||||
|
||||
Le workspace `0.5.0` conserve encore physiquement les noms `kb-*`, `kb_*`, `KB_*`, `kb-lib.*` et `kb_sol_*` là où ils existent. Leur présence avant migration ne remet pas en cause la cible ci-dessous.
|
||||
À partir de `0.5.1-pre.002`, les dix crates Solana généralistes sont physiquement nommées `ks-*` et leurs identifiants Rust `ks_*`. Les namespaces historiques `KB_*`, `kb-lib.*` et `kb_sol_*` restent temporairement présents jusqu'aux prereleases dédiées ; leur présence pendant cette migration bornée ne remet pas en cause la cible ci-dessous.
|
||||
|
||||
Le renommage des bibliothèques internes ne renomme pas le workspace, le dépôt ni le répertoire racine : ils restent `khadhroony-bot3` pendant toute la série pré-`1.0`. Un éventuel renommage du workspace racine est explicitement hors périmètre de `0.5.x` et ne doit intervenir qu'en `1.0` ou ultérieurement sur décision dédiée.
|
||||
|
||||
@@ -23,22 +23,22 @@ Le renommage des bibliothèques internes ne renomme pas le workspace, le dépôt
|
||||
|
||||
## 3. Crates Solana généralistes
|
||||
|
||||
La migration `0.5.1` doit renommer les dix crates généralistes suivantes :
|
||||
La migration `0.5.1-pre.002` renomme les dix crates généralistes suivantes :
|
||||
|
||||
| Nom `0.5.0` | Nom cible |
|
||||
|------------------------------|------------------------------|
|
||||
| `kb-core` | `ks-core` |
|
||||
| `kb-config` | `ks-config` |
|
||||
| `kb-lib` | `ks-lib` |
|
||||
| `kb-logging` | `ks-logging` |
|
||||
| `kb-program-ids` | `ks-program-ids` |
|
||||
| `kb-pipeline` | `ks-pipeline` |
|
||||
| Nom `0.5.0` | Nom cible |
|
||||
|---|---|
|
||||
| `kb-core` | `ks-core` |
|
||||
| `kb-config` | `ks-config` |
|
||||
| `kb-lib` | `ks-lib` |
|
||||
| `kb-logging` | `ks-logging` |
|
||||
| `kb-program-ids` | `ks-program-ids` |
|
||||
| `kb-pipeline` | `ks-pipeline` |
|
||||
| `kb-pipeline-demo-scenarios` | `ks-pipeline-demo-scenarios` |
|
||||
| `kb-onchain-transport` | `ks-onchain-transport` |
|
||||
| `kb-store` | `ks-store` |
|
||||
| `kb-wallet` | `ks-wallet` |
|
||||
| `kb-onchain-transport` | `ks-onchain-transport` |
|
||||
| `kb-store` | `ks-store` |
|
||||
| `kb-wallet` | `ks-wallet` |
|
||||
|
||||
Les identifiants Rust correspondants migrent vers `ks_*` : par exemple `kb_config` devient `ks_config` et `kb_pipeline_demo_scenarios` devient `ks_pipeline_demo_scenarios`.
|
||||
Les identifiants Rust correspondants migrent dans le même delta vers `ks_*` : par exemple `kb_config` devient `ks_config` et `kb_pipeline_demo_scenarios` devient `ks_pipeline_demo_scenarios`.
|
||||
|
||||
La migration doit couvrir les manifests, chemins de workspace, imports, exports, tests d'API externe, scripts, documentation, targets de build et bindings générés à la source. Les artefacts générés restent régénérés localement selon les règles du workspace et ne sont pas livrés sans nécessité explicite.
|
||||
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
<!-- file: docs/guides/CONFIGURATION.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Guide de configuration
|
||||
|
||||
## Objectif
|
||||
|
||||
Ce guide décrit le chargement et l’utilisation de la configuration bot3. La référence d’API détaillée reste `kb-config/USAGE.md`.
|
||||
Ce guide décrit le chargement et l’utilisation de la configuration bot3. La référence d’API détaillée reste `ks-config/USAGE.md`.
|
||||
|
||||
## Fichiers actifs
|
||||
|
||||
@@ -28,21 +28,21 @@ Le format actif est JSON. Le futur split de configuration prévu en `0.5.x` ne m
|
||||
## Exemple opérateur
|
||||
|
||||
```rust
|
||||
let environment = match kb_config::load_workspace_environment(
|
||||
let environment = match ks_config::load_workspace_environment(
|
||||
std::path::Path::new("."),
|
||||
) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
|
||||
let config = match kb_config::load_config_from_path(
|
||||
let config = match ks_config::load_config_from_path(
|
||||
std::path::Path::new("config/example.config.json"),
|
||||
) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
|
||||
let profile = match kb_config::active_profile(&config) {
|
||||
let profile = match ks_config::active_profile(&config) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
@@ -83,8 +83,8 @@ Pour isoler une erreur :
|
||||
|
||||
## Références
|
||||
|
||||
- `kb-config/README.md` ;
|
||||
- `kb-config/USAGE.md` ;
|
||||
- `kb-config/TODO.md` ;
|
||||
- `ks-config/README.md` ;
|
||||
- `ks-config/USAGE.md` ;
|
||||
- `ks-config/TODO.md` ;
|
||||
- `config/README.md` ;
|
||||
- `docs/decisions/WINCODE_COMPATIBILITY_POLICY.md`.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/guides/DEVNET_VALIDATION.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Guide de validation Devnet
|
||||
|
||||
@@ -33,7 +33,7 @@ Le rapport doit indiquer précisément les niveaux réellement exécutés.
|
||||
|
||||
## Commandes
|
||||
|
||||
Les scénarios peuvent être déclenchés depuis `kb-pipeline-demo-scenarios` ou le desktop. La validation frontend se fait uniquement avec :
|
||||
Les scénarios peuvent être déclenchés depuis `ks-pipeline-demo-scenarios` ou le desktop. La validation frontend se fait uniquement avec :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
@@ -61,12 +61,12 @@ Le registre ElGamal ne doit pas être déclaré validé sur Devnet ou Mainnet sa
|
||||
|
||||
- `docs/validation/V0_4_7_METAPLEX_TOKEN_METADATA_VALIDATION_REPORT.md` ;
|
||||
- `docs/DEVNET_EXECUTION_GUIDE.md` ;
|
||||
- `kb-pipeline-demo-scenarios/USAGE.md` ;
|
||||
- `ks-pipeline-demo-scenarios/USAGE.md` ;
|
||||
- `kb-app-demo-desktop/USAGE.md`.
|
||||
|
||||
## Metaplex Token Metadata
|
||||
|
||||
Les scénarios Metadata utilisent un profil Devnet existant, le runner de `kb-pipeline-demo-scenarios` et le panneau `demo_execution_metadata`. Les PDA dérivables ne doivent pas être saisis manuellement. Chaque parcours prépare sa fixture et dérive automatiquement les PDA et comptes de postcondition nécessaires à l’étape courante.
|
||||
Les scénarios Metadata utilisent un profil Devnet existant, le runner de `ks-pipeline-demo-scenarios` et le panneau `demo_execution_metadata`. Les PDA dérivables ne doivent pas être saisis manuellement. Chaque parcours prépare sa fixture et dérive automatiquement les PDA et comptes de postcondition nécessaires à l’étape courante.
|
||||
|
||||
Une liste de profils vide est une erreur de configuration ou de raccordement et doit être signalée explicitement. Une validation réseau exige une simulation RPC réelle ; une soumission exige en plus confirmation opérateur, signature, confirmation et postconditions observées.
|
||||
|
||||
|
||||
@@ -1,28 +1,28 @@
|
||||
<!-- file: docs/guides/LOGGING.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Guide de logging et tracing
|
||||
|
||||
## Objectif
|
||||
|
||||
`kb-logging` initialise les routes de tracing définies par la configuration et conserve les guards nécessaires à leur durée de vie.
|
||||
`ks-logging` initialise les routes de tracing définies par la configuration et conserve les guards nécessaires à leur durée de vie.
|
||||
|
||||
## Flux de démarrage
|
||||
|
||||
1. charger et valider la configuration avec `kb-config` ;
|
||||
1. charger et valider la configuration avec `ks-config` ;
|
||||
2. construire `LoggingConfig` ;
|
||||
3. appeler `kb_logging::init_logging` une seule fois ;
|
||||
3. appeler `ks_logging::init_logging` une seule fois ;
|
||||
4. conserver `LoggingGuard` jusqu’à la fermeture du processus ;
|
||||
5. émettre les événements avec des targets canoniques.
|
||||
|
||||
```rust
|
||||
let guard = match kb_logging::init_logging(&config.logging) {
|
||||
let guard = match ks_logging::init_logging(&config.logging) {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
|
||||
tracing::info!(
|
||||
target: kb_logging::tracing_target(),
|
||||
target: ks_logging::tracing_target(),
|
||||
routes = guard.route_count(),
|
||||
"logging initialized"
|
||||
);
|
||||
@@ -46,9 +46,9 @@ Les routes fichier ne doivent jamais écrire de secrets ou de keypairs.
|
||||
Les targets suivent les conventions du workspace, par exemple :
|
||||
|
||||
```text
|
||||
kb-pipeline.backfill
|
||||
kb-pipeline.decode-replay
|
||||
kb-onchain-transport.http
|
||||
ks-pipeline.backfill
|
||||
ks-pipeline.decode-replay
|
||||
ks-onchain-transport.http
|
||||
kb-lib.executor.spl.token-2022
|
||||
kb-lib.materializer.compliance.audit
|
||||
kb-lib.materializer.token.accounts
|
||||
@@ -73,7 +73,7 @@ Les fenêtres Tauri utilisent la permission tracing prévue par leurs capabiliti
|
||||
|
||||
## Références
|
||||
|
||||
- `kb-logging/README.md` ;
|
||||
- `kb-logging/USAGE.md` ;
|
||||
- `kb-config/USAGE.md` ;
|
||||
- `ks-logging/README.md` ;
|
||||
- `ks-logging/USAGE.md` ;
|
||||
- `ks-config/USAGE.md` ;
|
||||
- `docs/architecture/ARCHITECTURE.md`.
|
||||
|
||||
@@ -1,16 +1,16 @@
|
||||
<!-- file: docs/guides/POSTGRES_STORAGE.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Guide PostgreSQL et contrats de stockage
|
||||
|
||||
## Objectif
|
||||
|
||||
`kb-store` consolide les contrats de stockage Core, raw, decode et PostgreSQL de bot2 dans une crate unique.
|
||||
`ks-store` consolide les contrats de stockage Core, raw, decode et PostgreSQL de bot2 dans une crate unique.
|
||||
|
||||
## Connexion
|
||||
|
||||
```rust
|
||||
let options = match kb_store::PostgresStoreOptions::new(
|
||||
let options = match ks_store::PostgresStoreOptions::new(
|
||||
database_url,
|
||||
10,
|
||||
10_000,
|
||||
@@ -20,7 +20,7 @@ let options = match kb_store::PostgresStoreOptions::new(
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
|
||||
let store = match kb_store::PostgresStore::connect(options).await {
|
||||
let store = match ks_store::PostgresStore::connect(options).await {
|
||||
std::result::Result::Ok(value) => value,
|
||||
std::result::Result::Err(error) => return std::result::Result::Err(error),
|
||||
};
|
||||
@@ -62,5 +62,5 @@ Les traits publics séparent le contrat de l’implémentation PostgreSQL. Les o
|
||||
## Références
|
||||
|
||||
- `docs/architecture/STORAGE_ARCHITECTURE.md` ;
|
||||
- `kb-store/USAGE.md` ;
|
||||
- `kb-store/README.md`.
|
||||
- `ks-store/USAGE.md` ;
|
||||
- `ks-store/README.md`.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/guides/REPLAY_CORE_EXTRACTION_AND_MATERIALIZATION.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Guide extraction Core, replay et matérialisation
|
||||
|
||||
@@ -24,7 +24,7 @@ matérialisation optionnelle
|
||||
L’extraction transforme une transaction canonique persistée en entités Core normalisées. Elle doit conserver les index, comptes, Program IDs, succès ou échec de transaction et contexte nécessaire aux instructions internes.
|
||||
|
||||
```rust
|
||||
let summary = match kb_pipeline::execute_core_extraction(
|
||||
let summary = match ks_pipeline::execute_core_extraction(
|
||||
request,
|
||||
observer,
|
||||
).await {
|
||||
@@ -72,6 +72,6 @@ La progression persistée ne doit avancer qu’après clôture cohérente du can
|
||||
|
||||
- `docs/architecture/PIPELINE_ARCHITECTURE.md` ;
|
||||
- `docs/architecture/STORAGE_ARCHITECTURE.md` ;
|
||||
- `kb-pipeline/USAGE.md` ;
|
||||
- `kb-lib/USAGE.md` ;
|
||||
- `kb-store/USAGE.md`.
|
||||
- `ks-pipeline/USAGE.md` ;
|
||||
- `ks-lib/USAGE.md` ;
|
||||
- `ks-store/USAGE.md`.
|
||||
|
||||
@@ -1,26 +1,26 @@
|
||||
<!-- file: docs/guides/RPC_BACKFILL_AND_WEBSOCKET.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Guide RPC, backfill et WebSocket
|
||||
|
||||
## Séparation des responsabilités
|
||||
|
||||
- `kb-onchain-transport` communique avec les endpoints ;
|
||||
- `kb-pipeline` orchestre les campagnes ;
|
||||
- `kb-store` persiste les acquisitions canoniques et la progression ;
|
||||
- `ks-onchain-transport` communique avec les endpoints ;
|
||||
- `ks-pipeline` orchestre les campagnes ;
|
||||
- `ks-store` persiste les acquisitions canoniques et la progression ;
|
||||
- `kb-app-demo-desktop` fournit une interface opérateur ;
|
||||
- `kb-pipeline-demo-scenarios` construit et exécute les scénarios réutilisables de démonstration et de validation, notamment sur Devnet.
|
||||
- `ks-pipeline-demo-scenarios` construit et exécute les scénarios réutilisables de démonstration et de validation, notamment sur Devnet.
|
||||
|
||||
## Passage d’un scénario validé vers le pipeline
|
||||
|
||||
`kb-pipeline-demo-scenarios` n’est pas la destination finale d’une logique réutilisable en production. Son rôle est de composer des APIs publiques existantes, préparer les fixtures, imposer les garde-fous opérateur et démontrer un parcours complet sur un réseau de validation.
|
||||
`ks-pipeline-demo-scenarios` n’est pas la destination finale d’une logique réutilisable en production. Son rôle est de composer des APIs publiques existantes, préparer les fixtures, imposer les garde-fous opérateur et démontrer un parcours complet sur un réseau de validation.
|
||||
|
||||
Lorsqu’un composant d’un scénario est validé et qu’il est générique, déterministe et utilisable indépendamment de la démonstration, il doit résider dans la couche appropriée :
|
||||
|
||||
- `kb-lib` pour le décodage, la matérialisation, la construction d’instructions, les préflights et les politiques de sécurité ;
|
||||
- `kb-onchain-transport` pour les opérations réseau génériques ;
|
||||
- `kb-store` pour les contrats de persistance ;
|
||||
- `kb-pipeline` pour l’orchestration réutilisable, y compris sur Mainnet lorsque le profil, la politique et l’appelant l’autorisent.
|
||||
- `ks-lib` pour le décodage, la matérialisation, la construction d’instructions, les préflights et les politiques de sécurité ;
|
||||
- `ks-onchain-transport` pour les opérations réseau génériques ;
|
||||
- `ks-store` pour les contrats de persistance ;
|
||||
- `ks-pipeline` pour l’orchestration réutilisable, y compris sur Mainnet lorsque le profil, la politique et l’appelant l’autorisent.
|
||||
|
||||
La crate de scénarios conserve :
|
||||
|
||||
@@ -49,7 +49,7 @@ Avant une campagne :
|
||||
Le backfill parcourt les signatures, charge les transactions et les adapte vers le contrat canonique avant stockage.
|
||||
|
||||
```rust
|
||||
let summary = match kb_pipeline::execute_http_backfill(
|
||||
let summary = match ks_pipeline::execute_http_backfill(
|
||||
request,
|
||||
observer,
|
||||
).await {
|
||||
@@ -96,6 +96,6 @@ Distinguer :
|
||||
|
||||
## Références
|
||||
|
||||
- `kb-onchain-transport/USAGE.md` ;
|
||||
- `kb-pipeline/USAGE.md` ;
|
||||
- `ks-onchain-transport/USAGE.md` ;
|
||||
- `ks-pipeline/USAGE.md` ;
|
||||
- `kb-app-demo-desktop/USAGE.md`.
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
<!-- file: docs/plans/V0_5_1_KHADHROONY_SOLANA_NAMESPACE_AND_CONFIG_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Plan temporaire `0.5.1` — namespace Khadhroony Solana et configuration sûre
|
||||
|
||||
## 1. Statut et règle de cette prerelease
|
||||
|
||||
Ce document est le plan temporaire de `0.5.1`. `0.5.1-pre.001` reste exclusivement consacrée à l'inventaire, aux contrats de migration et au découpage des prereleases. Aucun répertoire de crate n'est renommé dans `pre.001` et aucun comportement runtime n'est restructuré.
|
||||
Ce document est le plan temporaire de `0.5.1`. `0.5.1-pre.001` a fermé l'inventaire et les contrats de migration. `0.5.1-pre.002` réalise le premier changement structurel : les dix crates Solana généralistes, leurs packages, identifiants Rust, chemins de workspace, tests externes, scripts et CLI migrent vers `ks-*` / `ks_*`. `kb-app-demo-desktop` et le workspace racine restent nommés comme avant.
|
||||
|
||||
La base `0.5.0-pre.004` a été validée par `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --all-targets`, `python3 scripts/audit_rust_workspace_rules.py` et `cargo test --workspace`. Les tests d'API externe passent également.
|
||||
La base `0.5.0-pre.004` puis `0.5.1-pre.001` ont été validées par `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --all-targets`, `python3 scripts/audit_rust_workspace_rules.py` et `cargo test --workspace`. Les tests d'API externe passent également. Les validations de `pre.002` doivent être rejouées après application du delta, car les noms de packages et de crates constituent une frontière de compilation réelle.
|
||||
|
||||
## 2. Invariant du workspace racine
|
||||
|
||||
@@ -32,18 +32,18 @@ Les bibliothèques internes Solana migrent vers `ks-*` / `ks_*` et leurs variabl
|
||||
|
||||
## 4. Inventaire des crates et ordre de migration
|
||||
|
||||
| Package actuel | Identifiant Rust actuel | Package cible | Identifiant Rust cible | Dépendances workspace directes actuelles | Ordre |
|
||||
|------------------------------|------------------------------|------------------------------|------------------------------|----------------------------------------------------------------------------------------------------|------:|
|
||||
| `kb-core` | `kb_core` | `ks-core` | `ks_core` | — | 1 |
|
||||
| `kb-program-ids` | `kb_program_ids` | `ks-program-ids` | `ks_program_ids` | — | 2 |
|
||||
| `kb-config` | `kb_config` | `ks-config` | `ks_config` | kb-core | 3 |
|
||||
| `kb-logging` | `kb_logging` | `ks-logging` | `ks_logging` | kb-core | 4 |
|
||||
| `kb-wallet` | `kb_wallet` | `ks-wallet` | `ks_wallet` | kb-core | 5 |
|
||||
| `kb-lib` | `kb_lib` | `ks-lib` | `ks_lib` | kb-core, kb-program-ids | 6 |
|
||||
| `kb-onchain-transport` | `kb_onchain_transport` | `ks-onchain-transport` | `ks_onchain_transport` | kb-config, kb-core, kb-lib | 7 |
|
||||
| `kb-store` | `kb_store` | `ks-store` | `ks_store` | kb-core, kb-lib | 8 |
|
||||
| `kb-pipeline` | `kb_pipeline` | `ks-pipeline` | `ks_pipeline` | kb-core, kb-config, kb-lib, kb-onchain-transport, kb-program-ids, kb-store | 9 |
|
||||
| `kb-pipeline-demo-scenarios` | `kb_pipeline_demo_scenarios` | `ks-pipeline-demo-scenarios` | `ks_pipeline_demo_scenarios` | kb-core, kb-config, kb-lib, kb-onchain-transport, kb-pipeline, kb-program-ids, kb-store, kb-wallet | 10 |
|
||||
| Package actuel | Identifiant Rust actuel | Package cible | Identifiant Rust cible | Dépendances workspace directes actuelles | Ordre |
|
||||
|---|---|---|---|---|---:|
|
||||
| `kb-core` | `kb_core` | `ks-core` | `ks_core` | — | 1 |
|
||||
| `kb-program-ids` | `kb_program_ids` | `ks-program-ids` | `ks_program_ids` | — | 2 |
|
||||
| `kb-config` | `kb_config` | `ks-config` | `ks_config` | kb-core | 3 |
|
||||
| `kb-logging` | `kb_logging` | `ks-logging` | `ks_logging` | kb-core | 4 |
|
||||
| `kb-wallet` | `kb_wallet` | `ks-wallet` | `ks_wallet` | kb-core | 5 |
|
||||
| `kb-lib` | `kb_lib` | `ks-lib` | `ks_lib` | kb-core, kb-program-ids | 6 |
|
||||
| `kb-onchain-transport` | `kb_onchain_transport` | `ks-onchain-transport` | `ks_onchain_transport` | kb-config, kb-core, kb-lib | 7 |
|
||||
| `kb-store` | `kb_store` | `ks-store` | `ks_store` | kb-core, kb-lib | 8 |
|
||||
| `kb-pipeline` | `kb_pipeline` | `ks-pipeline` | `ks_pipeline` | kb-core, kb-config, kb-lib, kb-onchain-transport, kb-program-ids, kb-store | 9 |
|
||||
| `kb-pipeline-demo-scenarios` | `kb_pipeline_demo_scenarios` | `ks-pipeline-demo-scenarios` | `ks_pipeline_demo_scenarios` | kb-core, kb-config, kb-lib, kb-onchain-transport, kb-pipeline, kb-program-ids, kb-store, kb-wallet | 10 |
|
||||
|
||||
`kb-app-demo-desktop` est adapté en dernier, mais garde son package, son répertoire et ses identifiants applicatifs.
|
||||
|
||||
@@ -58,18 +58,18 @@ bin : kb-pipeline-demo-scenarios-cli -> ks-pipeline-demo-scenarios-cli
|
||||
|
||||
Les valeurs suivantes sont des métriques d'orientation sur les fichiers actifs, hors archives et artefacts générés. Elles montrent qu'un renommage massif en une seule opération serait difficile à diagnostiquer.
|
||||
|
||||
| Crate | Références package / fichiers | Références identifiant Rust / fichiers |
|
||||
|------------------------------|------------------------------:|---------------------------------------:|
|
||||
| `kb-core` | 51 / 32 | 3165 / 407 |
|
||||
| `kb-config` | 56 / 33 | 201 / 44 |
|
||||
| `kb-lib` | 3145 / 550 | 2785 / 97 |
|
||||
| `kb-logging` | 72 / 27 | 22 / 3 |
|
||||
| `kb-program-ids` | 42 / 28 | 1413 / 334 |
|
||||
| `kb-pipeline` | 287 / 112 | 436 / 38 |
|
||||
| `kb-pipeline-demo-scenarios` | 145 / 75 | 173 / 18 |
|
||||
| `kb-onchain-transport` | 125 / 56 | 530 / 50 |
|
||||
| `kb-store` | 157 / 81 | 344 / 30 |
|
||||
| `kb-wallet` | 75 / 30 | 53 / 17 |
|
||||
| Crate | Références package / fichiers | Références identifiant Rust / fichiers |
|
||||
|---|---:|---:|
|
||||
| `kb-core` | 51 / 32 | 3165 / 407 |
|
||||
| `kb-config` | 56 / 33 | 201 / 44 |
|
||||
| `kb-lib` | 3145 / 550 | 2785 / 97 |
|
||||
| `kb-logging` | 72 / 27 | 22 / 3 |
|
||||
| `kb-program-ids` | 42 / 28 | 1413 / 334 |
|
||||
| `kb-pipeline` | 287 / 112 | 436 / 38 |
|
||||
| `kb-pipeline-demo-scenarios` | 145 / 75 | 173 / 18 |
|
||||
| `kb-onchain-transport` | 125 / 56 | 530 / 50 |
|
||||
| `kb-store` | 157 / 81 | 344 / 30 |
|
||||
| `kb-wallet` | 75 / 30 | 53 / 17 |
|
||||
|
||||
Le volume `kb-lib` inclut notamment les identités techniques `kb-lib.*`; il ne doit pas être interprété comme autant d'importations Cargo.
|
||||
|
||||
@@ -143,264 +143,264 @@ Les targets de tracing de crates génériques doivent également migrer vers `ks
|
||||
|
||||
### 6.1 Inventaire exhaustif des identités `kb-lib.*`
|
||||
|
||||
| Identité actuelle | Identité cible |
|
||||
|----------------------------------------------------------------|----------------------------------------------------------------|
|
||||
| `kb-lib.decoder.adapter.saber_decimal_wrapper` | `ks-lib-decoder.adapter.saber_decimal_wrapper` |
|
||||
| `kb-lib.decoder.adapter.spl_token_wrap` | `ks-lib-decoder.adapter.spl_token_wrap` |
|
||||
| `kb-lib.decoder.admin.jupiter_lock` | `ks-lib-decoder.admin.jupiter_lock` |
|
||||
| `kb-lib.decoder.admin.pump_fees` | `ks-lib-decoder.admin.pump_fees` |
|
||||
| `kb-lib.decoder.amm.aldrin_v1` | `ks-lib-decoder.amm.aldrin_v1` |
|
||||
| `kb-lib.decoder.amm.aldrin_v2` | `ks-lib-decoder.amm.aldrin_v2` |
|
||||
| `kb-lib.decoder.amm.alphaq` | `ks-lib-decoder.amm.alphaq` |
|
||||
| `kb-lib.decoder.amm.believe` | `ks-lib-decoder.amm.believe` |
|
||||
| `kb-lib.decoder.amm.bonk_swap` | `ks-lib-decoder.amm.bonk_swap` |
|
||||
| `kb-lib.decoder.amm.fluxbeam` | `ks-lib-decoder.amm.fluxbeam` |
|
||||
| `kb-lib.decoder.amm.goon_fi` | `ks-lib-decoder.amm.goon_fi` |
|
||||
| `kb-lib.decoder.amm.goosefx_gamma` | `ks-lib-decoder.amm.goosefx_gamma` |
|
||||
| `kb-lib.decoder.amm.goosefx_v2` | `ks-lib-decoder.amm.goosefx_v2` |
|
||||
| `kb-lib.decoder.amm.guac_swap` | `ks-lib-decoder.amm.guac_swap` |
|
||||
| `kb-lib.decoder.amm.lifinity_swap_v2` | `ks-lib-decoder.amm.lifinity_swap_v2` |
|
||||
| `kb-lib.decoder.amm.metadao_futarchy_amm` | `ks-lib-decoder.amm.metadao_futarchy_amm` |
|
||||
| `kb-lib.decoder.amm.metadao_v0_5` | `ks-lib-decoder.amm.metadao_v0_5` |
|
||||
| `kb-lib.decoder.amm.meteora_damm_v1` | `ks-lib-decoder.amm.meteora_damm_v1` |
|
||||
| `kb-lib.decoder.amm.meteora_damm_v2` | `ks-lib-decoder.amm.meteora_damm_v2` |
|
||||
| `kb-lib.decoder.amm.obric_v2` | `ks-lib-decoder.amm.obric_v2` |
|
||||
| `kb-lib.decoder.amm.one_dex` | `ks-lib-decoder.amm.one_dex` |
|
||||
| `kb-lib.decoder.amm.pump_swap` | `ks-lib-decoder.amm.pump_swap` |
|
||||
| `kb-lib.decoder.amm.raydium_lp_v4` | `ks-lib-decoder.amm.raydium_lp_v4` |
|
||||
| `kb-lib.decoder.amm.solfi` | `ks-lib-decoder.amm.solfi` |
|
||||
| `kb-lib.decoder.amm.solfi_v2` | `ks-lib-decoder.amm.solfi_v2` |
|
||||
| `kb-lib.decoder.amm.vertigo` | `ks-lib-decoder.amm.vertigo` |
|
||||
| `kb-lib.decoder.amm.virtuals` | `ks-lib-decoder.amm.virtuals` |
|
||||
| `kb-lib.decoder.amm.woofi` | `ks-lib-decoder.amm.woofi` |
|
||||
| `kb-lib.decoder.amm.zero_fi` | `ks-lib-decoder.amm.zero_fi` |
|
||||
| `kb-lib.decoder.amm.zora` | `ks-lib-decoder.amm.zora` |
|
||||
| `kb-lib.decoder.anchor` | `ks-lib-decoder.anchor` |
|
||||
| `kb-lib.decoder.api` | `ks-lib-decoder.api` |
|
||||
| `kb-lib.decoder.bridge.circle_cctp_token_messenger_minter` | `ks-lib-decoder.bridge.circle_cctp_token_messenger_minter` |
|
||||
| `kb-lib.decoder.bridge.circle_cctp_token_messenger_minter_v2` | `ks-lib-decoder.bridge.circle_cctp_token_messenger_minter_v2` |
|
||||
| `kb-lib.decoder.bridge.layer_zero_endpoint` | `ks-lib-decoder.bridge.layer_zero_endpoint` |
|
||||
| `kb-lib.decoder.bridge.layer_zero_executor` | `ks-lib-decoder.bridge.layer_zero_executor` |
|
||||
| `kb-lib.decoder.clmm.byreal` | `ks-lib-decoder.clmm.byreal` |
|
||||
| `kb-lib.decoder.clmm.fusion` | `ks-lib-decoder.clmm.fusion` |
|
||||
| `kb-lib.decoder.clmm.orca_whirlpool` | `ks-lib-decoder.clmm.orca_whirlpool` |
|
||||
| `kb-lib.decoder.clmm.pancake_swap` | `ks-lib-decoder.clmm.pancake_swap` |
|
||||
| `kb-lib.decoder.clmm.raydium` | `ks-lib-decoder.clmm.raydium` |
|
||||
| `kb-lib.decoder.clmm.stabble` | `ks-lib-decoder.clmm.stabble` |
|
||||
| `kb-lib.decoder.cpmm.raydium` | `ks-lib-decoder.cpmm.raydium` |
|
||||
| `kb-lib.decoder.dlmm.meteora` | `ks-lib-decoder.dlmm.meteora` |
|
||||
| `kb-lib.decoder.fees.bags_fee_share_v1` | `ks-lib-decoder.fees.bags_fee_share_v1` |
|
||||
| `kb-lib.decoder.fees.bags_fee_share_v2` | `ks-lib-decoder.fees.bags_fee_share_v2` |
|
||||
| `kb-lib.decoder.fees.pump_fees` | `ks-lib-decoder.fees.pump_fees` |
|
||||
| `kb-lib.decoder.governance.metadao_bid_wall` | `ks-lib-decoder.governance.metadao_bid_wall` |
|
||||
| `kb-lib.decoder.governance.metadao_futarchy` | `ks-lib-decoder.governance.metadao_futarchy` |
|
||||
| `kb-lib.decoder.governance.squads_multisig` | `ks-lib-decoder.governance.squads_multisig` |
|
||||
| `kb-lib.decoder.launchpad.boop_fun` | `ks-lib-decoder.launchpad.boop_fun` |
|
||||
| `kb-lib.decoder.launchpad.metadao_ico` | `ks-lib-decoder.launchpad.metadao_ico` |
|
||||
| `kb-lib.decoder.launchpad.meteora_dbc` | `ks-lib-decoder.launchpad.meteora_dbc` |
|
||||
| `kb-lib.decoder.launchpad.moonit` | `ks-lib-decoder.launchpad.moonit` |
|
||||
| `kb-lib.decoder.launchpad.orca_wavebreak` | `ks-lib-decoder.launchpad.orca_wavebreak` |
|
||||
| `kb-lib.decoder.launchpad.printr` | `ks-lib-decoder.launchpad.printr` |
|
||||
| `kb-lib.decoder.launchpad.pump_fun` | `ks-lib-decoder.launchpad.pump_fun` |
|
||||
| `kb-lib.decoder.launchpad.pump_pumpup_ai` | `ks-lib-decoder.launchpad.pump_pumpup_ai` |
|
||||
| `kb-lib.decoder.launchpad.raydium_launchlab` | `ks-lib-decoder.launchpad.raydium_launchlab` |
|
||||
| `kb-lib.decoder.launchpad.virtuals` | `ks-lib-decoder.launchpad.virtuals` |
|
||||
| `kb-lib.decoder.lending.clone` | `ks-lib-decoder.lending.clone` |
|
||||
| `kb-lib.decoder.lending.jupiter_lend_borrow` | `ks-lib-decoder.lending.jupiter_lend_borrow` |
|
||||
| `kb-lib.decoder.lending.jupiter_lend_earn` | `ks-lib-decoder.lending.jupiter_lend_earn` |
|
||||
| `kb-lib.decoder.lending.jupiter_lend_flash_loan` | `ks-lib-decoder.lending.jupiter_lend_flash_loan` |
|
||||
| `kb-lib.decoder.lending.jupiter_lend_liquidity` | `ks-lib-decoder.lending.jupiter_lend_liquidity` |
|
||||
| `kb-lib.decoder.lending.kamino` | `ks-lib-decoder.lending.kamino` |
|
||||
| `kb-lib.decoder.lending.marginfi_v2` | `ks-lib-decoder.lending.marginfi_v2` |
|
||||
| `kb-lib.decoder.lock.raydium_lp` | `ks-lib-decoder.lock.raydium_lp` |
|
||||
| `kb-lib.decoder.metadata.metaplex_token_metadata` | `ks-lib-decoder.metadata.metaplex_token_metadata` |
|
||||
| `kb-lib.decoder.metadata.solana_program_metadata` | `ks-lib-decoder.metadata.solana_program_metadata` |
|
||||
| `kb-lib.decoder.metadata.spl_name_service` | `ks-lib-decoder.metadata.spl_name_service` |
|
||||
| `kb-lib.decoder.nft.metaplex_bubblegum` | `ks-lib-decoder.nft.metaplex_bubblegum` |
|
||||
| `kb-lib.decoder.nft.tensor_cnft` | `ks-lib-decoder.nft.tensor_cnft` |
|
||||
| `kb-lib.decoder.orderbook.jupiter_limit_order` | `ks-lib-decoder.orderbook.jupiter_limit_order` |
|
||||
| `kb-lib.decoder.orderbook.jupiter_limit_order_v2` | `ks-lib-decoder.orderbook.jupiter_limit_order_v2` |
|
||||
| `kb-lib.decoder.orderbook.openbook_v2` | `ks-lib-decoder.orderbook.openbook_v2` |
|
||||
| `kb-lib.decoder.perpetuals.drift_v2` | `ks-lib-decoder.perpetuals.drift_v2` |
|
||||
| `kb-lib.decoder.perpetuals.jupiter` | `ks-lib-decoder.perpetuals.jupiter` |
|
||||
| `kb-lib.decoder.perpetuals.phoenix_eternal` | `ks-lib-decoder.perpetuals.phoenix_eternal` |
|
||||
| `kb-lib.decoder.perpetuals.zeta` | `ks-lib-decoder.perpetuals.zeta` |
|
||||
| `kb-lib.decoder.router.dflow_aggregator_v4` | `ks-lib-decoder.router.dflow_aggregator_v4` |
|
||||
| `kb-lib.decoder.router.jupiter_aggregator_v4` | `ks-lib-decoder.router.jupiter_aggregator_v4` |
|
||||
| `kb-lib.decoder.router.jupiter_aggregator_v6` | `ks-lib-decoder.router.jupiter_aggregator_v6` |
|
||||
| `kb-lib.decoder.router.jupiter_dca` | `ks-lib-decoder.router.jupiter_dca` |
|
||||
| `kb-lib.decoder.router.okx_labs_v1` | `ks-lib-decoder.router.okx_labs_v1` |
|
||||
| `kb-lib.decoder.router.okx_labs_v2` | `ks-lib-decoder.router.okx_labs_v2` |
|
||||
| `kb-lib.decoder.rwa.ondo_global_markets` | `ks-lib-decoder.rwa.ondo_global_markets` |
|
||||
| `kb-lib.decoder.solana.core` | `ks-lib-decoder.solana.core` |
|
||||
| `kb-lib.decoder.spl.account_compression` | `ks-lib-decoder.spl.account_compression` |
|
||||
| `kb-lib.decoder.spl.associated_token_account` | `ks-lib-decoder.spl.associated_token_account` |
|
||||
| `kb-lib.decoder.spl.elgamal_registry` | `ks-lib-decoder.spl.elgamal_registry` |
|
||||
| `kb-lib.decoder.spl.memo` | `ks-lib-decoder.spl.memo` |
|
||||
| `kb-lib.decoder.spl.noop` | `ks-lib-decoder.spl.noop` |
|
||||
| `kb-lib.decoder.spl.single_pool` | `ks-lib-decoder.spl.single_pool` |
|
||||
| `kb-lib.decoder.spl.stake_pool` | `ks-lib-decoder.spl.stake_pool` |
|
||||
| `kb-lib.decoder.spl.token` | `ks-lib-decoder.spl.token` |
|
||||
| `kb-lib.decoder.spl.token_2022` | `ks-lib-decoder.spl.token_2022` |
|
||||
| `kb-lib.decoder.stable.swap_hylo_exchange` | `ks-lib-decoder.stable.swap_hylo_exchange` |
|
||||
| `kb-lib.decoder.stable.swap_jupiter_stable` | `ks-lib-decoder.stable.swap_jupiter_stable` |
|
||||
| `kb-lib.decoder.stable.swap_numeraire` | `ks-lib-decoder.stable.swap_numeraire` |
|
||||
| `kb-lib.decoder.stable.swap_stabble` | `ks-lib-decoder.stable.swap_stabble` |
|
||||
| `kb-lib.decoder.staking.jito_tip_distribution` | `ks-lib-decoder.staking.jito_tip_distribution` |
|
||||
| `kb-lib.decoder.staking.kamino_farm` | `ks-lib-decoder.staking.kamino_farm` |
|
||||
| `kb-lib.decoder.staking.marinade_finance` | `ks-lib-decoder.staking.marinade_finance` |
|
||||
| `kb-lib.decoder.staking.solayer` | `ks-lib-decoder.staking.solayer` |
|
||||
| `kb-lib.decoder.storage.solana_record` | `ks-lib-decoder.storage.solana_record` |
|
||||
| `kb-lib.decoder.strategy.jupiter_dca` | `ks-lib-decoder.strategy.jupiter_dca` |
|
||||
| `kb-lib.decoder.treasury.helium_treasury_management` | `ks-lib-decoder.treasury.helium_treasury_management` |
|
||||
| `kb-lib.decoder.vault.carrot_defi` | `ks-lib-decoder.vault.carrot_defi` |
|
||||
| `kb-lib.decoder.vault.hylo_stability_pool` | `ks-lib-decoder.vault.hylo_stability_pool` |
|
||||
| `kb-lib.decoder.vault.kamino` | `ks-lib-decoder.vault.kamino` |
|
||||
| `kb-lib.decoder.vault.kamino_v2` | `ks-lib-decoder.vault.kamino_v2` |
|
||||
| `kb-lib.decoder.vault.kamino_yvaults` | `ks-lib-decoder.vault.kamino_yvaults` |
|
||||
| `kb-lib.decoder.vault.meteora` | `ks-lib-decoder.vault.meteora` |
|
||||
| `kb-lib.decoder.vesting.jupiter_lock` | `ks-lib-decoder.vesting.jupiter_lock` |
|
||||
| `kb-lib.decoder.vesting.streamflow` | `ks-lib-decoder.vesting.streamflow` |
|
||||
| `kb-lib.decoder.wallet.jupiter_apepro_smart_wallet` | `ks-lib-decoder.wallet.jupiter_apepro_smart_wallet` |
|
||||
| `kb-lib.decoder.weighted.swap_stabble` | `ks-lib-decoder.weighted.swap_stabble` |
|
||||
| `kb-lib.executor.adapter.saber_decimal_wrapper` | `ks-lib-executor.adapter.saber_decimal_wrapper` |
|
||||
| `kb-lib.executor.adapter.spl_token_wrap` | `ks-lib-executor.adapter.spl_token_wrap` |
|
||||
| `kb-lib.executor.amm.aldrin_v1` | `ks-lib-executor.amm.aldrin_v1` |
|
||||
| `kb-lib.executor.amm.aldrin_v2` | `ks-lib-executor.amm.aldrin_v2` |
|
||||
| `kb-lib.executor.amm.alphaq` | `ks-lib-executor.amm.alphaq` |
|
||||
| `kb-lib.executor.amm.believe` | `ks-lib-executor.amm.believe` |
|
||||
| `kb-lib.executor.amm.bonk_swap` | `ks-lib-executor.amm.bonk_swap` |
|
||||
| `kb-lib.executor.amm.fluxbeam` | `ks-lib-executor.amm.fluxbeam` |
|
||||
| `kb-lib.executor.amm.goon_fi` | `ks-lib-executor.amm.goon_fi` |
|
||||
| `kb-lib.executor.amm.goosefx_gamma` | `ks-lib-executor.amm.goosefx_gamma` |
|
||||
| `kb-lib.executor.amm.goosefx_v2` | `ks-lib-executor.amm.goosefx_v2` |
|
||||
| `kb-lib.executor.amm.guac_swap` | `ks-lib-executor.amm.guac_swap` |
|
||||
| `kb-lib.executor.amm.lifinity_swap_v2` | `ks-lib-executor.amm.lifinity_swap_v2` |
|
||||
| `kb-lib.executor.amm.metadao_v0_5` | `ks-lib-executor.amm.metadao_v0_5` |
|
||||
| `kb-lib.executor.amm.meteora_damm_v1` | `ks-lib-executor.amm.meteora_damm_v1` |
|
||||
| `kb-lib.executor.amm.meteora_damm_v2` | `ks-lib-executor.amm.meteora_damm_v2` |
|
||||
| `kb-lib.executor.amm.obric_v2` | `ks-lib-executor.amm.obric_v2` |
|
||||
| `kb-lib.executor.amm.one_dex` | `ks-lib-executor.amm.one_dex` |
|
||||
| `kb-lib.executor.amm.pump_swap` | `ks-lib-executor.amm.pump_swap` |
|
||||
| `kb-lib.executor.amm.raydium_lp_v4` | `ks-lib-executor.amm.raydium_lp_v4` |
|
||||
| `kb-lib.executor.amm.solfi` | `ks-lib-executor.amm.solfi` |
|
||||
| `kb-lib.executor.amm.solfi_v2` | `ks-lib-executor.amm.solfi_v2` |
|
||||
| `kb-lib.executor.amm.vertigo` | `ks-lib-executor.amm.vertigo` |
|
||||
| `kb-lib.executor.amm.woofi` | `ks-lib-executor.amm.woofi` |
|
||||
| `kb-lib.executor.amm.zero_fi` | `ks-lib-executor.amm.zero_fi` |
|
||||
| `kb-lib.executor.amm.zora` | `ks-lib-executor.amm.zora` |
|
||||
| `kb-lib.executor.bridge.circle_cctp_token_messenger_minter` | `ks-lib-executor.bridge.circle_cctp_token_messenger_minter` |
|
||||
| Identité actuelle | Identité cible |
|
||||
|---|---|
|
||||
| `kb-lib.decoder.adapter.saber_decimal_wrapper` | `ks-lib-decoder.adapter.saber_decimal_wrapper` |
|
||||
| `kb-lib.decoder.adapter.spl_token_wrap` | `ks-lib-decoder.adapter.spl_token_wrap` |
|
||||
| `kb-lib.decoder.admin.jupiter_lock` | `ks-lib-decoder.admin.jupiter_lock` |
|
||||
| `kb-lib.decoder.admin.pump_fees` | `ks-lib-decoder.admin.pump_fees` |
|
||||
| `kb-lib.decoder.amm.aldrin_v1` | `ks-lib-decoder.amm.aldrin_v1` |
|
||||
| `kb-lib.decoder.amm.aldrin_v2` | `ks-lib-decoder.amm.aldrin_v2` |
|
||||
| `kb-lib.decoder.amm.alphaq` | `ks-lib-decoder.amm.alphaq` |
|
||||
| `kb-lib.decoder.amm.believe` | `ks-lib-decoder.amm.believe` |
|
||||
| `kb-lib.decoder.amm.bonk_swap` | `ks-lib-decoder.amm.bonk_swap` |
|
||||
| `kb-lib.decoder.amm.fluxbeam` | `ks-lib-decoder.amm.fluxbeam` |
|
||||
| `kb-lib.decoder.amm.goon_fi` | `ks-lib-decoder.amm.goon_fi` |
|
||||
| `kb-lib.decoder.amm.goosefx_gamma` | `ks-lib-decoder.amm.goosefx_gamma` |
|
||||
| `kb-lib.decoder.amm.goosefx_v2` | `ks-lib-decoder.amm.goosefx_v2` |
|
||||
| `kb-lib.decoder.amm.guac_swap` | `ks-lib-decoder.amm.guac_swap` |
|
||||
| `kb-lib.decoder.amm.lifinity_swap_v2` | `ks-lib-decoder.amm.lifinity_swap_v2` |
|
||||
| `kb-lib.decoder.amm.metadao_futarchy_amm` | `ks-lib-decoder.amm.metadao_futarchy_amm` |
|
||||
| `kb-lib.decoder.amm.metadao_v0_5` | `ks-lib-decoder.amm.metadao_v0_5` |
|
||||
| `kb-lib.decoder.amm.meteora_damm_v1` | `ks-lib-decoder.amm.meteora_damm_v1` |
|
||||
| `kb-lib.decoder.amm.meteora_damm_v2` | `ks-lib-decoder.amm.meteora_damm_v2` |
|
||||
| `kb-lib.decoder.amm.obric_v2` | `ks-lib-decoder.amm.obric_v2` |
|
||||
| `kb-lib.decoder.amm.one_dex` | `ks-lib-decoder.amm.one_dex` |
|
||||
| `kb-lib.decoder.amm.pump_swap` | `ks-lib-decoder.amm.pump_swap` |
|
||||
| `kb-lib.decoder.amm.raydium_lp_v4` | `ks-lib-decoder.amm.raydium_lp_v4` |
|
||||
| `kb-lib.decoder.amm.solfi` | `ks-lib-decoder.amm.solfi` |
|
||||
| `kb-lib.decoder.amm.solfi_v2` | `ks-lib-decoder.amm.solfi_v2` |
|
||||
| `kb-lib.decoder.amm.vertigo` | `ks-lib-decoder.amm.vertigo` |
|
||||
| `kb-lib.decoder.amm.virtuals` | `ks-lib-decoder.amm.virtuals` |
|
||||
| `kb-lib.decoder.amm.woofi` | `ks-lib-decoder.amm.woofi` |
|
||||
| `kb-lib.decoder.amm.zero_fi` | `ks-lib-decoder.amm.zero_fi` |
|
||||
| `kb-lib.decoder.amm.zora` | `ks-lib-decoder.amm.zora` |
|
||||
| `kb-lib.decoder.anchor` | `ks-lib-decoder.anchor` |
|
||||
| `kb-lib.decoder.api` | `ks-lib-decoder.api` |
|
||||
| `kb-lib.decoder.bridge.circle_cctp_token_messenger_minter` | `ks-lib-decoder.bridge.circle_cctp_token_messenger_minter` |
|
||||
| `kb-lib.decoder.bridge.circle_cctp_token_messenger_minter_v2` | `ks-lib-decoder.bridge.circle_cctp_token_messenger_minter_v2` |
|
||||
| `kb-lib.decoder.bridge.layer_zero_endpoint` | `ks-lib-decoder.bridge.layer_zero_endpoint` |
|
||||
| `kb-lib.decoder.bridge.layer_zero_executor` | `ks-lib-decoder.bridge.layer_zero_executor` |
|
||||
| `kb-lib.decoder.clmm.byreal` | `ks-lib-decoder.clmm.byreal` |
|
||||
| `kb-lib.decoder.clmm.fusion` | `ks-lib-decoder.clmm.fusion` |
|
||||
| `kb-lib.decoder.clmm.orca_whirlpool` | `ks-lib-decoder.clmm.orca_whirlpool` |
|
||||
| `kb-lib.decoder.clmm.pancake_swap` | `ks-lib-decoder.clmm.pancake_swap` |
|
||||
| `kb-lib.decoder.clmm.raydium` | `ks-lib-decoder.clmm.raydium` |
|
||||
| `kb-lib.decoder.clmm.stabble` | `ks-lib-decoder.clmm.stabble` |
|
||||
| `kb-lib.decoder.cpmm.raydium` | `ks-lib-decoder.cpmm.raydium` |
|
||||
| `kb-lib.decoder.dlmm.meteora` | `ks-lib-decoder.dlmm.meteora` |
|
||||
| `kb-lib.decoder.fees.bags_fee_share_v1` | `ks-lib-decoder.fees.bags_fee_share_v1` |
|
||||
| `kb-lib.decoder.fees.bags_fee_share_v2` | `ks-lib-decoder.fees.bags_fee_share_v2` |
|
||||
| `kb-lib.decoder.fees.pump_fees` | `ks-lib-decoder.fees.pump_fees` |
|
||||
| `kb-lib.decoder.governance.metadao_bid_wall` | `ks-lib-decoder.governance.metadao_bid_wall` |
|
||||
| `kb-lib.decoder.governance.metadao_futarchy` | `ks-lib-decoder.governance.metadao_futarchy` |
|
||||
| `kb-lib.decoder.governance.squads_multisig` | `ks-lib-decoder.governance.squads_multisig` |
|
||||
| `kb-lib.decoder.launchpad.boop_fun` | `ks-lib-decoder.launchpad.boop_fun` |
|
||||
| `kb-lib.decoder.launchpad.metadao_ico` | `ks-lib-decoder.launchpad.metadao_ico` |
|
||||
| `kb-lib.decoder.launchpad.meteora_dbc` | `ks-lib-decoder.launchpad.meteora_dbc` |
|
||||
| `kb-lib.decoder.launchpad.moonit` | `ks-lib-decoder.launchpad.moonit` |
|
||||
| `kb-lib.decoder.launchpad.orca_wavebreak` | `ks-lib-decoder.launchpad.orca_wavebreak` |
|
||||
| `kb-lib.decoder.launchpad.printr` | `ks-lib-decoder.launchpad.printr` |
|
||||
| `kb-lib.decoder.launchpad.pump_fun` | `ks-lib-decoder.launchpad.pump_fun` |
|
||||
| `kb-lib.decoder.launchpad.pump_pumpup_ai` | `ks-lib-decoder.launchpad.pump_pumpup_ai` |
|
||||
| `kb-lib.decoder.launchpad.raydium_launchlab` | `ks-lib-decoder.launchpad.raydium_launchlab` |
|
||||
| `kb-lib.decoder.launchpad.virtuals` | `ks-lib-decoder.launchpad.virtuals` |
|
||||
| `kb-lib.decoder.lending.clone` | `ks-lib-decoder.lending.clone` |
|
||||
| `kb-lib.decoder.lending.jupiter_lend_borrow` | `ks-lib-decoder.lending.jupiter_lend_borrow` |
|
||||
| `kb-lib.decoder.lending.jupiter_lend_earn` | `ks-lib-decoder.lending.jupiter_lend_earn` |
|
||||
| `kb-lib.decoder.lending.jupiter_lend_flash_loan` | `ks-lib-decoder.lending.jupiter_lend_flash_loan` |
|
||||
| `kb-lib.decoder.lending.jupiter_lend_liquidity` | `ks-lib-decoder.lending.jupiter_lend_liquidity` |
|
||||
| `kb-lib.decoder.lending.kamino` | `ks-lib-decoder.lending.kamino` |
|
||||
| `kb-lib.decoder.lending.marginfi_v2` | `ks-lib-decoder.lending.marginfi_v2` |
|
||||
| `kb-lib.decoder.lock.raydium_lp` | `ks-lib-decoder.lock.raydium_lp` |
|
||||
| `kb-lib.decoder.metadata.metaplex_token_metadata` | `ks-lib-decoder.metadata.metaplex_token_metadata` |
|
||||
| `kb-lib.decoder.metadata.solana_program_metadata` | `ks-lib-decoder.metadata.solana_program_metadata` |
|
||||
| `kb-lib.decoder.metadata.spl_name_service` | `ks-lib-decoder.metadata.spl_name_service` |
|
||||
| `kb-lib.decoder.nft.metaplex_bubblegum` | `ks-lib-decoder.nft.metaplex_bubblegum` |
|
||||
| `kb-lib.decoder.nft.tensor_cnft` | `ks-lib-decoder.nft.tensor_cnft` |
|
||||
| `kb-lib.decoder.orderbook.jupiter_limit_order` | `ks-lib-decoder.orderbook.jupiter_limit_order` |
|
||||
| `kb-lib.decoder.orderbook.jupiter_limit_order_v2` | `ks-lib-decoder.orderbook.jupiter_limit_order_v2` |
|
||||
| `kb-lib.decoder.orderbook.openbook_v2` | `ks-lib-decoder.orderbook.openbook_v2` |
|
||||
| `kb-lib.decoder.perpetuals.drift_v2` | `ks-lib-decoder.perpetuals.drift_v2` |
|
||||
| `kb-lib.decoder.perpetuals.jupiter` | `ks-lib-decoder.perpetuals.jupiter` |
|
||||
| `kb-lib.decoder.perpetuals.phoenix_eternal` | `ks-lib-decoder.perpetuals.phoenix_eternal` |
|
||||
| `kb-lib.decoder.perpetuals.zeta` | `ks-lib-decoder.perpetuals.zeta` |
|
||||
| `kb-lib.decoder.router.dflow_aggregator_v4` | `ks-lib-decoder.router.dflow_aggregator_v4` |
|
||||
| `kb-lib.decoder.router.jupiter_aggregator_v4` | `ks-lib-decoder.router.jupiter_aggregator_v4` |
|
||||
| `kb-lib.decoder.router.jupiter_aggregator_v6` | `ks-lib-decoder.router.jupiter_aggregator_v6` |
|
||||
| `kb-lib.decoder.router.jupiter_dca` | `ks-lib-decoder.router.jupiter_dca` |
|
||||
| `kb-lib.decoder.router.okx_labs_v1` | `ks-lib-decoder.router.okx_labs_v1` |
|
||||
| `kb-lib.decoder.router.okx_labs_v2` | `ks-lib-decoder.router.okx_labs_v2` |
|
||||
| `kb-lib.decoder.rwa.ondo_global_markets` | `ks-lib-decoder.rwa.ondo_global_markets` |
|
||||
| `kb-lib.decoder.solana.core` | `ks-lib-decoder.solana.core` |
|
||||
| `kb-lib.decoder.spl.account_compression` | `ks-lib-decoder.spl.account_compression` |
|
||||
| `kb-lib.decoder.spl.associated_token_account` | `ks-lib-decoder.spl.associated_token_account` |
|
||||
| `kb-lib.decoder.spl.elgamal_registry` | `ks-lib-decoder.spl.elgamal_registry` |
|
||||
| `kb-lib.decoder.spl.memo` | `ks-lib-decoder.spl.memo` |
|
||||
| `kb-lib.decoder.spl.noop` | `ks-lib-decoder.spl.noop` |
|
||||
| `kb-lib.decoder.spl.single_pool` | `ks-lib-decoder.spl.single_pool` |
|
||||
| `kb-lib.decoder.spl.stake_pool` | `ks-lib-decoder.spl.stake_pool` |
|
||||
| `kb-lib.decoder.spl.token` | `ks-lib-decoder.spl.token` |
|
||||
| `kb-lib.decoder.spl.token_2022` | `ks-lib-decoder.spl.token_2022` |
|
||||
| `kb-lib.decoder.stable.swap_hylo_exchange` | `ks-lib-decoder.stable.swap_hylo_exchange` |
|
||||
| `kb-lib.decoder.stable.swap_jupiter_stable` | `ks-lib-decoder.stable.swap_jupiter_stable` |
|
||||
| `kb-lib.decoder.stable.swap_numeraire` | `ks-lib-decoder.stable.swap_numeraire` |
|
||||
| `kb-lib.decoder.stable.swap_stabble` | `ks-lib-decoder.stable.swap_stabble` |
|
||||
| `kb-lib.decoder.staking.jito_tip_distribution` | `ks-lib-decoder.staking.jito_tip_distribution` |
|
||||
| `kb-lib.decoder.staking.kamino_farm` | `ks-lib-decoder.staking.kamino_farm` |
|
||||
| `kb-lib.decoder.staking.marinade_finance` | `ks-lib-decoder.staking.marinade_finance` |
|
||||
| `kb-lib.decoder.staking.solayer` | `ks-lib-decoder.staking.solayer` |
|
||||
| `kb-lib.decoder.storage.solana_record` | `ks-lib-decoder.storage.solana_record` |
|
||||
| `kb-lib.decoder.strategy.jupiter_dca` | `ks-lib-decoder.strategy.jupiter_dca` |
|
||||
| `kb-lib.decoder.treasury.helium_treasury_management` | `ks-lib-decoder.treasury.helium_treasury_management` |
|
||||
| `kb-lib.decoder.vault.carrot_defi` | `ks-lib-decoder.vault.carrot_defi` |
|
||||
| `kb-lib.decoder.vault.hylo_stability_pool` | `ks-lib-decoder.vault.hylo_stability_pool` |
|
||||
| `kb-lib.decoder.vault.kamino` | `ks-lib-decoder.vault.kamino` |
|
||||
| `kb-lib.decoder.vault.kamino_v2` | `ks-lib-decoder.vault.kamino_v2` |
|
||||
| `kb-lib.decoder.vault.kamino_yvaults` | `ks-lib-decoder.vault.kamino_yvaults` |
|
||||
| `kb-lib.decoder.vault.meteora` | `ks-lib-decoder.vault.meteora` |
|
||||
| `kb-lib.decoder.vesting.jupiter_lock` | `ks-lib-decoder.vesting.jupiter_lock` |
|
||||
| `kb-lib.decoder.vesting.streamflow` | `ks-lib-decoder.vesting.streamflow` |
|
||||
| `kb-lib.decoder.wallet.jupiter_apepro_smart_wallet` | `ks-lib-decoder.wallet.jupiter_apepro_smart_wallet` |
|
||||
| `kb-lib.decoder.weighted.swap_stabble` | `ks-lib-decoder.weighted.swap_stabble` |
|
||||
| `kb-lib.executor.adapter.saber_decimal_wrapper` | `ks-lib-executor.adapter.saber_decimal_wrapper` |
|
||||
| `kb-lib.executor.adapter.spl_token_wrap` | `ks-lib-executor.adapter.spl_token_wrap` |
|
||||
| `kb-lib.executor.amm.aldrin_v1` | `ks-lib-executor.amm.aldrin_v1` |
|
||||
| `kb-lib.executor.amm.aldrin_v2` | `ks-lib-executor.amm.aldrin_v2` |
|
||||
| `kb-lib.executor.amm.alphaq` | `ks-lib-executor.amm.alphaq` |
|
||||
| `kb-lib.executor.amm.believe` | `ks-lib-executor.amm.believe` |
|
||||
| `kb-lib.executor.amm.bonk_swap` | `ks-lib-executor.amm.bonk_swap` |
|
||||
| `kb-lib.executor.amm.fluxbeam` | `ks-lib-executor.amm.fluxbeam` |
|
||||
| `kb-lib.executor.amm.goon_fi` | `ks-lib-executor.amm.goon_fi` |
|
||||
| `kb-lib.executor.amm.goosefx_gamma` | `ks-lib-executor.amm.goosefx_gamma` |
|
||||
| `kb-lib.executor.amm.goosefx_v2` | `ks-lib-executor.amm.goosefx_v2` |
|
||||
| `kb-lib.executor.amm.guac_swap` | `ks-lib-executor.amm.guac_swap` |
|
||||
| `kb-lib.executor.amm.lifinity_swap_v2` | `ks-lib-executor.amm.lifinity_swap_v2` |
|
||||
| `kb-lib.executor.amm.metadao_v0_5` | `ks-lib-executor.amm.metadao_v0_5` |
|
||||
| `kb-lib.executor.amm.meteora_damm_v1` | `ks-lib-executor.amm.meteora_damm_v1` |
|
||||
| `kb-lib.executor.amm.meteora_damm_v2` | `ks-lib-executor.amm.meteora_damm_v2` |
|
||||
| `kb-lib.executor.amm.obric_v2` | `ks-lib-executor.amm.obric_v2` |
|
||||
| `kb-lib.executor.amm.one_dex` | `ks-lib-executor.amm.one_dex` |
|
||||
| `kb-lib.executor.amm.pump_swap` | `ks-lib-executor.amm.pump_swap` |
|
||||
| `kb-lib.executor.amm.raydium_lp_v4` | `ks-lib-executor.amm.raydium_lp_v4` |
|
||||
| `kb-lib.executor.amm.solfi` | `ks-lib-executor.amm.solfi` |
|
||||
| `kb-lib.executor.amm.solfi_v2` | `ks-lib-executor.amm.solfi_v2` |
|
||||
| `kb-lib.executor.amm.vertigo` | `ks-lib-executor.amm.vertigo` |
|
||||
| `kb-lib.executor.amm.woofi` | `ks-lib-executor.amm.woofi` |
|
||||
| `kb-lib.executor.amm.zero_fi` | `ks-lib-executor.amm.zero_fi` |
|
||||
| `kb-lib.executor.amm.zora` | `ks-lib-executor.amm.zora` |
|
||||
| `kb-lib.executor.bridge.circle_cctp_token_messenger_minter` | `ks-lib-executor.bridge.circle_cctp_token_messenger_minter` |
|
||||
| `kb-lib.executor.bridge.circle_cctp_token_messenger_minter_v2` | `ks-lib-executor.bridge.circle_cctp_token_messenger_minter_v2` |
|
||||
| `kb-lib.executor.bridge.layer_zero_endpoint` | `ks-lib-executor.bridge.layer_zero_endpoint` |
|
||||
| `kb-lib.executor.bridge.layer_zero_executor` | `ks-lib-executor.bridge.layer_zero_executor` |
|
||||
| `kb-lib.executor.clmm.byreal` | `ks-lib-executor.clmm.byreal` |
|
||||
| `kb-lib.executor.clmm.fusion` | `ks-lib-executor.clmm.fusion` |
|
||||
| `kb-lib.executor.clmm.orca_whirlpool` | `ks-lib-executor.clmm.orca_whirlpool` |
|
||||
| `kb-lib.executor.clmm.pancake_swap` | `ks-lib-executor.clmm.pancake_swap` |
|
||||
| `kb-lib.executor.clmm.raydium` | `ks-lib-executor.clmm.raydium` |
|
||||
| `kb-lib.executor.clmm.stabble` | `ks-lib-executor.clmm.stabble` |
|
||||
| `kb-lib.executor.cpmm.raydium` | `ks-lib-executor.cpmm.raydium` |
|
||||
| `kb-lib.executor.dlmm.meteora` | `ks-lib-executor.dlmm.meteora` |
|
||||
| `kb-lib.executor.fees.bags_fee_share_v1` | `ks-lib-executor.fees.bags_fee_share_v1` |
|
||||
| `kb-lib.executor.fees.bags_fee_share_v2` | `ks-lib-executor.fees.bags_fee_share_v2` |
|
||||
| `kb-lib.executor.fees.pump_fees` | `ks-lib-executor.fees.pump_fees` |
|
||||
| `kb-lib.executor.governance.metadao_bid_wall` | `ks-lib-executor.governance.metadao_bid_wall` |
|
||||
| `kb-lib.executor.governance.metadao_futarchy` | `ks-lib-executor.governance.metadao_futarchy` |
|
||||
| `kb-lib.executor.governance.squads_multisig` | `ks-lib-executor.governance.squads_multisig` |
|
||||
| `kb-lib.executor.launchpad.boop_fun` | `ks-lib-executor.launchpad.boop_fun` |
|
||||
| `kb-lib.executor.launchpad.metadao_ico` | `ks-lib-executor.launchpad.metadao_ico` |
|
||||
| `kb-lib.executor.launchpad.meteora_dbc` | `ks-lib-executor.launchpad.meteora_dbc` |
|
||||
| `kb-lib.executor.launchpad.moonit` | `ks-lib-executor.launchpad.moonit` |
|
||||
| `kb-lib.executor.launchpad.orca_wavebreak` | `ks-lib-executor.launchpad.orca_wavebreak` |
|
||||
| `kb-lib.executor.launchpad.printr` | `ks-lib-executor.launchpad.printr` |
|
||||
| `kb-lib.executor.launchpad.pump_fun` | `ks-lib-executor.launchpad.pump_fun` |
|
||||
| `kb-lib.executor.launchpad.pump_pumpup_ai` | `ks-lib-executor.launchpad.pump_pumpup_ai` |
|
||||
| `kb-lib.executor.launchpad.raydium_launchlab` | `ks-lib-executor.launchpad.raydium_launchlab` |
|
||||
| `kb-lib.executor.launchpad.virtuals` | `ks-lib-executor.launchpad.virtuals` |
|
||||
| `kb-lib.executor.lending.clone` | `ks-lib-executor.lending.clone` |
|
||||
| `kb-lib.executor.lending.jupiter_lend_borrow` | `ks-lib-executor.lending.jupiter_lend_borrow` |
|
||||
| `kb-lib.executor.lending.jupiter_lend_earn` | `ks-lib-executor.lending.jupiter_lend_earn` |
|
||||
| `kb-lib.executor.lending.jupiter_lend_flash_loan` | `ks-lib-executor.lending.jupiter_lend_flash_loan` |
|
||||
| `kb-lib.executor.lending.jupiter_lend_liquidity` | `ks-lib-executor.lending.jupiter_lend_liquidity` |
|
||||
| `kb-lib.executor.lending.kamino` | `ks-lib-executor.lending.kamino` |
|
||||
| `kb-lib.executor.lending.marginfi_v2` | `ks-lib-executor.lending.marginfi_v2` |
|
||||
| `kb-lib.executor.lock.raydium_lp` | `ks-lib-executor.lock.raydium_lp` |
|
||||
| `kb-lib.executor.metadata.metaplex_token_metadata` | `ks-lib-executor.metadata.metaplex_token_metadata` |
|
||||
| `kb-lib.executor.metadata.solana_program_metadata` | `ks-lib-executor.metadata.solana_program_metadata` |
|
||||
| `kb-lib.executor.metadata.spl_name_service` | `ks-lib-executor.metadata.spl_name_service` |
|
||||
| `kb-lib.executor.nft.metaplex_bubblegum` | `ks-lib-executor.nft.metaplex_bubblegum` |
|
||||
| `kb-lib.executor.nft.tensor_cnft` | `ks-lib-executor.nft.tensor_cnft` |
|
||||
| `kb-lib.executor.orderbook.jupiter_limit_order` | `ks-lib-executor.orderbook.jupiter_limit_order` |
|
||||
| `kb-lib.executor.orderbook.jupiter_limit_order_v2` | `ks-lib-executor.orderbook.jupiter_limit_order_v2` |
|
||||
| `kb-lib.executor.orderbook.openbook_v2` | `ks-lib-executor.orderbook.openbook_v2` |
|
||||
| `kb-lib.executor.perpetuals.drift_v2` | `ks-lib-executor.perpetuals.drift_v2` |
|
||||
| `kb-lib.executor.perpetuals.jupiter` | `ks-lib-executor.perpetuals.jupiter` |
|
||||
| `kb-lib.executor.perpetuals.phoenix_eternal` | `ks-lib-executor.perpetuals.phoenix_eternal` |
|
||||
| `kb-lib.executor.perpetuals.zeta` | `ks-lib-executor.perpetuals.zeta` |
|
||||
| `kb-lib.executor.router.dflow_aggregator_v4` | `ks-lib-executor.router.dflow_aggregator_v4` |
|
||||
| `kb-lib.executor.router.jupiter_aggregator_v4` | `ks-lib-executor.router.jupiter_aggregator_v4` |
|
||||
| `kb-lib.executor.router.jupiter_aggregator_v6` | `ks-lib-executor.router.jupiter_aggregator_v6` |
|
||||
| `kb-lib.executor.router.okx_labs_v1` | `ks-lib-executor.router.okx_labs_v1` |
|
||||
| `kb-lib.executor.router.okx_labs_v2` | `ks-lib-executor.router.okx_labs_v2` |
|
||||
| `kb-lib.executor.rwa.ondo_global_markets` | `ks-lib-executor.rwa.ondo_global_markets` |
|
||||
| `kb-lib.executor.solana.core` | `ks-lib-executor.solana.core` |
|
||||
| `kb-lib.executor.solana.transaction` | `ks-lib-executor.solana.transaction` |
|
||||
| `kb-lib.executor.spl.account_compression` | `ks-lib-executor.spl.account_compression` |
|
||||
| `kb-lib.executor.spl.associated_token_account` | `ks-lib-executor.spl.associated_token_account` |
|
||||
| `kb-lib.executor.spl.elgamal_registry` | `ks-lib-executor.spl.elgamal_registry` |
|
||||
| `kb-lib.executor.spl.memo` | `ks-lib-executor.spl.memo` |
|
||||
| `kb-lib.executor.spl.noop` | `ks-lib-executor.spl.noop` |
|
||||
| `kb-lib.executor.spl.single_pool` | `ks-lib-executor.spl.single_pool` |
|
||||
| `kb-lib.executor.spl.stake_pool` | `ks-lib-executor.spl.stake_pool` |
|
||||
| `kb-lib.executor.spl.token` | `ks-lib-executor.spl.token` |
|
||||
| `kb-lib.executor.spl.token-2022` | `ks-lib-executor.spl.token-2022` |
|
||||
| `kb-lib.executor.spl.token_2022` | `ks-lib-executor.spl.token_2022` |
|
||||
| `kb-lib.executor.stable.swap_hylo_exchange` | `ks-lib-executor.stable.swap_hylo_exchange` |
|
||||
| `kb-lib.executor.stable.swap_jupiter_stable` | `ks-lib-executor.stable.swap_jupiter_stable` |
|
||||
| `kb-lib.executor.stable.swap_numeraire` | `ks-lib-executor.stable.swap_numeraire` |
|
||||
| `kb-lib.executor.stable.swap_stabble` | `ks-lib-executor.stable.swap_stabble` |
|
||||
| `kb-lib.executor.staking.jito_tip_distribution` | `ks-lib-executor.staking.jito_tip_distribution` |
|
||||
| `kb-lib.executor.staking.kamino_farm` | `ks-lib-executor.staking.kamino_farm` |
|
||||
| `kb-lib.executor.staking.marinade_finance` | `ks-lib-executor.staking.marinade_finance` |
|
||||
| `kb-lib.executor.staking.solayer` | `ks-lib-executor.staking.solayer` |
|
||||
| `kb-lib.executor.storage.solana_record` | `ks-lib-executor.storage.solana_record` |
|
||||
| `kb-lib.executor.strategy.jupiter_dca` | `ks-lib-executor.strategy.jupiter_dca` |
|
||||
| `kb-lib.executor.treasury.helium_treasury_management` | `ks-lib-executor.treasury.helium_treasury_management` |
|
||||
| `kb-lib.executor.vault.carrot_defi` | `ks-lib-executor.vault.carrot_defi` |
|
||||
| `kb-lib.executor.vault.hylo_stability_pool` | `ks-lib-executor.vault.hylo_stability_pool` |
|
||||
| `kb-lib.executor.vault.kamino` | `ks-lib-executor.vault.kamino` |
|
||||
| `kb-lib.executor.vault.kamino_v2` | `ks-lib-executor.vault.kamino_v2` |
|
||||
| `kb-lib.executor.vault.kamino_yvaults` | `ks-lib-executor.vault.kamino_yvaults` |
|
||||
| `kb-lib.executor.vault.meteora` | `ks-lib-executor.vault.meteora` |
|
||||
| `kb-lib.executor.vesting.jupiter_lock` | `ks-lib-executor.vesting.jupiter_lock` |
|
||||
| `kb-lib.executor.vesting.streamflow` | `ks-lib-executor.vesting.streamflow` |
|
||||
| `kb-lib.executor.wallet.jupiter_apepro_smart_wallet` | `ks-lib-executor.wallet.jupiter_apepro_smart_wallet` |
|
||||
| `kb-lib.executor.weighted.swap_stabble` | `ks-lib-executor.weighted.swap_stabble` |
|
||||
| `kb-lib.materializer.admin` | `ks-lib-materializer.admin` |
|
||||
| `kb-lib.materializer.bridge` | `ks-lib-materializer.bridge` |
|
||||
| `kb-lib.materializer.compliance.audit` | `ks-lib-materializer.compliance.audit` |
|
||||
| `kb-lib.materializer.fees` | `ks-lib-materializer.fees` |
|
||||
| `kb-lib.materializer.governance` | `ks-lib-materializer.governance` |
|
||||
| `kb-lib.materializer.lending` | `ks-lib-materializer.lending` |
|
||||
| `kb-lib.materializer.lifecycle` | `ks-lib-materializer.lifecycle` |
|
||||
| `kb-lib.materializer.liquidity` | `ks-lib-materializer.liquidity` |
|
||||
| `kb-lib.materializer.metadata.metaplex_token_metadata` | `ks-lib-materializer.metadata.metaplex_token_metadata` |
|
||||
| `kb-lib.materializer.metadata.solana_program_metadata` | `ks-lib-materializer.metadata.solana_program_metadata` |
|
||||
| `kb-lib.materializer.metadata.token_2022` | `ks-lib-materializer.metadata.token_2022` |
|
||||
| `kb-lib.materializer.nft` | `ks-lib-materializer.nft` |
|
||||
| `kb-lib.materializer.oracle` | `ks-lib-materializer.oracle` |
|
||||
| `kb-lib.materializer.orderbook` | `ks-lib-materializer.orderbook` |
|
||||
| `kb-lib.materializer.perpetuals` | `ks-lib-materializer.perpetuals` |
|
||||
| `kb-lib.materializer.pool.state` | `ks-lib-materializer.pool.state` |
|
||||
| `kb-lib.materializer.rewards` | `ks-lib-materializer.rewards` |
|
||||
| `kb-lib.materializer.risk` | `ks-lib-materializer.risk` |
|
||||
| `kb-lib.materializer.routing` | `ks-lib-materializer.routing` |
|
||||
| `kb-lib.materializer.staking` | `ks-lib-materializer.staking` |
|
||||
| `kb-lib.materializer.token.accounts` | `ks-lib-materializer.token.accounts` |
|
||||
| `kb-lib.materializer.token.metadata_risk` | `ks-lib-materializer.token.metadata_risk` |
|
||||
| `kb-lib.materializer.trades` | `ks-lib-materializer.trades` |
|
||||
| `kb-lib.materializer.transaction.annotations` | `ks-lib-materializer.transaction.annotations` |
|
||||
| `kb-lib.materializer.vault` | `ks-lib-materializer.vault` |
|
||||
| `kb-lib.executor.bridge.layer_zero_endpoint` | `ks-lib-executor.bridge.layer_zero_endpoint` |
|
||||
| `kb-lib.executor.bridge.layer_zero_executor` | `ks-lib-executor.bridge.layer_zero_executor` |
|
||||
| `kb-lib.executor.clmm.byreal` | `ks-lib-executor.clmm.byreal` |
|
||||
| `kb-lib.executor.clmm.fusion` | `ks-lib-executor.clmm.fusion` |
|
||||
| `kb-lib.executor.clmm.orca_whirlpool` | `ks-lib-executor.clmm.orca_whirlpool` |
|
||||
| `kb-lib.executor.clmm.pancake_swap` | `ks-lib-executor.clmm.pancake_swap` |
|
||||
| `kb-lib.executor.clmm.raydium` | `ks-lib-executor.clmm.raydium` |
|
||||
| `kb-lib.executor.clmm.stabble` | `ks-lib-executor.clmm.stabble` |
|
||||
| `kb-lib.executor.cpmm.raydium` | `ks-lib-executor.cpmm.raydium` |
|
||||
| `kb-lib.executor.dlmm.meteora` | `ks-lib-executor.dlmm.meteora` |
|
||||
| `kb-lib.executor.fees.bags_fee_share_v1` | `ks-lib-executor.fees.bags_fee_share_v1` |
|
||||
| `kb-lib.executor.fees.bags_fee_share_v2` | `ks-lib-executor.fees.bags_fee_share_v2` |
|
||||
| `kb-lib.executor.fees.pump_fees` | `ks-lib-executor.fees.pump_fees` |
|
||||
| `kb-lib.executor.governance.metadao_bid_wall` | `ks-lib-executor.governance.metadao_bid_wall` |
|
||||
| `kb-lib.executor.governance.metadao_futarchy` | `ks-lib-executor.governance.metadao_futarchy` |
|
||||
| `kb-lib.executor.governance.squads_multisig` | `ks-lib-executor.governance.squads_multisig` |
|
||||
| `kb-lib.executor.launchpad.boop_fun` | `ks-lib-executor.launchpad.boop_fun` |
|
||||
| `kb-lib.executor.launchpad.metadao_ico` | `ks-lib-executor.launchpad.metadao_ico` |
|
||||
| `kb-lib.executor.launchpad.meteora_dbc` | `ks-lib-executor.launchpad.meteora_dbc` |
|
||||
| `kb-lib.executor.launchpad.moonit` | `ks-lib-executor.launchpad.moonit` |
|
||||
| `kb-lib.executor.launchpad.orca_wavebreak` | `ks-lib-executor.launchpad.orca_wavebreak` |
|
||||
| `kb-lib.executor.launchpad.printr` | `ks-lib-executor.launchpad.printr` |
|
||||
| `kb-lib.executor.launchpad.pump_fun` | `ks-lib-executor.launchpad.pump_fun` |
|
||||
| `kb-lib.executor.launchpad.pump_pumpup_ai` | `ks-lib-executor.launchpad.pump_pumpup_ai` |
|
||||
| `kb-lib.executor.launchpad.raydium_launchlab` | `ks-lib-executor.launchpad.raydium_launchlab` |
|
||||
| `kb-lib.executor.launchpad.virtuals` | `ks-lib-executor.launchpad.virtuals` |
|
||||
| `kb-lib.executor.lending.clone` | `ks-lib-executor.lending.clone` |
|
||||
| `kb-lib.executor.lending.jupiter_lend_borrow` | `ks-lib-executor.lending.jupiter_lend_borrow` |
|
||||
| `kb-lib.executor.lending.jupiter_lend_earn` | `ks-lib-executor.lending.jupiter_lend_earn` |
|
||||
| `kb-lib.executor.lending.jupiter_lend_flash_loan` | `ks-lib-executor.lending.jupiter_lend_flash_loan` |
|
||||
| `kb-lib.executor.lending.jupiter_lend_liquidity` | `ks-lib-executor.lending.jupiter_lend_liquidity` |
|
||||
| `kb-lib.executor.lending.kamino` | `ks-lib-executor.lending.kamino` |
|
||||
| `kb-lib.executor.lending.marginfi_v2` | `ks-lib-executor.lending.marginfi_v2` |
|
||||
| `kb-lib.executor.lock.raydium_lp` | `ks-lib-executor.lock.raydium_lp` |
|
||||
| `kb-lib.executor.metadata.metaplex_token_metadata` | `ks-lib-executor.metadata.metaplex_token_metadata` |
|
||||
| `kb-lib.executor.metadata.solana_program_metadata` | `ks-lib-executor.metadata.solana_program_metadata` |
|
||||
| `kb-lib.executor.metadata.spl_name_service` | `ks-lib-executor.metadata.spl_name_service` |
|
||||
| `kb-lib.executor.nft.metaplex_bubblegum` | `ks-lib-executor.nft.metaplex_bubblegum` |
|
||||
| `kb-lib.executor.nft.tensor_cnft` | `ks-lib-executor.nft.tensor_cnft` |
|
||||
| `kb-lib.executor.orderbook.jupiter_limit_order` | `ks-lib-executor.orderbook.jupiter_limit_order` |
|
||||
| `kb-lib.executor.orderbook.jupiter_limit_order_v2` | `ks-lib-executor.orderbook.jupiter_limit_order_v2` |
|
||||
| `kb-lib.executor.orderbook.openbook_v2` | `ks-lib-executor.orderbook.openbook_v2` |
|
||||
| `kb-lib.executor.perpetuals.drift_v2` | `ks-lib-executor.perpetuals.drift_v2` |
|
||||
| `kb-lib.executor.perpetuals.jupiter` | `ks-lib-executor.perpetuals.jupiter` |
|
||||
| `kb-lib.executor.perpetuals.phoenix_eternal` | `ks-lib-executor.perpetuals.phoenix_eternal` |
|
||||
| `kb-lib.executor.perpetuals.zeta` | `ks-lib-executor.perpetuals.zeta` |
|
||||
| `kb-lib.executor.router.dflow_aggregator_v4` | `ks-lib-executor.router.dflow_aggregator_v4` |
|
||||
| `kb-lib.executor.router.jupiter_aggregator_v4` | `ks-lib-executor.router.jupiter_aggregator_v4` |
|
||||
| `kb-lib.executor.router.jupiter_aggregator_v6` | `ks-lib-executor.router.jupiter_aggregator_v6` |
|
||||
| `kb-lib.executor.router.okx_labs_v1` | `ks-lib-executor.router.okx_labs_v1` |
|
||||
| `kb-lib.executor.router.okx_labs_v2` | `ks-lib-executor.router.okx_labs_v2` |
|
||||
| `kb-lib.executor.rwa.ondo_global_markets` | `ks-lib-executor.rwa.ondo_global_markets` |
|
||||
| `kb-lib.executor.solana.core` | `ks-lib-executor.solana.core` |
|
||||
| `kb-lib.executor.solana.transaction` | `ks-lib-executor.solana.transaction` |
|
||||
| `kb-lib.executor.spl.account_compression` | `ks-lib-executor.spl.account_compression` |
|
||||
| `kb-lib.executor.spl.associated_token_account` | `ks-lib-executor.spl.associated_token_account` |
|
||||
| `kb-lib.executor.spl.elgamal_registry` | `ks-lib-executor.spl.elgamal_registry` |
|
||||
| `kb-lib.executor.spl.memo` | `ks-lib-executor.spl.memo` |
|
||||
| `kb-lib.executor.spl.noop` | `ks-lib-executor.spl.noop` |
|
||||
| `kb-lib.executor.spl.single_pool` | `ks-lib-executor.spl.single_pool` |
|
||||
| `kb-lib.executor.spl.stake_pool` | `ks-lib-executor.spl.stake_pool` |
|
||||
| `kb-lib.executor.spl.token` | `ks-lib-executor.spl.token` |
|
||||
| `kb-lib.executor.spl.token-2022` | `ks-lib-executor.spl.token-2022` |
|
||||
| `kb-lib.executor.spl.token_2022` | `ks-lib-executor.spl.token_2022` |
|
||||
| `kb-lib.executor.stable.swap_hylo_exchange` | `ks-lib-executor.stable.swap_hylo_exchange` |
|
||||
| `kb-lib.executor.stable.swap_jupiter_stable` | `ks-lib-executor.stable.swap_jupiter_stable` |
|
||||
| `kb-lib.executor.stable.swap_numeraire` | `ks-lib-executor.stable.swap_numeraire` |
|
||||
| `kb-lib.executor.stable.swap_stabble` | `ks-lib-executor.stable.swap_stabble` |
|
||||
| `kb-lib.executor.staking.jito_tip_distribution` | `ks-lib-executor.staking.jito_tip_distribution` |
|
||||
| `kb-lib.executor.staking.kamino_farm` | `ks-lib-executor.staking.kamino_farm` |
|
||||
| `kb-lib.executor.staking.marinade_finance` | `ks-lib-executor.staking.marinade_finance` |
|
||||
| `kb-lib.executor.staking.solayer` | `ks-lib-executor.staking.solayer` |
|
||||
| `kb-lib.executor.storage.solana_record` | `ks-lib-executor.storage.solana_record` |
|
||||
| `kb-lib.executor.strategy.jupiter_dca` | `ks-lib-executor.strategy.jupiter_dca` |
|
||||
| `kb-lib.executor.treasury.helium_treasury_management` | `ks-lib-executor.treasury.helium_treasury_management` |
|
||||
| `kb-lib.executor.vault.carrot_defi` | `ks-lib-executor.vault.carrot_defi` |
|
||||
| `kb-lib.executor.vault.hylo_stability_pool` | `ks-lib-executor.vault.hylo_stability_pool` |
|
||||
| `kb-lib.executor.vault.kamino` | `ks-lib-executor.vault.kamino` |
|
||||
| `kb-lib.executor.vault.kamino_v2` | `ks-lib-executor.vault.kamino_v2` |
|
||||
| `kb-lib.executor.vault.kamino_yvaults` | `ks-lib-executor.vault.kamino_yvaults` |
|
||||
| `kb-lib.executor.vault.meteora` | `ks-lib-executor.vault.meteora` |
|
||||
| `kb-lib.executor.vesting.jupiter_lock` | `ks-lib-executor.vesting.jupiter_lock` |
|
||||
| `kb-lib.executor.vesting.streamflow` | `ks-lib-executor.vesting.streamflow` |
|
||||
| `kb-lib.executor.wallet.jupiter_apepro_smart_wallet` | `ks-lib-executor.wallet.jupiter_apepro_smart_wallet` |
|
||||
| `kb-lib.executor.weighted.swap_stabble` | `ks-lib-executor.weighted.swap_stabble` |
|
||||
| `kb-lib.materializer.admin` | `ks-lib-materializer.admin` |
|
||||
| `kb-lib.materializer.bridge` | `ks-lib-materializer.bridge` |
|
||||
| `kb-lib.materializer.compliance.audit` | `ks-lib-materializer.compliance.audit` |
|
||||
| `kb-lib.materializer.fees` | `ks-lib-materializer.fees` |
|
||||
| `kb-lib.materializer.governance` | `ks-lib-materializer.governance` |
|
||||
| `kb-lib.materializer.lending` | `ks-lib-materializer.lending` |
|
||||
| `kb-lib.materializer.lifecycle` | `ks-lib-materializer.lifecycle` |
|
||||
| `kb-lib.materializer.liquidity` | `ks-lib-materializer.liquidity` |
|
||||
| `kb-lib.materializer.metadata.metaplex_token_metadata` | `ks-lib-materializer.metadata.metaplex_token_metadata` |
|
||||
| `kb-lib.materializer.metadata.solana_program_metadata` | `ks-lib-materializer.metadata.solana_program_metadata` |
|
||||
| `kb-lib.materializer.metadata.token_2022` | `ks-lib-materializer.metadata.token_2022` |
|
||||
| `kb-lib.materializer.nft` | `ks-lib-materializer.nft` |
|
||||
| `kb-lib.materializer.oracle` | `ks-lib-materializer.oracle` |
|
||||
| `kb-lib.materializer.orderbook` | `ks-lib-materializer.orderbook` |
|
||||
| `kb-lib.materializer.perpetuals` | `ks-lib-materializer.perpetuals` |
|
||||
| `kb-lib.materializer.pool.state` | `ks-lib-materializer.pool.state` |
|
||||
| `kb-lib.materializer.rewards` | `ks-lib-materializer.rewards` |
|
||||
| `kb-lib.materializer.risk` | `ks-lib-materializer.risk` |
|
||||
| `kb-lib.materializer.routing` | `ks-lib-materializer.routing` |
|
||||
| `kb-lib.materializer.staking` | `ks-lib-materializer.staking` |
|
||||
| `kb-lib.materializer.token.accounts` | `ks-lib-materializer.token.accounts` |
|
||||
| `kb-lib.materializer.token.metadata_risk` | `ks-lib-materializer.token.metadata_risk` |
|
||||
| `kb-lib.materializer.trades` | `ks-lib-materializer.trades` |
|
||||
| `kb-lib.materializer.transaction.annotations` | `ks-lib-materializer.transaction.annotations` |
|
||||
| `kb-lib.materializer.vault` | `ks-lib-materializer.vault` |
|
||||
|
||||
## 7. Inventaire des variables d'environnement
|
||||
|
||||
@@ -440,112 +440,112 @@ Les treize variables historiques `TOKEN_2022_*` sont des fixtures Devnet et conv
|
||||
|
||||
### 7.2 Mapping code/config/tests — 82 noms
|
||||
|
||||
| Nom actuel | Nom cible | Classe |
|
||||
|--------------------------------------------------------------|--------------------------------------------------------------|------------|
|
||||
| `HELIUS_API_KEY` | `KS_SECRET_HELIUS_API_KEY` | `secret` |
|
||||
| `KB_CONFIG_PATH` | `KS_CONFIG_PATH` | `internal` |
|
||||
| `KB_CONFIG_TEST_MISSING` | `KS_CONFIG_TEST_MISSING` | `internal` |
|
||||
| `KB_DEVNET_AIRDROP_LAMPORTS` | `KS_DEVNET_AIRDROP_LAMPORTS` | `internal` |
|
||||
| `KB_DEVNET_CONFIG_PATH` | `KS_DEVNET_CONFIG_PATH` | `internal` |
|
||||
| `KB_DEVNET_EXECUTION_TEST` | `KS_DEVNET_EXECUTION_TEST` | `internal` |
|
||||
| `KB_DEVNET_MEMO_EXECUTION_TEST` | `KS_DEVNET_MEMO_EXECUTION_TEST` | `internal` |
|
||||
| `KB_DEVNET_MEMO_SUBMIT` | `KS_DEVNET_MEMO_SUBMIT` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_COLLECTION_VERIFY_CAMPAIGN_TEST` | `KS_DEVNET_METAPLEX_COLLECTION_VERIFY_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_CREATE_MINT_CAMPAIGN_TEST` | `KS_DEVNET_METAPLEX_CREATE_MINT_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_CREATE_MINT_FAMILY` | `KS_DEVNET_METAPLEX_CREATE_MINT_FAMILY` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_ESCROW_CAMPAIGN_TEST` | `KS_DEVNET_METAPLEX_ESCROW_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_EXECUTION_TEST` | `KS_DEVNET_METAPLEX_EXECUTION_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_MAINTENANCE_CAMPAIGN_TEST` | `KS_DEVNET_METAPLEX_MAINTENANCE_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_MATERIALIZE_AFTER_CONFIRMATION` | `KS_DEVNET_METAPLEX_MATERIALIZE_AFTER_CONFIRMATION` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_OPERATION_JSON` | `KS_DEVNET_METAPLEX_OPERATION_JSON` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_OPERATOR_CONFIRMED` | `KS_DEVNET_METAPLEX_OPERATOR_CONFIRMED` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_PNFT_LIFECYCLE_CAMPAIGN_TEST` | `KS_DEVNET_METAPLEX_PNFT_LIFECYCLE_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_POSTCONDITION_READS_JSON` | `KS_DEVNET_METAPLEX_POSTCONDITION_READS_JSON` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_PREFLIGHT_READS_JSON` | `KS_DEVNET_METAPLEX_PREFLIGHT_READS_JSON` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_PRINT_BURN_CAMPAIGN_TEST` | `KS_DEVNET_METAPLEX_PRINT_BURN_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_SUBMIT` | `KS_DEVNET_METAPLEX_SUBMIT` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_USE_PROBE_TEST` | `KS_DEVNET_METAPLEX_USE_PROBE_TEST` | `internal` |
|
||||
| `KB_DEVNET_PROFILE` | `KS_DEVNET_PROFILE` | `internal` |
|
||||
| `KB_DEVNET_RPC_URL` | `KS_DEVNET_RPC_URL` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_EXECUTION_TEST` | `KS_DEVNET_SPL_ATA_EXECUTION_TEST` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_MINT` | `KS_DEVNET_SPL_ATA_MINT` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_NESTED_MINT` | `KS_DEVNET_SPL_ATA_NESTED_MINT` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_OPERATION` | `KS_DEVNET_SPL_ATA_OPERATION` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_OWNER_MINT` | `KS_DEVNET_SPL_ATA_OWNER_MINT` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_SUBMIT` | `KS_DEVNET_SPL_ATA_SUBMIT` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_TOKEN_PROGRAM` | `KS_DEVNET_SPL_ATA_TOKEN_PROGRAM` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_AMOUNT` | `KS_DEVNET_SPL_TOKEN_AMOUNT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_AUTHORITY` | `KS_DEVNET_SPL_TOKEN_AUTHORITY` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_DECIMALS` | `KS_DEVNET_SPL_TOKEN_DECIMALS` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_DESTINATION` | `KS_DEVNET_SPL_TOKEN_DESTINATION` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_EXECUTION_TEST` | `KS_DEVNET_SPL_TOKEN_EXECUTION_TEST` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_APPROVE_AMOUNT` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_APPROVE_AMOUNT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_AUTHORITY` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_AUTHORITY` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_DECIMALS` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_DECIMALS` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_DELEGATE` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_DELEGATE` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_DESTINATION` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_DESTINATION` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_FIRST_STEP_INDEX` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_FIRST_STEP_INDEX` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_INTER_STEP_DELAY_MS` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_INTER_STEP_DELAY_MS` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_MINT` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_MINT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_MINT_AMOUNT` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_MINT_AMOUNT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_PREPARATION_SETTLE_DELAY_MS` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_PREPARATION_SETTLE_DELAY_MS` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_PREPARE` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_PREPARE` | `internal` |
|
||||
| Nom actuel | Nom cible | Classe |
|
||||
|---|---|---|
|
||||
| `HELIUS_API_KEY` | `KS_SECRET_HELIUS_API_KEY` | `secret` |
|
||||
| `KB_CONFIG_PATH` | `KS_CONFIG_PATH` | `internal` |
|
||||
| `KB_CONFIG_TEST_MISSING` | `KS_CONFIG_TEST_MISSING` | `internal` |
|
||||
| `KB_DEVNET_AIRDROP_LAMPORTS` | `KS_DEVNET_AIRDROP_LAMPORTS` | `internal` |
|
||||
| `KB_DEVNET_CONFIG_PATH` | `KS_DEVNET_CONFIG_PATH` | `internal` |
|
||||
| `KB_DEVNET_EXECUTION_TEST` | `KS_DEVNET_EXECUTION_TEST` | `internal` |
|
||||
| `KB_DEVNET_MEMO_EXECUTION_TEST` | `KS_DEVNET_MEMO_EXECUTION_TEST` | `internal` |
|
||||
| `KB_DEVNET_MEMO_SUBMIT` | `KS_DEVNET_MEMO_SUBMIT` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_COLLECTION_VERIFY_CAMPAIGN_TEST` | `KS_DEVNET_METAPLEX_COLLECTION_VERIFY_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_CREATE_MINT_CAMPAIGN_TEST` | `KS_DEVNET_METAPLEX_CREATE_MINT_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_CREATE_MINT_FAMILY` | `KS_DEVNET_METAPLEX_CREATE_MINT_FAMILY` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_ESCROW_CAMPAIGN_TEST` | `KS_DEVNET_METAPLEX_ESCROW_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_EXECUTION_TEST` | `KS_DEVNET_METAPLEX_EXECUTION_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_MAINTENANCE_CAMPAIGN_TEST` | `KS_DEVNET_METAPLEX_MAINTENANCE_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_MATERIALIZE_AFTER_CONFIRMATION` | `KS_DEVNET_METAPLEX_MATERIALIZE_AFTER_CONFIRMATION` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_OPERATION_JSON` | `KS_DEVNET_METAPLEX_OPERATION_JSON` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_OPERATOR_CONFIRMED` | `KS_DEVNET_METAPLEX_OPERATOR_CONFIRMED` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_PNFT_LIFECYCLE_CAMPAIGN_TEST` | `KS_DEVNET_METAPLEX_PNFT_LIFECYCLE_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_POSTCONDITION_READS_JSON` | `KS_DEVNET_METAPLEX_POSTCONDITION_READS_JSON` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_PREFLIGHT_READS_JSON` | `KS_DEVNET_METAPLEX_PREFLIGHT_READS_JSON` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_PRINT_BURN_CAMPAIGN_TEST` | `KS_DEVNET_METAPLEX_PRINT_BURN_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_SUBMIT` | `KS_DEVNET_METAPLEX_SUBMIT` | `internal` |
|
||||
| `KB_DEVNET_METAPLEX_USE_PROBE_TEST` | `KS_DEVNET_METAPLEX_USE_PROBE_TEST` | `internal` |
|
||||
| `KB_DEVNET_PROFILE` | `KS_DEVNET_PROFILE` | `internal` |
|
||||
| `KB_DEVNET_RPC_URL` | `KS_DEVNET_RPC_URL` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_EXECUTION_TEST` | `KS_DEVNET_SPL_ATA_EXECUTION_TEST` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_MINT` | `KS_DEVNET_SPL_ATA_MINT` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_NESTED_MINT` | `KS_DEVNET_SPL_ATA_NESTED_MINT` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_OPERATION` | `KS_DEVNET_SPL_ATA_OPERATION` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_OWNER_MINT` | `KS_DEVNET_SPL_ATA_OWNER_MINT` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_SUBMIT` | `KS_DEVNET_SPL_ATA_SUBMIT` | `internal` |
|
||||
| `KB_DEVNET_SPL_ATA_TOKEN_PROGRAM` | `KS_DEVNET_SPL_ATA_TOKEN_PROGRAM` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_AMOUNT` | `KS_DEVNET_SPL_TOKEN_AMOUNT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_AUTHORITY` | `KS_DEVNET_SPL_TOKEN_AUTHORITY` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_DECIMALS` | `KS_DEVNET_SPL_TOKEN_DECIMALS` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_DESTINATION` | `KS_DEVNET_SPL_TOKEN_DESTINATION` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_EXECUTION_TEST` | `KS_DEVNET_SPL_TOKEN_EXECUTION_TEST` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_APPROVE_AMOUNT` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_APPROVE_AMOUNT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_AUTHORITY` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_AUTHORITY` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_DECIMALS` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_DECIMALS` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_DELEGATE` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_DELEGATE` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_DESTINATION` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_DESTINATION` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_FIRST_STEP_INDEX` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_FIRST_STEP_INDEX` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_INTER_STEP_DELAY_MS` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_INTER_STEP_DELAY_MS` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_MINT` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_MINT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_MINT_AMOUNT` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_MINT_AMOUNT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_PREPARATION_SETTLE_DELAY_MS` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_PREPARATION_SETTLE_DELAY_MS` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_PREPARE` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_PREPARE` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_RESUME_PREDECESSOR_SIGNATURE` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_RESUME_PREDECESSOR_SIGNATURE` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_SOURCE` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_SOURCE` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_SUBMIT` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_SUBMIT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_TEST` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_TEST` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_TRANSFER_AMOUNT` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_TRANSFER_AMOUNT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_MINT` | `KS_DEVNET_SPL_TOKEN_MINT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_NATIVE_ACCOUNT` | `KS_DEVNET_SPL_TOKEN_NATIVE_ACCOUNT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_PREFLIGHT_TEST` | `KS_DEVNET_SPL_TOKEN_PREFLIGHT_TEST` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_RECENT_PROBE_TEST` | `KS_DEVNET_SPL_TOKEN_RECENT_PROBE_TEST` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_SOURCE` | `KS_DEVNET_SPL_TOKEN_SOURCE` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_SUBMIT` | `KS_DEVNET_SPL_TOKEN_SUBMIT` | `internal` |
|
||||
| `KB_DEVNET_TOKEN_2022_METADATA_CAMPAIGN_TEST` | `KS_DEVNET_TOKEN_2022_METADATA_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_TOKEN_2022_METADATA_OPERATOR_CONFIRMED` | `KS_DEVNET_TOKEN_2022_METADATA_OPERATOR_CONFIRMED` | `internal` |
|
||||
| `KB_DEVNET_TRANSFER_LAMPORTS` | `KS_DEVNET_TRANSFER_LAMPORTS` | `internal` |
|
||||
| `KB_DEVNET_WALLET` | `KS_DEVNET_WALLET` | `internal` |
|
||||
| `KB_DEVNET_WALLET_ADDRESS` | `KS_DEVNET_WALLET_ADDRESS` | `internal` |
|
||||
| `KB_DEVNET_WALLET_DIR` | `KS_DEVNET_WALLET_DIR` | `internal` |
|
||||
| `KB_ENV_FILE` | `KS_ENV_FILE` | `internal` |
|
||||
| `KB_POSTGRES_DEVNET_URL` | `KS_SECRET_POSTGRES_DEVNET_URL` | `secret` |
|
||||
| `KB_POSTGRES_MAINNET_URL` | `KS_SECRET_POSTGRES_MAINNET_URL` | `secret` |
|
||||
| `KB_POSTGRES_TEST_URL` | `KS_SECRET_POSTGRES_TEST_URL` | `secret` |
|
||||
| `TOKEN_2022_APPROVE_AMOUNT_RAW` | `KS_DEVNET_TOKEN_2022_APPROVE_AMOUNT_RAW` | `internal` |
|
||||
| `TOKEN_2022_AUTHORITY` | `KS_DEVNET_TOKEN_2022_AUTHORITY` | `internal` |
|
||||
| `TOKEN_2022_BURN_AMOUNT_RAW` | `KS_DEVNET_TOKEN_2022_BURN_AMOUNT_RAW` | `internal` |
|
||||
| `TOKEN_2022_CLOSE_ACCOUNT` | `KS_DEVNET_TOKEN_2022_CLOSE_ACCOUNT` | `internal` |
|
||||
| `TOKEN_2022_DECIMALS` | `KS_DEVNET_TOKEN_2022_DECIMALS` | `internal` |
|
||||
| `TOKEN_2022_DELEGATE` | `KS_DEVNET_TOKEN_2022_DELEGATE` | `internal` |
|
||||
| `TOKEN_2022_DESTINATION` | `KS_DEVNET_TOKEN_2022_DESTINATION` | `internal` |
|
||||
| `TOKEN_2022_FREEZE_AUTHORITY` | `KS_DEVNET_TOKEN_2022_FREEZE_AUTHORITY` | `internal` |
|
||||
| `TOKEN_2022_MINT` | `KS_DEVNET_TOKEN_2022_MINT` | `internal` |
|
||||
| `TOKEN_2022_MINT_AMOUNT_RAW` | `KS_DEVNET_TOKEN_2022_MINT_AMOUNT_RAW` | `internal` |
|
||||
| `TOKEN_2022_PROGRAM` | `KS_DEVNET_TOKEN_2022_PROGRAM` | `internal` |
|
||||
| `TOKEN_2022_SOURCE` | `KS_DEVNET_TOKEN_2022_SOURCE` | `internal` |
|
||||
| `TOKEN_2022_TRANSFER_AMOUNT_RAW` | `KS_DEVNET_TOKEN_2022_TRANSFER_AMOUNT_RAW` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_SOURCE` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_SOURCE` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_SUBMIT` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_SUBMIT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_TEST` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_TEST` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_LIFECYCLE_TRANSFER_AMOUNT` | `KS_DEVNET_SPL_TOKEN_LIFECYCLE_TRANSFER_AMOUNT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_MINT` | `KS_DEVNET_SPL_TOKEN_MINT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_NATIVE_ACCOUNT` | `KS_DEVNET_SPL_TOKEN_NATIVE_ACCOUNT` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_PREFLIGHT_TEST` | `KS_DEVNET_SPL_TOKEN_PREFLIGHT_TEST` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_RECENT_PROBE_TEST` | `KS_DEVNET_SPL_TOKEN_RECENT_PROBE_TEST` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_SOURCE` | `KS_DEVNET_SPL_TOKEN_SOURCE` | `internal` |
|
||||
| `KB_DEVNET_SPL_TOKEN_SUBMIT` | `KS_DEVNET_SPL_TOKEN_SUBMIT` | `internal` |
|
||||
| `KB_DEVNET_TOKEN_2022_METADATA_CAMPAIGN_TEST` | `KS_DEVNET_TOKEN_2022_METADATA_CAMPAIGN_TEST` | `internal` |
|
||||
| `KB_DEVNET_TOKEN_2022_METADATA_OPERATOR_CONFIRMED` | `KS_DEVNET_TOKEN_2022_METADATA_OPERATOR_CONFIRMED` | `internal` |
|
||||
| `KB_DEVNET_TRANSFER_LAMPORTS` | `KS_DEVNET_TRANSFER_LAMPORTS` | `internal` |
|
||||
| `KB_DEVNET_WALLET` | `KS_DEVNET_WALLET` | `internal` |
|
||||
| `KB_DEVNET_WALLET_ADDRESS` | `KS_DEVNET_WALLET_ADDRESS` | `internal` |
|
||||
| `KB_DEVNET_WALLET_DIR` | `KS_DEVNET_WALLET_DIR` | `internal` |
|
||||
| `KB_ENV_FILE` | `KS_ENV_FILE` | `internal` |
|
||||
| `KB_POSTGRES_DEVNET_URL` | `KS_SECRET_POSTGRES_DEVNET_URL` | `secret` |
|
||||
| `KB_POSTGRES_MAINNET_URL` | `KS_SECRET_POSTGRES_MAINNET_URL` | `secret` |
|
||||
| `KB_POSTGRES_TEST_URL` | `KS_SECRET_POSTGRES_TEST_URL` | `secret` |
|
||||
| `TOKEN_2022_APPROVE_AMOUNT_RAW` | `KS_DEVNET_TOKEN_2022_APPROVE_AMOUNT_RAW` | `internal` |
|
||||
| `TOKEN_2022_AUTHORITY` | `KS_DEVNET_TOKEN_2022_AUTHORITY` | `internal` |
|
||||
| `TOKEN_2022_BURN_AMOUNT_RAW` | `KS_DEVNET_TOKEN_2022_BURN_AMOUNT_RAW` | `internal` |
|
||||
| `TOKEN_2022_CLOSE_ACCOUNT` | `KS_DEVNET_TOKEN_2022_CLOSE_ACCOUNT` | `internal` |
|
||||
| `TOKEN_2022_DECIMALS` | `KS_DEVNET_TOKEN_2022_DECIMALS` | `internal` |
|
||||
| `TOKEN_2022_DELEGATE` | `KS_DEVNET_TOKEN_2022_DELEGATE` | `internal` |
|
||||
| `TOKEN_2022_DESTINATION` | `KS_DEVNET_TOKEN_2022_DESTINATION` | `internal` |
|
||||
| `TOKEN_2022_FREEZE_AUTHORITY` | `KS_DEVNET_TOKEN_2022_FREEZE_AUTHORITY` | `internal` |
|
||||
| `TOKEN_2022_MINT` | `KS_DEVNET_TOKEN_2022_MINT` | `internal` |
|
||||
| `TOKEN_2022_MINT_AMOUNT_RAW` | `KS_DEVNET_TOKEN_2022_MINT_AMOUNT_RAW` | `internal` |
|
||||
| `TOKEN_2022_PROGRAM` | `KS_DEVNET_TOKEN_2022_PROGRAM` | `internal` |
|
||||
| `TOKEN_2022_SOURCE` | `KS_DEVNET_TOKEN_2022_SOURCE` | `internal` |
|
||||
| `TOKEN_2022_TRANSFER_AMOUNT_RAW` | `KS_DEVNET_TOKEN_2022_TRANSFER_AMOUNT_RAW` | `internal` |
|
||||
|
||||
### 7.3 Mapping guide opérateur Devnet — 17 noms
|
||||
|
||||
| Nom actuel | Nom cible | Classe |
|
||||
|---------------------------------------|---------------------------------------|------------|
|
||||
| `KB_CONFIRM_DEVNET_DATABASE_RESET` | `KS_CONFIRM_DEVNET_DATABASE_RESET` | `internal` |
|
||||
| `KB_DEVNET_CLASSIC_DESTINATION_ATA` | `KS_DEVNET_CLASSIC_DESTINATION_ATA` | `internal` |
|
||||
| `KB_DEVNET_CLASSIC_MINT` | `KS_DEVNET_CLASSIC_MINT` | `internal` |
|
||||
| `KB_DEVNET_CLASSIC_MINT_KEYPAIR` | `KS_DEVNET_CLASSIC_MINT_KEYPAIR` | `internal` |
|
||||
| `KB_DEVNET_CLASSIC_RECIPIENT` | `KS_DEVNET_CLASSIC_RECIPIENT` | `internal` |
|
||||
| Nom actuel | Nom cible | Classe |
|
||||
|---|---|---|
|
||||
| `KB_CONFIRM_DEVNET_DATABASE_RESET` | `KS_CONFIRM_DEVNET_DATABASE_RESET` | `internal` |
|
||||
| `KB_DEVNET_CLASSIC_DESTINATION_ATA` | `KS_DEVNET_CLASSIC_DESTINATION_ATA` | `internal` |
|
||||
| `KB_DEVNET_CLASSIC_MINT` | `KS_DEVNET_CLASSIC_MINT` | `internal` |
|
||||
| `KB_DEVNET_CLASSIC_MINT_KEYPAIR` | `KS_DEVNET_CLASSIC_MINT_KEYPAIR` | `internal` |
|
||||
| `KB_DEVNET_CLASSIC_RECIPIENT` | `KS_DEVNET_CLASSIC_RECIPIENT` | `internal` |
|
||||
| `KB_DEVNET_CLASSIC_RECIPIENT_KEYPAIR` | `KS_DEVNET_CLASSIC_RECIPIENT_KEYPAIR` | `internal` |
|
||||
| `KB_DEVNET_CLASSIC_SOURCE_ATA` | `KS_DEVNET_CLASSIC_SOURCE_ATA` | `internal` |
|
||||
| `KB_DEVNET_RECIPIENT` | `KS_DEVNET_RECIPIENT` | `internal` |
|
||||
| `KB_DEVNET_SCENARIO` | `KS_DEVNET_SCENARIO` | `internal` |
|
||||
| `KB_DEVNET_SIGNATURE` | `KS_DEVNET_SIGNATURE` | `internal` |
|
||||
| `KB_DEVNET_TOKEN_2022_FIXTURE` | `KS_DEVNET_TOKEN_2022_FIXTURE` | `internal` |
|
||||
| `KB_DEVNET_TOKEN_2022_MINT` | `KS_DEVNET_TOKEN_2022_MINT` | `internal` |
|
||||
| `KB_DEVNET_TOKEN_2022_MINT_KEYPAIR` | `KS_DEVNET_TOKEN_2022_MINT_KEYPAIR` | `internal` |
|
||||
| `KB_DEVNET_VALIDATION_DIR` | `KS_DEVNET_VALIDATION_DIR` | `internal` |
|
||||
| `KB_DEVNET_WALLET_PUBKEY` | `KS_DEVNET_WALLET_PUBKEY` | `internal` |
|
||||
| `KB_SPL_TOKEN_2022_PROGRAM_ID` | `KS_SPL_TOKEN_2022_PROGRAM_ID` | `internal` |
|
||||
| `KB_SPL_TOKEN_PROGRAM_ID` | `KS_SPL_TOKEN_PROGRAM_ID` | `internal` |
|
||||
| `KB_DEVNET_CLASSIC_SOURCE_ATA` | `KS_DEVNET_CLASSIC_SOURCE_ATA` | `internal` |
|
||||
| `KB_DEVNET_RECIPIENT` | `KS_DEVNET_RECIPIENT` | `internal` |
|
||||
| `KB_DEVNET_SCENARIO` | `KS_DEVNET_SCENARIO` | `internal` |
|
||||
| `KB_DEVNET_SIGNATURE` | `KS_DEVNET_SIGNATURE` | `internal` |
|
||||
| `KB_DEVNET_TOKEN_2022_FIXTURE` | `KS_DEVNET_TOKEN_2022_FIXTURE` | `internal` |
|
||||
| `KB_DEVNET_TOKEN_2022_MINT` | `KS_DEVNET_TOKEN_2022_MINT` | `internal` |
|
||||
| `KB_DEVNET_TOKEN_2022_MINT_KEYPAIR` | `KS_DEVNET_TOKEN_2022_MINT_KEYPAIR` | `internal` |
|
||||
| `KB_DEVNET_VALIDATION_DIR` | `KS_DEVNET_VALIDATION_DIR` | `internal` |
|
||||
| `KB_DEVNET_WALLET_PUBKEY` | `KS_DEVNET_WALLET_PUBKEY` | `internal` |
|
||||
| `KB_SPL_TOKEN_2022_PROGRAM_ID` | `KS_SPL_TOKEN_2022_PROGRAM_ID` | `internal` |
|
||||
| `KB_SPL_TOKEN_PROGRAM_ID` | `KS_SPL_TOKEN_PROGRAM_ID` | `internal` |
|
||||
|
||||
## 8. Split configuration / logging
|
||||
|
||||
@@ -566,7 +566,7 @@ Le code duplique actuellement dans `kb-config` et `kb-logging` les concepts :
|
||||
- `LogTargetConfig` ;
|
||||
- `LogTargetFilterConfig`.
|
||||
|
||||
`kb-app-demo-desktop` contient en plus une conversion manuelle de `kb_config::LoggingConfig` vers `kb_logging::LoggingConfig`. `0.5.1` doit supprimer cette duplication en donnant au logging un contrat possédé par `ks-logging`, tout en laissant `ks-config` charger/valider/composer les documents sans réinventer les types runtime du logging.
|
||||
`kb-app-demo-desktop` contient en plus une conversion manuelle de `ks_config::LoggingConfig` vers `ks_logging::LoggingConfig`. `0.5.1` doit supprimer cette duplication en donnant au logging un contrat possédé par `ks-logging`, tout en laissant `ks-config` charger/valider/composer les documents sans réinventer les types runtime du logging.
|
||||
|
||||
Aucun troisième document spécialisé n'est créé dans `0.5.1` sans bénéfice de découplage démontré.
|
||||
|
||||
@@ -640,12 +640,14 @@ Les tests ne doivent pas figer comme comportement légitime la fuite actuelle de
|
||||
- renommer physiquement les dix crates selon l'ordre de dépendance ;
|
||||
- migrer packages, paths, imports, exports, tests externes, scripts et CLI ;
|
||||
- adapter `kb-app-demo-desktop` sans le renommer ;
|
||||
- conserver encore les changements sémantiques de config hors de ce delta.
|
||||
- migrer les targets de tracing **racine** dont le contrat est couplé au nom Cargo (`ks-logging`, `ks-pipeline`, `ks-pipeline-demo-scenarios`, `ks-onchain-transport`, `ks-store`, `ks-wallet`) et réaligner les routes de logging qui utilisent les noms de crates ;
|
||||
- régénérer localement les bindings TS-RS de `ks-config` plutôt que livrer des bindings générés à la main ;
|
||||
- conserver encore les variables d'environnement, les identités `kb-lib.*` et les tables `kb_sol_*` hors de ce delta.
|
||||
|
||||
### `0.5.1-pre.003` — identités techniques et tracing
|
||||
### `0.5.1-pre.003` — identités techniques et tracing hiérarchique `ks-lib-*`
|
||||
|
||||
- migrer les 256 identités `kb-lib.*` vers `ks-lib-*` ;
|
||||
- migrer targets de tracing génériques vers `ks-*` ;
|
||||
- migrer les subtargets et identités de composants hiérarchiques qui ne pouvaient pas être changés par le simple renommage Cargo ;
|
||||
- synchroniser routes de logging, matrices, diagnostics, tests et provenance/replay ;
|
||||
- ne pas renommer encore les tables SQL `kb_sol_*`.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/RULES_SPECIFIC_KHADHROONY.md -->
|
||||
<!-- version: 12 -->
|
||||
<!-- version: 13 -->
|
||||
|
||||
# Règles spécifiques à `khadhroony-bot3`
|
||||
|
||||
@@ -13,10 +13,10 @@ Toute divergence avec une règle générale doit être explicitement documentée
|
||||
- Les noms de fichiers et de répertoires ne doivent contenir aucun accent, espace ou caractère spécial inutile.
|
||||
- Les noms internes doivent utiliser le format `snake_case` lorsque c'est applicable.
|
||||
- Les packages Rust utilisent le préfixe `kb-` ; leur identifiant Rust correspondant utilise automatiquement `kb_`.
|
||||
- Les décodeurs, matérialisateurs et exécuteurs sont des modules de `kb-lib`, pas des crates séparées.
|
||||
- Le crate de journalisation s'appelle `kb-logging`.
|
||||
- Les décodeurs, matérialisateurs et exécuteurs sont des modules de `ks-lib`, pas des crates séparées.
|
||||
- Le crate de journalisation s'appelle `ks-logging`.
|
||||
- Les réexports sont regroupés par visibilité : le bloc `pub use` précède le bloc séparé `pub(crate) use`, sans ligne vide interne à un bloc ; leur ordre naturel doit rester compatible avec `cargo fmt`.
|
||||
- Les familles de symboles consolidées dans `kb-lib` utilisent les préfixes `DC_`/`Dc`/`decoder_` pour les décodeurs, `MT_`/`Mt`/`materializer_` pour les matérialisateurs, `EX_`/`Ex`/`executor_` pour les exécuteurs et `MD_`/`Md`/`model_` pour les modèles.
|
||||
- Les familles de symboles consolidées dans `ks-lib` utilisent les préfixes `DC_`/`Dc`/`decoder_` pour les décodeurs, `MT_`/`Mt`/`materializer_` pour les matérialisateurs, `EX_`/`Ex`/`executor_` pour les exécuteurs et `MD_`/`Md`/`model_` pour les modèles.
|
||||
- Les méthodes inhérentes et helpers strictement privés peuvent conserver un nom local court ; les préfixes s’appliquent aux constantes, types, traits et fonctions libres exposés à la crate ou hors de la crate.
|
||||
- Les constantes temporaires `*_LEGACY_CRATE`, `*_MIGRATION_STATUS` et `*_MIGRATION_BOUNDARIES` doivent disparaître d’une famille dès que ses squelettes typés sont restaurés ; elles ne constituent jamais une API durable.
|
||||
|
||||
@@ -55,7 +55,7 @@ Toute divergence avec une règle générale doit être explicitement documentée
|
||||
- Toute absence volontaire de projection doit être documentée avec une justification technique précise. Un matérialisateur ne doit inventer ni état final, ni montant, ni autorité, ni frais, ni agrégation que l'observation ne prouve pas.
|
||||
- Chaque matérialisateur concret possède un composant structuré avec une façade limitée aux déclarations de sous-modules et réexports, un `constants.rs` et un `materializer.rs`. Les fichiers spécialisés `state.rs`, `account.rs` ou équivalents sont ajoutés seulement lorsque leur responsabilité est distincte.
|
||||
- L’identité runtime suit `kb-lib.materializer.<domain>[.<subsystem>]`. Le `processorName` persisté suit `materializer.<domain>[.<subsystem>]` et doit être exactement l’identité runtime sans le préfixe `kb-lib.`. Le tracing target d’un composant actif est identique à son identité runtime.
|
||||
- Les constantes d’un composant utilisent le préfixe `MT_<COMPONENT>_`, résident dans son `constants.rs`, sont réexportées par chaque façade jusqu’à `kb-lib/src/lib.rs` et sont consommées par `crate::`, y compris dans les tests lorsqu’elles sont `pub` ou `pub(crate)`.
|
||||
- Les constantes d’un composant utilisent le préfixe `MT_<COMPONENT>_`, résident dans son `constants.rs`, sont réexportées par chaque façade jusqu’à `ks-lib/src/lib.rs` et sont consommées par `crate::`, y compris dans les tests lorsqu’elles sont `pub` ou `pub(crate)`.
|
||||
- Toute sortie persistée contient un `processorName` issu de la constante du composant et une `projectionVersion` explicite. Une correction de provenance persistée impose une nouvelle version de projection.
|
||||
- Une coquille réservée implémente `MtMaterializer` et `MtApiEventMaterializer`, expose une constante `MT_*_ACCEPTED_FAMILIES` vide, refuse tous les événements, retourne une liste legacy vide et un résultat contextuel `Ignored`. Elle ne doit jamais créer un faux événement de transition.
|
||||
- Un composant state-only peut exposer uniquement des APIs de snapshots sans implémenter `MtApiEventMaterializer`; ce statut doit être explicite et ne crée pas artificiellement un matérialisateur instructionnel.
|
||||
@@ -77,24 +77,24 @@ Toute divergence avec une règle générale doit être explicitement documentée
|
||||
|
||||
### Frontière des pipelines
|
||||
|
||||
- `kb-pipeline` est le pipeline généraliste, réutilisable et indépendant d'un environnement de démonstration. Ses contrats doivent pouvoir être appelés depuis une application, un service, un worker, un CLI, des tests ou une autre orchestration, sur tout cluster compatible autorisé par la configuration.
|
||||
- `kb-pipeline` possède l'orchestration générique du backfill, de l'extraction Core, du replay, des corrélations stateful, du préflight, de la préparation, de la simulation, de la soumission autorisée, de la confirmation, de la postvalidation et de la matérialisation idempotente.
|
||||
- `kb-pipeline` ne doit contenir ni wallet, mint, compte, airdrop, autorité, adresse, séquence ou hypothèse codée en dur pour une démonstration Devnet ou Testnet.
|
||||
- `kb-pipeline-demo-scenarios` contient les fixtures, aides de campagne et tests automatisés spécifiques aux réseaux de test, actuellement Devnet ou Testnet.
|
||||
- Les fixtures, séquences, simulations/soumissions, postconditions et qualifications Devnet/Testnet réutilisables appartiennent à `kb-pipeline-demo-scenarios`, y compris lorsqu'elles sont déclenchées depuis le desktop.
|
||||
- `ks-pipeline` est le pipeline généraliste, réutilisable et indépendant d'un environnement de démonstration. Ses contrats doivent pouvoir être appelés depuis une application, un service, un worker, un CLI, des tests ou une autre orchestration, sur tout cluster compatible autorisé par la configuration.
|
||||
- `ks-pipeline` possède l'orchestration générique du backfill, de l'extraction Core, du replay, des corrélations stateful, du préflight, de la préparation, de la simulation, de la soumission autorisée, de la confirmation, de la postvalidation et de la matérialisation idempotente.
|
||||
- `ks-pipeline` ne doit contenir ni wallet, mint, compte, airdrop, autorité, adresse, séquence ou hypothèse codée en dur pour une démonstration Devnet ou Testnet.
|
||||
- `ks-pipeline-demo-scenarios` contient les fixtures, aides de campagne et tests automatisés spécifiques aux réseaux de test, actuellement Devnet ou Testnet.
|
||||
- Les fixtures, séquences, simulations/soumissions, postconditions et qualifications Devnet/Testnet réutilisables appartiennent à `ks-pipeline-demo-scenarios`, y compris lorsqu'elles sont déclenchées depuis le desktop.
|
||||
- `kb-app-demo-desktop` conserve l'adaptation UI/Tauri, l'état applicatif, la sélection opérateur, la progression/annulation et la présentation. Il ne doit pas maintenir une seconde implémentation d'une campagne réutilisable.
|
||||
- `kb-pipeline-demo-scenarios` peut préparer des wallets temporaires, demander des airdrops, créer des actifs de test, enchaîner plusieurs appels du pipeline généraliste et produire des preuves de validation réseau.
|
||||
- Le binaire `kb-pipeline-demo-scenarios-cli` reste un outil ciblé tant que son contrat public ne prévoit pas explicitement d'autres commandes. Son usage historique de préparation des fixtures SPL Token-2022 ne doit pas être généralisé implicitement à tous les scénarios.
|
||||
- `kb-pipeline-demo-scenarios` dépend de `kb-pipeline` ; la dépendance inverse est interdite.
|
||||
- Une primitive ou orchestration réellement réutilisable hors d'une campagne de validation précise doit être placée dans `kb-pipeline`, `kb-pipeline-demo-scenarios` ou la crate métier propriétaire selon sa responsabilité. Seuls les adaptateurs, états et séquences strictement propres à l'interaction UI restent dans le desktop.
|
||||
- `ks-pipeline-demo-scenarios` peut préparer des wallets temporaires, demander des airdrops, créer des actifs de test, enchaîner plusieurs appels du pipeline généraliste et produire des preuves de validation réseau.
|
||||
- Le binaire `ks-pipeline-demo-scenarios-cli` reste un outil ciblé tant que son contrat public ne prévoit pas explicitement d'autres commandes. Son usage historique de préparation des fixtures SPL Token-2022 ne doit pas être généralisé implicitement à tous les scénarios.
|
||||
- `ks-pipeline-demo-scenarios` dépend de `ks-pipeline` ; la dépendance inverse est interdite.
|
||||
- Une primitive ou orchestration réellement réutilisable hors d'une campagne de validation précise doit être placée dans `ks-pipeline`, `ks-pipeline-demo-scenarios` ou la crate métier propriétaire selon sa responsabilité. Seuls les adaptateurs, états et séquences strictement propres à l'interaction UI restent dans le desktop.
|
||||
- Les scénarios Mainnet sans écriture, par exemple les validations de backfill ou de replay, relèvent du pipeline généraliste et de documents de validation dédiés ; ils ne justifient pas l'introduction d'une logique Mainnet spécifique dans la crate de scénarios Devnet/Testnet.
|
||||
|
||||
### Autres frontières
|
||||
|
||||
- `kb-store` possède les contrats de persistance neutres et les adaptateurs de base de données.
|
||||
- PostgreSQL est l'adaptateur de production de `kb-store`.
|
||||
- Un futur adaptateur SQLite doit rester interne à `kb-store` et limité aux tests, imports et corpus locaux.
|
||||
- `kb-wallet` reste isolé du reste du système.
|
||||
- `ks-store` possède les contrats de persistance neutres et les adaptateurs de base de données.
|
||||
- PostgreSQL est l'adaptateur de production de `ks-store`.
|
||||
- Un futur adaptateur SQLite doit rester interne à `ks-store` et limité aux tests, imports et corpus locaux.
|
||||
- `ks-wallet` reste isolé du reste du système.
|
||||
- Les transactions raw sont immuables et restent la source d'audit.
|
||||
- Les replays doivent être ciblés par module, version, programme, surface, discriminator, slot ou signatures.
|
||||
- La documentation active du projet ne doit pas présenter l'ancien workspace comme architecture courante. Les documents de migration et copies de référence peuvent le nommer explicitement.
|
||||
@@ -124,20 +124,20 @@ Les nouvelles surfaces de programmes doivent utiliser un nom canonique basé sur
|
||||
Les modules internes de décodage doivent utiliser la hiérarchie de fichiers :
|
||||
|
||||
```text
|
||||
kb-lib/src/decoder/<function_code>/<family_code>_<identifier_code>[_vN].rs
|
||||
ks-lib/src/decoder/<function_code>/<family_code>_<identifier_code>[_vN].rs
|
||||
```
|
||||
|
||||
Exemples :
|
||||
|
||||
- `kb-lib/src/decoder/amm/raydium_cpmm.rs` ;
|
||||
- `kb-lib/src/decoder/clmm/raydium.rs` ;
|
||||
- `kb-lib/src/decoder/dlmm/meteora.rs` ;
|
||||
- `kb-lib/src/decoder/router/jupiter_aggregator_v6.rs` ;
|
||||
- `kb-lib/src/decoder/orderbook/openbook_v2.rs` ;
|
||||
- `kb-lib/src/decoder/metadata/metaplex_token_metadata.rs` ;
|
||||
- `kb-lib/src/decoder/nft/metaplex_bubblegum.rs`.
|
||||
- `ks-lib/src/decoder/amm/raydium_cpmm.rs` ;
|
||||
- `ks-lib/src/decoder/clmm/raydium.rs` ;
|
||||
- `ks-lib/src/decoder/dlmm/meteora.rs` ;
|
||||
- `ks-lib/src/decoder/router/jupiter_aggregator_v6.rs` ;
|
||||
- `ks-lib/src/decoder/orderbook/openbook_v2.rs` ;
|
||||
- `ks-lib/src/decoder/metadata/metaplex_token_metadata.rs` ;
|
||||
- `ks-lib/src/decoder/nft/metaplex_bubblegum.rs`.
|
||||
|
||||
Ces modules restent privés. Les consommateurs externes utilisent exclusivement les types et fonctions réexportés directement par `kb_lib`.
|
||||
Ces modules restent privés. Les consommateurs externes utilisent exclusivement les types et fonctions réexportés directement par `ks_lib`.
|
||||
|
||||
Les noms historiques ou issus d'IDL doivent être conservés dans le registre, mais ne doivent pas créer de nouveau module si un module canonique existe déjà.
|
||||
|
||||
@@ -178,13 +178,13 @@ Aucun renommage massif de modules n'est autorisé sans étape de contrôle dédi
|
||||
|
||||
## Règles de tracing
|
||||
|
||||
- Une crate ou un composant de `kb-lib` est opérationnel lorsqu’il effectue des I/O, orchestre un pipeline, décode, matérialise, exécute, applique une politique runtime ou prend une décision mutable observable.
|
||||
- Une crate ou un composant de `ks-lib` est opérationnel lorsqu’il effectue des I/O, orchestre un pipeline, décode, matérialise, exécute, applique une politique runtime ou prend une décision mutable observable.
|
||||
- Toute crate opérationnelle ajoutée ou modifiée doit dépendre de `tracing` depuis le workspace et déclarer exactement un `pub(crate) const TRACING_TARGET` dans `src/constants.rs`.
|
||||
- Hors `kb-lib`, la valeur canonique de `TRACING_TARGET_DECODER_METADATA_METAPLEX_TOKEN_METADATA` est le nom exact du package Cargo.
|
||||
- Dans `kb-lib`, chaque composant opérationnel possède son propre `constants.rs` et un target hiérarchique stable fondé sur son identifiant de décodeur, matérialiseur ou exécuteur ; un target unique `kb-lib` ne doit pas effacer l'identité du composant.
|
||||
- Hors `ks-lib`, la valeur canonique de `TRACING_TARGET_DECODER_METADATA_METAPLEX_TOKEN_METADATA` est le nom exact du package Cargo.
|
||||
- Dans `ks-lib`, chaque composant opérationnel possède son propre `constants.rs` et un target hiérarchique stable fondé sur son identifiant de décodeur, matérialiseur ou exécuteur ; un target unique `ks-lib` ne doit pas effacer l'identité du composant.
|
||||
- Les targets historiques `khbot.*` et les targets de fenêtre sont interdits dans les nouvelles modifications.
|
||||
- Les macros `tracing` doivent utiliser `target: crate::TRACING_TARGET` et des champs structurés stables. La granularité interne passe par `action`, `stage`, `window`, `campaign_id`, `signature`, `instruction_path`, `program_id`, `processor_name`, `processor_version`, `status` et `error_code`.
|
||||
- Les crates passives de types, contrats, DTO, API sans exécution, registres ou constantes restent sans dépendance `tracing`. `kb-config` reste une exception de bootstrap tant que sa validation précède l’installation du subscriber.
|
||||
- Les crates passives de types, contrats, DTO, API sans exécution, registres ou constantes restent sans dépendance `tracing`. `ks-config` reste une exception de bootstrap tant que sa validation précède l’installation du subscriber.
|
||||
- Il est interdit d’ajouter `tracing` sans événement réel, de conserver un tracing target déclaré mais inutilisé ou de consommer artificiellement un target avec `let _target`.
|
||||
- Une décision interne doit être journalisée par la crate responsable ; `kb-app-demo-desktop` ne journalise que les frontières Tauri/UI, les actions utilisateur et les résumés d’orchestration.
|
||||
- Tout input sélectionné sans décodeur compatible, tout résultat de décodage `failed` ou `unsupported`, tout résultat de matérialisation `failed`, toute validation de résultat invalide et toute erreur de persistance doivent émettre un événement `error` avant le retour ou la persistance terminale.
|
||||
@@ -201,14 +201,14 @@ Aucun renommage massif de modules n'est autorisé sans étape de contrôle dédi
|
||||
- Les dépendances déclarées dans `[workspace.dependencies]` forment un catalogue de versions et de features autorisées ; elles ne doivent être ajoutées à une crate consommatrice que lorsqu’un type, un encodeur, un décodeur ou un identifiant officiel est réellement utilisé.
|
||||
|
||||
- Dans un `Cargo.toml`, placer dans `[dependencies]` toute crate référencée par le code de bibliothèque compilé en production. Réserver `[dev-dependencies]` aux références contenues exclusivement dans `#[cfg(test)]`, les tests d’intégration, benches ou exemples. Une dépendance de test vers un décodeur ou matérialiseur concret est légitime lorsqu’elle sert uniquement à éprouver une orchestration générique fondée sur les traits API ; elle ne prouve pas qu’une capacité de production manque. Toute promotion de `dev-dependencies` vers `dependencies` doit être motivée par un appel runtime réel, et toute dépendance runtime inutilisée doit être supprimée.
|
||||
- Les registres de composition runtime des applications doivent énumérer explicitement chaque décodeur et matérialiseur concret activé. Toute nouvelle surface instructionnelle dotée d’un `MtApiEventMaterializer` doit être ajoutée au registre applicatif et couverte par un test d’inventaire ordonné ; une crate présente dans le workspace ou dans `kb_pipeline` n’est pas activée automatiquement. Les matérialiseurs exclusivement stateful qui n’implémentent pas `MtApiEventMaterializer` restent routés par leurs APIs de snapshots dédiées.
|
||||
- Les registres de composition runtime des applications doivent énumérer explicitement chaque décodeur et matérialiseur concret activé. Toute nouvelle surface instructionnelle dotée d’un `MtApiEventMaterializer` doit être ajoutée au registre applicatif et couverte par un test d’inventaire ordonné ; une crate présente dans le workspace ou dans `ks_pipeline` n’est pas activée automatiquement. Les matérialiseurs exclusivement stateful qui n’implémentent pas `MtApiEventMaterializer` restent routés par leurs APIs de snapshots dédiées.
|
||||
- Les corrélations instruction/état doivent produire une issue explicite (`confirmed`, `contradicted` ou `not_applicable`) et ne doivent jamais transformer automatiquement une configuration observée en violation, score ou conclusion métier.
|
||||
- Une interface officielle Solana ou SPL étroite doit être préférée à `solana-sdk` lorsque son contrat suffit.
|
||||
- L’ordre de préférence des formats est : schéma officiel `wincode`, schéma officiel Borsh, puis parseur local borné reproduisant exactement le runtime lorsque l’interface officielle n’expose que `bincode`.
|
||||
- Aucun nouveau code ne doit dépendre directement de `bincode`. Une interface officielle uniquement disponible derrière une feature `bincode` ne justifie pas l’activation de cette feature ; le layout doit alors être prouvé depuis les sources officielles et implémenté localement avec des bornes et des tests.
|
||||
- Les exécuteurs doivent utiliser les builders officiels disponibles, préserver l’ordre exact des metas, borner toute liste de comptes variable avant l’appel au builder et refuser les doublons lorsque leur répétition n’a pas de sémantique publiée.
|
||||
- Les features des interfaces doivent rester minimales et explicites. Une feature `serde`, `wincode`, `borsh`, `std`, `alloc` ou équivalente n’est activée que si la crate consommatrice l’utilise réellement.
|
||||
- Les crates applicatives ne doivent pas dépendre d’interfaces RPC ou transactionnelles uniquement pour relayer des types ; ces dépendances appartiennent à `kb_onchain_transport`, aux modèles communs justifiés ou à la crate opérationnelle propriétaire.
|
||||
- Les crates applicatives ne doivent pas dépendre d’interfaces RPC ou transactionnelles uniquement pour relayer des types ; ces dépendances appartiennent à `ks_onchain_transport`, aux modèles communs justifiés ou à la crate opérationnelle propriétaire.
|
||||
- Toute exception et toute implémentation locale doivent être documentées dans `docs/SOLANA_INTERFACE_DEPENDENCIES.md` avec la raison, la source officielle et la stratégie de test.
|
||||
- Tant que les types Solana consommés implémentent les traits de `wincode 0.5.x`, le catalogue
|
||||
workspace conserve `wincode = "^0.5"`. Le `Cargo.lock` local du workspace doit résoudre exactement
|
||||
@@ -221,13 +221,13 @@ Aucun renommage massif de modules n'est autorisé sans étape de contrôle dédi
|
||||
|
||||
## Règles des exécuteurs
|
||||
|
||||
- Les exécuteurs résident dans `kb_lib::executor`.
|
||||
- Une surface classifiée peut avoir un module décodeur et un module exécuteur distincts dans `kb-lib`.
|
||||
- Les exécuteurs résident dans `ks_lib::executor`.
|
||||
- Une surface classifiée peut avoir un module décodeur et un module exécuteur distincts dans `ks-lib`.
|
||||
- Les exécuteurs ne doivent pas dépendre des décodeurs.
|
||||
- Les exécuteurs utilisent les contrats `ExApi*` réexportés directement par la façade `kb_lib`.
|
||||
- Un squelette d’exécuteur doit exposer un type `Ex*Executor`, référencer uniquement des Program IDs de `kb-program-ids`, annoncer `Maybe` pour sa surface et construire exclusivement un plan réservé à zéro instruction.
|
||||
- Les exécuteurs utilisent les contrats `ExApi*` réexportés directement par la façade `ks_lib`.
|
||||
- Un squelette d’exécuteur doit exposer un type `Ex*Executor`, référencer uniquement des Program IDs de `ks-program-ids`, annoncer `Maybe` pour sa surface et construire exclusivement un plan réservé à zéro instruction.
|
||||
- La migration fonctionnelle d’un exécuteur doit remplacer ce comportement réservé par des capacités exactes `Supported` ou `Unsupported(reason)` ; aucun statut temporaire `LEGACY_CRATE` ou `MIGRATION_STATUS` ne doit subsister.
|
||||
- Les garde-fous communs doivent être placés dans les modules de sécurité partagés de `kb-lib`.
|
||||
- Les garde-fous communs doivent être placés dans les modules de sécurité partagés de `ks-lib`.
|
||||
- Aucun exécuteur ne doit envoyer de transaction sans simulation et validation explicite.
|
||||
- Les surfaces non classifiées ne doivent pas avoir de crate exécuteur.
|
||||
- La section « Couverture des exécuteurs » ci-dessus est normative pour chaque surface : la migration fonctionnelle doit fermer l’inventaire complet et ne peut pas sélectionner arbitrairement un sous-ensemble d’opérations officiellement constructibles.
|
||||
@@ -237,7 +237,7 @@ Aucun renommage massif de modules n'est autorisé sans étape de contrôle dédi
|
||||
|
||||
## Règles de configuration
|
||||
|
||||
- La configuration applicative commune doit passer par `kb-config`.
|
||||
- La configuration applicative commune doit passer par `ks-config`.
|
||||
- Les fichiers JSON de configuration ne doivent pas contenir de commentaires.
|
||||
- Les secrets ne doivent pas être écrits en clair dans le dépôt.
|
||||
- Les valeurs sensibles doivent utiliser des variables d'environnement ou un stockage chiffré dédié.
|
||||
@@ -245,23 +245,23 @@ Aucun renommage massif de modules n'est autorisé sans étape de contrôle dédi
|
||||
|
||||
## Ordre de développement cible
|
||||
|
||||
- `kb-logging` doit être stabilisé avant les logs avancés des autres crates.
|
||||
- `kb-config` doit être stabilisé avant les stores, RPC, wallet et applications.
|
||||
- `ks-logging` doit être stabilisé avant les logs avancés des autres crates.
|
||||
- `ks-config` doit être stabilisé avant les stores, RPC, wallet et applications.
|
||||
- Les contrats SQL et de matérialisation doivent être définis avant les gros décodeurs DEX.
|
||||
- Les implémentations détaillées des matérialisateurs doivent suivre les sorties réelles des décodeurs correspondants.
|
||||
- `kb-app-demo-desktop` doit fournir des validations live après chaque capacité majeure, sans créer une application Tauri séparée par crate.
|
||||
|
||||
## Constantes des composants de `kb-lib`
|
||||
## Constantes des composants de `ks-lib`
|
||||
|
||||
- Chaque composant classifié avec un `program_id` doit avoir son propre fichier `constants.rs`.
|
||||
- `constants.rs` contient les discriminators, sélecteurs, opcodes, constantes Borsh et constantes de décodage quand elles sont connues.
|
||||
- Le module parent puis `kb-lib/src/lib.rs` réexportent les constantes publiques nécessaires.
|
||||
- Les fichiers d'implémentation utilisent le chemin public le plus court réexporté par `kb-lib`.
|
||||
- Le module parent puis `ks-lib/src/lib.rs` réexportent les constantes publiques nécessaires.
|
||||
- Les fichiers d'implémentation utilisent le chemin public le plus court réexporté par `ks-lib`.
|
||||
- Les literals de `program_id` ne doivent pas rester dans `program_ids()`, sauf dans un fichier `constants.rs`.
|
||||
|
||||
## Identifiants de programmes
|
||||
|
||||
Les `program_id` connus doivent être définis une seule fois dans `kb-program-ids`. Les composants de décodeur, d’exécuteur, de store, d’application ou d’outil doivent référencer directement `kb_program_ids::XXX_PROGRAM_ID`. Les fichiers `constants.rs` locaux ne doivent pas redéfinir ces chaînes ; ils restent réservés aux constantes internes du module, par exemple discriminators, opcodes, seeds, index de comptes ou layouts.
|
||||
Les `program_id` connus doivent être définis une seule fois dans `ks-program-ids`. Les composants de décodeur, d’exécuteur, de store, d’application ou d’outil doivent référencer directement `ks_program_ids::XXX_PROGRAM_ID`. Les fichiers `constants.rs` locaux ne doivent pas redéfinir ces chaînes ; ils restent réservés aux constantes internes du module, par exemple discriminators, opcodes, seeds, index de comptes ou layouts.
|
||||
|
||||
## Validation frontend Tauri
|
||||
|
||||
@@ -274,14 +274,14 @@ Les `program_id` connus doivent être définis une seule fois dans `kb-program-i
|
||||
|
||||
## Architecture `khadhroony-bot3`
|
||||
|
||||
- Les décodeurs, exécuteurs et matérialisateurs résident exclusivement dans `kb-lib`.
|
||||
- Les décodeurs, exécuteurs et matérialisateurs résident exclusivement dans `ks-lib`.
|
||||
- Les modules peuvent posséder leur propre fichier de constantes.
|
||||
- Toute API publique portée depuis une ancienne crate doit être réexportée au crate root de `kb-lib`.
|
||||
- `kb-store` regroupe les contrats store-neutral et les adaptateurs de persistance, avec PostgreSQL comme adaptateur de production initial.
|
||||
- `kb-store/src/lib.rs` reste une façade : les DTO, entités, traits, requêtes et implémentations résident dans des modules privés dédiés et toute API publique est réexportée au crate root.
|
||||
- Les modèles source-neutral partagés avec les décodeurs, notamment `MdCoreInstructionReplayInput`, appartiennent à `kb-lib`; `kb-store` les consomme et les réexporte sans les dupliquer.
|
||||
- `kb-lib` ne dépend jamais de `kb-store`. Cette direction de dépendance évite tout cycle entre modèles, décodage et persistance.
|
||||
- `kb-store` ne dépend pas de `kb-config`. La frontière applicative transforme une configuration résolue en options de store explicitement validées.
|
||||
- Toute API publique portée depuis une ancienne crate doit être réexportée au crate root de `ks-lib`.
|
||||
- `ks-store` regroupe les contrats store-neutral et les adaptateurs de persistance, avec PostgreSQL comme adaptateur de production initial.
|
||||
- `ks-store/src/lib.rs` reste une façade : les DTO, entités, traits, requêtes et implémentations résident dans des modules privés dédiés et toute API publique est réexportée au crate root.
|
||||
- Les modèles source-neutral partagés avec les décodeurs, notamment `MdCoreInstructionReplayInput`, appartiennent à `ks-lib`; `ks-store` les consomme et les réexporte sans les dupliquer.
|
||||
- `ks-lib` ne dépend jamais de `ks-store`. Cette direction de dépendance évite tout cycle entre modèles, décodage et persistance.
|
||||
- `ks-store` ne dépend pas de `ks-config`. La frontière applicative transforme une configuration résolue en options de store explicitement validées.
|
||||
- Les adaptateurs concrets implémentent les mêmes traits neutres et ne font pas fuiter leurs types de connexion dans les contrats.
|
||||
- Seul `kb-app-demo-desktop` est conservé comme binaire pendant la migration initiale.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/validation/V0_4_8_METADATA_VALIDATION_REPORT.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Validation fonctionnelle — Metadata on-chain et clôture 0.4.8
|
||||
|
||||
@@ -41,7 +41,7 @@ Les cinq opérations indisponibles restent explicitement bornées par les observ
|
||||
|
||||
## Desktop Metadata
|
||||
|
||||
`kb-app-demo-desktop` sépare les trois domaines Metadata et appelle les scénarios réutilisables de `kb-pipeline-demo-scenarios`.
|
||||
`kb-app-demo-desktop` sépare les trois domaines Metadata et appelle les scénarios réutilisables de `ks-pipeline-demo-scenarios`.
|
||||
|
||||
La validation finale couvre notamment :
|
||||
|
||||
@@ -67,16 +67,16 @@ La campagne finale du 9 août 2026 est conforme :
|
||||
Les principales cibles unitaires observées comprennent :
|
||||
|
||||
- `kb-app-demo-desktop` : 144 tests ;
|
||||
- `kb-config` : 46 tests ;
|
||||
- `kb-core` : 2 tests ;
|
||||
- `kb-lib` : 706 tests, plus 9 tests d’intégration ;
|
||||
- `kb-logging` : 17 tests ;
|
||||
- `kb-onchain-transport` : 118 tests ;
|
||||
- `kb-pipeline` : 109 tests, plus 3 tests d’intégration Metadata ;
|
||||
- `kb-pipeline-demo-scenarios` : 105 tests bibliothèque, 1 test CLI et 1 test API externe ;
|
||||
- `kb-program-ids` : 6 tests ;
|
||||
- `kb-store` : 84 tests ;
|
||||
- `kb-wallet` : 6 tests.
|
||||
- `ks-config` : 46 tests ;
|
||||
- `ks-core` : 2 tests ;
|
||||
- `ks-lib` : 706 tests, plus 9 tests d’intégration ;
|
||||
- `ks-logging` : 17 tests ;
|
||||
- `ks-onchain-transport` : 118 tests ;
|
||||
- `ks-pipeline` : 109 tests, plus 3 tests d’intégration Metadata ;
|
||||
- `ks-pipeline-demo-scenarios` : 105 tests bibliothèque, 1 test CLI et 1 test API externe ;
|
||||
- `ks-program-ids` : 6 tests ;
|
||||
- `ks-store` : 84 tests ;
|
||||
- `ks-wallet` : 6 tests.
|
||||
|
||||
## Build desktop de release
|
||||
|
||||
|
||||
Reference in New Issue
Block a user