0.5.0-pre.002

Cargo.toml

@@ -1,5 +1,5 @@
 # file: Cargo.toml
-# version: 41
+# version: 42
 
 [workspace]
 resolver = "3"
@@ -18,7 +18,7 @@ members = [
 ]
 
 [workspace.package]
-version = "0.5.0-pre.1"
+version = "0.5.0-pre.2"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/khadhroony-bot3"

docs/README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/README.md -->
-<!-- version: 27 -->
+<!-- version: 28 -->
 
 # Documentation active de Khadhroony Bot3
 
@@ -103,6 +103,7 @@ Les preuves détaillées de `0.4.8-pre.*` restent accessibles sous `../olddocs/a
 ## 10. Plans de version actifs
 
 - [`Plan 0.5.0 — cadrage de la fondation 0.5.x`](plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md) : plan temporaire actif créé pendant `0.5.0-pre.001`, à maintenir jusqu’à la clôture de `0.5.0`.
+- [`Audit 0.5.0-pre.002 — configuration, logging, wallet et namespaces`](plans/V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md) : décisions de sécurité, split logging, namespace `KS_*`, migration wallet et audit du possible préfixe de crates `ks-*`.
 
 Le plan `0.4.8` reste archivé sous `../olddocs/archivekbot3/docs/plans/`.
 

docs/plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/V0_5_0_FOUNDATION_0_5_X_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Plan `0.5.0` — cadrage de la fondation `0.5.x`
 
@@ -11,7 +11,9 @@ Ce document est le livrable principal de `0.5.0-pre.001`.
 
 Le plan reste temporaire pendant le développement de `0.5.0`. Il doit être maintenu à chaque prerelease, puis archivé sous `olddocs/archivekbot3/` lors de la dernière prerelease, après transfert des décisions durables vers le ROADMAP, les règles, les guides et les documents de crates appropriés.
 
-**État de `pre.001` : plan proposé, à valider avant toute restructuration importante.**
+**État de `pre.001` : plan validé.**
+
+**État de `pre.002` : audit config/logging/wallet effectué ; les décisions détaillées sont consignées dans [`V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md`](V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md). Aucune restructuration fonctionnelle n'est encore appliquée.**
 
 ## 2. Base `0.4.8` à préserver
 
@@ -75,7 +77,9 @@ Le split futur ne doit pas être traité comme un simple déplacement de fichier
 
 `kb-config` et `kb-logging` possèdent actuellement des structures presque identiques `LoggingConfig`, `LogTargetConfig` et `LogTargetFilterConfig`. Le desktop les convertit manuellement dans `app_state.rs`.
 
-Cette duplication confirme l'existence d'une frontière à auditer en `0.5.1`, mais `pre.001` ne décide pas encore si le contrat source, le contrat runtime ou un adaptateur intermédiaire doit devenir canonique. La décision doit respecter la direction des dépendances du workspace et éviter de coupler `kb-config` au runtime de logging par commodité.
+`pre.002` confirme que le logging doit devenir un document et un schéma distincts de la configuration généraliste. Les profils logging doivent pouvoir évoluer indépendamment des profils réseau/applicatifs et la conversion manuelle du desktop doit disparaître lors de `0.5.1`.
+
+La propriété exacte du DTO source logging doit encore respecter la direction des dépendances : `kb-config` ne doit pas dépendre du runtime `kb-logging` par commodité. `0.5.1` devra choisir un propriétaire unique du contrat source et éviter une nouvelle crate si elle ne représente pas une responsabilité autonome.
 
 ### 5.3 `kb-wallet`
 
@@ -211,26 +215,35 @@ Ces écarts doivent être corrigés dans une prerelease documentaire de `0.5.0`
 
 ## 8. Préparation de `0.5.1` — `kb-config`
 
-### Questions à fermer avant code
+### Décisions fermées par `pre.002`
 
-1. Quel contrat sépare configuration source, configuration runtime résolue et vue publique redacted ?
+- toutes les variables d'environnement propres au projet devront utiliser le namespace `KS_*` ;
-2. Le logging doit-il être un fichier distinct, un sous-document distinct ou seulement un schéma distinct ?
+- `KS_SECRET_*` est strictement non exposable, y compris en debug/diagnostic ;
-3. Qui est propriétaire du shape source logging et qui est propriétaire du shape runtime ?
+- `KS_PUBLIC_*` est seulement candidate à une exposition explicitement autorisée par un DTO public ;
-4. Comment migrer l'actuel fichier unique sans casser les profils existants ?
+- autre `KS_*` reste interne et n'est visible que par un diagnostic explicite et borné ;
-5. Quelles valeurs sont des secrets explicites et quelles valeurs peuvent en contenir indirectement, par exemple une URL ?
+- toute valeur composée contenant un secret hérite de la classification `Secret` ;
-6. Comment interdire une sérialisation accidentelle d'un secret résolu ?
+- la configuration source, la configuration runtime résolue et les DTO publics/diagnostics doivent être des frontières distinctes ;
-7. Quels types ont réellement besoin d'être exportés via TS-RS ?
+- le logging doit être extrait dans un document et un schéma JSON indépendants ;
+- le profil logging doit pouvoir évoluer indépendamment du profil généraliste ;
+- la conversion manuelle `kb-config` -> `kb-logging` actuellement située dans le desktop doit disparaître ;
+- le renommage éventuel des crates `kb-*` -> `ks-*` doit être décidé transversalement avant de figer les nouveaux noms de types, chemins de bindings et exemples.
+
+L'audit a recensé 84 noms d'environnement actifs ou de fixture dans le code/configuration de référence : 67 `KB_*` et 17 sans namespace cible. La migration exacte est détaillée dans [`V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md`](V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md).
 
 ### Critères d'acceptation préparés
 
-- compatibilité ou migration explicite du format `0.4.8` ;
+- migration explicite du format `0.4.8` vers les documents séparés ;
-- schémas JSON distincts et synchronisés si la frontière est retenue ;
+- schémas JSON général et logging distincts et synchronisés avec leurs modèles ;
+- table exhaustive ancien nom d'environnement -> nouveau nom `KS_*` ;
+- refus des variables Khadhroony hors namespace `KS_*` après migration ;
 - tests des profils, defaults, validations croisées et erreurs ;
-- tests `.env`, `.env.local`, placeholders et fallbacks ;
+- tests `.env`, fichier dotenv sélectionné, placeholders et fallbacks ;
-- canaris secrets absents de tous les payloads publics, logs et erreurs ;
+- canaris `KS_SECRET_*` absents de tous les payloads publics, logs, diagnostics et erreurs ;
 - suppression du payload frontend de configuration résolue complète ;
+- aucun élargissement automatique de la surface publique uniquement parce que la build est debug ;
 - adaptation explicite de `kb-logging`, transport, pipeline, scénarios et desktop ;
 - aucune dépendance de `kb-store` vers `kb-config` ;
+- tests d'API externe de la façade `kb-config` avant changement structurel ;
 - documentation et exemples alignés.
 
 ## 9. Préparation de `0.5.2` — `kb-wallet`
@@ -345,16 +358,20 @@ Critère de sortie : plan complet et **validation explicite du plan avant toute
 
 ### `0.5.0-pre.002` — audit config/logging/wallet et contrats de sécurité
 
-Livrables prévus :
+Livrables réalisés :
 
-- inventaire exhaustif des consommateurs de `AppConfig`, `ProfileConfig`, structures logging et APIs wallet ;
+- inventaire des consommateurs de `AppConfig`, `ProfileConfig`, structures logging et APIs wallet ;
-- audit de tous les chemins de sérialisation, `Debug`, logs, erreurs, diagnostics et Tauri susceptibles de transporter un secret ;
+- audit des chemins de sérialisation, `Debug`, logs, erreurs, diagnostics et Tauri susceptibles de transporter un secret ;
+- confirmation du split logging en document + schéma indépendants ;
+- définition de la convention `KS_SECRET_*` / `KS_PUBLIC_*` / `KS_*` et de la propagation de sensibilité ;
+- inventaire de 84 contrats d'environnement actifs ou de fixture à migrer ;
 - audit des tests TS-RS et tests d'API externe manquants ;
 - caractérisation du format de configuration `0.4.8` et du format wallet `0.4.8` ;
 - dossier de migration `0.5.1` et `0.5.2` avec compatibilité, rollback et critères de non-divulgation ;
-- correction des documents de configuration rendus faux par l'audit, sans appliquer encore le nouveau format.
+- ouverture de l'audit transversal sur un éventuel namespace de crates `ks-*`, sans renommage prématuré ;
+- correction des documents de configuration rendus faux ou dangereux par l'audit, sans appliquer encore le nouveau format.
 
-Critère de sortie : aucune ambiguïté sur les frontières source/runtime/public de la configuration ni sur le contrat de migration wallet.
+Critère de sortie : frontières source/runtime/public fermées, namespace d'environnement cible défini, split logging confirmé et contrat de migration wallet borné. Le possible renommage de crates reste une décision transversale à fermer avant l'implémentation structurelle.
 
 ### `0.5.0-pre.003` — audit store/scénarios/desktop et contrats de préparation
 
@@ -467,6 +484,8 @@ Ne jamais lancer directement les scripts npm de développement ou build. Les com
 - les six surfaces ont un audit suffisamment précis pour leurs versions propriétaires ;
 - les contrats publics et formats persistés à migrer sont inventoriés ;
 - le chemin de fuite de configuration résolue est explicitement attribué à `0.5.1` avec critères de non-divulgation ;
+- le namespace d'environnement `KS_*` et les classes `Secret/Public/Internal` sont documentés avec propagation de sensibilité ;
+- le split logging en document et schéma indépendants est retenu comme cible de `0.5.1` ;
 - le format wallet `0.4.8` et ses exigences de migration sont documentés ;
 - le vocabulaire temporel/provenance/idempotence du store est défini avant tout schéma trading ;
 - la méthode d'audit decoder/executor/scenario/validation de `0.5.4` est fermée ;

docs/plans/V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md

@@ -0,0 +1,380 @@
+<!-- file: docs/plans/V0_5_0_PRE_002_CONFIG_LOGGING_WALLET_AUDIT.md -->
+<!-- version: 1 -->
+
+# Audit `0.5.0-pre.002` — configuration, logging, wallet et namespaces
+
+## 1. Objet
+
+Ce document complète le plan temporaire [`V0_5_0_FOUNDATION_0_5_X_PLAN.md`](V0_5_0_FOUNDATION_0_5_X_PLAN.md) avec l'audit approfondi prévu pour `0.5.0-pre.002`.
+
+Cette prerelease reste **non structurelle** : elle ferme les contrats à préparer pour `0.5.1` et `0.5.2`, mais ne scinde pas encore les fichiers de configuration, ne change pas les noms de variables d'environnement utilisés par le runtime, ne modifie pas le format wallet persistant et ne renomme aucune crate.
+
+## 2. Décisions de cadrage fermées
+
+### 2.1 Namespace des variables d'environnement
+
+Toutes les variables d'environnement appartenant à Khadhroony/Solana devront obligatoirement commencer par `KS_`.
+
+La convention cible comporte trois niveaux :
+
+- `KS_SECRET_*` : secret absolu, utilisable uniquement côté backend et jamais exposé, sérialisé, loggé ou inclus en clair dans une erreur, y compris en mode debug ou diagnostic ;
+- `KS_PUBLIC_*` : valeur explicitement candidate à l'exposition publique, mais seulement lorsqu'un DTO public l'autorise ;
+- autre `KS_*` : valeur interne, non exposée en fonctionnement normal et consultable uniquement par un diagnostic explicite et borné.
+
+Aucune variable hors namespace `KS_*` ne doit être lue comme contrat propre au projet après migration. Le runtime ne doit jamais énumérer l'environnement du processus pour décider automatiquement ce qui est exposable.
+
+Le préfixe ne remplace pas la politique de type : une valeur `KS_PUBLIC_*` n'est pas envoyée au frontend si aucun DTO public ne l'autorise, et une valeur issue d'un champ sémantiquement secret reste secrète même si son nom est mal classé.
+
+### 2.2 Propagation de la sensibilité
+
+La résolution d'un placeholder ne doit plus perdre son origine de sécurité.
+
+Si une chaîne composée contient au moins une valeur `KS_SECRET_*`, la chaîne résolue complète devient secrète. Exemple :
+
+```text
+https://mainnet.helius-rpc.com/?api-key=${KS_SECRET_HELIUS_API_KEY}
+```
+
+Le résultat complet doit être traité comme secret. La même règle s'applique aux DSN PostgreSQL et à toute autre composition.
+
+Ordre de dominance prévu pour une valeur composée :
+
+```text
+Secret > Internal/DebugOnly > Public
+```
+
+Une représentation publique doit être construite explicitement à partir du runtime ; elle ne doit jamais provenir d'une sérialisation complète suivie d'une suppression opportuniste de champs.
+
+### 2.3 Split de la configuration logging
+
+Le split du logging n'est plus une question ouverte : `0.5.1` devra extraire le logging du document général dans **un document et un schéma JSON distincts**.
+
+La cible minimale est donc :
+
+- un document de configuration général ;
+- un document de configuration logging ;
+- un schéma JSON général ;
+- un schéma JSON logging.
+
+Les profils généralistes et les profils logging doivent pouvoir évoluer indépendamment. Un profil réseau ne doit plus contenir une copie complète de toutes les routes logging.
+
+D'autres documents spécialisés ne seront ajoutés que si l'audit de `0.5.1` démontre une responsabilité, une validation ou un cycle de vie suffisamment indépendant ; le split ne doit pas devenir une fragmentation systématique.
+
+## 3. État réel de la configuration `0.4.8`
+
+### 3.1 Taille et duplication
+
+`config/example.config.json` représente environ 154 Ko.
+
+Les trois profils actifs (`local_devnet`, `mainnet_research`, `mainnet`) embarquent chacun un bloc logging d'environ 23 à 24 Ko. Ensemble, ces blocs représentent environ **70 Ko** de configuration, soit une part disproportionnée du document général.
+
+Les trois blocs ont la même structure et diffèrent principalement par :
+
+- les noms de routes associés au profil ;
+- les chemins sous `logs/<profil>/...` ;
+- quelques valeurs de niveau ou de sélection liées au profil.
+
+La séparation du logging est donc justifiée à la fois par la lisibilité, la maintenance et la réduction du couplage entre profil réseau et politique de tracing.
+
+### 3.2 Contrat public actuel
+
+`kb-config::ProfileConfig` contient directement :
+
+```text
+app
+logging
+database
+data
+solana
+wallet
+execution
+demo
+```
+
+`AppConfig`, `ProfileConfig` et toutes les sous-structures sont actuellement `Clone + Debug + Serialize + Deserialize + TS`.
+
+Les fonctions publiques `serialize_config_json` et `serialize_config_json_pretty` peuvent sérialiser la configuration runtime complète. Après résolution d'environnement, cette configuration peut contenir des secrets en clair.
+
+`DemoConfigPayload` clone aujourd'hui `AppConfig` et `ProfileConfig` complets et le frontend les affiche intégralement dans des JSON viewers avec copie activée. Cette surface doit disparaître dans `0.5.1` au profit d'un DTO public explicitement borné.
+
+### 3.3 Consommateurs actuels
+
+L'audit des onze crates confirme les principaux couplages suivants :
+
+- `AppConfig` est consommé directement par le desktop et `kb-pipeline-demo-scenarios` ;
+- `ProfileConfig` traverse le desktop, `kb-onchain-transport`, `kb-pipeline-demo-scenarios` et certaines fixtures/tests de `kb-pipeline` ;
+- les types logging de `kb-config` ne sont convertis vers `kb-logging` que par le desktop aujourd'hui ; cette conversion constitue donc un adaptateur applicatif accidentel à supprimer ;
+- `kb-wallet` est consommé principalement par `kb-pipeline-demo-scenarios` et quelques adaptations desktop ; les scénarios utilisent directement `TemporaryWallet`, `TemporaryWalletStore`, `WalletAlias`, `WalletSummary`, `as_signer()` et `as_sync_signer()`.
+
+Cette concentration permet de préparer des migrations bornées, mais `ProfileConfig` reste suffisamment diffus pour interdire un changement de shape sans phase de compatibilité/test.
+
+### 3.4 Résolution d'environnement actuelle
+
+`resolve_environment_placeholders` :
+
+- accepte n'importe quel nom dans `${NAME}` ;
+- lit directement `std::env::var(name)` ;
+- retourne une `String` ordinaire ;
+- ne conserve ni origine, ni visibilité, ni indicateur de secret ;
+- peut donc transformer une URL ou un DSN contenant un secret en simple chaîne indistinguable d'une valeur publique.
+
+Le futur resolver devra refuser les variables de projet hors namespace `KS_*` et conserver suffisamment de métadonnées pour empêcher la perte de sensibilité.
+
+## 4. Inventaire des contrats d'environnement
+
+L'audit du code, de `config/example.config.json`, de `.env.example` et des fichiers de fixture `.env` Token-2022 trouve **84 noms de variables/entrées de type environnement actuellement utilisés comme contrats actifs ou de fixture** :
+
+- 67 commencent par `KB_` ;
+- 17 ne commencent ni par `KB_` ni par `KS_` ;
+- aucune n'utilise encore le namespace cible `KS_`.
+
+Les variables non conformes comprennent notamment :
+
+- `HELIUS_API_KEY` ;
+- les familles `TOKEN_2022_*` ;
+- des entrées de fixture ElGamal/validity proof.
+
+Les guides opérateur contiennent en plus des variables shell historiques qui devront être réconciliées avec la même règle lors de la migration documentaire.
+
+### 4.1 Secrets certains
+
+Les contrats suivants doivent devenir explicitement secrets :
+
+- `HELIUS_API_KEY` -> cible de famille `KS_SECRET_HELIUS_*` ;
+- `KB_POSTGRES_MAINNET_URL` -> cible `KS_SECRET_POSTGRES_MAINNET_URL` ;
+- `KB_POSTGRES_DEVNET_URL` -> cible `KS_SECRET_POSTGRES_DEVNET_URL` ;
+- `KB_POSTGRES_TEST_URL` -> cible `KS_SECRET_POSTGRES_TEST_URL`.
+
+Une URL ou un DSN complet contenant l'un de ces secrets hérite de la classification `Secret` après résolution.
+
+### 4.2 Variables internes
+
+Les sélecteurs de profil, chemins, opt-ins de tests, confirmations opérateur, paramètres de campagnes et valeurs de fixture ne doivent pas être promus artificiellement en `KS_PUBLIC_*`. Par défaut, ils deviennent des `KS_*` internes.
+
+`KS_PUBLIC_*` doit rester réservé aux valeurs dont une exposition publique est réellement requise et testée.
+
+### 4.3 Migration
+
+`0.5.1` devra fournir une table de migration exhaustive ancien nom -> nouveau nom avant changement du runtime et de `.env.example`.
+
+La migration ne doit pas laisser le code lire durablement les anciens alias `KB_*`, `TOKEN_2022_*` ou `HELIUS_API_KEY`, car cela contredirait la règle du namespace unique. Si une compatibilité transitoire est nécessaire pendant une prerelease de migration, elle doit être explicitement bornée, détecter les conflits et être supprimée avant clôture de la version propriétaire.
+
+## 5. Frontières source / runtime / public
+
+Le futur contrat de `0.5.1` doit distinguer trois représentations conceptuelles.
+
+### 5.1 Source
+
+La représentation source conserve les documents utilisateur, les placeholders et les valeurs non résolues nécessaires à la validation/migration.
+
+Elle ne doit pas être confondue avec un objet sûr à afficher.
+
+### 5.2 Runtime
+
+La représentation runtime contient les valeurs effectivement utilisables par les consommateurs backend.
+
+Elle peut contenir des secrets résolus et ne doit donc pas dériver automatiquement une surface de sérialisation/TS-RS générale. Les champs sensibles connus doivent être encapsulés ou accompagnés d'une classification qui empêche `Debug`, sérialisation ou erreur accidentelle.
+
+### 5.3 Public/diagnostic
+
+Les DTO publics sont construits explicitement à partir du runtime :
+
+- vue publique normale : uniquement les champs autorisés et valeurs `KS_PUBLIC_*` nécessaires ;
+- diagnostic explicite : peut ajouter des valeurs `KS_*` internes sélectionnées ;
+- secrets : jamais de valeur, uniquement un état non secret tel que `configured: true` lorsque cela apporte une valeur opérateur.
+
+Le simple fait qu'une build Rust utilise `debug_assertions` ne doit pas élargir automatiquement la surface Tauri.
+
+## 6. Propriété du contrat logging
+
+### 6.1 Duplication actuelle
+
+`kb-config` et `kb-logging` exposent chacun :
+
+- `LoggingConfig` ;
+- `LogTargetConfig` ;
+- `LogTargetFilterConfig`.
+
+Leurs champs sont pratiquement identiques. `kb-app-demo-desktop/src/app_state.rs` effectue une conversion champ par champ avant `kb_logging::init_logging`.
+
+`kb-logging::LogFileRoute` n'a aucun consommateur actif hors de `kb-logging` et constitue un contrat legacy à réévaluer pendant la migration.
+
+### 6.2 Direction de dépendance à préserver
+
+`kb-config` ne doit pas dépendre du runtime logging simplement pour réutiliser ses types.
+
+La solution de `0.5.1` devra choisir un propriétaire unique du contrat source logging et supprimer la conversion manuelle du desktop. Deux solutions restent architecturalement acceptables avant implémentation :
+
+1. `kb-config` possède le DTO source logging séparé et `kb-logging` le consomme directement ou via un adaptateur propriétaire du runtime ;
+2. une frontière de configuration logging est déplacée dans une surface dédiée sans faire dépendre la configuration générale de l'initialisation `tracing`.
+
+Le choix final doit minimiser la duplication sans réintroduire une crate artificielle si elle n'apporte pas de responsabilité autonome.
+
+## 7. Audit `kb-wallet`
+
+### 7.1 Points déjà solides
+
+Le wallet actuel protège correctement plusieurs frontières :
+
+- `TemporaryWallet` ne dérive ni `Serialize` ni `Clone` ;
+- son implémentation `Debug` n'affiche que l'alias, la clé publique et le chemin ;
+- les octets du keypair restent privés ;
+- les buffers temporaires de lecture/écriture sont zeroized ;
+- les fichiers existants ne sont pas écrasés ;
+- les liens symboliques et permissions trop ouvertes sont refusés ;
+- `as_signer()` et `as_sync_signer()` fournissent la capacité de signature sans exposer les octets.
+
+### 7.2 Contrat persistant à migrer
+
+Le format `0.4.8` est un contrat réel :
+
+```text
+<alias>.json
+```
+
+contient le tableau JSON standard du keypair Solana, sans enveloppe de version et sans chiffrement applicatif.
+
+`0.5.2` devra donc traiter ce format comme **legacy importable**, et non le modifier in-place sans stratégie.
+
+### 7.3 Exigences de migration `0.5.2`
+
+Avant implémentation, le design devra préciser :
+
+- format versionné du nouveau conteneur ;
+- détection sûre du format legacy ;
+- import sans perte de clé publique ;
+- écriture atomique du nouveau format avant suppression éventuelle de l'ancien ;
+- rollback après échec ;
+- corruption et mauvais secret de déverrouillage ;
+- séparation identité / secret / état verrouillé / capacité de signer ;
+- absence de secret dans config, logs, erreurs, Tauri et backup metadata ;
+- politique d'import/export et sauvegarde/restauration si ces capacités sont retenues.
+
+Aucun mot de passe ou matériau de déchiffrement ne devra être stocké dans la configuration générale. Une automatisation non interactive éventuelle devra utiliser une source secrète dédiée, classée `KS_SECRET_*`.
+
+## 8. Tests d'API externe manquants
+
+Le workspace possède des tests d'API externe pour `kb-lib`, `kb-pipeline` et une partie de `kb-pipeline-demo-scenarios`, mais aucun dossier `tests/` équivalent pour `kb-config`, `kb-logging` ou `kb-wallet`.
+
+Avant les refactors propriétaires, il faudra ajouter des tests de caractérisation externes couvrant au minimum :
+
+### `kb-config`
+
+- chargement du format `0.4.8` de référence ;
+- profil actif et invariants publics ;
+- contrat de schéma embarqué ;
+- migration vers les documents séparés ;
+- refus des variables de projet hors `KS_*` ;
+- canaris `KS_SECRET_*` absents de toute vue publique, erreur et diagnostic.
+
+Ces tests ne doivent pas figer la sérialisation dangereuse actuelle d'une configuration résolue complète.
+
+### `kb-logging`
+
+- initialisation depuis le futur contrat source canonique ;
+- conservation des routes/niveaux/filtres/formats ;
+- migration sans dépendance au desktop.
+
+### `kb-wallet`
+
+- lecture d'une fixture legacy `0.4.8` ;
+- identité de clé publique après migration ;
+- corruption, permissions et atomicité ;
+- absence de secret dans `Debug` et surfaces publiques ;
+- tests de lock/unlock seulement après choix du format chiffré.
+
+## 9. Audit du possible renommage `kb-*` -> `ks-*`
+
+La demande de namespace `KS_` pour l'environnement ouvre légitimement la question du nom des crates généralistes. Cette question ne doit cependant pas être traitée par remplacement global.
+
+### 9.1 Crates candidates
+
+Les responsabilités actuelles rendent les crates suivantes plausiblement généralistes Solana et donc candidates à un préfixe `ks-*` si le renommage est retenu :
+
+- `kb-core` ;
+- `kb-config` ;
+- `kb-lib` ;
+- `kb-logging` ;
+- `kb-program-ids` ;
+- `kb-pipeline` ;
+- `kb-onchain-transport` ;
+- `kb-store` ;
+- `kb-wallet`.
+
+`kb-pipeline-demo-scenarios` doit être classée séparément : sa logique est réutilisable et non spécifique au frontend, mais son rôle de validation/scénarios peut justifier un nom différent de la simple substitution de préfixe.
+
+`kb-app-demo-desktop` reste clairement une application Khadhroony Bot et n'est pas candidate au même renommage automatique.
+
+### 9.2 Namespaces à ne pas confondre
+
+Un éventuel renommage de packages Cargo touche plusieurs espaces de noms distincts :
+
+1. nom de répertoire ;
+2. nom `[package]` Cargo ;
+3. identifiant Rust (`kb_config` -> éventuellement `ks_config`) ;
+4. chemins TS-RS/bindings ;
+5. targets `tracing` ;
+6. noms de binaires/CLI ;
+7. identités persistées de décodeurs, matérialiseurs et exécuteurs ;
+8. préfixes SQL et noms de tables.
+
+Ces couches ne doivent pas être renommées en bloc.
+
+En particulier :
+
+- les tables `kb_sol_*` sont des contrats SQL publiés et ne doivent pas changer de nom du seul fait d'un renommage Cargo ;
+- les identités telles que `kb-lib.decoder.*`, `kb-lib.materializer.*` et `kb-lib.executor.*` peuvent être persistées dans le ledger, les événements ou les clés d'idempotence ; leur changement exige un audit de migration propre ;
+- les targets `tracing` peuvent être renommés séparément, mais cela impose une migration du document logging et de ses filtres.
+
+### 9.3 Décision à prendre avant implémentation structurelle
+
+Avant de lancer `0.5.1`, la clôture de `0.5.0` devra statuer sur l'une des stratégies suivantes :
+
+- conserver `kb-*` comme namespace historique pour toutes les crates ;
+- renommer uniquement les packages/libs réellement généralistes en `ks-*`, en laissant les applications `kb-*` ;
+- planifier un chantier de renommage dédié dans le ROADMAP si l'impact est trop transversal pour être absorbé proprement par `0.5.1`.
+
+Aucun renommage n'est livré par `pre.002`.
+
+## 10. Dossier de migration préparé pour `0.5.1`
+
+`0.5.1` devra au minimum :
+
+1. introduire le namespace `KS_*` et la classification Secret/Public/Internal ;
+2. fournir la table exhaustive de renommage des variables actuelles ;
+3. remplacer le resolver non typé par une résolution conservant la sensibilité ;
+4. séparer la configuration générale et la configuration logging en deux documents et deux schémas ;
+5. supprimer `logging` de chaque `ProfileConfig` généraliste ;
+6. rendre la sélection du profil logging indépendante du profil général ;
+7. supprimer la duplication de types logging ou la conversion manuelle desktop ;
+8. séparer source, runtime et DTO publics/diagnostics ;
+9. retirer `AppConfig`/`ProfileConfig` complets des payloads Tauri ;
+10. ajouter les tests de migration `0.4.8` -> nouveau format et les canaris de non-divulgation.
+
+Le détail des noms de fichiers et types Rust sera fixé dans la première prerelease d'implémentation de `0.5.1`, après décision sur le namespace de crates.
+
+## 11. Dossier de migration préparé pour `0.5.2`
+
+`0.5.2` devra :
+
+1. caractériser le format legacy `0.4.8` par fixture externe ;
+2. définir un conteneur wallet versionné avant chiffrement ;
+3. séparer identité, secret, état de verrouillage et capacité de signer ;
+4. définir migration/rollback atomiques ;
+5. conserver les capacités `Signer` nécessaires aux exécuteurs sans exposer le secret ;
+6. interdire toute propagation de secret vers config/logging/Tauri ;
+7. ajouter import/export, backup/restore et multi-wallet uniquement avec contrats de sécurité et tests correspondants.
+
+## 12. Critère de sortie de `pre.002`
+
+La prerelease peut être considérée comme cadrée lorsque :
+
+- le split logging document + schéma séparés est accepté comme cible ;
+- la convention `KS_SECRET_*` / `KS_PUBLIC_*` / `KS_*` est normative pour la migration ;
+- la propagation de sensibilité des valeurs composées est requise ;
+- les surfaces source/runtime/public sont distinctes ;
+- le format wallet legacy et sa stratégie de migration sont explicitement bornés ;
+- les tests externes manquants sont identifiés ;
+- le possible renommage `kb-*` -> `ks-*` est isolé comme décision transversale, sans toucher les identités persistées ou SQL par accident.
+
+La prochaine prerelease prévue reste `0.5.0-pre.003`, consacrée à `kb-store`, aux scénarios et au desktop.

kb-config/CHANGELOG.md

@@ -1,8 +1,15 @@
 <!-- file: kb-config/CHANGELOG.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 
 # CHANGELOG — kb-config
 
+## `0.5.0-pre.002`
+
+- confirme pour `0.5.1` le split de la configuration générale et du logging en documents et schémas distincts ;
+- fixe la convention cible `KS_SECRET_*` / `KS_PUBLIC_*` / `KS_*` pour les variables d’environnement propres au projet ;
+- documente la séparation future source/runtime/public et interdit l’usage diagnostic du JSON résolu complet ;
+- précise les tâches de migration, tests externes et non-divulgation sans modifier encore le contrat runtime `0.4.8`.
+
 ## 0.4.6
 
 - alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;

kb-config/README.md

@@ -1,5 +1,5 @@
 <!-- file: kb-config/README.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # kb-config
 
@@ -31,7 +31,7 @@ Les principales fonctions sont `read_config_json_file_with_environment`, `parse_
 
 ## Statut
 
-La configuration actuelle est fonctionnelle et validée. Un futur découpage de la configuration générale et du logging est prévu en `0.5.x` afin de réduire les duplications entre profils.
+La configuration actuelle est fonctionnelle et validée, mais son format `0.4.8` reste monolithique. Le cadrage `0.5.0-pre.002` confirme que `0.5.1` séparera la configuration générale et le logging en documents et schémas distincts, introduira le namespace d’environnement `KS_*` et séparera les représentations source, runtime et publiques afin qu’aucun secret résolu ne soit exposé.
 
 ## Documents
 

kb-config/TODO.md

@@ -1,15 +1,20 @@
 <!-- file: kb-config/TODO.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # TODO — kb-config
 
 ## Série `0.5.x`
 
-- [ ] Configuration - décider si la configuration doit être scindée en deux ou trois fichiers.
+- [ ] `0.5.1` - séparer la configuration générale et le logging en documents et schémas JSON distincts.
-- [ ] Configuration - extraire les blocs de logging dupliqués entre profils vers une configuration dédiée.
+- [ ] `0.5.1` - rendre la sélection du profil logging indépendante du profil généraliste.
-- [ ] Configuration - alléger la configuration générale sans casser les invariants existants.
+- [ ] `0.5.1` - définir un propriétaire unique du contrat source logging et supprimer la conversion manuelle du desktop.
-- [ ] Migration - définir une stratégie explicite pour les fichiers de configuration actuels.
+- [ ] `0.5.1` - migrer toutes les variables d’environnement propres au projet vers le namespace `KS_*`.
-- [ ] Contrat - maintenir l’identité entre le schéma embarqué et `config/schema.config.json`.
+- [ ] `0.5.1` - appliquer les classes `KS_SECRET_*`, `KS_PUBLIC_*` et `KS_*` interne avec propagation de sensibilité aux valeurs composées.
-- [ ] Tests - ajouter les tests de migration et de compatibilité du futur format multi-fichiers.
+- [ ] `0.5.1` - séparer les représentations source, runtime résolue, publique et diagnostic.
-- [ ] Documentation - mettre à jour les guides et exemples après implémentation.
+- [ ] `0.5.1` - interdire qu’un secret résolu soit sérialisé, loggé, inclus dans une erreur ou transmis via Tauri.
-- [ ] Intégration - coordonner la migration avec `kb-logging` et les crates consommatrices.
+- [ ] `0.5.1` - supprimer l’exposition frontend de `AppConfig` et `ProfileConfig` résolus complets.
+- [ ] Migration - fournir une table exhaustive des anciens noms d’environnement vers `KS_*` et une stratégie explicite pour le format `0.4.8`.
+- [ ] Contrat - maintenir l’identité entre chaque schéma embarqué et son fichier sous `config/`.
+- [ ] Tests - ajouter les tests d’API externe, de migration multi-fichiers et les canaris de non-divulgation.
+- [ ] Documentation - mettre à jour guides, exemples et `.env.example` seulement avec l’implémentation correspondante.
+- [ ] Intégration - coordonner la migration avec logging, transports, pipeline, scénarios et applications.

kb-config/USAGE.md

@@ -1,5 +1,5 @@
 <!-- file: kb-config/USAGE.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Utilisation de kb-config
 
@@ -35,7 +35,7 @@ for path in report.loaded_files {
 }
 ```
 
-`EnvironmentLoadReport` indique les fichiers chargés. Les placeholders non résolus sans fallback restent visibles afin que la validation ou le consommateur puisse les signaler explicitement.
+`EnvironmentLoadReport` indique les fichiers chargés. Les placeholders non résolus sans fallback restent visibles afin que la validation ou le consommateur puisse les signaler explicitement. Le format `0.4.8` accepte encore les anciens noms d’environnement ; la migration `0.5.1` imposera le namespace `KS_*`.
 
 ## Résolution explicite des placeholders
 
@@ -46,7 +46,7 @@ let resolved = kb_config::resolve_environment_placeholders(raw);
 assert!(resolved.contains("databaseUrl"));
 ```
 
-Cette API est utile pour un outil de diagnostic qui veut afficher le JSON résolu avant parsing.
+Cette API retourne actuellement une chaîne résolue ordinaire et peut donc contenir des secrets issus de l’environnement. Elle doit rester strictement backend et ne doit pas être utilisée pour afficher, logger ou transmettre le JSON résolu. `0.5.1` remplacera cette frontière par une résolution conservant la classification de sensibilité.
 
 ## Validation et parsing
 

kb-logging/CHANGELOG.md

@@ -1,8 +1,14 @@
 <!-- file: kb-logging/CHANGELOG.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 
 # CHANGELOG — kb-logging
 
+## `0.5.0-pre.002`
+
+- confirme le futur document et schéma logging indépendants de la configuration généraliste ;
+- identifie la duplication `LoggingConfig`/`LogTargetConfig`/`LogTargetFilterConfig` avec `kb-config` et la conversion manuelle du desktop comme dette à supprimer en `0.5.1` ;
+- classe `LogFileRoute` comme contrat legacy sans consommateur actif à réévaluer avant restructuration.
+
 ## 0.4.6
 
 - alignement de la crate sur la version fonctionnelle bot3 `0.4.6` ;

kb-logging/README.md

@@ -1,5 +1,5 @@
 <!-- file: kb-logging/README.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # kb-logging
 
@@ -16,7 +16,7 @@
 
 ## Hors périmètre
 
-La crate ne charge pas le fichier de configuration et ne définit pas les targets des autres crates. `kb-config` fournit les valeurs et chaque crate publie son propre target canonique.
+La crate ne charge pas actuellement le fichier de configuration et ne définit pas les targets des autres crates. Le cadrage `0.5.0-pre.002` confirme qu’un document logging séparé sera introduit en `0.5.1`; la propriété exacte du DTO source sera fixée sans faire dépendre la configuration générale du runtime tracing.
 
 ## API publique
 

kb-logging/TODO.md

@@ -1,11 +1,14 @@
 <!-- file: kb-logging/TODO.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # TODO — kb-logging
 
 ## Série `0.5.x`
 
-- [ ] Configuration - définir avec `kb-config` le contrat de la configuration logging séparée.
+- [ ] `0.5.1` - consommer un document logging et un schéma distincts de la configuration généraliste.
-- [ ] Compatibilité - préserver targets, niveaux, filtres, formats et routes pendant la migration.
+- [ ] `0.5.1` - définir avec `kb-config` un propriétaire unique du DTO source logging sans coupler `kb-config` au runtime tracing.
-- [ ] Tests - ajouter les tests de migration du format de configuration.
+- [ ] `0.5.1` - supprimer la conversion champ par champ actuellement portée par le desktop.
+- [ ] Compatibilité - préserver targets, niveaux, filtres, formats, routes et sémantique wildcard pendant la migration.
+- [ ] Contrat - réévaluer `LogFileRoute`, actuellement sans consommateur actif hors de la crate.
+- [ ] Tests - ajouter les tests d’API externe et de migration du futur format logging.
 - [ ] Documentation - mettre à jour les exemples après implémentation du nouveau chargement.

kb-wallet/CHANGELOG.md

@@ -1,8 +1,14 @@
 <!-- file: kb-wallet/CHANGELOG.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # CHANGELOG — kb-wallet
 
+## `0.5.0-pre.002`
+
+- caractérise le format persistant `0.4.8` comme format legacy à importer plutôt qu’à modifier in-place ;
+- prépare pour `0.5.2` un conteneur versionné, une migration atomique/rollback et la séparation identité/secret/verrouillage/signature ;
+- renforce le TODO sur l’absence de propagation de secrets vers configuration, logs, erreurs, diagnostics ou Tauri.
+
 ## `0.4.8-pre.013`
 
 - `pre.013-delta-fix-021` ajoute `TemporaryWallet::as_sync_signer()` afin de préserver le marqueur `Sync` du `solana_keypair::Keypair` lorsque le signataire traverse un futur async qui doit être `Send` ;

kb-wallet/TODO.md

@@ -1,18 +1,19 @@
 <!-- file: kb-wallet/TODO.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # TODO — kb-wallet
 
 ## Série `0.5.x`
 
-- [ ] Fonctionnalité - gérer plusieurs wallets persistants.
+- [ ] `0.5.2` - caractériser le format legacy `<alias>.json` contenant le tableau JSON standard du keypair Solana.
-- [ ] Fonctionnalité - ajouter la sélection et la persistance du wallet actif.
+- [ ] `0.5.2` - définir un conteneur persistant versionné avant d’introduire le chiffrement.
-- [ ] Sécurité - ajouter le chiffrement et le déchiffrement protégés par mot de passe.
+- [ ] `0.5.2` - séparer identité publique, matériau secret, état verrouillé/déverrouillé et capacité de signature.
-- [ ] Sécurité - ajouter le changement de mot de passe.
+- [ ] Migration - définir import legacy, écriture atomique, rollback et conservation de la clé publique.
-- [ ] Sécurité - ajouter le verrouillage et le déverrouillage explicites.
+- [ ] Fonctionnalité - gérer plusieurs wallets persistants et la sélection du wallet actif si retenue.
-- [ ] Fonctionnalité - ajouter l’import et l’export contrôlés.
+- [ ] Sécurité - ajouter chiffrement/déchiffrement et changement de secret seulement après validation du format.
-- [ ] Fonctionnalité - ajouter la sauvegarde et la restauration.
+- [ ] Sécurité - ajouter verrouillage/déverrouillage explicites et invalidation de session.
-- [ ] Sécurité - définir les politiques de stockage, session et autorisation de signature.
+- [ ] Fonctionnalité - ajouter import/export, sauvegarde/restauration avec contrats de sécurité explicites.
-- [ ] Intégration - relier la sélection du wallet aux profils et signers.
+- [ ] Sécurité - interdire tout secret wallet dans config générale, logs, erreurs, diagnostics ou Tauri.
-- [ ] Tests - ajouter les tests de corruption, concurrence et récupération.
+- [ ] Intégration - relier la sélection du wallet aux profils et signers sans exposer les octets secrets.
+- [ ] Tests - ajouter une API externe de caractérisation, corruption, concurrence, récupération et migration.
 - [ ] Documentation - produire un guide de sécurité avant tout usage hors démonstration.

olddocs/archivekbot3/docs/audits/V0_4_8_PRE_015_METADATA_TRANSVERSAL_RECONCILIATION_AUDIT.md

@@ -32,14 +32,14 @@ Metaplex Token Metadata, Token-2022 Token Metadata et Solana Program Metadata n
 
 Les matrices actives restent cohérentes entre elles :
 
-| Matrice | Inventaire |
+| Matrice              |                          Inventaire |
-|---|---:|
+|----------------------|------------------------------------:|
-| comptes | 3 entrées |
+| comptes              |                           3 entrées |
-| instructions stables | 9 |
+| instructions stables |                                   9 |
-| exécuteur | 9 opérations |
+| exécuteur            |                        9 opérations |
-| matérialisation | 2 snapshots + 9 faits d’instruction |
+| matérialisation      | 2 snapshots + 9 faits d’instruction |
-| pipeline | 9 opérations |
+| pipeline             |                        9 opérations |
-| validation Devnet | 9 opérations `confirmed` |
+| validation Devnet    |            9 opérations `confirmed` |
 
 La matrice Devnet conserve `0.4.8-pre.009` comme milestone propriétaire du contrat de scénarios, tandis que ses preuves pointent vers la campagne réelle `pre.010`. Ce découpage est codé explicitement dans le validateur et n’est pas une divergence à corriger.
 

olddocs/archivekbot3/docs/plans/V0_4_8_SOLANA_PROGRAM_METADATA_AND_TOKEN_2022_COMPLETENESS_PLAN.md

@@ -15,13 +15,13 @@ Il doit être maintenu pendant chaque prerelease, puis archivé pendant la derni
 
 ### 2.1 Surfaces strictement distinctes
 
-| Surface                           | Program ID ou frontière                                            | Rôle dans `0.4.8`                                                               |
+| Surface                           | Program ID ou frontière                                            | Rôle dans `0.4.8`                                                                                  |
-|-----------------------------------|--------------------------------------------------------------------|---------------------------------------------------------------------------------|
+|-----------------------------------|--------------------------------------------------------------------|----------------------------------------------------------------------------------------------------|
 | Metaplex Token Metadata           | `metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s`                      | surface héritée de `0.4.7`, réauditée et qualifiée à 15 `confirmed` / 5 `unavailable` en `pre.013` |
-| Token-2022 Token Metadata         | programme Token-2022 `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` | complétude livrée en `pre.011` et validée sur Devnet en `pre.012`                |
+| Token-2022 Token Metadata         | programme Token-2022 `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` | complétude livrée en `pre.011` et validée sur Devnet en `pre.012`                                  |
-| `spl-token-metadata-interface`    | interface sans Program ID autonome imposé                          | source contractuelle des instructions metadata implémentées par Token-2022      |
+| `spl-token-metadata-interface`    | interface sans Program ID autonome imposé                          | source contractuelle des instructions metadata implémentées par Token-2022                         |
-| Solana Program Metadata           | `ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S`                      | surface complète livrée de `pre.003` à `pre.010`, avec neuf opérations Devnet `confirmed` |
+| Solana Program Metadata           | `ProgM6JCCvbYkfKqJYHePx4xxSUSqJp7rh8Lyv7nk7S`                      | surface complète livrée de `pre.003` à `pre.010`, avec neuf opérations Devnet `confirmed`          |
-| contenu distant HTTP/IPFS/Arweave | transport off-chain indépendant                                    | hors `0.4.8`, reporté à l’horizon `0.15+`                                       |
+| contenu distant HTTP/IPFS/Arweave | transport off-chain indépendant                                    | hors `0.4.8`, reporté à l’horizon `0.15+`                                                          |
 
 Aucun décodeur Token-2022 existant n’est un décodeur partiel de `ProgM6…`. Les deux contrats doivent conserver des namespaces, modèles, matrices, tests et scénarios distincts.