@@ -102,12 +103,10 @@ Les preuves détaillées de `0.4.8-pre.*` restent accessibles sous `../olddocs/a
## 10. Plans de version actifs
Le cadrage`0.5.0` est clôturé. Son plan et les audits `pre.002`/`pre.003` sont archivés sous `../olddocs/archivekbot3/docs/plans/`.
Les plans temporaires`0.5.0` et `0.5.1` sont clôturés et archivés sous `../olddocs/archivekbot3/docs/plans/`.
Plan actif de `0.5.1`:
- [`V0_5_1_KHADHROONY_SOLANA_NAMESPACE_AND_CONFIG_PLAN.md`](plans/V0_5_1_KHADHROONY_SOLANA_NAMESPACE_AND_CONFIG_PLAN.md) — inventaire de migration `ks-*` / `ks_*` / `KS_*`, configuration sûre et découpage borné des prereleases.
Le plan détaillé de `0.5.2` sera créé dans sa première prerelease conformément au cycle de développement ; aucun plan temporaire `0.5.2`n’est préécrit avant cet inventaire.
@@ -69,7 +69,7 @@ Il dépend des contrats de `ks-lib`, des données de `ks-store` et des capacité
-`ks-pipeline-demo-scenarios` fournit les fixtures et campagnes réseau réutilisables spécifiques aux validations Devnet/Testnet. Les scénarios réutilisables doivent être appelables sans dépendre du desktop.
- Le binaire `ks-pipeline-demo-scenarios-cli` reste un outil ciblé ; son existence n’impose pas d’exposer chaque scénario par un CLI.
-`kb-app-demo-desktop` est une crate mixte : bibliothèque Tauri et binaire desktop. Les commandes et projections UI y restent, tandis que la logique de scénario réutilisable doit être déléguée à `ks-pipeline-demo-scenarios`. Le reliquat éventuel de scénarios encore déclarés directement dans le desktop sera audité en `0.5.4`.
-`ks-wallet` fournit actuellement une frontière limitée de wallet temporaire et de signataire. Elle devient `ks-wallet` en`0.5.1`, puis sa restructuration fonctionnelle est planifiée en `0.5.2`.
-`ks-wallet` fournit actuellement une frontière limitée de wallet temporaire et de signataire. Son namespace `ks-*` est stabilisé depuis`0.5.1` et sa restructuration fonctionnelle est planifiée en `0.5.2`.
- Les IDs canoniques ne doivent pas être dispersés lorsqu’ils appartiennent au registre de `ks-program-ids`.
- Les APIs publiques de modèles, décodeurs, exécuteurs et matérialisateurs sont exposées par `ks-lib`.
- Les commandes Tauri et payloads frontend spécifiques restent dans `kb-app-demo-desktop`.
- Les scénarios réseau réutilisables spécifiques à Devnet/Testnet appartiennent à `ks-pipeline-demo-scenarios`, future `ks-pipeline-demo-scenarios`. `kb-app-demo-desktop` doit se limiter à l’adaptation Tauri, aux payloads UI, à la présentation et à l’appel de ces scénarios ; les doublons résiduels seront réconciliés en `0.5.4`.
- Les scénarios réseau réutilisables spécifiques à Devnet/Testnet appartiennent à `ks-pipeline-demo-scenarios`. `kb-app-demo-desktop` doit se limiter à l’adaptation Tauri, aux payloads UI, à la présentation et à l’appel de ces scénarios ; les doublons résiduels seront réconciliés en `0.5.4`.
- Toute primitive ou orchestration réellement généraliste, indépendante de l’UI et d’une campagne de démonstration précise, appartient à `ks-pipeline` ou à la crate métier propriétaire.
- Les fixtures contractuelles communes restent sous `test-fixtures/contract-matrices/` lorsqu’elles sont consommées par plusieurs tests.
- Les archives documentaires ne participent ni au build ni aux décisions normatives.
La migration bot2 vers bot3 est close pour le périmètre fonctionnel repris jusqu’à `0.4.7`. La version `0.4.8` complète ensuite la fondation Metadata on-chain en distinguant Solana Program Metadata, Token-2022 Token Metadata et Metaplex Token Metadata, avec leurs décodeurs, matérialisateurs, exécuteurs lorsque applicables, orchestration stateful, scénarios réutilisables et intégration desktop.
`0.5.1` stabilise le domaine Khadhroony Solana sous `ks-*` / `KS_*` et remplace la configuration monolithique par des documents spécialisés composables, avec une frontière backend/public explicitement sanitisée.
La série `0.5.x` ne vise pas à étendre immédiatement la couverture protocolaire : elle migre d’abord les bibliothèques vers `ks-*`, puis stabilise `ks-config`, `ks-wallet`, `ks-store` et les frontières de scénarios afin d’éviter de devoir casser ces fondations après l’arrivée des protocoles trading. `0.6.x` introduira ensuite le décodeur Anchor générique avant la séquence Meteora/Raydium/Pump/Orca/Jupiter.
| `ks-logging` | bibliothèque | initialisation du logging et du tracing | README/TODO/USAGE/CHANGELOG présents |
| `ks-program-ids` | bibliothèque | registre des programmes et comptes Solana connus | README/TODO/USAGE/CHANGELOG présents |
@@ -19,7 +19,7 @@
| `ks-wallet` | bibliothèque | wallet temporaire et frontière de signataire | nom `ks-*` actif ; refonte `0.5.2` |
| `kb-app-demo-desktop` | bibliothèque + binaire | application de démonstration Tauri | documentée ; réconciliation en `0.5.4` |
La table décrit les noms physiques actifs depuis `0.5.1-pre.002`. La migration a renommé les dix crates généralistes en `ks-core`, `ks-config`, `ks-lib`, `ks-logging`, `ks-program-ids`, `ks-pipeline`, `ks-pipeline-demo-scenarios`, `ks-onchain-transport`, `ks-store` et `ks-wallet`. `kb-app-demo-desktop` conserve son nom parce qu’il appartient au domaine applicatif Bot. Voir [`../decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md`](../decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md).
La table décrit les noms physiques stabilisés par `0.5.1`. La migration a renommé les dix crates généralistes en `ks-core`, `ks-config`, `ks-lib`, `ks-logging`, `ks-program-ids`, `ks-pipeline`, `ks-pipeline-demo-scenarios`, `ks-onchain-transport`, `ks-store` et `ks-wallet`. `kb-app-demo-desktop` conserve son nom parce qu’il appartient au domaine applicatif Bot. Voir [`../decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md`](../decisions/KHADHROONY_SOLANA_NAMESPACE_POLICY.md).
@@ -48,7 +48,7 @@ Cette crate peut préparer des wallets temporaires, demander des airdrops, crée
Le binaire `ks-pipeline-demo-scenarios-cli` est actuellement un outil ciblé de préparation des fixtures SPL Token-2022 réutilisées par les démonstrations Devnet. Son existence ne signifie pas que chaque scénario doit être exposé par un CLI ni que le desktop doit consommer ses scénarios.
`kb-app-demo-desktop` conserve ses commandes Tauri, états, payloads et parcours de présentation Devnet/Testnet. La logique réutilisable de préparation et d’exécution de campagne appartient à `ks-pipeline-demo-scenarios`, renommée `ks-pipeline-demo-scenarios` en`0.5.1`. `0.5.4` auditera les scénarios encore déclarés directement dans le desktop et déplacera ceux qui sont réutilisables. La dépendance inverse de `ks-pipeline` vers les scénarios reste interdite et cette règle se conserve après migration vers `ks-pipeline`.
`kb-app-demo-desktop` conserve ses commandes Tauri, états, payloads et parcours de présentation Devnet/Testnet. La logique réutilisable de préparation et d’exécution de campagne appartient à `ks-pipeline-demo-scenarios`, dont le namespace `ks-*` est stabilisé depuis`0.5.1`. `0.5.4` auditera les scénarios encore déclarés directement dans le desktop et déplacera ceux qui sont réutilisables. La dépendance inverse de `ks-pipeline` vers les scénarios reste interdite et cette règle se conserve après migration vers `ks-pipeline`.
## 5. Contrats de preuve
@@ -57,5 +57,5 @@ Les tests unitaires, tests d’intégration et matrices de `test-fixtures/contra
## 6. Limites connues
- Le registre ElGamal n’est pas déclaré validé sur Devnet ou Mainnet.
- La réconciliation finale des scénarios encore dupliqués entre desktop et la future `ks-pipeline-demo-scenarios` est planifiée en `0.5.4`.
-Après `0.5.1`, les futurs protocoles doivent conserver cette frontière : orchestration généraliste dans `ks-pipeline`, scénarios réseau réutilisables dans `ks-pipeline-demo-scenarios`, adaptation UI/Tauri dans le desktop.
- La réconciliation finale des scénarios encore dupliqués entre le desktop et `ks-pipeline-demo-scenarios` est planifiée en `0.5.4`.
-Les futurs protocoles doivent conserver cette frontière : orchestration généraliste dans `ks-pipeline`, scénarios réseau réutilisables dans `ks-pipeline-demo-scenarios`, adaptation UI/Tauri dans le desktop.
@@ -59,7 +59,7 @@ Les noms de tables, contrats de replay et APIs publiques sont documentés dans `
- erreurs explicites ;
- séparation entre données brutes, résultats de décodage et matérialisations.
La série `0.5.3` normalisera cette fondation avant l’arrivée des protocoles trading. Elle doit notamment distinguer `slot`, `block_time` et les timestamps d’acquisition/persistance, normaliser la structure interne de la future `ks-store`, vérifier les champs et index manquants et préparer les futures matérialisations trading, routing et multi-pools sans perdre les contrats de provenance et d’idempotence.
La série `0.5.3` normalisera cette fondation avant l’arrivée des protocoles trading. Elle doit notamment distinguer `slot`, `block_time` et les timestamps d’acquisition/persistance, normaliser la structure interne de `ks-store`, vérifier les champs et index manquants et préparer les futures matérialisations trading, routing et multi-pools sans perdre les contrats de provenance et d’idempotence.
La même migration remplace le préfixe historique des tables Solana `kb_sol_*` par `k_sol_*`. La base peut encore être reconstruite ou migrée proprement avant `0.6.x`, il n’est donc pas nécessaire de conserver indéfiniment l’ancien préfixe. Le préfixe `kb_*` est réservé aux éventuelles tables dont la responsabilité appartient réellement au domaine applicatif Bot, pas aux faits Solana simplement consommés par le bot.
@@ -145,7 +145,7 @@ appartiennent à `execution.config.json`, avec les limites de dépense, frais, s
## Contrat runtime transitoire
Pendant `0.5.1`, `ks-config` reconstruit encore `AppConfig/ProfileConfig` afin de préserver les consommateurs backend existants. Il s'agit d'une projection runtime, pas d'un document source ni d'une surface de sortie. Depuis `pre.008`, ces contrats et les documents spécialisés susceptibles de contenir des valeurs résolues ne dérivent ni `serde::Serialize` ni `Debug`.
`ks-config` reconstruit encore `AppConfig/ProfileConfig` comme projection runtime transitoire afin de préserver les consommateurs backend existants. Il s'agit d'une projection runtime, pas d'un document source ni d'une surface de sortie. Depuis `0.5.1`, ces contrats et les documents spécialisés susceptibles de contenir des valeurs résolues ne dérivent ni `serde::Serialize` ni `Debug`.
Les fixtures de compatibilité sont sous `test-fixtures/config/`. Elles ne doivent pas être chargées en production.
@@ -163,11 +163,11 @@ La section `application` d'une composition est opaque à `ks-config`. Le desktop
## Frontière TS-RS
Depuis `pre.008`, `ks-config` et `ks-lib` ne dépendent plus de TS-RS et ne possèdent plus de bindings TypeScript générés. Les DTO traversant Tauri appartiennent à `kb-app-demo-desktop` ou à la future application concernée. Une exception dans une crate `ks-*` exige un contrat TypeScript générique indépendant de Tauri explicitement justifié et audité.
Depuis `0.5.1`, `ks-config` et `ks-lib` ne dépendent plus de TS-RS et ne possèdent plus de bindings TypeScript générés. Les DTO traversant Tauri appartiennent à `kb-app-demo-desktop` ou à la future application concernée. Une exception dans une crate `ks-*` exige un contrat TypeScript générique indépendant de Tauri explicitement justifié et audité.
## Étape suivante
`pre.009` est une prerelease de clôture : réconciliation documentaire, audits finaux, nettoyage des TODO, archivage du plan/prompt et préparation de`0.5.2`.
`0.5.1` clôt cette architecture de configuration. Les changements fonctionnels de wallet appartiennent à `0.5.2`, la normalisation SQL à `0.5.3` et l’audit final des scénarios/exécuteurs à`0.5.4`.
# 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`. 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, les compositions de binaires et les defaults autonomes. `pre.008` ferme maintenant les frontières source/runtime/public/diagnostic, la non-divulgation et TS-RS. `kb-app-demo-desktop` et le workspace racine restent nommés comme avant.
Après `pre.007-delta-fix-002`, 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 le 10 août 2026. `pre.008` peut donc modifier uniquement les frontières de sortie/configuration sans rouvrir le split structurel déjà validé.
## 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 :
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.
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.
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-*`.
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.*`
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.
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.
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é.
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-*`.
## 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 :
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 ;
- 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.
- **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.
La version `0.5.1` ferme la première restructuration de fondation décidée pendant `0.5.0` : namespaces Khadhroony Solana, configuration composable, séparation source/runtime/public et réduction de la surface TS-RS aux applications.
Elle ne modifie volontairement ni le préfixe SQL historique `kb_sol_*`, ni la structure fonctionnelle profonde de `ks-wallet`, ni la couverture protocolaire Solana/DEX.
## Namespace et ownership
La cible validée est :
- dix bibliothèques Solana généralistes sous `ks-*` / `ks_*` ;
-`kb-app-demo-desktop` conservé dans le domaine applicatif Bot ;
- identités techniques actives sous `ks-lib-decoder.*`, `ks-lib-executor.*` et `ks-lib-materializer.*` ;
- variables Solana sous `KS_*`, avec `KS_SECRET_*`, `KS_PUBLIC_*` et internes ;
-`KB_*` réservé aux contrats réellement possédés par une application Bot.
Le workspace, le dépôt et le répertoire racine restent volontairement nommés `khadhroony-bot3`.
## Configuration composable
La configuration source est répartie entre :
```text
config/
├── kb-app-demo-desktop.default.config.json
├── logging.config.json
├── transport.config.json
├── listeners.config.json
├── store.config.json
├── wallet.config.json
├── execution.config.json
├── exemples/
└── schemas/
```
Les documents spécialisés possèdent leurs defaults et profils indépendants. La composition d’un binaire sélectionne les documents et profils qu’il consomme sans obliger `ks-config` à connaître la structure métier de l’application.
`logs_directory` et `wallets_directory` sont globaux à leurs domaines respectifs. Les autorisations d’envoi appartiennent à la politique d’exécution. Les defaults de reconnexion WebSocket appartiennent au transport et peuvent être surchargés par endpoint.
## Frontières de sensibilité
La classification appliquée est :
```text
Secret > Internal > Public
```
Elle s’applique aussi aux valeurs composées après substitution des placeholders d’environnement.
Les contrats source/runtime susceptibles de contenir des valeurs résolues sensibles restent backend-only et ne dérivent ni `serde::Serialize` ni `Debug` par défaut.
Les snapshots de transport exposables ne transportent plus les URLs résolues. Les erreurs HTTP/WS et de validation ne recopient plus les valeurs rejetées, les corps HTTP distants ni les messages JSON-RPC distants susceptibles de réinjecter un credential.
## Tauri et TS-RS
`ks-config` et `ks-lib` ne produisent plus de bindings TS-RS.
Les contrats TypeScript/Tauri appartiennent à l’application consommatrice. `kb-app-demo-desktop` construit explicitement ses DTO publics et diagnostiques et ne retourne plus directement les contrats runtime `ks-*`.
Les canaris desktop et transport vérifient notamment :
- absence d’URL RPC/WS résolue dans les payloads ;
- absence de DSN PostgreSQL ;
- absence de chemin wallet/SQLite dans les payloads fonctionnels ;
- absence de secret canari dans les projections publiques/diagnostiques ;
-`Debug` sanitisé pour les clients/sessions transport.
## Validation opérateur du 10 août 2026
Après `0.5.1-pre.008-delta-fix-003`, l’opérateur a validé :
-`cargo fmt --all` ;
-`cargo check --workspace` ;
-`cargo clippy --all-targets` sans warning ;
-`python3 scripts/audit_rust_workspace_rules.py` avec audit Rust général propre, export completeness à zéro candidat et audit Khadhroony propre ;
-`cargo test --workspace` ;
-`cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json` avec chargement de la composition et initialisation des transports/store.
Les principales cibles unitaires observées après le dernier correctif comprennent :
-`kb-app-demo-desktop` : 165 tests ;
-`ks-config` : 31 tests, plus 2 tests d’API externe ;
-`ks-core` : 2 tests ;
-`ks-lib` : 606 tests, plus 9 tests d’intégration/API externe ;
-`ks-pipeline-demo-scenarios` : 105 tests bibliothèque, 1 test CLI et 1 test d’API externe ;
-`ks-program-ids` : 6 tests ;
-`ks-store` : 84 tests ;
-`ks-wallet` : 6 tests.
## Validation finale de `pre.009`
`0.5.1-pre.009` ne doit introduire aucun nouveau comportement fonctionnel. Après application du delta de clôture, la campagne standard doit être rejouée :
```bash
cargo fmt --all
cargo check --workspace
cargo clippy --all-targets
python3 scripts/audit_rust_workspace_rules.py
cargo test --workspace
```
Avant publication finale de `0.5.1`, le build desktop de release est recommandé afin de vérifier également TypeScript/Vite par la chaîne Tauri :
Ce rapport ne prétend pas que ce build de release a déjà été exécuté pour `0.5.1`.
## Reports
- restructuration fonctionnelle profonde du wallet : `0.5.2` ;
- migration `kb_sol_*` vers `k_sol_*` et normalisation temporelle/provenance : `0.5.3` ;
- centralisation finale des scénarios et audit des exécuteurs : `0.5.4` ;
- nouvelle qualification réseau ElGamal uniquement si une possibilité technique nouvelle apparaît.
## Traçabilité
Le plan temporaire `0.5.1` et le prompt de session `030` sont archivés sous `olddocs/archivekbot3/`. Les décisions durables restent dans le ROADMAP, les guides, les règles et la politique de namespace active.
## Statut
**Fondation fonctionnelle `0.5.1` prête pour la validation finale de la prerelease de clôture.**
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
