v0.5.1-pre.009
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: olddocs/archivekbot3/001.README.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# Archive documentaire de khadhroony-bot3
|
||||
|
||||
@@ -36,3 +36,7 @@ Le plan `0.4.8`, le prompt de session `028`, les audits `V0_4_8_PRE_*` et les ra
|
||||
## Clôture 0.5.0
|
||||
|
||||
Le plan de fondation `0.5.0`, les audits `pre.002` et `pre.003` ainsi que le prompt de session `029` sont archivés sous `docs/plans/` et `prompts/`. Les décisions durables ont été transférées au ROADMAP, aux documents d’architecture et à `docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md`.
|
||||
|
||||
## Clôture 0.5.1
|
||||
|
||||
Le plan de namespace/configuration `0.5.1` et le prompt de session `030` sont archivés sous `docs/plans/` et `prompts/`. Les décisions durables restent dans le ROADMAP, les guides de configuration, la politique de namespace et le rapport actif `docs/validation/V0_5_1_FOUNDATION_VALIDATION_REPORT.md`.
|
||||
|
||||
@@ -0,0 +1,785 @@
|
||||
<!-- file: olddocs/archivekbot3/docs/plans/V0_5_1_KHADHROONY_SOLANA_NAMESPACE_AND_CONFIG_PLAN.md -->
|
||||
<!-- version: 9 -->
|
||||
|
||||
# Plan archivé `0.5.1` — namespace Khadhroony Solana et configuration sûre
|
||||
|
||||
## 1. Statut de clôture
|
||||
|
||||
Ce document a servi de plan temporaire à `0.5.1` et est archivé lors de `0.5.1-pre.009`. Les prereleases `pre.001` à `pre.004` ont fermé l’inventaire puis migré crates, identités techniques et variables d’environnement ; `pre.005` à `pre.007` ont terminé le split logging/transport/listeners/store/wallet/execution ; `pre.008` et ses correctifs ont fermé les frontières source/runtime/public/diagnostic, TS-RS et la non-divulgation. `kb-app-demo-desktop` et le workspace racine ont conservé leur nom.
|
||||
|
||||
Le 10 août 2026, après `pre.008-delta-fix-003`, l’opérateur a validé `cargo fmt`, `cargo check --workspace`, `cargo clippy --all-targets`, l’audit workspace, `cargo test --workspace` et le démarrage Tauri. Les décisions durables ont été transférées au ROADMAP, aux guides, à la politique de namespace, aux TODO et au rapport de validation `0.5.1`. Ce plan n’est plus normatif.
|
||||
|
||||
## 2. Invariant du workspace racine
|
||||
|
||||
La migration `khadhroony-solana` **ne renomme pas le workspace, le dépôt ni le répertoire racine**.
|
||||
|
||||
Pendant toute la série pré-`1.0`, sauf décision ultérieure explicite :
|
||||
|
||||
```text
|
||||
workspace / repository / root directory = khadhroony-bot3
|
||||
```
|
||||
|
||||
Les bibliothèques internes Solana utilisent `ks-*` / `ks_*` et leurs variables possédées utilisent `KS_*`; les futurs contrats réellement spécifiques au Bot utiliseront `KB_*`. Elles restent toutes membres du workspace `khadhroony-bot3`. Un éventuel renommage du workspace racine ne doit pas être entrepris avant `khadhroony-bot3` `1.0` ou une version ultérieure explicitement dédiée à cette opération.
|
||||
|
||||
## 3. Frontière des domaines
|
||||
|
||||
- `khadhroony-project` : umbrella de projets de trading et/ou crypto, pouvant aussi contenir des projets de trading non crypto comme de futurs `khadhroony-xtb` ou `khadhroony-mt5` ;
|
||||
- `khadhroony-solana` : bibliothèques généralistes dédiées à Solana et réutilisables par plusieurs applications ;
|
||||
- `khadhroony-bot3` : workspace applicatif actuel et futur robot de trading consommant les composants `khadhroony-solana` ;
|
||||
- `kb-app-demo-desktop` : application du workspace Bot, actuellement banc de validation des composants Solana mais susceptible d'accueillir plus tard des démonstrations propres au bot.
|
||||
|
||||
`ks-pipeline-demo-scenarios` appartient bien à `khadhroony-solana` : ses scénarios qualifient les composants Solana et ne dépendent pas d'une stratégie de trading Bot.
|
||||
|
||||
## 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 |
|
||||
|
||||
`kb-app-demo-desktop` est adapté en dernier, mais garde son package, son répertoire et ses identifiants applicatifs.
|
||||
|
||||
`kb-pipeline-demo-scenarios` possède également :
|
||||
|
||||
```text
|
||||
lib : kb_pipeline_demo_scenarios -> ks_pipeline_demo_scenarios
|
||||
bin : kb-pipeline-demo-scenarios-cli -> ks-pipeline-demo-scenarios-cli
|
||||
```
|
||||
|
||||
### 4.1 Surface textuelle mesurée avant migration
|
||||
|
||||
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 |
|
||||
|
||||
Le volume `kb-lib` inclut notamment les identités techniques `kb-lib.*`; il ne doit pas être interprété comme autant d'importations Cargo.
|
||||
|
||||
### 4.2 Tests d'API externe à préserver
|
||||
|
||||
- `kb-lib/tests/external_decoder_api.rs` ;
|
||||
- `kb-lib/tests/external_executor_api.rs` ;
|
||||
- `kb-lib/tests/external_materializer_api.rs` ;
|
||||
- `kb-lib/tests/external_metaplex_token_metadata_executor_api.rs` ;
|
||||
- `kb-lib/tests/external_solana_program_metadata_account_api.rs` ;
|
||||
- `kb-lib/tests/external_solana_program_metadata_executor_api.rs` ;
|
||||
- `kb-lib/tests/external_solana_program_metadata_instruction_api.rs` ;
|
||||
- `kb-lib/tests/external_solana_program_metadata_model_api.rs` ;
|
||||
- `kb-lib/tests/operation_naming_matrix.rs` ;
|
||||
- `kb-pipeline/tests/external_metadata_metaplex_token_metadata_pipeline_api.rs` ;
|
||||
- `kb-pipeline/tests/external_metadata_solana_program_pipeline_api.rs` ;
|
||||
- `kb-pipeline/tests/external_metadata_token_2022_pipeline_api.rs` ;
|
||||
- `kb-pipeline-demo-scenarios/tests/external_metadata_solana_program_scenarios_api.rs`.
|
||||
|
||||
Les scripts d'audit contenant des références directes aux noms actuels incluent au minimum :
|
||||
|
||||
- `scripts/audit_khadhroony_workspace_rules.py` ;
|
||||
- `scripts/audit_rust_general_rules.py`.
|
||||
|
||||
Le renommage doit préserver la sémantique de ces audits, pas seulement les faire compiler.
|
||||
|
||||
## 5. Contrats qui suivent le renommage de crate
|
||||
|
||||
Le renommage physique `kb-*` -> `ks-*` couvre en `0.5.1` :
|
||||
|
||||
- répertoires des dix crates ;
|
||||
- `workspace.members` ;
|
||||
- noms `package` Cargo ;
|
||||
- noms de dépendances workspace et chemins `path` ;
|
||||
- identifiants Rust `kb_*` -> `ks_*` ;
|
||||
- nom de la lib et du CLI de `ks-pipeline-demo-scenarios` ;
|
||||
- imports, exports et tests d'API externe ;
|
||||
- scripts d'audit et commandes documentées ;
|
||||
- targets de tracing qui représentent réellement une crate `khadhroony-solana` ;
|
||||
- bindings TS-RS à la source lorsqu'ils incorporent une identité de crate. Les fichiers générés ne sont pas livrés sans nécessité explicite.
|
||||
|
||||
Ne suivent **pas** automatiquement le renommage :
|
||||
|
||||
- le workspace/repository/répertoire racine `khadhroony-bot3` ;
|
||||
- `kb-app-demo-desktop` ;
|
||||
- les tables SQL `kb_sol_*`, réservées à `0.5.3` -> `k_sol_*` ;
|
||||
- les éventuelles futures tables Bot `kb_*` ;
|
||||
- les noms sémantiques qui n'ont jamais été préfixés `kb` et ne représentent pas une identité de crate.
|
||||
|
||||
## 6. Identités runtime et persistées
|
||||
|
||||
L'inventaire actif vérifié en `pre.003` contient **255 identités uniques `kb-lib.*` à migrer** :
|
||||
|
||||
- 118 décodeurs ;
|
||||
- 112 exécuteurs ;
|
||||
- 25 matérialiseurs.
|
||||
|
||||
Le comptage de cadrage `pre.001` indiquait 256/113 exécuteurs ; le rescannage exhaustif du corpus réellement utilisé a corrigé cette dérive avant migration. Le mapping ci-dessous reste la source exhaustive des 255 identités historiques vers leurs identités `ks-lib-*`.
|
||||
|
||||
La règle de migration est :
|
||||
|
||||
```text
|
||||
kb-lib.decoder.<suffix> -> ks-lib-decoder.<suffix>
|
||||
kb-lib.executor.<suffix> -> ks-lib-executor.<suffix>
|
||||
kb-lib.materializer.<suffix> -> ks-lib-materializer.<suffix>
|
||||
```
|
||||
|
||||
Cette migration est volontaire avant `0.6.x` : les bases peuvent encore être reconstruites ou migrées, et conserver des identités `kb-lib.*` créerait une dette durable dans les replays, diagnostics et données persistées.
|
||||
|
||||
Les `processor_name` sémantiques déjà indépendants du préfixe de crate, par exemple `materializer.admin` ou `materializer.trades`, **ne doivent pas recevoir artificiellement un préfixe `ks-lib-`**. Seules les identités effectivement `kb`-namespacées migrent.
|
||||
|
||||
Les targets de tracing de crates génériques doivent également migrer vers `ks-*`. Les routes de logging doivent être mises à jour dans la même prerelease afin qu'un changement de target ne rende aucune sortie silencieuse.
|
||||
|
||||
### 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` |
|
||||
| `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` |
|
||||
|
||||
## 7. Inventaire des variables d'environnement
|
||||
|
||||
L'audit distingue trois ensembles afin de ne pas transformer des exemples historiques en contrats runtime :
|
||||
|
||||
- **85 noms** actuellement utilisés/référencés par le code, les tests, `.env.example`, les fixtures ou `config/app.config.json` ;
|
||||
- **17 noms supplémentaires** présents uniquement dans le guide opérateur Devnet actif ;
|
||||
- soit **102 noms historiques actifs à migrer ou consolider**, dont plusieurs convergent volontairement vers une même cible canonique.
|
||||
|
||||
Le chiffre `84` mentionné dans un audit `0.5.0` était une estimation antérieure et ne doit plus être utilisé comme contrat.
|
||||
|
||||
`KB_DATABASE_URL`, présent uniquement dans un exemple générique de `kb-config/USAGE.md`, est considéré obsolète et doit être supprimé/corrigé plutôt que migré. `KB_LIB_NOMENCLATURE` est un faux positif documentaire et n'est pas une variable d'environnement.
|
||||
|
||||
### 7.1 Politique cible
|
||||
|
||||
```text
|
||||
Khadhroony Solana / ks-* : KS_SECRET_* / KS_PUBLIC_* / KS_*
|
||||
Khadhroony Bot / kb-* : KB_SECRET_* / KB_PUBLIC_* / KB_*
|
||||
```
|
||||
|
||||
Le namespace suit le **propriétaire fonctionnel** du contrat. `kb-app-demo-desktop` peut donc lire une variable `KS_*` lorsqu'il adapte une capacité Solana ; cela ne transforme pas cette variable en contrat Bot. À l'issue de `pre.004`, aucun besoin d'environnement actuellement propre au desktop n'a été identifié : tous les noms runtime existants appartiennent à `ks-config`, `ks-store`, `ks-pipeline` ou `ks-pipeline-demo-scenarios`.
|
||||
|
||||
Dans chaque namespace :
|
||||
|
||||
- `*_SECRET_*` : jamais exposable ;
|
||||
- `*_PUBLIC_*` : candidate explicite à une surface publique, mais seulement via un DTO/surface autorisé ;
|
||||
- autre `KS_*` / `KB_*` : interne, diagnostic explicite seulement si non sensible.
|
||||
|
||||
La migration reste fail-closed. Les URLs PostgreSQL et la clé Helius sont des secrets certains. Les fixtures Token-2022 effectivement retournées au desktop sont classées `KS_PUBLIC_*`. Les autres contrôles de scénario restent internes. La propagation de sensibilité dans les valeurs composées et le camouflage effectif sont reportés après le split config/logging afin de ne pas mélanger renommage, restructuration et politique de sortie dans une seule prerelease.
|
||||
|
||||
Secrets certains :
|
||||
|
||||
```text
|
||||
HELIUS_API_KEY -> KS_SECRET_HELIUS_API_KEY
|
||||
KB_POSTGRES_DEVNET_URL -> KS_SECRET_POSTGRES_DEVNET_URL
|
||||
KB_POSTGRES_MAINNET_URL -> KS_SECRET_POSTGRES_MAINNET_URL
|
||||
KB_POSTGRES_TEST_URL -> KS_SECRET_POSTGRES_TEST_URL
|
||||
```
|
||||
|
||||
Les anciennes fixtures `TOKEN_2022_*` et les alias opérateur déjà préfixés convergent vers **un seul vocabulaire**. Par exemple `TOKEN_2022_MINT` et `KB_DEVNET_TOKEN_2022_MINT` convergent vers `KS_PUBLIC_DEVNET_TOKEN_2022_MINT`; `TOKEN_2022_PROGRAM` et `KB_SPL_TOKEN_2022_PROGRAM_ID` convergent vers `KS_PUBLIC_SPL_TOKEN_2022_PROGRAM_ID`; `KB_DEVNET_WALLET_ADDRESS` et `KB_DEVNET_WALLET_PUBKEY` convergent vers `KS_PUBLIC_DEVNET_WALLET_ADDRESS`. Aucun alias legacy permanent n'est conservé.
|
||||
|
||||
### 7.2 Mapping code/config/tests — 85 noms
|
||||
|
||||
| Nom actuel | Nom cible | Classe |
|
||||
|------------------------------|-----------------------------------|----------------|
|
||||
| `HELIUS_API_KEY` | `KS_SECRET_HELIUS_API_KEY` | `secret` |
|
||||
| `KB_CONFIG_PATH` | `KB_APP_DEMO_DESKTOP_CONFIG_PATH` | `internal` Bot |
|
||||
| `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` |
|
||||
|
||||
La cible `KB_APP_DEMO_DESKTOP_CONFIG_PATH` remplace la transition `KS_CONFIG_PATH` de `pre.004` : une composition appartient au binaire qui la charge, alors que les documents qu’elle référence restent possédés par les crates `ks-*`.
|
||||
| `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_PUBLIC_DEVNET_WALLET_ADDRESS` | `public` |
|
||||
| `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_PUBLIC_DEVNET_TOKEN_2022_APPROVE_AMOUNT_RAW` | `public` |
|
||||
| `TOKEN_2022_AUTHORITY` | `KS_PUBLIC_DEVNET_TOKEN_2022_AUTHORITY` | `public` |
|
||||
| `TOKEN_2022_BURN_AMOUNT_RAW` | `KS_PUBLIC_DEVNET_TOKEN_2022_BURN_AMOUNT_RAW` | `public` |
|
||||
| `TOKEN_2022_CLOSE_ACCOUNT` | `KS_PUBLIC_DEVNET_TOKEN_2022_CLOSE_ACCOUNT` | `public` |
|
||||
| `TOKEN_2022_DECIMALS` | `KS_PUBLIC_DEVNET_TOKEN_2022_DECIMALS` | `public` |
|
||||
| `TOKEN_2022_DELEGATE` | `KS_PUBLIC_DEVNET_TOKEN_2022_DELEGATE` | `public` |
|
||||
| `TOKEN_2022_DESTINATION` | `KS_PUBLIC_DEVNET_TOKEN_2022_DESTINATION` | `public` |
|
||||
| `TOKEN_2022_FREEZE_AUTHORITY` | `KS_PUBLIC_DEVNET_TOKEN_2022_FREEZE_AUTHORITY` | `public` |
|
||||
| `TOKEN_2022_MINT` | `KS_PUBLIC_DEVNET_TOKEN_2022_MINT` | `public` |
|
||||
| `TOKEN_2022_MINT_AMOUNT_RAW` | `KS_PUBLIC_DEVNET_TOKEN_2022_MINT_AMOUNT_RAW` | `public` |
|
||||
| `TOKEN_2022_PROGRAM` | `KS_PUBLIC_SPL_TOKEN_2022_PROGRAM_ID` | `public` |
|
||||
| `TOKEN_2022_SOURCE` | `KS_PUBLIC_DEVNET_TOKEN_2022_SOURCE` | `public` |
|
||||
| `TOKEN_2022_TRANSFER_AMOUNT_RAW` | `KS_PUBLIC_DEVNET_TOKEN_2022_TRANSFER_AMOUNT_RAW` | `public` |
|
||||
| `ELGAMAL_REGISTRY_ADDRESS` | `KS_PUBLIC_DEVNET_ELGAMAL_REGISTRY_ADDRESS` | `public` |
|
||||
| `ELGAMAL_PUBKEY_BASE64` | `KS_PUBLIC_DEVNET_ELGAMAL_PUBKEY_BASE64` | `public` |
|
||||
| `PUBKEY_VALIDITY_PROOF_CONTEXT` | `KS_PUBLIC_DEVNET_PUBKEY_VALIDITY_PROOF_CONTEXT` | `public` |
|
||||
|
||||
### 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` |
|
||||
| `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_PUBLIC_DEVNET_TOKEN_2022_MINT` | `public` |
|
||||
| `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_PUBLIC_DEVNET_WALLET_ADDRESS` | `public` |
|
||||
| `KB_SPL_TOKEN_2022_PROGRAM_ID` | `KS_PUBLIC_SPL_TOKEN_2022_PROGRAM_ID` | `public` |
|
||||
| `KB_SPL_TOKEN_PROGRAM_ID` | `KS_PUBLIC_SPL_TOKEN_PROGRAM_ID` | `public` |
|
||||
|
||||
## 8. Décomposition des documents de configuration
|
||||
|
||||
Le split est désormais fondé sur deux niveaux complémentaires :
|
||||
|
||||
1. chaque document spécialisé est autonome, possède ses valeurs globales et un `default_profile` ;
|
||||
2. une composition `<binary>.default.config.json` n'existe que lorsqu'un binaire doit remplacer des fichiers/profils ou porter des paramètres propres à l'application.
|
||||
|
||||
Les documents partagés à l'issue de `pre.007` sont :
|
||||
|
||||
```text
|
||||
config/logging.config.json
|
||||
config/transport.config.json
|
||||
config/listeners.config.json
|
||||
config/store.config.json
|
||||
config/wallet.config.json
|
||||
config/execution.config.json
|
||||
```
|
||||
|
||||
Le desktop conserve :
|
||||
|
||||
```text
|
||||
config/kb-app-demo-desktop.default.config.json
|
||||
```
|
||||
|
||||
`ks-pipeline-demo-scenarios` n'a plus de composition dédiée par défaut. En absence de `KS_DEVNET_CONFIG_PATH`, il compose directement les `default_profile` indépendants des documents partagés. Un override explicite reste possible pour un besoin opérateur particulier.
|
||||
|
||||
Les valeurs non dépendantes d'un profil sont sorties des profils :
|
||||
|
||||
- `logging.logs_directory = ${KS_LOGS_DIRECTORY:-logs}` ;
|
||||
- `wallet.wallets_directory = ${KS_WALLETS_DIRECTORY:-wallets}`.
|
||||
|
||||
Les chemins relatifs de logs et de wallets sont résolus sous ces racines. Les autorisations `*_send_enabled` appartiennent désormais à `execution.config.json`, pas à `wallet.config.json`.
|
||||
|
||||
Le transport possède des classes WebSocket de defaults nommées. Chaque endpoint choisit une classe et peut fournir ses propres `overrides`; `auto_reconnect` appartient donc au transport et non à `AppSectionConfig`. Les classes actuelles couvrent uniquement les surfaces réellement présentes : RPC WS standard et RPC WS à capacité supérieure. Une future surface Helius avancée aura sa propre classe/contrat lorsqu'elle sera implémentée.
|
||||
|
||||
Lorsqu'une composition référence un profil, `ks-config` doit prouver son existence avant de construire le runtime. Lorsqu'aucune composition n'est fournie, les noms des `default_profile` n'ont pas besoin d'être identiques : chaque document est résolu indépendamment. La composition ne devient pas une seconde surface de paramètres : les overrides de champ restent dans le contrat spécialisé qui les possède, et les globals explicitement configurables utilisent leurs variables d'environnement dédiées.
|
||||
|
||||
`AppConfig/ProfileConfig` demeure provisoirement un **contrat runtime résolu backend-only** pour préserver les consommateurs pendant la migration. Depuis `pre.008`, il ne contient plus les champs propres au desktop, ne dérive plus `serde::Serialize`/`Debug` et ne traverse plus Tauri. La section `application` de la composition est opaque à `ks-config`; le desktop la valide avec son propre schéma sans réintroduire un document généraliste monolithique.
|
||||
|
||||
## 9. Source, runtime, public et diagnostic
|
||||
|
||||
La configuration doit distinguer explicitement :
|
||||
|
||||
1. **source** : valeurs du fichier, références `${KS_*}`, informations nécessaires à la validation ;
|
||||
2. **runtime** : valeurs résolues utilisées par le backend, éventuellement secrètes ;
|
||||
3. **public** : DTO explicitement construit et strictement borné pour Tauri/TS-RS/UI ;
|
||||
4. **diagnostic** : surface explicitement demandée, pouvant montrer des valeurs `KS_*` internes non sensibles mais jamais une valeur `KS_SECRET_*`.
|
||||
|
||||
### 9.1 Frontière appliquée en `pre.008`
|
||||
|
||||
`kb-app-demo-desktop/src/demo_config.rs` ne transporte plus `AppConfig` ni `ProfileConfig`. Il construit explicitement :
|
||||
|
||||
```text
|
||||
runtime backend-only
|
||||
-> DemoConfigPublicPayload
|
||||
-> DemoConfigDiagnosticPayload
|
||||
```
|
||||
|
||||
La projection publique exclut URLs, DSN, chemins de stockage/wallet et politiques internes non destinées à l'UI. Le diagnostic borné ne transmet pour les valeurs sensibles que des états tels que `configured`/`missing`, plus les métadonnées internes explicitement autorisées.
|
||||
|
||||
La correction interdit le modèle :
|
||||
|
||||
```text
|
||||
serialize(runtime_config) -> supprimer quelques champs -> exposer
|
||||
```
|
||||
|
||||
Les contrats source/runtime de `ks-config` susceptibles de contenir des secrets résolus ne dérivent ni `serde::Serialize` ni `Debug`, et les sérialiseurs publics historiques de `AppConfig` sont supprimés. La sensibilité des placeholders est classée selon `Secret > Internal > Public`; une chaîne composée contenant un placeholder `KS_SECRET_*`/`KB_SECRET_*` hérite de `Secret`.
|
||||
|
||||
TS-RS est désormais une frontière applicative : `ks-config` et `ks-lib` ne dépendent plus de `ts-rs` et ne génèrent plus de bindings. `kb-app-demo-desktop` possède les DTO TS-RS nécessaires à ses commandes Tauri.
|
||||
|
||||
## 10. Tests de caractérisation avant et pendant migration
|
||||
|
||||
Avant chaque changement structurel correspondant, conserver ou ajouter des tests qui vérifient :
|
||||
|
||||
- la topologie des dix crates et leurs dépendances attendues ;
|
||||
- les 14 tests d'API externe et leurs imports par crate root ;
|
||||
- l'inventaire exact des identités runtime ;
|
||||
- l'absence de `kb-*` / `kb_*` résiduel dans les dix crates après leur prerelease de renommage, hors exceptions explicitement listées ;
|
||||
- le maintien de `khadhroony-bot3` comme nom racine ;
|
||||
- la cohérence entre targets de tracing et routes de logging ;
|
||||
- la résolution des anciennes fixtures/env pendant la phase de migration uniquement, puis leur suppression ;
|
||||
- l'interdiction des variables de configuration possédées par le workspace hors namespace d'ownership `KS_*` ou `KB_*` ;
|
||||
- la propagation de sensibilité depuis `KS_SECRET_*` vers les valeurs composées ;
|
||||
- l'impossibilité pour une sentinelle secrète d'apparaître dans `Debug`, logs, erreurs, payloads Tauri, sérialisation publique ou diagnostic ;
|
||||
- la validation indépendante des schémas source de composition, logging, transport, listeners, store, wallet et execution sous `config/schemas/` ;
|
||||
- la résolution indépendante des `default_profile` sans supposer des noms identiques ;
|
||||
- le refus des références de profils inexistants dans une composition ;
|
||||
- le maintien de `logs_directory` et `wallets_directory` hors profils ;
|
||||
- la résolution des classes de defaults WebSocket avant les overrides propres aux endpoints ;
|
||||
- la validation du schéma `resolved.app.config.schema.json` uniquement comme contrat runtime transitoire ;
|
||||
- l'indépendance des profils généralistes et logging ;
|
||||
- l'absence de duplication structurelle des types logging entre `ks-config` et `ks-logging` ;
|
||||
- le maintien des contrats publics réellement nécessaires après remplacement des types de configuration exposés.
|
||||
|
||||
Les tests ne doivent pas figer comme comportement légitime la fuite actuelle de configuration résolue.
|
||||
|
||||
## 11. Découpage borné des prereleases `0.5.1`
|
||||
|
||||
### `0.5.1-pre.001` — plan et inventaire
|
||||
|
||||
- présent document ;
|
||||
- version d'ouverture ;
|
||||
- aucune migration physique de crate ;
|
||||
- validation du mapping avant renommage massif.
|
||||
|
||||
### `0.5.1-pre.002` — packages et identifiants Rust `ks-*` / `ks_*`
|
||||
|
||||
- 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 ;
|
||||
- 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 hiérarchique `ks-lib-*`
|
||||
|
||||
- migrer les 255 identités `kb-lib.*` réellement présentes vers `ks-lib-*` ;
|
||||
- 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_*`.
|
||||
|
||||
### `0.5.1-pre.004` — namespaces d’environnement et classification
|
||||
|
||||
- migrer code, tests, `.env.example`, configuration et guides vers le namespace d’ownership `KS_*` ou `KB_*` ;
|
||||
- consolider les aliases historiques Token-2022 ;
|
||||
- matérialiser la classification secret/public/internal dans les noms et fermer les alias legacy ;
|
||||
- reporter la propagation de sensibilité et le camouflage effectif après le split config/logging ;
|
||||
- supprimer les anciens noms une fois la migration vérifiée ;
|
||||
- étendre l’audit workspace pour refuser la réintroduction de variables applicatives hors `KS_*` / `KB_*` dans le code, `.env.example`, la configuration exemple et le guide opérateur ;
|
||||
- ne pas encore modifier les DTO publics ni implémenter le camouflage, qui appartiennent désormais à `pre.008` après la fin du split des documents.
|
||||
|
||||
### `0.5.1-pre.005` — split config/logging
|
||||
|
||||
- **implémenté** : extraction initiale du logging hors de l’ancien document applicatif monolithique ;
|
||||
- **implémenté** : centralisation des schémas sous `config/schemas/` ;
|
||||
- **implémenté** : profils logging indépendants ;
|
||||
- **implémenté** : `ks-logging` devient propriétaire unique du contrat logging et de sa validation ;
|
||||
- **implémenté** : suppression de la conversion `ks_config::LoggingConfig` -> `ks_logging::LoggingConfig`.
|
||||
|
||||
### `0.5.1-pre.006` — composition binaire + transport + listeners
|
||||
|
||||
- **implémenté** : remplacement du rôle de `app.config.json` par des compositions `<binary>.default.config.json` ;
|
||||
- **implémenté** : création de `kb-app-demo-desktop.default.config.json` et première composition transitoire propre à `ks-pipeline-demo-scenarios`, ensuite supprimée en `pre.007` au profit des defaults partagés ;
|
||||
- **implémenté** : extraction des endpoints HTTP/WebSocket vers `transport.config.json` avec schéma et exemple dédiés ;
|
||||
- **implémenté** : extraction des listeners vers `listeners.config.json` avec schéma et exemple dédiés ;
|
||||
- **implémenté** : sélection explicite des profils logging/transport/listeners par chaque composition ;
|
||||
- **implémenté** : maintien temporaire de `AppConfig/ProfileConfig` comme contrat runtime résolu afin de ne pas casser tous les consommateurs pendant la migration ;
|
||||
- **implémenté** : consommation directe de `TransportProfileConfig` par `ks-onchain-transport` ;
|
||||
- **implémenté** : suppression des anciens fichiers source `app.config.json`, `example.app.config.json` et de leur schéma source historique ;
|
||||
- ne pas encore modifier les DTO publics ni la politique de camouflage.
|
||||
|
||||
### `0.5.1-pre.007` — defaults partagés + store + wallet + execution
|
||||
|
||||
- **implémenté** : extraction de `database` vers `store.config.json` ;
|
||||
- **implémenté** : suppression de `DataConfig`, avec `logs_directory` global dans logging et `wallets_directory` global dans wallet ;
|
||||
- **implémenté** : extraction du stockage/alias/persistance wallet vers `wallet.config.json` avec chemins relatifs à la racine globale ;
|
||||
- **implémenté** : déplacement de `localnet_send_enabled`, `devnet_send_enabled`, `testnet_send_enabled` et `mainnet_send_enabled` vers `execution.config.json` ;
|
||||
- **implémenté** : extraction complète des politiques d'exécution vers `execution.config.json` ;
|
||||
- **implémenté** : déplacement de `auto_reconnect` vers des classes de defaults WebSocket nommées, avec overrides par endpoint ;
|
||||
- **implémenté** : remplacement des `active_profile` des documents partagés par des `default_profile` autonomes ;
|
||||
- **implémenté** : suppression de la composition par défaut de `ks-pipeline-demo-scenarios`; les scénarios utilisent les defaults partagés sauf override explicite `KS_DEVNET_CONFIG_PATH` ;
|
||||
- **implémenté** : validation par `ks-config` de l'existence des profils référencés par une composition ;
|
||||
- **audit TS-RS** : 17 exports `export_to` restent dans `ks-config`, 100 dans `ks-lib` et 89 dans `kb-app-demo-desktop`; le frontend desktop n'importe directement que ses bindings `kb_app_demo_desktop`, aucun binding `ks-config`/`ks-lib`.
|
||||
|
||||
Le split partagé est considéré terminé après cette prerelease. Les champs applicatifs transitoires de la composition desktop seront traités avec la frontière publique/application de `pre.008`, et non par la création d'un nouveau document généraliste.
|
||||
|
||||
### `0.5.1-pre.008` — surfaces publiques sûres, TS-RS et camouflage
|
||||
|
||||
- **implémenté** : `AppConfig/ProfileConfig` et les documents source/runtime sensibles restent backend-only, sans `serde::Serialize` ni `Debug` ;
|
||||
- **implémenté** : le fragment `application` devient opaque pour `ks-config` et est validé par le schéma possédé par `kb-app-demo-desktop` ;
|
||||
- **implémenté** : `DemoConfigPayload` remplace la configuration résolue complète par des DTO public/diagnostic construits champ par champ ;
|
||||
- **implémenté** : URLs RPC/WS, DSN PostgreSQL et chemins sensibles ne traversent pas le payload configuration ; les diagnostics n'exposent que des états bornés ;
|
||||
- **implémenté** : classification `Secret > Internal > Public` des variables et chaînes composées, avec canaris de non-divulgation et erreurs de validation qui n'échoent plus les valeurs rejetées ;
|
||||
- **implémenté** : suppression de `ts-rs` de `ks-config` et `ks-lib`, suppression de leurs dérivations/export et de leurs bindings générés historiques ;
|
||||
- **implémenté** : audit workspace empêchant la réintroduction de TS-RS dans `ks-*` et de `Serialize`/`Debug` sur les contrats de configuration sensibles sans décision explicite ;
|
||||
- **implémenté** : test d'API externe de la classification/camouflage et canaris desktop empêchant la fuite de secrets dans les projections Tauri.
|
||||
|
||||
### `0.5.1-pre.009` — clôture
|
||||
|
||||
- réconciliation complète des namespaces, compositions, schémas et docs ;
|
||||
- audits finaux ;
|
||||
- suppression des TODO terminés ;
|
||||
- archivage de ce plan et du prompt `030` ;
|
||||
- préparation du prompt `0.5.2` pour `ks-wallet` ;
|
||||
- aucune nouvelle fonctionnalité structurelle majeure.
|
||||
|
||||
Un correctif `fix-XXX` n'avance jamais cette séquence ; sa numérotation repart à `fix-001` pour chaque prerelease.
|
||||
|
||||
## 12. Hors périmètre de `0.5.1`
|
||||
|
||||
- renommage du workspace/repository/répertoire racine `khadhroony-bot3` ;
|
||||
- restructuration fonctionnelle profonde de `ks-wallet` (`0.5.2`) ;
|
||||
- renommage des tables `kb_sol_*` -> `k_sol_*` et refonte temporelle/store (`0.5.3`) ;
|
||||
- centralisation finale des scénarios et audit de complétude exécuteurs (`0.5.4`) ;
|
||||
- programmes Anchor/DEX (`0.6.x+`) ;
|
||||
- nouvelle tentative de qualification réseau ElGamal sans nouvelle possibilité technique.
|
||||
|
||||
## 13. Contrôles de référence
|
||||
|
||||
À chaque delta Rust ou contractuel :
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
```
|
||||
|
||||
Le desktop n'est lancé avec `cargo tauri dev` que lorsqu'une frontière runtime/UI qu'il couvre change. Les scripts npm de build/dev ne sont jamais lancés directement.
|
||||
|
||||
## 14. Critères de sortie de `0.5.1`
|
||||
|
||||
`0.5.1` n'est clôturable que lorsque :
|
||||
|
||||
- les dix bibliothèques Solana utilisent `ks-*` / `ks_*` ;
|
||||
- le workspace racine s'appelle toujours `khadhroony-bot3` ;
|
||||
- les variables Solana ont migré vers `KS_*` avec classification nominale sûre et `KB_*` reste réservé aux futurs contrats Bot ;
|
||||
- les identités techniques `kb-lib.*` ciblées ont disparu au profit de `ks-lib-*` ;
|
||||
- les binaires utilisent leurs compositions dédiées et les documents logging/transport/listeners sont séparés, partageables et validés indépendamment ;
|
||||
- database, les répertoires logging/wallet, wallet, execution et les réglages propres au desktop ont quitté la composition avant la construction des surfaces publiques ;
|
||||
- aucune configuration runtime résolue complète ne traverse Tauri ;
|
||||
- aucun secret canari n'apparaît dans les surfaces publiques ou diagnostiques ;
|
||||
- les tests d'API externe, audits et tests workspace sont propres ;
|
||||
- les décisions durables ont quitté ce plan temporaire pour les documents normatifs avant archivage.
|
||||
@@ -0,0 +1,468 @@
|
||||
<!-- file: olddocs/archivekbot3/prompts/030_v0_5_1_khadhroony_solana_namespace_and_config.md -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# Khadhroony Bot3 — `0.5.1` — migration Khadhroony Solana et configuration sûre
|
||||
|
||||
## Mission
|
||||
|
||||
Reprendre `khadhroony-bot3` après la clôture validée de `0.5.0` et exécuter la première migration structurelle de la fondation `0.5.x`.
|
||||
|
||||
`0.5.1` doit accomplir deux objectifs liés :
|
||||
|
||||
1. séparer explicitement le domaine des bibliothèques Solana généralistes du domaine applicatif Khadhroony Bot en migrant les bibliothèques vers les namespaces `ks-*` / `ks_*` ;
|
||||
2. restructurer la configuration sur cette nouvelle fondation, avec `KS_*` pour les contrats Solana, `KB_*` réservé aux contrats Bot, séparation du logging et politique stricte de non-divulgation des secrets.
|
||||
|
||||
Cette version est une migration de fondation. Elle ne doit pas ouvrir de nouveau programme Anchor/DEX et ne doit pas absorber prématurément les chantiers `ks-wallet`, `ks-store` ou de complétude des scénarios réservés respectivement à `0.5.2`, `0.5.3` et `0.5.4`.
|
||||
|
||||
## Base validée à préserver
|
||||
|
||||
La release `0.5.0` est une version de cadrage sans restructuration runtime majeure. Elle a établi :
|
||||
|
||||
- la séparation de domaine entre `khadhroony-solana` et `khadhroony-bot` ;
|
||||
- l'inventaire des frontières de configuration, logging, wallet, store, scénarios et desktop ;
|
||||
- la cible de renommage des dix crates Solana généralistes ;
|
||||
- la convention d'environnement par ownership : `KS_*` pour Khadhroony Solana et `KB_*` pour les futurs contrats spécifiques au Bot ;
|
||||
- le split obligatoire de la configuration généraliste et de la configuration logging ;
|
||||
- la nécessité de séparer configuration source, runtime résolue et surfaces publiques/diagnostiques ;
|
||||
- la migration future des identités techniques `kb-lib.*` vers le domaine `ks-lib-*` ;
|
||||
- la migration SQL `kb_sol_*` → `k_sol_*` réservée à `0.5.3` ;
|
||||
- le maintien de `kb-app-demo-desktop` côté Bot ;
|
||||
- le maintien de l'exception ElGamal dans son statut synthétique actuel tant qu'aucune nouvelle preuve réseau n'est disponible.
|
||||
|
||||
La politique normative est :
|
||||
|
||||
```text
|
||||
docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md
|
||||
```
|
||||
|
||||
Elle doit être lue avant toute proposition de code.
|
||||
|
||||
## Positionnement des projets à conserver
|
||||
|
||||
`khadhroony-project` est une umbrella de projets de trading et/ou de crypto. Elle n'est pas limitée à Solana ni même à la crypto. Des projets futurs pourront par exemple viser XTB ou MetaTrader sans dépendre de Solana.
|
||||
|
||||
`khadhroony-solana` regroupe les bibliothèques généralistes dédiées à Solana.
|
||||
|
||||
`khadhroony-bot` / bot3 est le domaine applicatif du futur robot de trading consommant les composants Khadhroony Solana, avec à terme analyse/création de stratégies et exécution de trading automatique.
|
||||
|
||||
`kb-app-demo-desktop` reste dans le domaine Bot. Il sert actuellement surtout de banc de validation des composants Solana généralistes, mais pourra aussi accueillir des démonstrations spécifiques au bot.
|
||||
|
||||
Le workspace, le dépôt et le répertoire racine restent nommés `khadhroony-bot3` pendant toute la migration `0.5.1` et plus généralement jusqu'à `1.0` ou une version ultérieure explicitement dédiée. Renommer des crates vers `ks-*` ne doit jamais être interprété comme une autorisation de renommer le workspace racine.
|
||||
|
||||
## Lectures obligatoires avant toute proposition
|
||||
|
||||
1. `README.md`, `ROADMAP.md`, `CHANGELOG.md`, `RULES.md` et ce prompt ;
|
||||
2. `docs/decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md` ;
|
||||
3. toutes les règles actives sous `docs/rules/`, en particulier :
|
||||
- `RULES_GENERAL.md` ;
|
||||
- `RULES_RUST.md` ;
|
||||
- `RULES_SPECIFIC_KHADHROONY.md` ;
|
||||
- `CRATE_DOCUMENTATION_RULES.md` ;
|
||||
- `VERSION_DEVELOPMENT_LIFECYCLE.md` ;
|
||||
4. `docs/architecture/PROJECT_OBJECTIVES.md`, `CRATE_MAP.md`, `ARCHITECTURE.md`, `PIPELINE_ARCHITECTURE.md`, `STORAGE_ARCHITECTURE.md` et `SURFACE_CRATE_MATRIX.md` ;
|
||||
5. `README.md`, `USAGE.md`, `TODO.md` et `CHANGELOG.md` des dix crates à renommer et de `kb-app-demo-desktop` ;
|
||||
6. les compositions `config/<binary>.default.config.json`, les documents partagés `logging.config.json`, `transport.config.json`, `listeners.config.json`, leurs schémas sous `config/schemas/`, `.env.example` et les fixtures runtime sous `test-fixtures/config/` ;
|
||||
7. les tests d'API externe, tests TS-RS, scripts d'audit et références de noms de crates/targets/identités ;
|
||||
8. les documents archivés `0.5.0` uniquement comme historique, jamais comme source prioritaire face à la politique active et au code courant.
|
||||
|
||||
Avant de modifier un nom public, rechercher son usage réel dans les onze crates, les tests, scripts, fixtures, documentation et contrats persistés.
|
||||
|
||||
## Première prerelease obligatoire de `0.5.1`
|
||||
|
||||
La première prerelease de `0.5.1` est consacrée au plan détaillé de migration. Elle ne doit pas commencer par renommer des répertoires à l'aveugle.
|
||||
|
||||
Elle doit produire au minimum :
|
||||
|
||||
- la table exhaustive des dix crates et identifiants Rust à migrer ;
|
||||
- la table des dépendances workspace et ordre de renommage ;
|
||||
- l'inventaire des noms de packages, bins, libs, imports, exports, tests externes, scripts et documentation concernés ;
|
||||
- l'inventaire exhaustif des variables d'environnement actuellement utilisées, leur propriétaire `KS` ou `KB` et leur nom canonique ;
|
||||
- la classification de chaque variable en `*_SECRET_*`, `*_PUBLIC_*` ou interne dans le namespace de son propriétaire ;
|
||||
- l'inventaire des identités runtime/persistées et targets techniques à migrer ;
|
||||
- l'inventaire des payloads Tauri/TS-RS pouvant actuellement transporter de la configuration résolue ;
|
||||
- l'inventaire des structures dupliquées entre configuration et logging ;
|
||||
- la stratégie de migration des fichiers de configuration et schémas ;
|
||||
- les tests de caractérisation nécessaires avant changement ;
|
||||
- un plan temporaire `0.5.1` sous `docs/plans/`, à archiver à la dernière prerelease de la version.
|
||||
|
||||
Le plan doit être validé avant le premier renommage massif.
|
||||
|
||||
## Migration obligatoire des crates vers `ks-*`
|
||||
|
||||
Les dix crates généralistes doivent migrer ainsi :
|
||||
|
||||
```text
|
||||
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
|
||||
```
|
||||
|
||||
Les identifiants Rust correspondants migrent de `kb_*` vers `ks_*`.
|
||||
|
||||
`kb-app-demo-desktop` conserve son nom.
|
||||
|
||||
La migration doit couvrir de manière cohérente :
|
||||
|
||||
- noms de répertoires ;
|
||||
- `Cargo.toml` workspace et manifests des crates ;
|
||||
- noms de package, library et binary lorsqu'ils appartiennent au domaine Solana généraliste ;
|
||||
- dépendances workspace ;
|
||||
- chemins Rust ;
|
||||
- imports et réexports ;
|
||||
- tests d'API externe ;
|
||||
- scripts Python ;
|
||||
- fixtures et matrices lorsque le nom fait partie d'un contrat actif ;
|
||||
- documentation active ;
|
||||
- configuration Tauri uniquement là où elle référence les crates renommées ;
|
||||
- TS-RS à la source, sans livrer artificiellement les bindings générés.
|
||||
|
||||
La migration ne doit pas créer de dépendance d'une crate `ks-*` vers `kb-app-demo-desktop` ou une future application Bot.
|
||||
|
||||
## Identités runtime, tracing et persistance
|
||||
|
||||
La migration de namespace inclut les identités techniques généralistes actuellement préfixées par `kb-lib`.
|
||||
|
||||
La cible comprend notamment :
|
||||
|
||||
```text
|
||||
kb-lib.decoder.* -> ks-lib-decoder.*
|
||||
kb-lib.materializer.* -> ks-lib-materializer.*
|
||||
kb-lib.executor.* -> ks-lib-executor.*
|
||||
```
|
||||
|
||||
Avant remplacement, établir une matrice exhaustive des catégories concernées :
|
||||
|
||||
- tracing targets ;
|
||||
- `processor_name` ;
|
||||
- identités de replay ;
|
||||
- identités d'idempotence ;
|
||||
- clés de provenance ;
|
||||
- valeurs persistées dans les tests/fixtures ;
|
||||
- diagnostics et matrices contractuelles ;
|
||||
- tout autre identifiant stable contenant un préfixe historique `kb-*` ou `kb-lib.*`.
|
||||
|
||||
La base peut encore être reconstruite ou migrée avant `0.6.x`. Il est donc acceptable de casser proprement une identité historique si elle appartient réellement à Khadhroony Solana, à condition que la migration soit explicite, testée et documentée.
|
||||
|
||||
Ne pas renommer arbitrairement les segments métier `solana`, `spl`, protocoles, surfaces ou opérations lorsqu'ils expriment déjà une sémantique stable.
|
||||
|
||||
## Tables SQL : ne pas anticiper `0.5.3`
|
||||
|
||||
La cible durable des tables Solana est :
|
||||
|
||||
```text
|
||||
kb_sol_* -> k_sol_*
|
||||
```
|
||||
|
||||
et les éventuelles tables réellement spécifiques au domaine Bot utiliseront :
|
||||
|
||||
```text
|
||||
kb_*
|
||||
```
|
||||
|
||||
Cependant, le renommage physique des tables et la normalisation des migrations appartiennent à `0.5.3` avec `ks-store`, car ce chantier doit être traité avec `block_time`, provenance, idempotence, index et contrats de replay.
|
||||
|
||||
`0.5.1` peut mettre à jour les identités techniques persistées `ks-lib-*`, mais ne doit pas transformer la migration SQL en chantier secondaire dispersé.
|
||||
|
||||
## Namespace obligatoire des variables d'environnement
|
||||
|
||||
Le namespace suit le propriétaire fonctionnel du contrat :
|
||||
|
||||
```text
|
||||
Khadhroony Solana / ks-* : KS_SECRET_* / KS_PUBLIC_* / KS_*
|
||||
Khadhroony Bot / kb-* : KB_SECRET_* / KB_PUBLIC_* / KB_*
|
||||
```
|
||||
|
||||
Une variable de scénario ou de configuration Solana reste `KS_*` même si `kb-app-demo-desktop` la consomme. `KB_*` est réservé aux besoins réellement propres au desktop ou aux futures crates du Bot. Les variables standard de l'OS, de Cargo ou d'outils tiers ne sont pas renommées artificiellement.
|
||||
|
||||
Les classes ont la même sémantique dans les deux namespaces :
|
||||
|
||||
- `*_SECRET_*` : secret absolu, jamais exposé ni loggé ;
|
||||
- `*_PUBLIC_*` : candidate explicite à une surface publique, sans autorisation automatique d'exposition ;
|
||||
- autres `KS_*` / `KB_*` : internes, absentes des payloads normaux.
|
||||
|
||||
La migration des noms et la fermeture des alias legacy appartiennent à `pre.004`. La propagation de sensibilité dans les valeurs composées, le camouflage et les DTO publics sûrs sont réalisés après le split config/logging.
|
||||
|
||||
## Split obligatoire de la configuration
|
||||
|
||||
`0.5.1` doit extraire la configuration logging du document généraliste.
|
||||
|
||||
La cible minimale est conceptuellement :
|
||||
|
||||
```text
|
||||
configuration générale + schéma général
|
||||
configuration logging + schéma logging
|
||||
```
|
||||
|
||||
Les profils généralistes et logging sont indépendants. Il ne doit plus être nécessaire de recopier un bloc logging complet dans chaque profil réseau/applicatif.
|
||||
|
||||
D'autres documents spécialisés sont autorisés seulement si l'audit démontre qu'ils réduisent réellement le couplage et possèdent une responsabilité ou validation indépendante.
|
||||
|
||||
Ne pas découper arbitrairement la configuration en un fichier par sous-structure.
|
||||
|
||||
## Propriété des contrats de logging
|
||||
|
||||
`0.5.0` a constaté une duplication des structures `LoggingConfig`, `LogTargetConfig` et `LogTargetFilterConfig` entre la configuration et le runtime logging.
|
||||
|
||||
`0.5.1` doit définir un propriétaire clair du contrat source de logging sans créer de cycle de dépendances.
|
||||
|
||||
La solution retenue doit :
|
||||
|
||||
- éviter une duplication de DTO identiques ;
|
||||
- éviter que `ks-config` dépende du runtime `ks-logging` uniquement pour réutiliser un type ;
|
||||
- éviter une nouvelle crate de contrat si elle n'a pas de responsabilité autonome suffisante ;
|
||||
- supprimer les conversions manuelles du desktop lorsque la nouvelle frontière le permet.
|
||||
|
||||
## Configuration source, runtime et publique
|
||||
|
||||
La restructuration doit empêcher qu'une configuration résolue complète puisse être envoyée au frontend par commodité.
|
||||
|
||||
Distinguer au minimum :
|
||||
|
||||
1. représentation source : fichiers, placeholders et références `${KS_*}` / `${KB_*}` ;
|
||||
2. représentation runtime : valeurs validées et résolues nécessaires au backend ;
|
||||
3. représentation publique/diagnostique : DTO explicitement construits pour l'UI, les diagnostics ou une API externe.
|
||||
|
||||
Une valeur runtime contenant un secret ne doit pas redevenir une `String` publique sans classification ni contrôle.
|
||||
|
||||
Éviter le modèle :
|
||||
|
||||
```text
|
||||
runtime complet -> sérialisation -> suppression/redaction après coup
|
||||
```
|
||||
|
||||
Préférer :
|
||||
|
||||
```text
|
||||
runtime -> construction explicite d'un DTO public sûr
|
||||
```
|
||||
|
||||
## Résolution d'environnement et `.env`
|
||||
|
||||
Auditer et tester :
|
||||
|
||||
- `${NAME}` ;
|
||||
- `${NAME:-fallback}` ;
|
||||
- erreurs de variable absente ;
|
||||
- valeurs vides ;
|
||||
- substitutions multiples ;
|
||||
- valeurs composées ;
|
||||
- détection et propagation de la sensibilité ;
|
||||
- priorité environnement / `.env` / valeur par défaut selon le contrat actuel ;
|
||||
- absence de fuite dans les messages d'erreur ;
|
||||
- comportement des profils.
|
||||
|
||||
Le mécanisme final doit accepter uniquement les noms de variables conformes au nouveau contrat lorsqu'ils appartiennent au workspace.
|
||||
|
||||
## Payloads Tauri et TS-RS
|
||||
|
||||
Le risque prioritaire identifié en `0.5.0` est l'exposition de `AppConfig` / `ProfileConfig` résolus au frontend.
|
||||
|
||||
`0.5.1` doit supprimer cette possibilité par construction.
|
||||
|
||||
Les commandes Tauri restent des adaptateurs minces :
|
||||
|
||||
- aucune logique métier nouvelle dans `tauri.rs` ;
|
||||
- aucun `?` ni unwrap dans les commandes Tauri ;
|
||||
- DTO publics dédiés ;
|
||||
- aucun secret résolu dans les bindings ou réponses ;
|
||||
- diagnostics séparés des payloads normaux ;
|
||||
- tests négatifs avec valeurs sentinelles secrètes.
|
||||
|
||||
## Tests de sécurité obligatoires
|
||||
|
||||
Ajouter des tests prouvant notamment que :
|
||||
|
||||
- une sentinelle issue de `KS_SECRET_*` ou `KB_SECRET_*` n'apparaît dans aucune sérialisation publique ;
|
||||
- elle n'apparaît pas dans les erreurs publiques ;
|
||||
- elle n'apparaît pas dans les diagnostics debug ;
|
||||
- une URL ou DSN composée avec un secret est entièrement traitée comme sensible ;
|
||||
- `KS_PUBLIC_*` / `KB_PUBLIC_*` n'est exposé que par une surface explicitement autorisée ;
|
||||
- une variable interne `KS_*` / `KB_*` n'apparaît pas dans le payload normal ;
|
||||
- les anciens noms d'environnement sont absents après migration ;
|
||||
- les schémas JSON général et logging valident leurs documents respectifs ;
|
||||
- le choix d'un profil logging est indépendant du profil général ;
|
||||
- les tests d'API externe compilent avec les nouveaux noms `ks_*`.
|
||||
|
||||
Ne pas figer par test un comportement `0.5.0` connu comme dangereux uniquement pour préserver la compatibilité.
|
||||
|
||||
## Ordre approximatif des prereleases
|
||||
|
||||
Le détail doit être confirmé par `0.5.1-pre.001`, mais la trajectoire cible est :
|
||||
|
||||
### `0.5.1-pre.001` — plan de migration
|
||||
|
||||
- inventaires exhaustifs ;
|
||||
- table de renommage ;
|
||||
- matrice d'identités ;
|
||||
- matrice des variables d'environnement ;
|
||||
- stratégie config/logging ;
|
||||
- tests de caractérisation ;
|
||||
- plan temporaire.
|
||||
|
||||
### `0.5.1-pre.002` — migration mécanique `ks-*` / `ks_*`
|
||||
|
||||
- renommer les dix crates ;
|
||||
- manifests, imports, exports, scripts et tests ;
|
||||
- maintenir un workspace compilable et auditable ;
|
||||
- conserver `kb-app-demo-desktop`.
|
||||
|
||||
### `0.5.1-pre.003` — identités techniques `ks-lib-*`
|
||||
|
||||
- migrer les targets et identités runtime/persistables généralistes ;
|
||||
- synchroniser matrices, tracing, diagnostics et provenance/replay ;
|
||||
- conserver encore les variables d'environnement pour la prerelease suivante.
|
||||
|
||||
### `0.5.1-pre.004` — environnement et classification nominale
|
||||
|
||||
- migrer les contrats Solana vers `KS_*` et réserver `KB_*` aux futurs contrats Bot ;
|
||||
- classer les secrets en `*_SECRET_*`, les valeurs explicitement publiques en `*_PUBLIC_*` et le reste en interne ;
|
||||
- consolider les alias historiques Token-2022 ;
|
||||
- mettre à jour `.env.example`, configuration, fixtures, scénarios, store, desktop et guides ;
|
||||
- ne pas encore implémenter le camouflage ou la propagation de sensibilité.
|
||||
|
||||
### `0.5.1-pre.005` — split configuration/logging
|
||||
|
||||
- extraire le logging dans son document et son schéma indépendants ;
|
||||
- rendre les profils logging indépendants ;
|
||||
- transférer la propriété des contrats logging à `ks-logging`.
|
||||
|
||||
### `0.5.1-pre.006` — composition binaire + transport + listeners
|
||||
|
||||
- remplacer le rôle du document monolithique par des compositions `<binary>.default.config.json` ;
|
||||
- fournir une composition dédiée au desktop et une composition dédiée aux scénarios ;
|
||||
- extraire transport et listeners dans des documents/schémas indépendants ;
|
||||
- conserver `AppConfig/ProfileConfig` comme contrat runtime résolu transitoire ;
|
||||
- permettre aux transports de consommer directement `TransportProfileConfig`.
|
||||
|
||||
### `0.5.1-pre.007` — store + wallet + execution + configuration dédiée des binaires
|
||||
|
||||
- extraire database vers store, `logs_directory` vers logging et les chemins de wallets vers wallet selon leur ownership réel ;
|
||||
- déplacer les permissions `*_send_enabled` du wallet vers execution ;
|
||||
- sortir la configuration spécifique au desktop du domaine `ks-config` ;
|
||||
- réduire les compositions à des références vers profils spécialisés et configuration dédiée ;
|
||||
- vérifier qu'un futur worker peut ajouter sa propre composition sans enregistrer son identité dans `ks-config`.
|
||||
|
||||
### `0.5.1-pre.008` — runtime/public, camouflage et Tauri sûr
|
||||
|
||||
- **réalisé** : rendre les contrats `ks-config` source/runtime sensibles backend-only, sans `Serialize`/`Debug` ;
|
||||
- **réalisé** : rendre `application` opaque pour `ks-config` et valider le fragment desktop avec son schéma propriétaire ;
|
||||
- **réalisé** : remplacer l'exposition `AppConfig/ProfileConfig` par des DTO public/diagnostic construits explicitement ;
|
||||
- **réalisé** : propager `Secret > Internal > Public` aux chaînes composées et supprimer l'écho de valeurs rejetées dans les erreurs de validation ;
|
||||
- **réalisé** : retirer TS-RS et les bindings générés de `ks-config`/`ks-lib`, avec audit empêchant leur réintroduction implicite ;
|
||||
- **réalisé** : ajouter les canaris de non-divulgation et le test d'API externe de sensibilité.
|
||||
|
||||
### `0.5.1-pre.009` — réconciliation et clôture
|
||||
|
||||
- audit exhaustif des anciens préfixes et anciens documents ;
|
||||
- documentation finale ;
|
||||
- TODO/changelogs ;
|
||||
- validations workspace ;
|
||||
- archivage du plan/prompt ;
|
||||
- préparation de `0.5.2`.
|
||||
|
||||
Ce découpage reste borné : aucun chantier SQL `k_sol_*`, wallet ou DEX n'est absorbé dans `0.5.1`.
|
||||
|
||||
## Règles de développement à conserver
|
||||
|
||||
- Rust 2024 ;
|
||||
- aucune utilisation de `unsafe`, `unwrap`, `expect` ou `panic` dans le code de production ;
|
||||
- imports réservés aux traits nécessaires, chemins explicites pour les autres symboles ;
|
||||
- respect des en-têtes `file:` / `version:` et incrément des versions locales des fichiers modifiés ;
|
||||
- documentation Rust en anglais, documentation Markdown en français ;
|
||||
- aucune ligne vide interne artificielle dans les fonctions Rust et exactement une newline en fin de fichier ;
|
||||
- aucune logique métier nouvelle dans `kb-app-demo-desktop` lorsqu'elle peut résider dans une crate `ks-*` réutilisable ;
|
||||
- les commandes Tauri restent des adaptateurs minces et n'utilisent ni `?` ni unwrap ;
|
||||
- les archives sous `olddocs/` ne sont jamais réécrites hors opération d'archivage explicitement demandée.
|
||||
|
||||
## Règle frontend/Tauri obligatoire
|
||||
|
||||
Ne jamais lancer directement :
|
||||
|
||||
```text
|
||||
npm run dev
|
||||
npm run build
|
||||
npm --prefix kb-app-demo-desktop run build
|
||||
```
|
||||
|
||||
Les commandes npm manuelles sont limitées à l'installation explicite de dépendances nécessaires, notamment `npm i` et `npm i -D`.
|
||||
|
||||
Le développement desktop est piloté par :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
Le build de release est piloté par :
|
||||
|
||||
```bash
|
||||
cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
Tauri déclenche lui-même les scripts frontend configurés.
|
||||
|
||||
## Discipline des scénarios et validations
|
||||
|
||||
Le renommage de `kb-pipeline-demo-scenarios` vers `ks-pipeline-demo-scenarios` ne change pas son rôle : les scénarios sont des validations réutilisables des composants Solana, pas de la logique spécifique au bot.
|
||||
|
||||
Les campagnes déjà qualifiées ne doivent pas être rejouées automatiquement uniquement parce qu'une crate ou un identifiant a changé de nom. Les tests contractuels, compilations et chemins de preuve doivent être vérifiés ; un rerun réseau n'est requis que si une frontière réellement couverte par la preuve a changé.
|
||||
|
||||
ElGamal reste une exception connue et ne doit pas devenir une tâche implicite de `0.5.1`.
|
||||
|
||||
## Documentation et deltas
|
||||
|
||||
À chaque prerelease ou correctif :
|
||||
|
||||
- mettre à jour uniquement les documents rendus faux ou incomplets ;
|
||||
- conserver les README/USAGE généralistes ;
|
||||
- utiliser les changelogs pour la chronologie ;
|
||||
- supprimer les TODO terminés ;
|
||||
- maintenir le plan temporaire ;
|
||||
- livrer uniquement un ZIP delta avec `delta.md` ;
|
||||
- ne jamais livrer `Cargo.lock`, les lockfiles frontend, `node_modules`, `dist`, `target` ou les bindings générés sans nécessité explicite ;
|
||||
- ne jamais fournir de SHA/checksum dans la réponse de livraison ;
|
||||
- recommencer la numérotation `fix-001` à chaque nouvelle prerelease.
|
||||
|
||||
Un renommage mécanique massif doit rester traçable dans `delta.md` et ne doit pas masquer des changements fonctionnels sans rapport.
|
||||
|
||||
## Dernière prerelease obligatoire
|
||||
|
||||
La dernière prerelease de `0.5.1` devra :
|
||||
|
||||
- exécuter les validations finales ;
|
||||
- vérifier qu'aucun ancien nom de crate ou variable projet interdit ne subsiste hors archives/historique explicitement autorisé ;
|
||||
- vérifier les identités runtime/persistées migrées ;
|
||||
- vérifier la non-divulgation des secrets ;
|
||||
- finaliser README, ROADMAP, changelogs, TODO, règles, guides et schémas concernés ;
|
||||
- transférer les décisions durables du plan vers les documents normatifs ;
|
||||
- archiver le plan et le prompt de session terminés sous `olddocs/archivekbot3/` ;
|
||||
- préparer le prompt `0.5.2` consacré à `ks-wallet` ;
|
||||
- préparer la release finale sans introduire un nouveau chantier structurel majeur.
|
||||
|
||||
## Contrôles de référence
|
||||
|
||||
```bash
|
||||
cargo fmt --all
|
||||
cargo check --workspace
|
||||
cargo clippy --all-targets
|
||||
python3 scripts/audit_rust_workspace_rules.py
|
||||
cargo test --workspace
|
||||
```
|
||||
|
||||
Lorsque le desktop doit être validé :
|
||||
|
||||
```bash
|
||||
cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
|
||||
Pour une validation de release desktop :
|
||||
|
||||
```bash
|
||||
cargo tauri build -c kb-app-demo-desktop/tauri.conf.json
|
||||
```
|
||||
Reference in New Issue
Block a user